聚合支付业务作为新生力量受到各大运营商、互联网企业追捧，新建聚合支付平台，其复杂接入场景及高并发，极易发生交易故障，影响客户感知。为此，特提出聚合支付业务平台的容灾双活建设思路，并制定相应策略，为开展聚合支付业务的运营商建设者提供参考。
1 互联网金融相关概念
1.1 互联网金融
互联网金融是指传统金融与互联网技术相结合，在互联网工具下实现的金融模式创新发展。互联网金融的特性是去中心化，可以降低系统风险，资金双方可以直接对接，免除复杂的交易规则。互联网金融既可以对传统金融的产品和服务按新的形式创新，也可以全新化金融产品和服务，这就是互联网金融的基本内涵。
1.2 聚合支付
聚合支付业务汇聚了微信、支付宝、翼支付、云闪付等主流第三方移动支付能力，通过扫一个商家二维码，或一把扫码枪，或人脸识别，即可实现多种第三方支付的识别，完成交易。聚合支付业务是信息技术及互联网金融业务发生碰撞的结果。聚合支付和移动支付同样进入了运营商发展的业务范围。通过线下商户打造可以连接B端的优势，聚合支付起到场景的“连接”作用。运营商在突破移动支付和聚合支付时，对于移动支付领域的高并发处理机制的陌生，往往导致业务长时间受影响，为有效的解决单点建设单域交易问题，特提出聚合支付业务平台的容灾双活建设思路，并制定相应策略，以下对初建的聚合支付单点聚合平台简称聚合H平台。
2 现状分析
2.1 现有通道类接入的短板分析
聚合支付H平台，部署在四川A市，上游通道有2类，一类是第三方支付的汇聚商，比如拉卡拉、通联、银联、网联；一类是直连微信和支付宝等第三方支付平台，称之为直连通道。初建平台接入了1个汇聚通道T，作为主要通道。聚合支付业务的交易80%以上为单通道交易，该聚合支付的交易也占上游汇聚商聚合T通道交易的60%以上，上游T通道目前也只有南京单一机房，尚未实现分布式异地双活，即出现四川聚合支付H平台到南京机房的网络故障，尤其是光缆挖断，路由迂回后，交易链路质量难以满足交易要求，且恢复时间也较长。
2.2 聚合H平台承载的PAAS平台的短板
聚合支付H平台承载于A公司自用PAAS平台，为四川A市某机房，且互联网到聚合支付业务的路由跳数高达7条，容易出现节点故障导致业务全阻，尤其是设备故障导致的长时间业务中断，无法也无时间无途径实现“一地两中心”和基于异地灾备的“两地三中心”容灾平台体系建设。
2.3 聚合单通道接入的短板
聚合H平台的上游T通道只接入单一通道，该通道故障后，聚合H平台交易严重受阻的情况，没法进行业务的负荷分担。
3 聚合支付平台异地部署容灾双活建设思路
要能保障聚合支付交易高并发业务持续稳定运行，可参照“双核异构”整体架构，以集中+分布并存的技术路线为基础，基于弹性、融合、敏捷创新的设计思路，构建开放核心业务系统，保持大机与开放核心之间数据、服务的对等和同步，交易可随时回切，对业务运营几乎无影响” 。按国家金融应用示范案例，确保核心，周边弹性来整体设计。
双活容灾是指在两个站点同时承载业务或数据流量，当某一站点出现故障后，能在秒级将故障站点业务流量转移至另一站点，做到用户侧的无感知。即通过四川A市的单点部署，增加贵州B市的容灾节点部署，跨省、异地容灾部署。并通过单一T通道，增加备份通道，针对大型商户接入，增加直连微信、支付宝通道，结合聚合支付业务与现有资源特点，明确了达标阀值条件下的双活容灾方案。如图1所示。
图1 容灾平台异地双活原理图
3.1 达标阈值条件下的容灾思路
全业务的双活无论在资源投入，软件改造等方面的代价都非常大，稍有不慎还会带来业务灾难性后果，在设计异地多活方案中也需要找到一个适合聚合支付业务的双活方案。在故障发生时，异地节点可保证基本的交易底层能力，对于登录状态、进件能力、内部支撑能力和商户关联增值等应用暂未考虑。
3.2 双活指标设定
为实现最小代价完成聚合支付业务的异地双活目标，做有条件的异地双活是一个比较可行的方案。故障时，只确保切换的业务交易（包含确定时间后的一段时间）可用。在业务发生故障时，收到指令到人工方式切换，RTO时间控制在30分钟内，即RTO=30MIN。备注：恢复时间目标（RTO，Recovery Time Objective），指企业可容许服务中断的时间长度，是容灾平台系统核心指标之一。
根据聚合支付目前的交易架构，采用当天交易（含查询）直接读库，通过开源的Data Transit System工具进行四川侧和贵州侧的全库的数据增量同步（建设前全备后追平数据），并做好数据一致性的自动比对和预警，按照贵州的物理距离及数据库的高等级维护标准，设置RPO约等于零。备注：恢复时间目标（RPO，RecoveryPoint Objective），指当服务恢复后，恢复得来的数据所对应时间点，也是容灾平台系统核心指标之一。
3.3 业务运行方式
为了简化异地容灾平台建立的难度，将先采用日常全业务仍在四川A市的自有PAAS平台运行，当出现重大故障时，再将交易与订单查询的业务切至贵州平台，同时将对时延不敏感的业务如统计类业务指向贵州节点，这样不仅确保重点交易业务的可用性，也确保了贵州节点的热备可用能力。
3.4 数据一致性
在正常情况下由上游汇聚商T通道采用数据同步工具实时数据同步到贵州，为保证数据一致性，避免数据库的主键冲突，切换时当数据追平后，通过DTS对数据库binlog日志解析的最后GTID（贵州侧）作为切回的记录参考点。
3.5 有条件容灾切换适用条件及业务影响分析
本次涉及的聚合支付业务有条件双活容灾平台适用于四川侧发生机房、网络、系统等不可抗拒事件且短时间无法恢复，聚合支付交易几乎不可用的极端情况下，可通过切换到贵州数据中心保障聚合支付可交易不被长时间中断。由于是有条件的容灾方案，在启用贵州容灾平台前，需具备如下适应条件：四川侧NGINX可操作（可选）；四川及贵州数据库可用，且可登录操作（必备）；四川数据库到贵州数据库网络正常（必备）；DTS数据同步工具运行正常（必备）。
目前的容灾切换方案在保证聚合支付基本的交易与订单查询功能之外，其它功能均会被限制无法使用，直至四川侧平台恢复并切回。业务流量切回四川之前聚合支付交易及订单查询业务由贵州节点承接，会影响商户登陆、退款、订单查询、门店管理和渠道录入等相关非交易功能的使用。
4 容灾平台建设重要节点及准备
4.1 备用链路调试
为避免因四川侧机房到T通道汇聚点到某市机房的互联网可达性的网络故障而引起聚合支付大量交易失败问题，导致切换机房的事情发生，必须要将数据承载网作为T通道的内网备用链路，备用链路需在切换前2个月完成测试。
4.2 资源情况摸底
为便于上游汇聚商协调资源，将聚合支付需求的资源统计和上报，总体资源配置：核数和内存，公众服务组件准备等。
4.3 一致性
贵州机房按照四川机房基础镜像和服务组件、配置、部署方式进行镜像部署，上游通道商负责底层和数据库的维护，聚合支付运维团队负责应用层的维护，应用版本发布也同时两地发布，上游通道商T通道角色按照现有聚合支付维护模式中的维护团队的工作定位。
4.4 GTM切换操作
在容灾切换过程中，流量的切换是该项目成功的关键，经过评估无法采用DNS绑定或网络重定向方式完成，理论上可行，几乎没有实操性，经过多次深入的技术讨论决定采用CNAME技术通过GTM方式来切换流量，简单实用，可操作性强，只需要提前在聚合支付DNS域名侧进行贵州CNAME绑定，达到聚合支付四川侧全阻后将所有请求无感知切换到贵州容灾点。
5 容灾切换关键步骤
5.1 全切，四川侧业务切至贵州步骤
切换前准备—四川测数据路操作—数据支撑系统工具操作—贵州侧数据路操作—指向贵州—业务验证及测试。
5.2 全切，贵州侧业务切回四川步骤
DTS数据支撑系统回写—检查四川侧应用—贵州侧操作—DTS同步操作—指回四川—业务验证及测试—DTS继续同步贵州。在切换过程中，尤其要高度重视数据的同步于校核，避免支付平台的数据，或传送过程中数据被篡改。“很多商户以及集团使用聚合支付平台，那么损失的就是商户与支付平台这两家，商户有些时候对小金额的订单并没有详细的检查，包括支付平台也未对一些小金额的订单仔细的审计，导致攻击者混淆视线模拟正常的支付过程来篡改订单状态达到获取自己利益的目的” 防止篡改最好的方法，就是两边数据一致性的对比。传送前的备份数据，主用数据库数据，与切换侧数据库进行抽检。
5.3 简化版容灾切换方案
若聚合支付故障期间四川侧数据库保持正常运行，可通过GTM切换用户访问域名的方式，将用户访问的流量请求导入贵州运行，通过部署在贵州机房的应用提供给用户基本的交易与订单查询功能，数据的读写仍然保留在四川。对此方案进行了实际验证，经过测试，在实际切换过程中耗时仅1-2分钟，且无交易中断现象，交易响应时长也没有明显增长（仍能在1s左右完成交易），保证了良好的用户使用体验。
6 结语
聚合支付有条件容灾平台切换演练成功实施后，通过业务观察及验证实施效果，达到预期设定，经过优化，在人员准备到位后进行切换RPO预计可到5分钟，数据RTO为0，可以满足聚合支付业务在四川侧业务全阻的情况下将聚合支付交易能力迁移到贵州容灾机房继续承担交易业务，同时多通道的接入，有效缓解了单一通道的全阻风险。
要切实保障聚合支付平台交易底层的安全，可充分借鉴金融系统建设方式，注重加强基础管控，构建全方位的新技术风险防范体系，实施与组织架构相配套的信息系统研发过程体系，落实从需求、设计、开发、测试、运维到下线的全生命周期应用安全管理，采用安全基线的方法 ，融合多种手段，既要保障交易的安全，也要保障数据的安全。下一步需要强化数据的双向同步，可实现无感切换的双活，并同时研究 容灾节点和主用节点相互替换，即备升主、主降备的长时间运营模式下，各周边能力的适应性问题和数据防篡改问题。
