《分布式系统可用性保证方法和实践》

本文属于专栏《构建工业级QPS百万级服务》系列简介-CSDN博客

1、什么是可用性

2、保障可用性的方法

2.1、可用性保障的前置手段

2.1.1、灰度验证

2.1.2、小流量验证

2.1.3、上线流程

2.1.4、前置手段总结

2.2、可用性保障的后置手段

2.2.1、问题发现

2.2.1.1、监控

2.2.1.2、告警

2.2.2、运维手段

2.2.3、产品手段

2.2.4、后置手段总结

1、什么是可用性

可用性是指一个系统在用户需要时能够正常提供服务的能力。需要注意，从用户的角度来看，可用性针对的功能，而不是某个系统。另外用户群体不一样，则可用性则一样。如GPT的聊天功能，“可用”意味着能秒级响应人类的输入，而对银行的大额转账功能，“可用”意味者秒级接受用户请求，小时级甚至天级完成实际转账。

2、保障可用性的方法

首先可用性的量化指标是，可用时间/总时间，如功能在最近10小时内，有持续1小时的不可使用，则系统可用性是90%。在无限的时间中，系统不可能做到100%可用，我们保障可用性，本质是提高可用的概率。

功能是系统的一部分，从软件的角度，保障功能的稳定性，本质是保障系统的稳定性。要说明系统稳定性的保障，首先要理解系统是如果构建的。如下图，是现代软件开发的基本流程，“需求收集”、“方案设计”、“开发&自测”是由于业务不同，所以差异大，目前业界没有统一的抽象出来的与可用性相关的方法。而灰度验证、小流量验证、以及上线后的预案，是提高系统可用概率的关键。

我们将可用性保障手段分为前置手段和后置手段。而我们的前置手段，做的都是增加可用性的概率，后置手段，做的都是快速将可用性恢复到一个高水位。

2.1、可用性保障的前置手段

2.1.1、灰度验证

由于开发过程中的自测，甚至QA介入的功能测试，是局部的。如果直接上线，会导致一些问题暴露到线上，如从未出现过的异常请求、不易mock的多用户并发请求。而灰度验证的核心思路，是尽可能的保障和数据链路、资源类别等与线上一致，在相同输入的情况下，验证输出的一致率。如下图，灰度环境想暴露的是“请求处理系统”从版本1升级到版本2的，可能带来的问题。有几个点，在实践中需要注意：

引流：在海量数据处理系统，网络成本是不可忽视的。在部分业务中，引流并不需要全量，如搜索系统中，可以引入各个区域的随机5%的流量。而对一些统计相关系统，用户之间相互影响，那流量之间不是用户独立，可能是组织独立，那就引入部分组织的流量。
一致率验证系统：虽然数据、数据链路都完全一致，但是处理时间是有随机性的，所以返回数据不可避免的出现不一致的问题。我们可以做的是，让一致率保持在高水平。这里所谓的高水平和业务相关。在实践中，一个好用的方法是，让灰度版本和线上保持一致，然后观察一致率系统的diff分布作为基线，然后在灰度时，观察各场景diff分布是否符合预期+抽部分case分析
diff调查系统：该系统的功能是帮助快速分析diff case。本质就是根据结果，反查前置链路日志，找到问题根源。如果系统链路长，日志展示效率低，配合日志，开发一个可视化，易操作的问题分析工具或者网页，也是常态

2.1.2、小流量验证

如下图，小流量验证，指的是线上环境，部分用户用版本1的处理系统，部分用户用版本2的处理系统。为什么有了灰度环境，还需要小流量验证，本质还是因为，在系统开发的历史经验中，我们总结出，通过灰度验证的系统，依然在可用性的概率上不够高。这里我们不再验证一致率，因为输入已经不一致，我们观察的是用户反馈，如果用户没意见，那自然系统是可用的。

2.1.3、上线流程

通过灰度验证和小流量验证，我们已经确定了系统大概率可用。那保障已经验证的版本上线，看似简单，但是稍不注意，也会影响线上系统可用性。

第一，使用容器保障线上环境的一致性，否则我们将有大量的精力花费在“为什么只有这台机器有问题”的低级且无意义的问题中。

第二，保障线上的操作记录持久化，以方便每次查看上次上线的流程，以及区别。甚至，无论哪个行业、环节。减少非标准化操作，都是提升效率，保障可用性的通用方法。

第三，对正在使用的系统，升级版本，正如对正在跑的汽车，换轮子一样。要让换轮子的操作，对司机无感，就像车型和道路有差别，那对不同业务系统的升级方式，也同样有差别。这里我举两个最常见系统的例子。分别是无状态查询系统、有状态的流式计算系统。如果对这两类系统不熟悉的，可以翻阅我之前写的《构建工业级QPS百万级服务》中的无状态服务和有状态服务的架构设计相关知识。

对于无状态的查询系统，如下图，核心是先注销机器，再升级，再重连。这里值得注意的是，即使负载均衡不再发送请求，机器1中依然可能有正在处理的请求。所以我们不是在没有新请求进入机器1之后，就升级版本，而是机器1处理完所有请求之后。

对于有状态的流式计算服务。我们考虑两种情况，一种状态存储在数据库中，这是为了状态持久化，以及简化业务系统；另一种是状态存储在本地，这是为了减少网络I/O，加快计算速度。对于状态存储在数据库中，升级流程如下图，值得注意的几个点是：

