不可容忍的4个9业务高速增长下如何保证系统的稳定性和高可用？.pdf

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