说.
  • 2019-07-24 20:48:58 103.226.196.* 对s**e说:
    复制度来源:性能,可用性,扩展性

    1. 软件系统在发布后还可以不断地修改和演
      进,这就意味着不断有新的需求需要实现。如果新需求能够不改代码甚至少改代码就可以实现,
      那当然是皆大欢喜的,否则来一个需求就要求系统大改一次,成本会非常高,程序员心里也不爽
      (改来改去),产品经理也不爽(做得那么慢),老板也不爽(那么多人就只能干这么点事)。
      因此作为架构师,我们总是试图去预测所有的变化,然后设计完美的方案来应对,当下一次需求
      真正来临时,架构师可以自豪地说:这个我当时已经预测到了,架构已经完美地支持,只需要一
      两天工作量就可以了!
      oo[129] xx[0] 2019-07-24 20:50:02
    2. 设计具备良好可扩展性的系统,有两个基本条件:正确预测变化、完美封装变化。但要达成这两
      oo[135] xx[0] 2019-07-24 20:50:23
    3. 可扩展性:变化/稳定
      coc/dry都有助于可扩展性.
      oo[112] xx[0] 2019-07-24 20:54:26
    4. 另外三个来源:成本/安全/规模
      oo[118] xx[0] 2019-07-24 20:55:30

    赞(140) 查看 回复
  • 2019-07-24 20:45:17 103.226.196.* 对s**e说:
    高可用相对复杂。
    高性能,不管通过什么方式,或多或少,性能总获提高,行为上非必须做;高可用必须做,
    因为系统宕机或数据丢失时,谈高性能也无意义。
    高可用涉及分布式存储和分布式计算,这两课题本身就复杂。
    高可用涉及的非技术因素,如自然,政治

    1. 2,高可用的监控十分的重要,只有能先发现问题,才能接下来处理问题。
      oo[168] xx[0] 2019-07-24 20:47:47

    赞(121) 查看 回复
  • 2019-07-24 20:44:09 103.226.196.* 对s**e说:
    核心思想:网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件
    部署在多台服务器上;数据存储在多台服务器上互相备份。通过上述技术手段,当任何一台
    服务器宕机或出现各种不可预期的问题时,就将相应的服务切换到其他可用的服务器上,不
    影响系统的整体可用性,也不会导致数据丢失。
    从架构角度看可用性:当前网站系统多采用经典的分层模型,从上到下为:应用层、服务层
    与数据层。应用层主要实现业务逻辑处理;服务层提供可复用的服务;数据层负责数据读
    写;在部署架构上常采用应用和数据分离部署,应用会部署到不同服务器上,这些服务器被
    称为应用层的服务器;这些可复用的服务也会各自部署在不同服务器上,称为服务层的服务
    器;而各类数据库系统、文件柜等数据则部署在数据层的服务器。
    硬件故障方面引起不可用的技术解决措施:(1)应用服务器。可通过负载均衡设备将多个应用
    服务器构建为集群对外提供服务(前提是这些服务需要设计为无状态,即应用服务器不保存
    业务的上下文信息,而仅根据每次请求提交的数据进行业务逻辑的操作响应),当均衡设备
    通过心跳检测手段检测到应用服务器不可用时,则将其从集群中移除,并将请求切换到其他
    可用的应用服务上。(2)服务层服务器。这些服务器被应用层通过分布式服务框架(如Dubb
    o)访问,分布式服务框架可在应用层客户端程序中实现软件负载均衡,并通过服务注册中心
    提供服务的服务器进行心跳检测,当发现有服务器不可用时,立即通知客户端程序修改服务
    列表,同时移除响应的服务器。(3)数据服务器。需要在数据写入时进行数据同步复制
    赞(117) 查看 回复
  • 2019-07-24 19:33:58 77.243.191.* 对E**i说:
    Invest $ 5,000 in cryptocurrency once and get $ 70,000 passive income per month: https://tiny.cc/z9j39y?y4KZDcormHjNp6
    赞(113) 查看 回复
  • 2019-07-24 19:32:46 117.139.255.* 对h*说:
    同意有个同学的回复,仅拿服务注册这一点来比较其实是不公平的。新技术出来是解决问题的,并且从理念来说,将与业务无关的微服务的功能拆分到通用的sidecar这一点本身就是趋势,也是更为自然的一种选择,让专业的人做专业的事情,开发人员做好业务开发,微服务框架和治理交给service mesh,各得其所。
    赞(111) 查看 回复

  • 关于本站 @ 2018 | 川公网安备 51092202000218号 蜀ICP备16026747号