系统稳定性与高可用保障

一、前言

高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在系统架构设计中必须考虑的因素之一。今天我们就来聊一聊三 H 中的高可用，也是我们常说的系统稳定性。

> 本篇文章只聊思路，没有太多的深入细节。阅读全文大概需要 5~10 分钟。

二、高可用的定义

业界常用 N 个 9 来量化一个系统可用性程度，可以直接映射到网站正常运行时间的百分比上。

可用性的计算公式：

大部分公司的要求是 4 个 9，也就是年度宕机时长不能超过 53 分钟，实际要达到这个目标还是非常困难的，需要各个子模块相互配合。

要想提升一个系统的可用性，首先需要知道影响系统稳定性的因素有哪些。

三、影响稳定性的因素

首先我们先梳理一下影响系统稳定性的一些常见的问题场景，大致可分为三类：

• 人为因素 不合理的变更、外部攻击等等

• 软件因素 代码 bug、设计漏洞、GC 问题、线程池异常、上下游异常

• 硬件因素 网络故障、机器故障等

下面就是对症下药，首先是故障前的预防，其次是故障后的快速恢复能力，下面我们就聊聊几种常见的解决思路。

四、提升稳定性的几种思路

4.1 系统拆分

拆分不是以减少不可用时间为目的，而是以减少故障影响面为目的。因为一个大的系统拆分成了几个小的独立模块，一个模块出了问题不会影响到其他的模块，从而降低故障的影响面。系统拆分又包括接入层拆分、服务拆分、数据库拆分。

• 接入层 & 服务层 一般是按照业务模块、重要程度、变更频次等维度拆分。

• 数据层 一般先按照业务拆分后，如果有需要还可以做垂直拆分也就是数据分片、读写分离、数据冷热分离等。

::: hljs-center

4.2 解耦

:::

系统进行拆分之后，会分成多个模块。模块之间的依赖有强弱之分。如果是强依赖的，那么如果依赖方出问题了，也会受到牵连出问题。这时可以梳理整个流程的调用关系，做成弱依赖调用。弱依赖调用可以用 MQ 的方式来实现解耦。即使下游出现问题，也不会影响当前模块。

4.3 技术选型

可以在适用性、优缺点、产品口碑、社区活跃度、实战案例、扩展性等多个方面进行全量评估，挑选出适合当前业务场景的中间件 & 数据库。前期的调研一定要充分，先对比、测试、研究，再决定，磨刀不误砍柴工。

4.4 冗余部署 & 故障自动转移

服务层的冗余部署很好理解，一个服务部署多个节点，有了冗余之后还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务时间。所以，又往往是通过 “自动故障转移” 来实现系统的高可用。即某个节点宕机后需要能自动摘除上游流量，这些能力基本上都可以通过负载均衡的探活机制来实现。

涉及到数据层就比较复杂了，但是一般都有成熟的方案可以做参考。一般分为一主一从、一主多从、多主多从。不过大致的原理都是数据同步实现多从，数据分片实现多主，故障转移时都是通过选举算法选出新的主节点后在对外提供服务（这里如果写入的时候不做强一致同步，故障转移时会丢失一部分数据）。具体可以参考 Redis Cluster、ZK、Kafka 等集群架构。

4.5 容量评估

在系统上线前需要对整个服务用到的机器、DB、cache 都要做容量评估，机器容量的容量可以采用以下方式评估：

• 明确预期流量指标 - QPS；
• 明确可接受的时延和安全水位指标（比如 CPU%≤40%，核心链路 RT≤50ms）；
• 通过压测评估单机在安全水位以下能支持的最高 QPS（建议通过混合场景来验证，比如按照预估流量配比同时压测多个核心接口）；
• 最后就可以估算出具体的机器数量了。

DB 和 cache 评估除了 QPS 之外还需要评估数据量，方法大致相同，等到系统上线后就可以根据监控指标做扩缩容了。

4.6 服务快速扩容能力 & 泄洪能力

现阶段不论是容器还是 ECS，单纯的节点复制扩容是很容易的，扩容的重点需要评估的是服务本身是不是无状态的，比如：

• 下游 DB 的连接数最多支持当前服务扩容几台？
• 扩容后缓存是否需要预热？
• 放量策略

