美团Java团队分享：如何实践支付通道自动化管理

随着支付业务量激增，支付团队不断壮大。为了知足日益增加的业务需求，大量的支付通道逐渐接入，但因为对接的各银行和第三方系统的稳定性良莠不齐，支付通道故障时有发生，做为承接上下游的核心系统，要在一系列不稳定的系统之上创建一个能够给上游提供稳定服务的系统，仅依赖人工维护是远远不够的，因此创建一个完善的支付通道自动化管理系统势在必行。本文主要介绍美团点评技术团队支付通道自动化管理的演进之路。

初级阶段

监控系统初级阶段

故障处理流程图以下：

支付通道自动化管理的初级阶段持续时间是2014.06~2015.09，故障处理手动切走、手动切回，一次支付通道故障的详细处理流程以下：
(1) 支付网关监控检测到支付通道成功率异常，发送报警消息到美团点评技术；
(2) 美团点评技术当即查看监控页面确认故障，并登录到渠道路由配置页面去修改对应支付通道的状态，将通道置为不可用；
(3) 收银台实时读取支付通道状态，将故障通道的流量所有切走；
(4) 美团点评技术联系银行或第三方报故障，对方去查看问题，确认恢复后通知美团点评技术；
(5) 美团点评技术修改支付通道状态为可用，收银台实时读取到该支付通道，将线上流量导入；
(6) 若是支付通道恢复，则用户能够正常交易，本次故障结束；
(7) 若是支付通道未恢复，大量交易失败，美团点评技术须要将该通道从新置为不可用，再次去联系银行或第三方处理，如此往复，直到该通道的全部交易正常，本次故障结束。

半自动化阶段

初级阶段存在的问题

初级阶段系统的主要目标是扩大支付通道的覆盖范围，提升用户支付成功的几率。随着支付通道的不断接入，因为公网环境、银行或第三方系统的不稳定性，致使故障频率升高，故障时间延长。而此时处于初级阶段的监控系统已没法有效保证通道的稳定性：
(1) 支付网关监控报警漏报率较高，小流量通道故障没法及时发现；
(2) 支付通道切换都是人来手动处理，一方面技术的工做量严重增长，另外一方面没法保证在处理故障过程当中没有任何误操做；
(3) 故障解决花费的时间较长，故障对用户形成的影响就更大，同时用户的不断重试对支付系统自己也形成很大的压力；
(4) 故障通道尝试恢复时，只能所有打开用线上真实交易来检测，可能会由于通道还没有恢复，形成二次故障，扩大影响范围。

系统优化

优化监控系统

(1) 优化监控算法：优化监控算法，将报警的准确度提升到95%，基本作到无误报、无漏报；
(2) 新增自动置通道为不可用功能：监控检测到支付通道故障时，一方面发送报警消息给技术人员，另外一方面调用渠道路由的接口将支付通道置为不可用，实现支付通道故障的快速降级。

此时的监控系统以下图所示：

渠道路由支持实时通道变动

在初级系统中，渠道路由的主要功能是提供经过页面修改支付通道配置来实现人为管理支付通道的功能。随着监控系统的完善，监控准确度和灵敏度提高，此时监控系统已经具有支付通道管理的决策力，须要渠道路由提供一个能够实时更新支付通道状态的接口，以实现支付通道的自动化管理。而做为自动通道切换的补偿机制，渠道路由还实现了基于移动App人工一键切换的功能，尽最大可能保证故障的快速解决。

渠道路由提供的接口除了具有实时通道状态变动功能之外，还须要进行了如下几个方面的控制：
(1) 一键切换功能，必须控制访问权限；
(2) 具备事务控制和时效性控制，不管是自动仍是一键切换，一次故障必须能且只能切走通道流量一次；
(3) 必须保证通道状态变化能够经过各类途径通知到相关的技术人员。

故障处理流程图

支付通道自动化管理的半自动化阶段持续时间是2015.10~2016.10，故障处理自动切走、手动切回，一次通道故障的详细处理流程以下：
(1) 监控检测到通道成功率异常发送报警消息给美团点评技术，同时自动将通道置为不可用；
(2) 美团收银台实时读取通道状态，将故障通道的流量所有切走；
(3) 美团点评技术当即联系银行和第三方报故障，对方确认问题和恢复状况后反馈到美团；
(4) 美团点评技术修改通道状态为可用，收银台实时读取到通道状态为正常后，将线上流量放入该通道；
(5) 若是通道恢复，则用户能够正常交易，本次故障结束；
(6) 若是通道未恢复，大量交易失败，美团点评技术或监控会再次将通道状态为不可用；
(7) 美团点评技术再次联系银行或第三方处理故障，如此往复，直到线上交易正常，本次故障结束。

