https://segmentfault.com/u/dewujishu
高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在系统架构设计中必须考虑的因素之一。今天我们就来聊一聊三H中的高可用，也是我们常说的系统稳定性。
本篇文章只聊思路，没有太多的深入细节。阅读全文大概需要5~10分钟。
业界常用N个9来量化一个系统可用性程度，可以直接映射到网站正常运行时间的百分比上。
可用性的计算公式：
大部分公司的要求是4个9，也就是年度宕机时长不能超过53分钟，实际要达到这个目标还是非常困难的，需要各个子模块相互配合。
要想提升一个系统的可用性，首先需要知道影响系统稳定性的因素有哪些。
首先我们先梳理一下影响系统稳定性的一些常见的问题场景，大致可分为三类：
下面就是对症下药，首先是故障前的预防，其次是故障后的快速恢复能力，下面我们就聊聊几种常见的解决思路。
拆分不是以减少不可用时间为目的，而是以减少故障影响面为目的。因为一个大的系统拆分成了几个小的独立模块，一个模块出了问题不会影响到其他的模块，从而降低故障的影响面。系统拆分又包括接入层拆分、服务拆分、数据库拆分。
系统进行拆分之后，会分成多个模块。模块之间的依赖有强弱之分。如果是强依赖的，那么如果依赖方出问题了，也会受到牵连出问题。这时可以梳理整个流程的调用关系，做成弱依赖调用。弱依赖调用可以用MQ的方式来实现解耦。即使下游出现问题，也不会影响当前模块。
可以在适用性、优缺点、产品口碑、社区活跃度、实战案例、扩展性等多个方面进行全量评估，挑选出适合当前业务场景的中间件&数据库。前期的调研一定要充分，先对比、测试、研究，再决定，磨刀不误砍柴工。
服务层的冗余部署很好理解，一个服务部署多个节点，有了冗余之后还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务时间。所以，又往往是通过“自动故障转移”来实现系统的高可用。即某个节点宕机后需要能自动摘除上游流量，这些能力基本上都可以通过负载均衡的探活机制来实现。
涉及到数据层就比较复杂了，但是一般都有成熟的方案可以做参考。一般分为一主一从、一主多从、多主多从。不过大致的原理都是数据同步实现多从，数据分片实现多主，故障转移时都是通过选举算法选出新的主节点后在对外提供服务（这里如果写入的时候不做强一致同步，故障转移时会丢失一部分数据）。具体可以参考Redis Cluster、ZK、Kafka等集群架构。
在系统上线前需要对整个服务用到的机器、DB、cache都要做容量评估，机器容量的容量可以采用以下方式评估：
DB和cache评估除了QPS之外还需要评估数据量，方法大致相同，等到系统上线后就可以根据监控指标做扩缩容了。
现阶段不论是容器还是ECS，单纯的节点复制扩容是很容易的，扩容的重点需要评估的是服务本身是不是无状态的，比如：
这些因素都是需要提前做好准备，整理出完备的SOP文档，当然最好的方式是进行演练，实际上手操作，有备无患。
泄洪能力一般是指冗余部署的情况下，选择几个节点作为备用节点，平时承担很小一部分流量，当流量洪峰来临时，通过调整流量路由策略把热节点的一部分流量转移到备用节点上。
对比扩容方案这种成本相对较高，但是好处就是响应快，风险小。
流量整形也就是常说的限流，主要是防止超过预期外的流量把服务打垮，熔断则是为了自身组件或者依赖下游故障时，可以快速失败防止长期阻塞导致雪崩。关于限流熔断的能力，开源组件Sentinel基本上都具备了，用起来也很简单方便，但是有一些点需要注意。
如果一个服务的多个下游同时出现阻塞，单个下游接口一直达不到熔断标准（比如异常比例跟慢请求比例没达到阈值），那么将会导致整个服务的吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。引入资源隔离后，可以限制单个下游接口可使用的最大线程资源，确保在未熔断前尽可能小的影响整个服务的吞吐量。
说到隔离机制，这里可以扩展说一下，由于每个接口的流量跟RT都不一样，很难去设置一个比较合理的可用最大线程数，并且随着业务迭代，这个阈值也难以维护。这里可以采用共享加独占来解决这个问题，每个接口有自己的独占线程资源，当独占资源占满后，使用共享资源，共享池在达到一定水位后，强制使用独占资源，排队等待。这种机制优点比较明显就是可以在资源利用最大化的同时保证隔离性。
这里的线程数只是资源的一种，资源也可以是连接数、内存等等。
系统性保护是一种无差别限流，一句话概念就是在系统快要崩溃之前对所有流量入口进行无差别限流，当系统恢复到健康水位后停止限流。具体一点就是结合应用的 Load、总体平均 RT、入口 QPS 和线程数等几个维度的监控指标，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
当系统出现故障时，我们首先需找到故障的原因，然后才是解决问题，最后让系统恢复。排障的速度很大程度上决定了整个故障恢复的时长，而可观测性的最大价值在于快速排障。其次基于Metrics、Traces、Logs三大支柱配置告警规则，可以提前发现系统可能存在的风险&问题，避免故障的发生。
变更是可用性最大的敌人，99%的故障都是来自于变更，可能是配置变更，代码变更，机器变更等等。那么如何减少变更带来的故障呢？
对于一个动态演进的系统而言，我们没有办法将故障发生的概率降为0，能做的只有尽可能的预防和缩短故障时的恢复时间。当然我们也不用一味的追求可用性，毕竟提升稳定性的同时，维护成本、机器成本等也会跟着上涨，所以需要结合系统的业务SLO要求，适合的才是最好的。
如何做好稳定性和高可用保障是一个很庞大的命题，本篇文章没有太多的深入细节，只聊了整体的一些思路，主要是为了大家在以后的系统高可用建设过程中，有一套系统的框架可以参考。最后感谢耐心看完的同学。
*文/新一
关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