这些因素都是需要提前做好准备，整理出完备的 SOP 文档，当然最好的方式是进行演练，实际上手操作，有备无患。

泄洪能力一般是指冗余部署的情况下，选择几个节点作为备用节点，平时承担很小一部分流量，当流量洪峰来临时，通过调整流量路由策略把热节点的一部分流量转移到备用节点上。

对比扩容方案这种成本相对较高，但是好处就是响应快，风险小。

4.7 流量整形 & 熔断降级

流量整形也就是常说的限流，主要是防止超过预期外的流量把服务打垮，熔断则是为了自身组件或者依赖下游故障时，可以快速失败防止长期阻塞导致雪崩。关于限流熔断的能力，开源组件 Sentinel 基本上都具备了，用起来也很简单方便，但是有一些点需要注意。

• 限流阈值一般是配置为服务的某个资源能支撑的最高水位，这个需要通过压测摸底来评估。随着系统的迭代，这个值可能是需要持续调整的。如果配置的过高，会导致系统崩溃时还没触发保护，配置的过低会导致误伤。

• 熔断降级 - 某个接口或者某个资源熔断后，要根据业务场景跟熔断资源的重要程度来评估应该抛出异常还是返回一个兜底结果。比如下单场景如果扣减库存接口发生熔断，由于扣减库存在下单接口是必要条件，所以熔断后只能抛出异常让整个链路失败回滚，如果是获取商品评论相关的接口发生熔断，那么可以选择返回一个空，不影响整个链路。

4.8 资源隔离

如果一个服务的多个下游同时出现阻塞，单个下游接口一直达不到熔断标准（比如异常比例跟慢请求比例没达到阈值），那么将会导致整个服务的吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。引入资源隔离后，可以限制单个下游接口可使用的最大线程资源，确保在未熔断前尽可能小的影响整个服务的吞吐量。

说到隔离机制，这里可以扩展说一下，由于每个接口的流量跟 RT 都不一样，很难去设置一个比较合理的可用最大线程数，并且随着业务迭代，这个阈值也难以维护。这里可以采用共享加独占来解决这个问题，每个接口有自己的独占线程资源，当独占资源占满后，使用共享资源，共享池在达到一定水位后，强制使用独占资源，排队等待。这种机制优点比较明显就是可以在资源利用最大化的同时保证隔离性。

这里的线程数只是资源的一种，资源也可以是连接数、内存等等。

4.9 系统性保护

系统性保护是一种无差别限流，一句话概念就是在系统快要崩溃之前对所有流量入口进行无差别限流，当系统恢复到健康水位后停止限流。具体一点就是结合应用的 Load、总体平均 RT、入口 QPS 和线程数等几个维度的监控指标，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

4.10 可观测性 & 告警

当系统出现故障时，我们首先需找到故障的原因，然后才是解决问题，最后让系统恢复。排障的速度很大程度上决定了整个故障恢复的时长，而可观测性的最大价值在于快速排障。其次基于 Metrics、Traces、Logs 三大支柱配置告警规则，可以提前发现系统可能存在的风险 & 问题，避免故障的发生。

4.11 变更流程三板斧

变更是可用性最大的敌人，99% 的故障都是来自于变更，可能是配置变更，代码变更，机器变更等等。那么如何减少变更带来的故障呢？

• 可灰度 用小比例的一部分流量来验证变更后的内容，减小影响用户群。

• 可回滚 出现问题后，能有有效的回滚机制。涉及到数据修改的，发布后会引起脏数据的写入，需要有可靠的回滚流程，保证脏数据的清除。

• 可观测 通过观察变更前后的指标变化，很大程度上可以提前发现问题。

除了以上三板斧外，还应该在其他开发流程上做规范，比如代码控制，集成编译、自动化测试、静态代码扫描等。

五、总结

对于一个动态演进的系统而言，我们没有办法将故障发生的概率降为 0，能做的只有尽可能的预防和缩短故障时的恢复时间。当然我们也不用一味的追求可用性，毕竟提升稳定性的同时，维护成本、机器成本等也会跟着上涨，所以需要结合系统的业务 SLO 要求，适合的才是最好的。