智能支付稳定性测试实战

本文根据美团高级测试开发工程师勋伟在美团第43期技术沙龙“美团金融千万级交易系统质量保障之路”的演讲整理而成。主要介绍了美团智能支付业务在稳定性方向遇到的挑战，并重点介绍QA在稳定性测试中的一些方法与实践。

背景

美团支付承载了美团全部的交易流量，按照使用场景可以将其分为线上支付和智能支付两类业务。线上支付，支撑用户线上消费场景，处理美团所有线上交易，为团购、外卖、酒店旅游等业务线提供支付能力；智能支付，支撑用户到店消费场景，处理美团所有线下交易，通过智能POS、二维码支付、盒子支付等方式，为商家提供高效、智能化的收银解决方案。其中，智能支付作为新扩展的业务场景，去年也成为了美团增速最快的业务之一。

面临的挑战

而随着业务的快速增长，看似简单的支付动作，背后系统的复杂度却在持续提升。体现在：上层业务入口、底层支付渠道的不断丰富，微服务化背景下系统的纵向分层、服务的横向拆分，还有对外部系统（营销中心、会员中心、风控中心等）、内部基础设施（队列、缓存等）的依赖也越来越多，整条链路上的核心服务节点超过20个，业务复杂度可想而知。

此外，技术团队在短时间内就完成了从几个人到近百人规模的扩张，这也是一个潜在的不稳定因素。曾经在一段时间内，整个系统处在“牵一发而动全身”的状态，即使自身系统不做任何发版升级，也会因为一些基础设施、上下游服务的问题，业务会毫无征兆地受到影响。

痛定思痛，我们对发生过的线上问题进行复盘，分析影响服务稳定性的原因。通过数据发现，72%的严重故障集中在第三方服务和基础设施故障，对应的一些典型事故场景，比如：第三方支付通道不稳定、基础设施（如消息队列）不稳定，进而导致整个系统雪崩，当依赖方故障恢复后，我们的业务却很难立即恢复。

解决方案

基于这些问题，我们开展了稳定性建设专项，目的很明确：提升服务的可用性。目标是逐步将系统可用性从2个9提升到3个9，再向4个9去努力。这个过程中最核心的两个策略：柔性可用，意思是尽可能保证核心功能可用，或在有损情况下尽可能保证核心用户体验，降低影响；另一个是快速恢复，即用工具或机制保证故障的快速定位和解决，降低故障修复时间。

围绕这两个策略，在稳定性建设中的常见操作：限流、熔断降级、扩容，用于打造系统的柔性可用；故障响应SOP、故障自动处理，用于故障处理时的快速恢复。而QA的工作更侧重于对这些“常见操作”进行有效性验证。基于经验，重点介绍“三把利剑”：故障演练、线上压测、持续运营体系。

故障演练的由来

举个真实的案例，在一次处理某支付通道不稳定的线上问题时，开发同学执行之前已经测试通过的预案（服务端关闭该通道，预期客户端将该支付通道的开关置灰，并会提示用户使用其他支付方式），但执行中却发现预案无法生效（服务端操作后，客户端该支付通道仍处于开启状态）。非故障场景下预案功能正常，故障场景下却失效了。

这就是故障演练的由来，我们需要尽可能还原故障场景，才能真正验证预案的有效性。

故障演练的整体方案

故障演练的整体方案，主要分为三部分：

负载生成模块，负责尽可能还原系统的真实运行场景（要求覆盖核心业务流程）。
故障注入模块，包含故障注入工具、故障样本库（涵盖外部服务、基础组件、机房、网络等各种依赖，并重点关注超时、异常两种情况）。
业务验证模块，结合自动化测试用例和各个监控大盘来进行。

为了更高效地开展故障演练，我们的策略是分为两个阶段进行。首先，针对单系统进行故障演练，从故障样本库出发，全面覆盖该系统所有的保护预案；在此基础上，进行全链路故障演练，聚焦核心服务故障，验证上下游服务的容错性。

故障演练的效果

事实证明，故障演练确实给我们带来了很多“惊喜”，暴露了很多隐患。这里列举三类问题：数据库主从延迟影响交易；基础设施故障时，业务未做降级；依赖服务超时设置不合理、限流策略考虑不足等。

线上压测的由来

面对业务的指数级增长，我们必须对系统可承载的流量做到心中有数。对于QA来说，需要找到精准、高效的系统容量评估方法。我们碰到的难点包括：链路长、环节多、服务错综复杂，线下环境与线上差异大等等，基于测试有效性和测试成本考虑，我们决定要做线上压测，而且要实现全链路的线上压测。

线上压测的整体方案

全链路压测的实现方案，与业界主流方案没有太大区别。根据压测流程，首先，场景建模，以便更真实的还原线上系统运行场景；其次，基础数据构造，应满足数据类型以及量级的要求，避免数据热点；之后，流量构建，读写流量构造或回放，同时对压测流量进行标记和脱敏；再之后，压测执行，过程中收集链路各节点的业务运行状态、资源使用情况等；最后，生成压测报告。

基于全链路线上压测方案，可以根据业务需求，灵活地进行单链路压测、分层压测等。更为重要的是，基于压测我们可以进行线上的故障演练，用于更加真实的验证系统限流、熔断等保护预案。

线上压测的效果

通过全链路线上压测，一方面让我们对系统容量做到心中有数，另一方面也让我们发现了线上系统运行过程中的潜在问题，而且这些问题一般都是高风险的。同样列举三类问题：基础设施优化，如机房负载不均衡、数据库主从延迟严重等；系统服务优化，如线程池配置不合理、数据库需要拆分等；故障预案优化，如限流阈值设置过低，有的甚至已经接近限流边缘而浑然不知等等。

持续运营体系的由来

智能支付的稳定性建设是作为一个专项在做，持续了近3个月的时间；在效果还不错的情况下，我们从智能支付延伸到整个金融服务平台，以虚拟项目组的方式再次运转了3个月的时间。通过项目方式，确实能集中解决现存的大部分稳定性问题，但业务在发展、系统在迭代，稳定性建设必然是一项长期的工作。于是，QA牵头SRE、DBA、RD，建立了初步的稳定性持续运营体系，并在持续完善。