2020年不可容忍4个9业务高速增长下如何保证系统稳定性和高可用？
时间：2020-11-19 20:13:13 来源：勤学考试网 本文已影响 人 
不可容忍的 4 个 9，业务高速增长下，如何保证系统的稳定
性和高可用？
“ 2017 年 8 月 25 日，我怀着“再也不要在下班时间收到报警”的美好期待，加入美团金融智能支付负责核心交易，结果入职后收到的报警一天紧似一天。
核心交易是整个智能支付的核心链路，承担着智能支付百分之百的流量，不敢有丝毫的懈怠。
下面是我们的日单量增长曲线从图中可以看到，从
2017
年下半年开始，我们的日单量增长迅速，而且压力和流量在
午、晚高峰时段非常集中。在这种情况下，报警和小事故日
益频繁，交易的稳定性面临着严峻的考验。
下面是早期的可用性趋势图，仔细看的话，可以看到可用性
有下降的趋势，旁边的总可用性显示只有
4 个 9
9998765% ），美团点评排在第一的价值观是“以客户为中心”显，然对交易这种稳定性要求非常高的系统， 低于 5 个 9
是不可容忍的。启动排查
在很长时间里，我们做的只是在原有系统上增加功能，架构上没有大调整。但是随着业务增长，就算我们系统没有任何发版升级，也会突然出现一些事故。
事故出现的频率越来越高，我们自身的升级，也经常是困难
重重。基础设施升级、 上下游升级， 经常会发生“蝴蝶效应”，
毫无征兆的受到影响。
以下是这些现象的鱼骨图分析为了保证交易的高可用，智能支付技术团队快速整合平台和集团技术资源，成立了专题项目组——“战狼”，聚焦支付技术底层基础，排查系统风险点和系统问题，全力为智能支付商户与客户提供一个良好、安全、顺畅的支付体验。使命必达，为核心交易系统保驾护航！
发现问题
通过排查，我们发现了系统的主要问题，从大方面说就是
外部的问题和自身的问题，当然症结在于架构的问题。
问题分类如下图所示值得一提的是如果我们业务量没有上来，这些问题本不是问题。
系统刚搭建完成好比建造了一个“土房子”，考虑自己能在里面住就可以了，而发展到四合院，就要考虑东厢、西厢等一些布局的问题，再发展到一个小区，就涉及内部道路、配套等等。
再大一点发展成一个城市，就要涉及到各种保障工作，比如下雨了怎么排水，进城要设置哪些关卡，哪些道路要放置监控等。
系统建设也是这样，一个用户基数小、日活少的系统，要考虑的主要是完成功能，随着业务量增大，就要开始涉及系统间的问题，接着去发展一些基础设施、共通组件等。
而我们目前的局面是，系统已经扩大到了“城市”的规模，我们要解决更繁重的问题。分析问题
首先我们要对目前所面临的问题进行分析。
事务中包含外部调用
外部调用包括对外部系统的调用和基础组件的调用。它具有返回时间不确定性的特征，必然会造成大事务。
大的数据库事务会造成其他对数据库连接的请求获取不到，那么和这个数据库相关的所有服务都很可能处于等待状态，造成连接池被打满，多个服务直接宕掉。如果这个没做好，
危险指数五颗星。
下面的图显示出外部调用时间的不可控 超时时间和重
试次数不合理
对外部系统和缓存、消息队列等基础组件的依赖，如果超时时间设置过长、重试过多，系统长时间不返回，可能会导致
连接池被打满，系统死掉；如果超时时间设置过短， 499 错误会增多，系统的可用性会降低。
如果超时时间设置得短，重试次数设置得多，会增加系统的
整体耗时；如果超时时间设置得短，重试次数设置得也少，
那么这次请求的返回结果会不准确。
波士顿矩阵分析图如下举个例子服务 A 依赖于两个服
务的数据完成此次操作。平时没有问题，假如服务 B 在你
不知道的情况下，响应时间变长，甚至停止服务。
而你的客户端超时时间设置过长，则你完成此次请求的响应
时间就会变长，此时如果发生意外，后果会很严重。
Java 的 Servlet 容器，无论是 Tomcat 还是 Jetty 都是多
线程模型，都用 worker 线程来处理请求。
这个可配置有上限，当你的请求打满 worker 线程的最大值
之后，剩余请求会被放到等待队列。
等待队列也有上限，一旦等待队列都满了，那这台 Web
Server 就会拒绝服务，对应到 Nginx 上返回就是 502 。
如果你的服务是 QPS 较高的服务，那基本上这种场景下，你的服务也会跟着被拖垮；如果你的上游也没有合理的设置超时时间，那故障会继续向上扩散。这种故障逐级放大的过程，就是服务雪崩效应。
外部依赖的地方没有熔断
在依赖的服务不可用时，服务调用方应该通过一些技术手段，向上提供有损服务，保证业务柔性可用。
而系统没有熔断，如果由于代码逻辑问题上线引起故障、网络问题、调用超时、业务促销调用量激增、服务容量不足等原
下载文档 收藏
分享 赏
0
- 下载文档
- 收藏
- 0
