精选留言(156)

• 
  公号-技术夜未眠

  2018-05-08

  今日心得 需求驱动驱动；而高可用与高性能，是架构设计中两个非常重要的决策因素。因此，面对不同业务系统的不同需求，对高可用与高性能也会有不同的决策结论，其实现的复杂度也各不相同。支付宝业务，对于可用性和性能就会有很高的要求，在可用性方面希望能提供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)数据服务器。需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份；当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。 软件方面引起不可用的技术解决措施：通过软件开发过程进行质量保证。通过预发布验证、严格测试、灰度发布等手段，尽量减少上线服务的故障。

  展开

  共 11 条评论

  392
• 
  小超在努力

  2018-08-16

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

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

  共 6 条评论

  84
• 
  彡工鸟

  2018-05-08

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

  展开

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

  共 5 条评论

  82
• 
  bieber

  2018-05-25

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

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

  共 2 条评论

  69
• 
  性能

  2018-05-29

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

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

  共 3 条评论

  30
• 
  夜行观星

  2018-05-13

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

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

  共 2 条评论

  30
• 
  晓晨同学

  2019-02-19

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

  展开

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

  

  27
• 
  YMF_WX1981

  2018-05-08

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

  展开

  

  24
• 
  A李文

  2020-03-17

  冷备、温备、热备的具体区别是

  作者回复: 冷备：系统没启动 温备：系统启动，但是没法接管业务 热备：系统启动，随时可以接管业务

  共 4 条评论

  20
• 
  佳

  2018-10-27

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

  作者回复: 很正确👍

  

  13
• 
  孙振超

  2018-05-26

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

  作者回复: 确实如此

  

  11
• 
  云学

  2018-05-15

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

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

  

  11
• 
  罗烽

  2018-05-08

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

  展开

  

  11
• 
  李志伟

  2018-05-08

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

  

  9
• 
  Geek_88604f

  2019-07-20

  本质上高可用更难。到目前为止业界还没有办法明确度量到底能达到几个9。你交付给我一个系统，你可以说达到了3个9或4个9，我怎么能相信你呢？反之性能指标是可以很快就能实测出来的。 一般地讲，高可用和高性能就像列车的两条轨道共同进退。一方面为了实现数据库的高可用需要部署主从模式或一主多从模式，但是这样会影响数据库的读写性能；另一方面为了实现高性能，对业务服务器进行扩容，大规模的集群有上千台服务器，几乎每天都会出现各种类型的故障，这就影响到了系统的高可用。

  展开

  作者回复: 独到的解读

  共 3 条评论

  8
• 
  Geek_d8f635

  2018-05-09

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

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

  共 2 条评论

  8
• 
  MavenTalker

  2018-05-08

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

  

  6
• 
  邱荣财

  2020-10-28

  高性能路线，拆拆拆，拆系统，拆服务，拆微服务，拆函数服务，拆任务，拆进程，拆线程，任务调度，加机器。 高可用路线，合合合，多条链接合起来作为一个线路，主备合起来作为一个系统，主从合起来作为一个系统，多份数据合起来作为一份数据，状态决策，CAP

  作者回复: 很有道理������

  

  5
• 
  威

  2019-03-18

  老师你好，高性能和高可用有明确的界限吗，感觉有时候是混着用的。例如现实中我们会使用扩展处理单元的形式来提高性能，但是同时也提高了系统的可用性。比如为了不出现单点，我们会把业务系统双机部署，同时提供无状态服务，上游通过nginx来分流，既提高了性能，也能在某台机down掉时，另一个节点也能提高服务，从而达到高可用目的

  作者回复: 概念上有明确的界限，但本质上都是冗余更多物理硬件，所以很多时候两者可以同时考虑

  共 2 条评论

  5
• 
  Joker

  2018-05-25

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

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

  

  5