什么是高可用

维稳

「维稳」，顾名思义就是维持稳定，那什么叫稳定。

回想一下，生活上一些可以找到稳定的地方：

• 住的自己买的且不需要还贷房子，我们会觉得稳定，因为不需要担心被房东无故房租加价或赶出来、或者自己现金流出现问题导致断供，不可控不能预期的情况较少。
• 看NBA比赛，湖人3节过后领先30分的时候，我觉得稳了，因为被翻盘的几率太小了。
• 某个软件用起来，不会用着用着挂掉蓝屏，内存使用不会忽高忽低，那就叫稳。
• 你看到一个陌生人走在大街上，他是在正常的往前走，不会无故摇摇晃晃，不会随便跟别人搭话，不会突然扑过来打你，他的行为是符合常理的，所以感觉稳定。

所以「稳定」其实是一种心理的预期管理。一个东西稳定，意思就是，他是什么样子、有哪些状态、出现什么结果可以怎么处理，是已经事先预知的。

我们看一下IT系统，“不稳”有以下症状：

1、变更之后就算通过了验证，也会有可能被用户报障某块功能不可用，我明明没动这一块哇怎么会踩坑呢，原来代码千丝万缕太复杂，对影响范围判断错误导致漏测最终用户报障才知晓不可用。

2、负责的某个被不少系统依赖的基础服务，出了问题就容易乱了手脚，判断影响范围、找运维找研发、升级事件、同步故障、补偿措施等，混乱操作会直接证明了你能力不行。

3、公共资源使用没有规范，大家都在用，突然出现一个滥用、或者真的超过了使用的资源瓶颈，一大片关联系统都会收到影响。

…………

所以，不管是我们“为或不为”，“不稳”的感觉如影随形。

你自己的问题、还是别的系统问题、还是网络问题、还是云服务的问题，都有可能导致自己负责的系统不可用。故障也许会迟到但不会缺席，虽然我们陆陆续续提了一些优化，但貌似并没有增加太多安全感，总觉得离挂掉的不远。

高可用定义

「维稳」是大白话，对应软件架构上叫高可用，High Availability，简称HA。维基百科是这么解释，

高可用性（英语：high availability，缩写为 HA），IT术语，指系统无中断地执行其功能的能力，代表系统的可用性程度。是进行系统设计时的准则之一。高可用性系统与构成该系统的各个组件相比可以更长时间运行。

整个概念里面重点就在「无中断」，就是系统“不死”。

不稳定就是系统时而输出不了，高可用保持输出的无中断，所以高可用和稳定，我认为可以划等号。

可用性和可靠性

需要澄清一下，可用性和可靠性是两个概念。比如对于一个API来讲，

• 可靠性，系统是否具备无差错地执行预期操作的能力，专注的是输出质量；API返回的是否符合预期？是否是正确的？
• 可用性，为了执行这些操作，系统当前可运行的能力，专注的是执行能力；API有返回吗？

可靠性更多地可以靠测试保证，但可用性比可靠性需要考虑的维度和复杂度都要高得多。

我们现在只讨论可用性问题。

低可用原因

怎么才可以高可用呢，既然高可用难以达到，我们可以反过来用逆向思维考虑。

造成程序低可用的原因是什么？针对每个原因再优化，那我们就可以一步步接近理想的高可用。

资源耗尽

资源指的是服务器、网路之类的有限资源，资源肯定都是有限的，有限体现在容积和期限。

• 服务器cpu、内存等都有能力的上限，花光了就没了，只能扩容。
• 服务器运行都有损耗，故障的一天总会到来。

资源是程序最底层的依赖，如果耗尽了那程序运行就会越来越慢直至无法响应。

举个例子，就是前一阵子google大面积宕机就是硬盘用完的问题。

预期外压力

程序设计也是有极限，架构、成本、压力，没有三者兼顾的最优选择。

所以一个程序最初的方案和架构可能是较为简陋的，但可以适应当时的压力；然而随着应用程序被越来越多的人使用，就很可能需要对代码和应用程序进行修改以支撑不断增加的压力。

比如某些系统突然搞一些定时抢奖品的活动，这种就容易人为造成压力，如果没有事先做好突增的压力评估，特别是系统所依赖的某些环境容易疏漏，那在活动期间的压力就很可能把服务压死。

团队协作

这是沟通管理的问题，项目复杂度高了，需要的团队成员和角色就越来越多；人多沟通就会有损耗，人员流动也有损耗，最后实现的架构未必是原来设计的样子，会打折扣。

每个人的编程方式风格也有可能各异，引入的组件也可能功能重叠、版本不一致等问题。

架构也会有破窗效应，架构慢慢被腐蚀，最终就会破坏原有架构可制成的可用性。

外部依赖

绝大部分程序不可能独立运行，都需要外部saas服务、中间件等依赖，这些通用的服务虽然稳定，但也会有不可用的风险。

由于这层依赖链的存在，基础服务的不可用就会导致我们程序不可用。

技术债务

技术方案、时间、质量、金钱，这些成本在实现一个功能的时候都需要取舍，有时候为保当前的业务快速上线，的确会把技术舍弃，选择优先发布的方式。

这样就会造成技术债务，技术债务就是，原本应该考虑的、设计的技术环节，债务越多就越影响系统的可用性。

具体来说，技术债务包括：

• 缺乏设计，每个系统都需要设计，而且设计是有容量极限，随着时间和用户量增加，就容易超出容量极限造成不可用。
• 遗留bug，每个版本迭代为了按时发布，遗留一些bug，bug的堆积就有可能形成不可用的后患。
• 技术能力缺乏，开发人员技术能力不足，考虑不周，缺乏宏观把握和预见性，对框架、技术细节了解不够深入，没考虑并发场景，这种债务层层叠加之下，也容易造成不可用。

参考：
1、《可伸缩架构（第2版）：云环境下的高可用与风险管理》https://book.douban.com/subject/35178755/