美团点评智能支付核心交易系统的可用性实践

本文是我原创，原文首发于美团点评技术博客，原文地址是：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较高的服务，那基本上这种场景下，你的服务也会跟着被拖垮。若是你的上游也没有合理的设置超时时间，那故障会继续向上扩散。这种故障逐级放大的过程，就是服务雪崩效应。

解决方法：

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

• 统计这个接口99%的响应时间是多少，设置的超时时间在这个基础上加50%。若是接口依赖第三方，而第三方的波动比较大，也能够按照95%的响应时间。

• 重试次数若是系统服务重要性高，则按照默认，通常是重试三次。不然，能够不重试。

1.4    解决慢查询

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

 

解决方法：

• 将查询分红实时查询、近实时查询和离线查询。实时查询可穿透数据库，其它的不走数据库，能够用Elasticsearch来实现一个查询中心，处理近实时查询和离线查询。

• 读写分离。写走主库，读走从库。

• 索引优化。索引过多会影响数据库写性能。索引不够查询会慢。DBA建议一个数据表的索引数不超过4个。

• 不容许出现大表。MySQL数据库的一张数据表当数据量达到千万级，效率开始急剧降低。

1.5 熔断

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

 

解决方法：

• 自动熔断：可使用Netflix的Hystrix或者美团点评本身研发的Rhino来作快速失败。

• 手动熔断：确认下游支付通道抖动或不可用，能够手动关闭通道。

 

2. 发生频率要低之本身不做死

 

本身不做死要作到两点：第一本身不做，第二本身不死。

2.1 不做

关于不做，我总结了如下7点：

1>不当小白鼠：只用成熟的技术，不因技术自己的问题影响系统的稳定。
2>职责单一化：不因职责耦合而削弱或抑制它完成最重要职责的能力。
3>流程规范化：下降人为因素带来的影响。
4>过程自动化：让系统更高效、更安全的运营。
5>容量有冗余：为了应对竞对系统不可用用户转而访问咱们的系统、大促来临等状况，和出于容灾考虑，至少要保证系统2倍以上的冗余。
6>持续的重构：持续重构是确保代码长期没人动，一动就出问题的有效手段。
7>漏洞及时补：美团点评有安全漏洞运维机制，提醒督促各个部门修复安全漏洞。

 

2.2 不死

关于不死，地球上有五大不死神兽：能在恶劣环境下中止新陈代谢的“水熊虫”；能够返老还童的“灯塔水母”；在硬壳里休养生息的“蛤蜊”；水、陆、寄生样样都成的“涡虫”；有隐生能力的“轮虫”。它们的共通特征用在系统设计领域上就是自身容错能力强。这里“容错”的概念是：使系统具备容忍故障的能力，即在产生故障的状况下，仍有能力将指定的过程继续完成。容错便是Fault Tolerance，确切地说是容故障(Fault)，而并不是容错误(Error)。

 

 

3. 发生频率要低之不被别人搞死

3.1 限流

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

 

解决方法：

• 经过对服务端的业务性能压测，能够分析出一个相对合理的最大QPS。

• 流量控制中用的比较多的三个算法是令牌桶、漏桶、计数器。可使用Guava的RateLimiter来实现。其中SmoothBurstry是基于令牌桶算法的，SmoothWarmingUp是基于漏桶算法的。

• 核心交易这边采用美团服务治理平台OCTO作thrift截流。可支持接口粒度配额、支持单机/集群配额、支持指定消费者配额、支持测试模式工做、及时的报警通知。其中测试模式是只报警并不真正节流。关闭测试模式则超过限流阈值系统作异常抛出处理。限流策略能够随时关闭。

• 可使用Netflix的Hystrix或者美团点评本身研发的Rhino来作特殊的针对性限流。

 

4. 故障范围要小之隔离

隔离是指将系统或资源分割开，在系统发生故障时能限定传播范围和影响范围。

服务器物理隔离原则

① 内外有别：内部系统与对外开放平台区分对待。
② 内部隔离：从上游到下游按通道从物理服务器上进行隔离，低流量服务合并。
③ 外部隔离：按渠道隔离，渠道之间互不影响。

线程池资源隔离

• Hystrix经过命令模式，将每一个类型的业务请求封装成对应的命令请求。每一个命令请求对应一个线程池，建立好的线程池是被放入到ConcurrentHashMap中。
  注意：尽管线程池提供了线程隔离，客户端底层代码也必需要有超时设置，不能无限制的阻塞以至于线程池一直饱和。

信号量资源隔离

• 开发者可使用Hystrix限制系统对某一个依赖的最高并发数，这个基本上就是一个限流策略。每次调用依赖时都会检查一下是否到达信号量的限制值，如达到，则拒绝。

 

5. 故障恢复要快之快速发现

发现分为事前发现、事中发现和过后发现。事前发现的主要手段是压测和故障演练；事中发现的主要手段是监控报警；过后发现的主要手段是数据分析。

5.1 全链路线上压测

你的系统是否适合全链路线上压测呢?通常来讲，全链路压测适用于如下场景：

① 针对链路长、环节多、服务依赖错综复杂的系统，全链路线上压测能够更快更准确的定位问题。
② 有完备的监控报警，出现问题能够随时终止操做。
③ 有明显的业务峰值和低谷。低谷期就算出现问题对用户影响也比较小。

全链路线上压测的目的主要有：

