随着支付业务量激增，支付团队不断壮大。为了满足日益增长的业务需求，大量的支付通道逐渐接入，但由于对接的各银行和第三方系统的稳定性参差不齐，支付通道故障时有发生，作为承接上下游的核心系统，要在一系列不稳定的系统之上建立一个可以给上游提供稳定服务的系统，仅依赖人工维护是远远不够的，所以建立一个完善的支付通道自动化管理系统势在必行。本文主要介绍美团点评技术团队支付通道自动化管理的演进之路。
监控系统初级阶段
故障处理流程图如下：
支付通道自动化管理的初级阶段持续时间是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职场、在线课程、学习资源分享等，特别注意：我们是免费分享学习资源，阿里架构师分享知识，多年工作经验的梳理和总结，带着大家全面、科学地建立自己的技术体系和技术认知。进群免费领取以下架构师学习资料：
相关文章
