05 | 复杂度来源：高可用

精选留言(109)

• 

  公号-代码荣耀

  今日心得
  
  需求驱动驱动；而高可用与高性能，是架构设计中两个非常重要的决策因素。因此，面对不同业务系统的不同需求，对高可用与高性能也会有不同的决策结论，其实现的复杂度也各不相同。支付宝业务，对于可用性和性能就会有很高的要求，在可用性方面希望能提供7＊24不间断服务，在高性能方面则希望能实时收付款；而对于一个学生管理系统，在可用性与性能方面就不一定要有多高的要求，比如晚上可关机，几秒内能查询到信息也可接受。为此，高可用性与高性能的复杂度讨论需要结合业务需求。
  
  1 WHAT - 什么是可用性？
  定义可用性，可以先定义什么是不可用。需要经历若干环节，网站的页面才能呈现在最终的用户面前；而其中的任何一个环节出现了故障，都可能会导致网站的页面不可访问，也就是出现了网站不可用的情况。昨夜iOS版本QQ出现大面积闪退就是一个系统不可用的典型案例。
  
  我们可以利用百分比来对网站可用性进行度量：
  网站不可用时间=完成故障修复的时间点 - 故障发现的时间点
  网站年度可用时间=年度总时间 - 网站不可用时间
  网站年度可用性=(网站年度可用时间/年度总时间) x 100%
  
  举例：一些知名大型网站的可用性可达到99.99%（俗称4个9），我们可以算一下一年下来留给处理故障的时间有多少？
  年度总时间=365*24*60=525600分钟
  网站不可用时间=525600*(1-99.99%)=52.56分钟
  也就是，如果网站要达到4个9的可用性，一年下来网站不可用时间最多53分钟（也就是不足1个小时）。
  
  可见，高可用性就是技术实力的象征，高可用性就是竞争力。
  
  2 WHY - 为什么会出现不可用？
  硬件故障。网站多运行在普通的商用服务器，而这些服务器本身就不具备高可用性，再加之网站系统背后有数量众多服务器，那么一定时间内服务器宕机是大概率事件，直接导致部署在该服务器上的服务受影响。
  
  软件BUG或网站更新升级发布。BUG不能消灭，只能减少；上线后的系统在运行过程中，难免会出现故障，而这些故障同样直接导致某些网站服务不可用；此外，网站更新升级发布也会引起相对较频繁的服务器宕机。
  
  不可抗拒力。如地震、水灾、战争等。
  
  3 HOW - 如何做到高可用
  核心思想：网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。
  
  从架构角度看可用性：当前网站系统多采用经典的分层模型，从上到下为：应用层、服务层与数据层。应用层主要实现业务逻辑处理；服务层提供可复用的服务；数据层负责数据读写；在部署架构上常采用应用和数据分离部署，应用会部署到不同服务器上，这些服务器被称为应用层的服务器；这些可复用的服务也会各自部署在不同服务器上，称为服务层的服务器；而各类数据库系统、文件柜等数据则部署在数据层的服务器。
  
  硬件故障方面引起不可用的技术解决措施：(1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务（前提是这些服务需要设计为无状态，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应），当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。(2)服务层服务器。这些服务器被应用层通过分布式服务框架（如Dubbo）访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。(3)数据服务器。需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份；当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。
  
  软件方面引起不可用的技术解决措施：通过软件开发过程进行质量保证。通过预发布验证、严格测试、灰度发布等手段，尽量减少上线服务的故障。

  2018-05-08

  

   200
• 

  彡工鸟

  这么多回复里，没有人提到高可用和高性能的量化指标，没有这个指标前提下，无法断定哪个更复杂吧。打个比方，高可用两条99就行了，你觉得会复杂，会难么？高性能要求你在并发百万，千万级调用十几个服务前提下，仍能保持10多毫秒，你觉得简单？复杂与否还是要指标。另外，很多人都关注应用节点和硬件节点高可用，却忽略了业务高可用这个视角，系统全挂了，你人工接入业务，在后台帮用户开通，办理，对业务来说也是高可用吧。以上个人看法

  作者回复: 你说的有道理，没有绝对的结论，我的问题只是想引起大家思考，通过思考来更深入理解复杂度。
  
  通常情况下，高可用要复杂一些，因为需要考虑的情景很多，而且没有完美的方案，只能做取舍。

  2018-05-08

  

   41
• 

  bieber

  高可用的解决方法不是解决，而是减少或者规避，而规避某个问题的时候，一般都会引发另一个问题，只是这个问题比之前的小，高可用的设计过程其实也是一个取舍的过程。这也就是为什么系统可用性永远只是说几个九，永远缺少那个一。
  而高性能，这个基本上就是定义计算能力，可以通过架构的优化，算法的改进，硬件的升级都可以得到很好的解决，从而达到我们心里对性能的预期…

  作者回复: 有道理，没有完美的高可用方案

  2018-05-25

  

   19
• 

  YMF_WX1981

  高可用相对复杂。
  
  高性能，不管通过什么方式，或多或少，性能总获提高，行为上非必须做；高可用必须做，因为系统宕机或数据丢失时，谈高性能也无意义。
  
  高可用涉及分布式存储和分布式计算，这两课题本身就复杂。
  
  高可用涉及的非技术因素，如自然，政治。
  
  So...
  
  

  2018-05-08

  

   13
• 

  夜行观星

  就我一个人注意到ZK的选举算法不是Paxos吗？虽然不是本文重点😂

  作者回复: 感谢指正，ZK的协议是ZAB，官方文档也解释了ZAB不是Paxos算法，因为两者的设计目标不同，我没有深入研究两者协议，但大部分研究过的人认为ZAB是在Paxos算法上进行了改良和优化，有兴趣的可以深入研究一下。

  2018-05-13

  

   9
• 

  罗烽

  高性能，高可用，哪个复杂度更高？
  我认为高可用更复杂。性能方面，我们可已通过增加机器，拆分服务来提高性能。但是高可用这个不是通过单纯花钱（增加机器）能解决的，但还是必须要花钱😂😂，相比较而言，它更需要一个良好的设计，这个就很复杂了。
  关于高可用，我有些自己的想法
  1，还是要做小的服务，小的服务稳定性会更高。
  2，高可用的监控十分的重要，只有能先发现问题，才能接下来处理问题。
  3， 存储高可用（减少和规避数据不一致），这个太复杂的不清楚，我们的业务现在没有那么复杂，数据库用的就是阿里云的主备rds，相比较而言，使用阿里云的服务会让我们的服务保障性更高些，这个只能想到这些

  2018-05-08

  

   8
• 

  晓晨同学

  核心思想：网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。
  
  从架构角度看可用性：当前网站系统多采用经典的分层模型，从上到下为：应用层、服务层与数据层。应用层主要实现业务逻辑处理；服务层提供可复用的服务；数据层负责数据读写；在部署架构上常采用应用和数据分离部署，应用会部署到不同服务器上，这些服务器被称为应用层的服务器；这些可复用的服务也会各自部署在不同服务器上，称为服务层的服务器；而各类数据库系统、文件柜等数据则部署在数据层的服务器。
  
  硬件故障方面引起不可用的技术解决措施：(1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务（前提是这些服务需要设计为无状态，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应），当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。(2)服务层服务器。这些服务器被应用层通过分布式服务框架（如Dubbo）访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。(3)数据服务器。需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份；当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。
  

  作者回复: 为你点赞👍👍👍

  2019-02-19

  

   7
• 

  李志伟

  个人觉得根据场景而定，如果一个系统部署结构复杂，组件众多，数据量也很大。那么高可用性的代价就会比较高。因为高可用意味着冗余，
  冗余也就意味着要有额外的策略来管理这些冗余的组件。另外大数据量数据服务冗余异地多活也是很有挑战性的。 于此相对如果一个系统他的业务复杂度很高，涉及到很多的复杂计算，但是本身部署结构不复杂，那么这时候高性能的复杂度就会比较大

  2018-05-08

  

   7
• 

  歪脖贰点零

  为保证高可用，有时候会引入其他组件，比如keepalive等等，此时keepalive也易容易产生单点问题，于是做主从或其他方案。若其他方案同样存在单点问题，如此往复下去。悲观的看，似乎无止境，更多的时候是个取舍。

  2018-05-08

  

   5
• 

  性能

  老师，银行账务类强一致性业务，适用最终一致性方案吗？我们通常要求既要实时看到账务操作结果，又要提供高性能，最终只能用依赖于数据库实现一致性，但性能压力很大

  作者回复: 强一致性目前没有太好的方式，目前一般采取用户分区的做法，即：将用户分散在多个数据分区中，每个数据分区中的用户用单点数据库保证强一致性

  2018-05-29

  

   3
• 

  孙振超

  相对而言还是高可用更难些，按照作者说的高性能其实就是容量，在负载均衡系统高可用的情况下加机器就可以了，而想做到各个环节的高可用不是靠加机器就能搞定的，通常需要复杂的算法、引入更多的中间件、牺牲一定的性能才能实现，这其中还要进行各种权衡取舍裁剪才可以

  作者回复: 确实如此

  2018-05-26

  

   3
• 

  高歌在羊城

  大神，希望后面多一些落地的案例分析，章节篇幅可以长一点，一次讲一个要点都行😁

  作者回复: 别急，后面很多案例和模式分析

  2018-05-08

  

   3
• 

  Ivan

  高可用一般会考虑的更多一些，简单点说一个不可以的服务也就不存在性能一说，冗余是高可用的主要手段，高可用的主要复杂度体现在状态监控，服务切换或服务恢复上，为了降低其复杂度，又有无状态设计，熔断设计等等，这里面其实又牵扯到高性能，一个高性能的服务往往是快的小的独立的，相应的其高可用也就较容易实现。感觉最终的落地点还是在业务复杂度上，登录偏向高性能，支付偏向高可用

  2018-05-08

  

   3
• 

  幸福时光

  架构的问题谈复杂性不如谈重要性来得直接，这个依赖于架构所要解决的业务场景的复杂度是对高性能有更高要求，还是对高可用有更高要求。如果对高性能的要求取舍大于高可用，自然高性能的架构考虑势必会复杂一些。大多数情况下，鱼和熊掌不可兼得，最终架构选择还是要依赖业务场景做出平衡。

  2018-05-08

  

   3
• 

  佳

  高性能虽然复杂，但是只要通过合理的集群方案还是可以解决业务的性能需求，但是高可用也只能做到相对高可用，绝对高可用是不存在的，总会有诸多突发外界因素进行干扰，高性能的实现是受人为控制的，只要是在人的控制范围内，那问题都不是问题，但是要做到高可用，很多事情都不是人能控制的，比如天灾人祸

  作者回复: 很正确👍

  2018-10-27

  

   2
• 

  小超在努力

  古人有言：先解决有无，再解决优化。所以可用更难，性能次之，找对象同理。

  作者回复: 你已参透天机😄

  2018-08-16

  

   2
• 

  Joker

  高性能是为了达到一个量化的目标，通常我们会有各种不同的办法去实现，抛开消耗来说，方法有很多种，就像上篇讲到的，粗暴加机器，优雅划分等;但是高可用是为了规避一个非量化的抽象bug场景集合，这些不都是能提前预测到的，所以高可用一般来说都会比高性能复杂！

  作者回复: 是的，通俗来讲，高性能是土豪，有钱可以任性；高可用是文豪，需要日积月累修炼😃

  2018-05-25

  

   2
• 

  云学

  有些人把高可用与高可靠混淆了，高可用是不要中断服务，高可靠是数据不丢失。

  作者回复: 有区别，但实践中一般很难清晰的区分，否则每次都要解释半天，我们一般都是混用，大家都明白是什么意思。
  
  严格来说，高可用是指正常提供服务的概率，主要和故障恢复时间有关；高可靠是指出问题的概率，主要和故障次数有关。大部分情况下其实我们都是说可用性，因为保证系统能够正常提供服务才是我们的首要目标。

  2018-05-15

  

   2
• 

  Geek_d8f635

  区块链技术如果越来越成熟，是不是对高性能有很大帮助？

  作者回复: 据我目前对区块链的理解来看，区块链恰恰是性能低下的实现方案，不但没有帮助，还会存在明显的性能问题

  2018-05-09

  

   2
• 

  itperson

  高可用更复杂一些，因为需要考虑很多的异常处理方式。

  2018-05-08

  

   2