系统在困境（adversity）（硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）。
plan挂了之后，系统能不能活下来？ 有没有负责兜底的PlanB。
造成错误的原因叫做故障（fault），能预料并应对故障的系统特性可称为容错（fault-tolerant）或韧性（resilient）。
注意故障（fault）不同于失效（failure）【2】。故障通常定义为系统的一部分状态偏离其标准，而失效则是系统作为一个整体停止向用户提供服务。故障的概率不可能降到零，因此最好设计容错机制以防因故障而导致失效。
影响可用性的因素
首先我们先梳理一下影响系统稳定性的一些常见的问题场景，大致可分为三类：
人为因素
不合理的变更、外部攻击等等
软件因素
代码bug、设计漏洞、GC问题、线程池异常、上下游异常
硬件因素
网络故障、机器故障等
可用性速降到最低的表现-雪崩
两个导火索：
- 下游或者本身机器故障导致latency增加
- 上游请求qps变高
实际的并发超过了最大能支持的并发（当下游变慢后，该值迅速会下降），过载就发生了。过载不可怕，如果上游不重试，系统终将恢复。
如何提高可用性
系统拆分
拆分不是以减少不可用时间为目的，而是以减少故障影响面为目的。
因为一个大的系统拆分成了几个小的独立模块，一个模块（大概率是变更导致，例如升级代码）出了问题不会影响到其他的模块，从而降低故障的影响面。
系统拆分又包括接入层拆分、服务拆分、数据库拆分。
接入层&服务层
【轻重分离】
一般是按照业务模块、重要程度、变更频次等维度拆分。
数据层
【轻重分离】、【冷热分离】、【读写分离】
一般先按照业务拆分后，如果有需要还可以做垂直拆分也就是数据分片、读写分离、数据冷热分离等。
把核心库与非核心库分机器部署，避免相互影响。
解耦
系统进行拆分之后，会分成多个模块。模块之间的依赖有强弱之分。
如果是强依赖的，那么如果依赖方出问题了，也会受到牵连出问题，强依赖需要基于被依赖放的SLA做好超时熔断配置以及本服务自身的容量预估。
这时可以梳理整个流程的调用关系，做成弱依赖调用。
弱依赖调用可以用MQ的方式来实现解耦。即使下游出现问题，也不会影响当前模块。
技术选型
可以在适用性、优缺点、产品口碑、社区活跃度、实战案例、扩展性等多个方面进行全量评估，挑选出适合当前业务场景的中间件&数据库。
前期的调研一定要充分，先对比、测试、研究，再决定，磨刀不误砍柴工。
冗余部署&故障自动转移
服务层的冗余部署很好理解，一个服务部署多个节点，有了冗余之后还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务时间。
所以，又往往是通过“自动故障转移”来实现系统的高可用。即某个节点宕机后需要能自动摘除上游流量，这些能力基本上都可以通过负载均衡的探活机制来实现。
涉及到数据层就比较复杂了，但是一般都有成熟的方案可以做参考。
一般分为一主一从、一主多从、多主多从。不过大致的原理都是数据同步实现多从，数据分片实现多主，故障转移时都是通过选举算法选出新的主节点后在对外提供服务（这里如果写入的时候不做强一致同步，故障转移时会丢失一部分数据）。具体可以参考Redis Cluster、ZK、Kafka等集群架构。
容量评估
- 每个系统，自己的最大处理能力是多少要做到清清楚楚。
在系统上线前需要对整个服务用到的机器、DB、cache都要做容量评估，机器容量的容量可以采用以下方式评估：
- 明确预期流量指标-QPS；
- 明确可接受的时延和安全水位指标（比如CPU%≤40%，核心链路RT≤50ms）；
通过压测评估单机在安全水位以下能支持的最高QPS（建议通过混合场景来验证，比如按照预估流量配比同时压测多个核心接口）；
最后就可以估算出具体的机器数量了。
DB和cache评估除了QPS之外还需要评估数据量，方法大致相同，等到系统上线后就可以根据监控指标做扩缩容了。
服务快速扩容能力&泄洪能力
现阶段不论是容器还是ECS，单纯的节点复制扩容是很容易的，扩容的重点需要评估的是服务本身是不是无状态的，比如：
下游DB的连接数最多支持当前服务扩容几台？
扩容后缓存是否需要预热？
放量策略
这些因素都是需要提前做好准备，整理出完备的SOP文档，当然最好的方式是进行演练，实际上手操作，有备无患。
泄洪能力一般是指冗余部署的情况下，选择几个节点作为备用节点，平时承担很小一部分流量，当流量洪峰来临时，通过调整流量路由策略把热节点的一部分流量转移到备用节点上。
对比扩容方案这种成本相对较高，但是好处就是响应快，风险小。
限流&熔断降级
对于用户的重试行为，要适当的延缓。例如登录发现后端响应失败，再重新展现登录页面前，可以适当延时几秒钟，并展现进度条等友好界面。当多次重试还失败的情况下，要安抚用户。
过载保护很重要的一点，不是说要加强系统性能、容量，成功应答所有请求，而是保证在高压下，系统的服务能力不要陡降到0，而是顽强的对外展现最大有效处理能力。
前端系统有保护后端系统的义务，sla中承诺多大的能力，就只给到后端多大的压力。这就要求每一个前后端接口的地方，都有明确的负载约定，一环扣一环。
每个系统要有能力发现哪些是有效的请求，哪些是无效的请求。当过载发生时，该拒绝的请求（1、超出整个系统处理能力范围的；2、已经超时的无效请求）越早拒绝越好
中间层server对后端发送请求，重试机制要慎用，一定要用的话要有严格频率控制。
当雪球发生了，直接清空雪球队列（例如重启进程可以清空socket缓冲区）可能是快速恢复的有效方法。
流量整形也就是常说的限流，主要是防止超过预期外的流量把服务打垮，熔断则是为了自身组件或者依赖下游故障时，可以快速失败防止长期阻塞导致雪崩。
关于限流熔断的能力，开源组件Sentinel基本上都具备了，用起来也很简单方便，但是有一些点需要注意。
【自适应限流】限流阈值一般是配置为服务的某个资源能支撑的最高水位，这个需要通过压测摸底来评估。随着系统的迭代，这个值可能是需要持续调整的。如果配置的过高，会导致系统崩溃时还没触发保护，配置的过低会导致误伤。
熔断降级-某个接口或者某个资源熔断后，要根据业务场景跟熔断资源的重要程度来评估应该抛出异常还是返回一个兜底结果。
比如下单场景如果扣减库存接口发生熔断，由于扣减库存在下单接口是必要条件，所以熔断后只能抛出异常让整个链路失败回滚，如果是获取商品评论相关的接口发生熔断，那么可以选择返回一个空，不影响整个链路。
过载保护
异常有内外两种，一种是外部流量特别高，一种是某一个依赖故障导致系统响应变慢。
这里的课题应该包括：熔断、限流、超时控制、全局超时控制、服务降级（区分核心流程与非核心流程）
过载保护方案
这里推荐一种方案：在该系统每个机器上新增一个进程：interface进程。
Interface进程能够快速的从socket缓冲区中取得请求，打上当前时间戳，压入channel。
业务处理进程从channel中获取请求和该请求的时间戳，如果发现时间戳早于当前时间减去超时时间（即已经超时，处理也没有意义），就直接丢弃该请求，或者应答一个失败报文。
Channel是一个先进先出的通信方式，可以是socket，也可以是共享内存、消息队列、或者管道，不限。
Socket缓冲区要设置合理，如果过大，导致及时interface进程都需要处理长时间才能清空该队列，就不合适了。
建议的大小上限是：缓存住超时时间内interface进程能够处理掉的请求个数（注意考虑网络通讯中的元数据）。
参考：https://www.sohu.com/a/211248633_472869
资源隔离
如果一个服务的多个下游同时出现阻塞，单个下游接口一直达不到熔断标准（比如异常比例跟慢请求比例没达到阈值），那么将会导致整个服务的吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。引入资源隔离后，可以限制单个下游接口可使用的最大线程资源，确保在未熔断前尽可能小的影响整个服务的吞吐量。
说到隔离机制，这里可以扩展说一下，由于每个接口的流量跟ResponseTime都不一样，很难去设置一个比较合理的可用最大线程数，并且随着业务迭代，这个阈值也难以维护。
这里可以采用共享加独占来解决这个问题，每个接口有自己的独占线程资源，当独占资源占满后，使用共享资源，共享池在达到一定水位后，强制使用独占资源，排队等待。
这种机制优点比较明显就是可以在资源利用最大化的同时保证隔离性。
这里的线程数只是资源的一种，资源也可以是连接数、内存等等。
系统性保护
系统性保护是一种无差别限流，一句话概念就是在系统快要崩溃之前对所有流量入口进行无差别限流，当系统恢复到健康水位后停止限流。具体一点就是结合应用的 Load、总体平均 RT、入口 QPS 和线程数等几个维度的监控指标，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
4.10 可观测性&告警
当系统出现故障时，我们首先需找到故障的原因，然后才是解决问题，最后让系统恢复。排障的速度很大程度上决定了整个故障恢复的时长，而可观测性的最大价值在于快速排障。其次基于Metrics、Traces、Logs三大支柱配置告警规则，可以提前发现系统可能存在的风险&问题，避免故障的发生。
4.11 变更流程三板斧
变更是可用性最大的敌人，99%的故障都是来自于变更，可能是配置变更，代码变更，机器变更等等。那么如何减少变更带来的故障呢？
可灰度
用小比例的一部分流量来验证变更后的内容，减小影响用户群。
产品特性设计和发布上，要尽量避免某个时刻导致大量用户集体触发某些请求的设计。发布的时候注意灰度。
可回滚
出现问题后，能有有效的回滚机制。涉及到数据修改的，发布后会引起脏数据的写入，需要有可靠的回滚流程，保证脏数据的清除。
可观测
通过观察变更前后的指标变化，很大程度上可以提前发现问题。 除了以上三板斧外，还应该在其他开发流程上做规范，比如代码控制，集成编译、自动化测试、静态代码扫描等。
五、总结
对于一个动态演进的系统而言，我们没有办法将故障发生的概率降为0，能做的只有尽可能的预防和缩短故障时的恢复时间。当然我们也不用一味的追求可用性，毕竟提升稳定性的同时，维护成本、机器成本等也会跟着上涨，所以需要结合系统的业务SLO要求，适合的才是最好的。
冗余
从根本上讲，解决高可用，只有一个方法，就是冗余。通过冗余更多的机器，来应对机器的硬件故障或者彼此之间的网络故障。
多机房部署
通过多机房部署来增加冗余。
多活的好处
- 响应时间短、提升用户体验
- 服务高可用
- 降低成本
- 廉价的机器（非洲用户访问非洲的机器）
- 流量的分摊（西方节日时，流量通过亚洲来分摊）
如何做到异地多活（必须要解决的一些问题）
接入层流量控制：用户默认访问哪个DC？什么时候做切换？ 如何控制这个切换过程？
各DC业务逻辑一致：对于用户来说， 他的流量被调度前后，业务逻辑是一致的。 比如facebook上有一些内容对于亚洲用户是不可见的，不能因为亚洲用户的流量被迁移到了美洲机房，这个限制就失效了。
跨DC的实时数据同步与冲突处理：还是以fb为例， 如果访问非洲机房的用户A给访问南美洲机房的用户B的一个帖子点了赞， 那么B应该能及时收到相关的通知。这背后就依赖数据的实时同步。
在多活情况下， 多DC的数据写入势必会引入数据的冲突， 比如facebook位于美东的的审核系统和位于东南亚的用户同时操作了一条帖子， 就会产生数据的冲突。提供全球级别的强一致性
对于大多数业务而言， 我们只需要最终一致性即可（比如点赞之类的计数）。 但是某些业务，需要全球的强一致保障(比如下
单、支付之类的操作）。
同城多机房：延迟1～3ms
主要看接口的实现（如果有几十次的跨机房交互，这种是不可接受的）
实现相对比较简单
单机房写入；每一个机房近读取本机房的缓存与数据
如果数据发生变更，需要做两边机房缓存的清理，一般通过canal订阅数据库变更
国内异地多机房:延迟50ms以内
尽量减少跨机房的调用；而应该避免跨机房的数据库与缓存操作
多机房写入，按照用户或者其他业务维度来进行流量分割，使得一部分流量总是请求A机房，而另外的总是请求B机房。
根据业务需要，选择满足：
(1）一致性（如果选择了一致性，那么可用性便得不到100%保障）
(2）可用性（如果选择了可用性，那么一致性需要事后做补偿）
数据同步方式有两种：
（1）基于存储系统主从复制：同步redis、Mysql等
（2）基于消息队列：同步缓存、HBase的数据
跨国多机房：延迟在100～200ms
避免跨机房的调用，而只能做异步同步
每个SLA级别需要做的事情
感觉一下提高1个9，难度有多大。
三个9: 非核心业务可以容忍
四个9: 核心业务
运维值班体系、业务变更流程、故障处理流程、更加完善的系统故障排查工具、灰度发布（确保服务可回滚）
五个9: 必须让机器来自动处理恢复！
尽量思考故障发生后应该怎么办
考虑点：如何自动的发现故障、如何自动化的应对故障、系统运维-尽量避免故障发生
具体方法：failover(故障转移)、超时控制、服务降级、熔断限流
failover:
- 完全对等
- 非完全对等（例如存在主备节点，心跳，选择paxos, raft等）
