背景

 

2017年8月25日，我怀着“再也不要在下班时间收到报警”的美好期待，加入美团金融智能支付负责核心交易，结果入职后收到的报警一天紧似一天。核心交易是整个智能支付的核心链路，承担着智能支付百分之百的流量，不敢有丝毫的懈怠。

　　从17年下半年开始，我们的日单量增长迅速，而且压力和流量在午、晚高峰时段非常集中。在这种情况下，报警和小事故日益频繁，交易的稳定性面临着严峻的考验。下面是早期的可用性趋势图，仔细看的话，可以看到可用性有下降的趋势，旁边的总可用性显示只有4个9（99.998765%），美团点评排在第一的价值观是“以客户为中心”，显然对交易这种稳定性要求非常高的系统，低于5个9是不可容忍的。

启动排查

 

在很长时间里，我们做的只是在原有系统上增加功能，架构上没有大调整。但是随着业务增长，就算我们系统没有任何发版升级，也会突然出现一些事故。事故出现的频率越来越高，我们自身的升级，也经常是困难重重。基础设施升级、上下游升级，经常会发生“蝴蝶效应”，毫无征兆的受到影响。以下是这些现象的鱼骨图分析：

 

为了保证交易的高可用，智能支付技术团队快速整合平台和集团技术资源，成立了专题项目组——“战狼”，聚焦支付技术底层基础，排查系统风险点和系统问题，全力为智能支付商户与客户提供一个良好、安全、顺畅的支付体验。使命必达，为核心交易系统保驾护航！

 

发现问题

 

通过排查，我们发现了系统的主要问题，从大方面说就是：外部的问题和自身的问题，当然症结在于架构的问题。问题分类如下图所示：

 

 

值得一提的是：如果我们业务量没有上来，这些问题其实本不是问题。系统刚搭建完成好比建造了一个“土房子”，考虑自己能在里面住就可以了，而发展到四合院，就要考虑东厢、西厢等一些布局的问题，再发展到一个小区，就涉及内部道路、配套等等，再大一点发展成一个城市，就要涉及要各种保障工作，比如下雨了怎么排水，进城要设置哪些关卡，哪些道路要放置监控等。

 

系统建设也是这样，一个用户基数小、日活少的系统，要考虑的主要是完成功能，随着业务量增大，就要开始涉及系统间的问题，接着去发展一些基础设施、共通组件等，而我们目前的局面是，系统已经扩大到了“城市”的规模，我们要解决更繁重的问题。

 

分析问题

 

首先我们要对目前所面临的问题进行分析。

 

事务中包含外部调用

 

外部调用包括对外部系统的调用和基础组件的调用。它具有返回时间不确定性的特征，必然会造成大事务。大的数据库事务会造成其它对数据库连接的请求获取不到，那么和这个数据库相关的所有服务都很可能处于等待状态，造成连接池被打满，多个服务直接宕掉。如果这个没做好，危险指数五颗星。下面的图显示出外部调用时间的不可控：

 

 

超时时间和重试次数不合理

 

对外部系统和缓存、消息队列等基础组件的依赖，如果超时时间设置过长、重试过多，系统长时间不返回，可能会导致连接池被打满，系统死掉；如果超时时间设置过短，499错误会增多，系统的可用性会降低。如果超时时间设置得短，重试次数设置得多，会增加系统的整体耗时；如果超时时间设置得短，重试次数设置得也少，那么这次请求的返回结果会不准确。波士顿矩阵分析图如下：

 

举个例子：

服务A依赖于两个服务的数据完成此次操作。平时没有问题，假如服务B在你不知道的情况下，响应时间变长，甚至停止服务，而你的客户端超时时间设置过长，则你完成此次请求的响应时间就会变长，此时如果发生意外，后果会很严重。

 

Java的Servlet容器，无论是Tomcat还是Jetty都是多线程模型，都用worker线程来处理请求。这个可配置有上限，当你的请求打满worker线程的最大值之后，剩余请求会被放到等待队列。等待队列也有上限，一旦等待队列都满了，那这台Web Server就会拒绝服务，对应到Nginx上返回就是502。如果你的服务是QPS较高的服务，那基本上这种场景下，你的服务也会跟着被拖垮。如果你的上游也没有合理的设置超时时间，那故障会继续向上扩散。这种故障逐级放大的过程，就是服务雪崩效应。

 

外部依赖的地方没有熔断

 

在依赖的服务不可用时，服务调用方应该通过一些技术手段，向上提供有损服务，保证业务柔性可用。而系统没有熔断，如果由于代码逻辑问题上线引起故障、网络问题、调用超时、业务促销调用量激增、服务容量不足等原因，服务调用链路上有一个下游服务出现故障，就可能导致接入层其它的业务不可用。下图是对无熔断影响的鱼骨图分析：

 

对于依赖我们的上游没有限流

 

在开放式的网络环境下，对外系统往往会收到很多有意无意的恶意攻击，如DDoS攻击、用户失败重刷。虽然我们的队友各个是精英，但还是要做好保障，不被上游的疏忽影响，毕竟，谁也无法保证其他同学哪天会写一个如果下游返回不符合预期就无限次重试的代码。这些内部和外部的巨量调用，如果不加以保护，往往会扩散到后台服务，最终可能引起后台基础服务宕机。下图是对无限流影响的问题树分析：

 

慢查询问题

 

慢查询会降低应用的响应性能和并发性能。在业务量增加的情况下造成数据库所在的服务器CPU利用率急剧攀升，严重的会导致数据库不响应，只能重启解决。关于慢查询，可以参考我们技术博客之前的文章《MySQL索引原理及慢查询优化》。

 

依赖不合理

 

每多一个依赖方，风险就会累加。特别是强依赖，它本身意味着一荣俱荣、一损俱损。

 

废弃逻辑和临时代码

 

过期的代码会对正常逻辑有干扰，让代码不清晰。特别是对新加入的同事，他们对明白干什么用的代码可以处理。但是已经废弃的和临时的，因为不知道干什么用的，所以改起来更忐忑。如果知道是废弃的，其它功能改了这一块没改，也有可能这块不兼容，引发问题。下图是William Pietri（曾任Code for America的研发总监）定义的代码类别，不持续维护的代码从长期成本来说是很高的：

 

没有有效的资源隔离

 

容易造成级联多米诺骨牌效应。

针对上述问题，我们提出了解决方案。

 

 

解决问题

 

1. 事务中不包含外部调用

 

• 排查各个系统的代码，检查在事务中是否存在RPC调用、HTTP调用、消息队列操作、缓存、循环查询等耗时的操作，这个操作应该移到事务之外，理想的情况是事务内只处理数据库操作。

• 对大事务添加监控报警。大事务发生时，会收到邮件和短信提醒，一般的报警标准是1s。

• 建议不要用XML配置事务，而采用注解的方式。原因是XML配置事务，第一可读性不强，第二切面通常配置的比较泛滥，容易造成事务过大，第三对于嵌套情况的规则不好处理。

 

 

2. 超时时间设置合理和重试次数

 

• 首先要调研被依赖服务自己调用下游的超时时间是多少。调用方的超时时间要大于被依赖方调用下游的时间。

• 统计这个接口99%的超时时间是多少