如果2.1先执行，会有一部分数据在机器1中未得到处理，这种适用于业务可以丢失部分用户请求，如统计一个地区的雨水量，是10w升，还是(10w-1)升，并不影响后续规划。这种情况可以通过请求在此时间段重复发送，更常见的是请求转发的具体实现是消息队列，而下游采用pull的方式，那向前一段时间pull就行，不过这也只是降低了丢失数据的可能性，不能100%解决。
如果2.2先执行，保证了数据至少被处理一次（不考虑机器崩溃的情况，这个我会在本文后面讲到）。但是机器1的备用机，处理的请求如果被机器1快，那可能出现，结果顺序不一致的问题，所以对于即需要请求不丢失，也需要处理顺序一致的系统，需要增加后置验证和数据修复系统。
数据权限的抢占和去除，需要依赖，线性一致性系统，如zookeeper

对于状态在本地的系统。核心思想是，通过流量复制，让不同机器状态一致之后，对系统进行升级。如下图，可以看出，使用升级还是前的数据由下游控制，对于重复流量或者数据丢失的取舍，也更容易解决。但是这样我们就长期需要双份机器，相比方案1，我们实践做出的抉择，本质上是对比的，（外部状态存储成本 + 数据I/O成本）和（双份机器成本）。这个需要结合具体的业务分析。

2.1.4、前置手段总结

总的来说，前置手段，无论哪种方式，一定是两个目的之一：提前暴露可能的问题、通过抽象标准流程减少操作问题。而实践中，我们更多的精力是，结合业务，在可用性概率和成本之间做取舍。

2.2、可用性保障的后置手段

后置手段是，指的发现问题之后，通过人为介入，让用户看到功能正确性恢复。那么即使发现问题，和发现问题后的介入手段则是快速恢复可用的关键。

2.2.1、问题发现

业界最常用的问题发现手段是两类，服务侧的监控以及告警，用户侧的反馈。

2.2.1.1、监控

首先服务侧的监控，一律是通过日志得到的。对CPU、内存、网络资源、磁盘等监控，是通过内核日志监控的，对业务软件的指标监控，同理也是通过对业务日志统计监控的。

以一个《构建工业级QPS百万级服务》中，所说的查询两个日期中间的节假日数量的系统为例。大概会有如下可视化监控

系统资源层面
- 单机/集群的 CPU百分比、CPU load、内存、网络流量、磁盘。
业务层面
- nginx层的处理请求数量、延迟
- 每个接口的请求总量，单个请求的平均大小，请求失败的数量、请求失败的原因、请求处理的延迟，请求的用户画像分布（如地区，时间）
- 请求数据库的次数，请求延迟，请求失败的数量、请求失败的原因
- 请求的首尾时间分布、请求在服务中每个处理流程的耗时、以及处理漏斗
- 软件异常（如c++ 的core dump）
产品层面
- 用户的好评、差评，甚至电话至客服。这些反馈都很重要，但是尽量把问题扼杀在这个之前，否则将会有大面积用户受损

这些监控，也要从均值、top99、max等角度拆分。另外监控不是越多越好，监控的目的只有一个，帮助发现问题，而不是展现系统逻辑。

另外，实践中，我们要将监控分等级，如软件异常的监控的优先级，明显比请求的用户画像分布重要。为了更高效地发现问题，把重要的监控合并到一个页面是有意义的。

2.2.1.2、告警

监控，是人发起的主动查看。但是没有人可以1天24小时，盯着监控，即使三班倒，也难免遗漏。所以我们需要主动推送的机制。而告警的基本依据是，当前数据量级和之前有一定的差距，说明系统大概率出现的不符合预期的问题。

一般的告警依据的是，当前分钟和上一分钟的指标差距，比如当前分钟请求数量比上一分钟低20%，或者当前分钟的请求延迟比上一分钟高30%。或者比昨天同一分钟去比。无论怎么比结合的都是业务流量已有的规律。而这些规律是根据历史经验总结出来的，一般来说，报警数量是大于问题数量的，这样才能减少问题出现了，但是没有告警的情况。

告警通知，同样也按照紧急程度分为，邮件/消息/短信/电话。毕竟人的精力是有限的，太多的噪声，也是在消耗成本。

2.2.2、运维手段

那么我们在有科学的监控之后，且监控已经帮助我们及时地发现问题了，我们怎么处理呢。

对于系统资源相关的问题，核心思路是在保证大部分用户可用。这里的关键方法是：限流、切流、扩容。

限流的本质是损失一小部分用户的请求。比如系统内存使用达到90%时，再到达的用户直接返回失败，如果不这样做，可能会导致系统崩溃，从而所有用户都不能正常请求。
切流的本质是让一部分用户请求准确性受损。比如有一个灾备机房，这个机房的软件版本降低了计算精度，减少了计算需要的资源。
对于无状态的服务，如果成本在计划范围内，扩容是最好的选择。但是如果成本紧张，或者状态恢复慢，则需要在限流或者切流之后做。

对于正确性问题，导致不可用。一般出现在新版本上线后不久，或者一个新的用户场景触发了老版本的bug。这里的关键方法是：回滚、限流、bugfix。

一般逻辑bug，都是出现在上线后不久。回滚到上一个没问题的版本是最好的办法
但是回滚不是万能的，比如新版本上线后，多个上下游链路是配合升级的，那单模块回滚会有困难，这个时候我们只能通过上游限制流量，甚至关停服务解决。不给返回，永远比给错误的返回好
bugfix，一般来说不是立刻解决问题的办法。因为它也需要灰度、小流量验证。如果一个bugfix不经过验证上线，那它将可能带来更长时间，以及更严重的不可用。如果不经过验证就上线，那也只能把希望寄托给运气了