【金融案例】马蜂窝支付中心架构演进

接口监控可以针对固定host IP绑定以及设置超时时间，监控请求支持GET、POST两种方式，POST方式可以设置固定请求参数辅助，监控频率支持分钟、秒两种级别配置；响应数据模块可以校验HTTP code是否异常，配置响应数据类型，比较检测返回key值，针对DB监控还可以设置DB查询超时时间；报警模块目前支持短信和邮件两种方式，可以设置最小、最大报警阈值，超过最大阈值每隔最大报警数会触发一次报警，规避了故障期间短信轰炸问题。

（2）监控核心

为了实现最快监控频率10秒，同时可以支持成千上万的监控项并行运行，支付监控采用了多进程管理的方式。父进程创建指定数量的子进程，每个子进程完成固定数量的监控任务退出任务，此时父进程实时监控子进程状态并创建新的子进程执行任务；父进程还可以接受外部信号完成服务重启以及停止，流程如下：

（3）监控报警

执行监控项会根据监控配置进行接口请求以及返回数据分析处理，然后通过Redis计数方式按报警策略进行报警通知。日常监控短信示例：

2.3实践经验

（1）数据一致性

上文提到，我们采用模块化的方式来解耦业务功能与支付功能。在这个过程中，每引入一个模块就会涉及到系统交互问题，因此最核心的便是数据一致性问题。针对数据一致性问题需要引入事务，实时、延迟校验以及补偿机制保证数据的最终一致性。从架构看是很清晰的，但是对于整个改造过程是艰难的，犹如给飞行的飞机更换发动机，所以我们也把这个过程形容为一个刮骨疗伤的阶段。

（2）稳定性

支付服务都是由第三方支付通道提供的，支付通道存在不稳定性。比如用户用支付宝支付了一笔订单，由于各种原因，支付中心没有收到支付成功的通知，用户又用微信再次付款，导致重复支付。

为了解决这个问题，支付中心采用定时扫描的策略，主动发现重复支付单并自动执行退款，不需要人工参与。退款流程中，退款单需要经过申请、审核、调用退款接口等流程，在调接口环节，可能会发生失败。调用失败的退款单，会根据退避算法发起重试，逐渐加大重试间隔，直到次数超过限制。失败单数量超过阈值、或者有订单处于失败时间超过阈值时会触发报警。自动处理不了的退款单可以人工检测，或线下退款。

总结&展望

目前，马蜂窝支付中心已经具备支持多业务、多场景、多支付方式的能力，但想要实现一个真正意义上「百花齐放」的平台，还有很多地方需要改进和完善。

即将到来的支付中心3.0将以微服务的思想把单体应用按照业务进行解耦，会逐渐从一个高耦合的单一系统演变为众多子系统组成的高并发、高可用、支持更多交易支付场景的分布式系统。微服务化拆分后，在系统结构上将更加清晰，但对于整体系统的开发管理和维护也将带来更大的挑战。

伴随马蜂窝「内容+交易」的战略升级，支付中心也会探索更多的支付方式和能力，持续为各业务线赋能。（来源：架构文摘 文/马蜂窝电商支付结算团队 编选：）

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!