① 了解整个系统的处理能力
② 排查性能瓶颈
③ 验证限流、降级、熔断、报警等机制是否符合预期并分析数据反过来调整这些阈值等信息
④ 发布的版本在业务高峰的时候是否符合预期
⑤ 验证系统的依赖是否符合预期

全链路压测的简单实现：

① 采集线上日志数据来作流量回放，为了和实际数据进行流量隔离，须要对部分字段进行偏移处理。
② 数据着色处理。能够用中间件来获取和传递流量标签。
③ 能够用影子数据表来隔离流量，可是须要注意磁盘空间，建议若是磁盘剩余空间不足70%采用其余的方式隔离流量。
④ 外部调用可能须要Mock。实现上能够采用一个Mock服务随机产生和线上外部调用返回时间分布的时延。

压测工具上，核心交易这边使用美团点评开发的pTest。

 

 

6. 故障恢复要快之快速定位

定位须要靠谱的数据。所谓靠谱就是和要发现的问题紧密相关的，无关的数据会形成视觉盲点，影响定位。因此对于日志，要制定一个简明日志规范。另外系统监控、业务监控、组件监控、实时分析诊断工具也是定位的有效抓手。

 

 

7. 故障恢复要快之快速解决

要解决，提早是发现和定位。解决的速度还取决因而自动化的、半自动化的仍是手工的。核心交易有意向搭建一个高可用系统。咱们的口号是：“不重复造轮子，用好轮子。”这是一个集成平台，职责是：“聚焦核心交易高可用，更好、更快、更高效。”

美团点评内部可使用的用于发现、定位、处理的系统和平台很是多，可是若是一个个打开连接或者登录系统，势必影响解决速度。因此咱们要作集成，让问题一站式解决。但愿达到的效果举例以下：

 

工具介绍

Hystrix

Hystrix实现了断路器模式来对故障进行监控，当断路器发现调用接口发生了长时间等待，就使用快速失败策略，向上返回一个错误响应，这样达到防止阻塞的目的。这里重点介绍一下Hystrix的线程池资源隔离和信号量资源隔离。

线程池资源隔离

 

优势

• 使用线程能够彻底隔离第三方代码，请求线程能够快速放回。

• 当一个失败的依赖再次变成可用时，线程池将清理，并当即恢复可用，而不是一个长时间的恢复。

• 能够彻底模拟异步调用，方便异步编程。

缺点

• 线程池的主要缺点是它增长了CPU，由于每一个命令的执行涉及到排队（默认使用SynchronousQueue避免排队），调度和上下文切换。

• 对使用ThreadLocal等依赖线程状态的代码增长复杂性，须要手动传递和清理线程状态（Netflix公司内部认为线程隔离开销足够小，不会形成重大的成本或性能的影响）。

信号量资源隔离

开发者可使用Hystrix限制系统对某一个依赖的最高并发数。这个基本上就是一个限流策略，每次调用依赖时都会检查一下是否到达信号量的限制值，如达到，则拒绝。

 

优势

• 不新起线程执行命令，减小上下文切换。

缺点

• 没法配置断路，每次都必定会去尝试获取信号量。

比较一下线程池资源隔离和信号量资源隔离

• 线程隔离是和主线程无关的其余线程来运行的；而信号量隔离是和主线程在同一个线程上作的操做。

• 信号量隔离也能够用于限制并发访问，防止阻塞扩散，与线程隔离的最大不一样在于执行依赖代码的线程依然是请求线程。

• 线程池隔离适用于第三方应用或者接口、并发量大的隔离；信号量隔离适用于内部应用或者中间件；并发需求不是很大的场景。

   

Rhino

Rhino是美团点评基础架构团队研发并维护的一个稳定性保障组件，提供故障模拟、降级演练、服务熔断、服务限流等功能。和Hystrix对比：

• 内部经过CAT（美团点评开源的监控系统，参见以前的博客“深度剖析开源分布式监控CAT”）进行了一系列埋点，方便进行服务异常报警。

• 接入配置中心，能提供动态参数修改，好比强制熔断、修改失败率等。

总结思考

王国维 在《人间词话》里谈到了治学经验，他说：古今之成大事业、大学问者，必通过三种之境界：

第一种境界
昨夜西风凋碧树。独上高楼，望尽天涯路。
第二种境界
衣带渐宽终不悔，为伊消得人憔悴。
第三种境界
众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。

核心交易的高可用目前正在经历第一种：高瞻远瞩认清前人所走的路，以总结和学习前人的经验作为起点。

下一阶段，既然认定了目标，咱们会呕心沥血孜孜以求，持续发展高可用。最终，当咱们作了不少的事情，回过头来看，相信会对高可用有更清晰和深刻的认识。敬请期待咱们下一次的分享~~

关于做者

晓静，20岁时毕业于东北大学计算机系。在毕业后的第一家公司因为出众的语言天赋，在1年的时间里从零开始学日语并以超高分经过了国际日语一级考试，担当两年日语翻译的工做。后就任于人人网，转型作互联网开发。中国科学院心理学研究生。有近百个技术发明专利，创业公司合伙人。有日本东京，美国硅谷技术支持经验。目前任美团点评技术专家，负责核心交易。（欢迎关注静儿的我的技术公众号：编程一辈子  ） 

 

 

----------  END  ----------

招聘信息

美团金融核心交易招聘实习生，要求：19年即将毕业的研究生，Java方向，有技术追求。高速发展的业务须要高速发展的团队，做为核心部门，咱们急需相信技术改变世界的你！有意者请关注个人我的技术公众号并留言。