主要完成的改进点

(1) 优化报警监控算法，并支持一键查看通道状态，保证支付通道故障的快速发现；
(2) 实现故障通道一键切换和自动切换，从各方面保证通道故障快速处理；
(3) 大幅下降处理支付通道故障的人力成本。

全自动化阶段

半自动化阶段存在的问题

半自动化阶段已将故障处理流程大幅简化，但此时的系统中还存在如下问题：
(1) 通道恢复依赖于银行或第三方的反馈，致使支付通道恢复延时较久；
(2) 一次通道故障涉及到的系统和人员较多，人工没法保证全面和及时的周知。

但渠道路由因为早期设计的局限性，没法实现全自动化，须要优化监控系统和渠道路由系统。

系统优化

实现监控自动回切

监控自动回切的主要思想是对故障通道进行小幅放量，经过检测放量交易的成功率判断通道是否恢复正常。若是小幅放量的交易成功率正常则继续放量，反之则直接将通道切回故障，隔一段时间再从新开始进行放量测试，直到将通道置为正常为止。自动回切状态机以下图所示：

此过程的关键点是通道放量节奏的控制，通道放量节奏的影响要素有三个：首次放量的大小、两次放量时间间隔、通道放量速度，放量节奏太快则易形成二次故障，太慢则通道恢复过慢，没法达到缩短故障影响时间的效果。如下是最终实现的一次通道回切过程示例：

(1) 通道放量，但放量失败

(2) 再次放量，若是成功则扩大放量

(3) 通道切回正常

实现通道相关系统间联动

支付通道故障时，一方面经过消息组件通知到营销活动、退款等系统，协助进行活动下线、通道退款关闭等处理，减小通道故障对其余系统的影响；另外一方面以接口方式通知业务方系统，协助业务方系统进行故障分析。

渠道路由重构和优化

解决业务问题

支付通道有两种通道类型，第一种定义为“单卡通道”，只给指定银行的指定卡种使用的通道，好比“中国银行储蓄卡快捷通道”就只能给输入了中国银行储蓄卡卡号的请求使用；第二种定义为“跨卡通道”，能给多个银行的指定卡种使用的通道，好比“银联API储蓄卡”就能够给“中国银行储蓄卡”、“中国建设银行储蓄卡”等多个银行的储蓄卡帐号使用。

(1) 处理“跨卡通道”上某家银行故障的状况

因为老路由系统设计之初，只简单从“银行渠道”和“支付通道”两个维度考虑存储信息，设计的表结构比较简单，对于支付通道故障的状况只能切换整个通道。若是是“跨卡通道”的单个银行故障，老系统没法作到只把这故障银行流量切走——要么听任整个“跨卡通道”由于单个故障银行拉低成功率，要么切走总体通道的流量。在新路由系统中，针对每家银行的指定卡种，分别记录“跨卡通道自己不支持”和“跨卡通道支持可是银行系统故障”的两类数据，在执行路由逻辑筛选的时候就根据这些信息进行过滤，实现“跨卡通道”切走单个故障银行。

(2) 配合通道监控系统实现通道的回切放量，试探性逐步恢复通道

解决技术问题

(1) 收敛分散的业务和存储逻辑

驱使重构路由系统的一大缘由是老路由系统业务逻辑和数据存储分散、系统间的逻辑严重耦合、边界不清晰，常常在系统间模糊地段踩坑。所以，重构后须要将路由逻辑所有收敛到路由系统，这包含两个层面：

代码层面——新路由系统须要整合老路由系统逻辑（Java代码）和上游收银台中的路由逻辑（PHP），划清上下游的职责边界。
存储层面——原来收银台或者交易系统会分别从配置中心、缓存、数据库表、代码配置文件、老路由系统接口中获取不一样的数据，数据没法被集中管理。重构以后，所有数据都由新路由管理集中管理，任何上游的数据需求都经过RPC接口请求路由系统。

(2) 系统容量和时效性

因为路由逻辑和基础数据都收敛到新系统，重构后的路由将成为支付路径上的关键环节，用户在美团点评的每次支付交易至少会调用一次路由系统。根据目前美团点评的体量，这对路由系统的峰值容量提出考验。另外一方面，因为重构系统须要兼容以前的老逻辑，这会致使有些接口的响应时间达到几百毫秒甚至超过一秒，对内网调用来讲是不可接受的。

