本文是我原创，原文首发于美团点评技术博客，原文地址是：https://mp.weixin.qq.com/s/pxNRzWs3sZmbr-K18FvnrA

 

背景

每个系统都有它最核心的指标。比如在收单领域：进件系统第一重要的是保证入件准确，第二重要的是保证上单效率。清结算系统第一重要的是保证准确打款，第二重要的是保证及时打款。我们负责的系统是美团点评智能支付的核心链路，承担着智能支付100%的流量，内部习惯称为核心交易。因为涉及美团点评所有线下交易商家、用户之间的资金流转，对于核心交易来说：第一重要的是稳定性，第二重要的还是稳定性。

问题引发

作为一个平台部门，我们的理想是第一阶段快速支持业务；第二阶段把控好一个方向；第三阶段观察好市场的方向，自己去引领一个大方向。

理想很丰满，现实是自从2017年初的每日几十万订单，到年底时，单日订单已经突破700万，系统面临着巨大的挑战。支付通道在增多；链路在加长；系统复杂性也相应增加。从最初的POS机到后来的二维码产品，小白盒、小黑盒、秒付……产品的多元化，系统的定位也在时刻的发生着变化。而系统对于变化的应对速度像是一个在和兔子赛跑的乌龟。

 

 

由于业务的快速增长，就算系统没有任何发版升级，也会突然出现一些事故。事故出现的频率越来越高，系统自身的升级，也经常是困难重重。基础设施升级、上下游升级，经常会发生“蝴蝶效应”，毫无征兆的受到影响。

 

问题分析

核心交易的稳定性问题根本上是怎么实现高可用的问题。

可用性指标

业界高可用的标准是按照系统宕机时间来衡量的：

 

因为业界的标准是后验的指标，考虑到对于平时工作的指导意义，我们通常采用服务治理平台OCTO来统计可用性。计算方法是：

 

可用性分解

业界系统可靠性还有两个比较常用的关键指标：

• 平均无故障时间(Mean Time Between Failures，简称MTBF)：即系统平均能够正常运行多长时间，才发生一次故障

• 平均修复时间(Mean Time To Repair，简称MTTR)：即系统由故障状态转为工作状态时修理时间的平均值

对于核心交易来说，可用性最好是无故障。在有故障的时候，判定影响的因素除了时间外，还有范围。将核心交易的可用性问题分解则为：

 

问题解决

1. 发生频率要低之别人死我们不死

1.1 消除依赖、弱化依赖和控制依赖

用STAR法则举一个场景：

情境(situation)

我们要设计一个系统A，完成：使用我们美团点评的POS机，通过系统A连接银行进行付款，我们会有一些满减，使用积分等优惠活动。

任务(task)

分析一下对于系统A的显性需求和隐性需求：

1>需要接收上游传过来的参数，参数里包含商家信息、用户信息、设备信息、优惠信息。
2>生成单号，将交易的订单信息落库。
3>敏感信息要加密。
4>要调用下游银行的接口。
5>要支持退款。
6>要把订单信息同步给积分核销等部门。    
7>要能给商家一个查看订单的界面。
8>要能给商家进行收款的结算。
基于以上需求，分析一下怎样才能让里面的最核心链路“使用POS机付款”稳定。

  行动(action)

分析一下：需求1到4是付款必需链路，可以做在一个子系统里，姑且称之为收款子系统。5到8各自独立，每个都可以作为一个子系统来做，具体情况和开发人员数量、维护成本等有关系。

值得注意的是需求5-8和收款子系统的依赖关系并没有功能上的依赖，只有数据上的依赖。即他们都要依赖生成的订单数据。

收款子系统是整个系统的核心，对稳定性要求非常高。其他子系统出了问题，收款子系统不能受到影响。

基于上面分析，我们需要做一个收款子系统和其他子系统之间的一个解耦，统一管理给其他系统的数据。这里称为“订阅转发子系统”，只要保证这个系统不影响收款子系统的稳定即可。

粗略架构图如下：

 

结果(result)

从上图可以看到，收款子系统和退款子系统、结算子系统、信息同步子系统、查看订单子系统之间没有直接依赖关系。这个架构达到了消除依赖的效果。收款子系统不需要依赖数据订阅转发子系统，数据订阅转发子系统需要依赖收款子系统的数据。我们控制依赖，数据订阅转发子系统从收款子系统拉取数据，而不需要收款子系统给数据订阅转发子系统推送数据。这样，数据订阅转发子系统挂了，收款子系统不受影响。

再说数据订阅转发子系统拉取数据的方式。比如数据存在MySQL数据库中，通过同步Binlog来拉取数据。如果采用消息队列来进行数据传输，对消息队列的中间件就有依赖关系了。如果我们设计一个灾备方案：消息队列挂了，直接RPC调用传输数据。对于这个消息队列，就达到了弱化依赖的效果。

1.2 事务中不包含外部调用

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

 

解决方法：

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

• 对大事务添加监控报警。大事务发生时，会收到邮件和短信提醒。针对数据库事务，一般分为1s以上、500ms以上、100ms以上三种级别的事务报警。

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

•  

  

1.3    设置合理的超时和重试

对外部系统和缓存、消息队列等基础组件的依赖。假设这些被依赖方突然发生了问题，我们系统的响应时间是：内部耗时+依赖方超时时间*重试次数。如果超时时间设置过长、重试过多，系统长时间不返回，可能会导致连接池被打满，系统死掉；如果超时时间设置过短，499错误会增多，系统的可用性会降低。

举个例子：

 

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

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

解决方法：

• 首先要调研被依赖服务