水平扩容机器是能够解决第一个问题的，可是没法解决第二个问题。基于路由的业务场景是典型的“读多写少”、且基础数据总量有限的状况，数据彻底能够缓存在业务机器上，这样能极大地减小对数据库的读取次数。采用本地缓存的方案后，系统接口响应时间由秒级降为毫秒级。因为下降了请求处理时间，一个线程的处理能力也相应提升了数十倍，系统的总体处理能力获得量级提高。

(3) 系统容灾方案

路由系统的容灾主要从两方面实现：

下降对外部组件的依赖性——“本地缓存”的引入使得路由系统处理实时业务请求时，不直接读取外部的缓存中心或者数据库，这样避免了这些基础组件可能带来的风险。

制定服务异常时的备用方案——若是路由系统异常将会直接致使用户没法支付，于是收银台系统须要对路由进行依赖降级，采用的方案是：
a. 路由系统定时从数据库中读取基础数据，并根据路由策略产生兜底数据，同步到配置中心；
b. 当路由系统异常，收银台系统将降级读取兜底数据，保证用户完成支付。

故障处理流程

支付通道自动化管理的半自动化阶段持续时间是2016.11至今，故障处理自动切走、自动切回，一次通道故障的处理流程以下：
(1) 监控检测到通道成功率异常发送报警消息给美团点评技术人员，同时自动将通道置为不可用；
(2) 收银台实时读取通道配置，收银台不会再将流量放入该通道，从而将故障通道的流量所有切走；
(3) 监控在将通道置为不可用一段时间后，尝试对故障通道放部份量进来用以检测通道是否正常；
(4) 若是放进来的这部份量成功率正常，监控则继续放2倍的量，直到通道全量，监控将通道置为可用；
(5) 若是放进来的这部份量成功率异常，则将通道直接置为不可用，监控隔一段时间后再继续进行放量，直到通道恢复为可用；
(6) 美团点评技术在发现通道故障后，能够向银行或第三方询问故障缘由，并记录，留做往后分析使用。

系统演进到这里，支付通道的管理已经基本实现了彻底自动化，只有故障缘由等附加信息须要人工获取。

主要解决的问题

(1) 渠道路由重构和优化后提供了根据配比放量的功能和通道故障发送推送消息到各个须要知道通道状态变化的系统；
(2) 监控能够根据通道当前状态和成功率状况，能够主动选择将通道置为故障、开始放量、继续放量、切回故障、置为正常等操做，检测通道是否恢复，以实现支付通道自动管理的功能；
(3) 释放了大量须要处理通道故障的人力资源；
(4) 及时周知到相关系统，下降故障影响，协助业务方系统进行故障分析。

各阶段系统优化数据对比

支付通道管理系统在故障处理上的性能对比数据以下：

阶段	初级阶段	半自动阶段	全自动阶段
平均故障响应时间	20min	1min	1min
平均人力成本	60min	43min	2min
平均故障恢复延迟	180min	180min	20min

注：
故障响应时间：从通道发生故障到通道被置为不可用的时间；
平均人力成本：故障发生期间须要耗费人力；
平均故障恢复延迟：银行或第三方真正恢复到美团打开通道入口的时间。

总结与展望

支付通道管理系统的演进过程就是一个完整的支付通道自动化管理的实践之路，自动化不只提高了系统故障处理能力，提高系统可用性，还释放了大量人力。随着支付系统的发展，后续支付通道自动化管理系统还将面临新的问题和挑战。总结实践的过程，主要有如下两点：

监控系统的完善和优化

从监控系统从单一的成功率计算到覆盖几乎全部维度，以及后续的与其余系统联动实现支付通道自动化管理的功能，对于维护和提高系统可用性和稳定性起到了很是重要的做用。

渠道路由功能的完善

渠道路由提供了通道切走和回切放量功能，与监控系统完美的配合，实现支付通道的自动化管理功能。

目前的支付通道自动化管理还须要在如下四个方面进行优化：

(1) 优化监控算法，将报警准确率95%提高到99%以上；
(2) 故障自动通知到银行或第三方技术人员，彻底释放故障处理耗费的人力；
(3) 实现银行和第三方网关网络异常的自动化处理；
(4) 渠道路由的回切放量，优先命中耐受力比较强（统计维度上客诉少）的用户进行成功率探测，以减小对业务的影响。

 推荐一个Java架构技术交流群：688583154里面有Java工程化、分布式、微服务、高性能、性能调优、Spring，MyBatis，Netty源码设计模式分析等知识点讲解与IT技术、IT职场、在线课程、学习资源分享等，特别注意：咱们是免费分享学习资源，阿里架构师分享知识，多年工做经验的梳理和总结，带着你们全面、科学地创建本身的技术体系和技术认知。进群免费领取如下架构师学习资料：