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

接口监控可以针对牢靠host IP绑定以及配置超时时刻，监控哀求支持GET、POST两种方法，POST方法可以配置牢靠哀求参数帮助，监控频率支持分钟、秒两种级别设置；相应数据模块可以校验HTTP code是否非常，设置相应数据范例，较量检测返回key值，针对DB监控还可以配置DB查询超时时刻；报警模块今朝支持短信和邮件两种方法，可以配置最小、最大报警阈值，高出最大阈值每隔最大报警数会触发一次报警，规避了妨碍时代短信轰炸题目。

（2）监控焦点

为了实现最快监控频率10秒，同时可以支持成千上万的监控项并行运行，付出监控回收了多历程打点的方法。父历程建设指定命量的子历程，每个子历程完成牢靠命量的监控使命退出使命，此时父历程及时监控子历程状态并建设新的子历程执利用命；父历程还可以接管外部信号完成处事重启以及遏制，流程如下：

（3）监控报警

执行监控项会按照监控设置举办接口哀求以及返回数据说明处理赏罚，然后通过Redis计数方法按报警计策举办报警关照。一般监控短信示例：

2.3实践履历

（1）数据同等性

上文提到，我们回收模块化的方法来解耦营业成果与付出成果。在这个进程中，每引入一个模块就会涉及到体系交互题目，因此最焦点的即是数据同等性题目。针对数据同等性题目必要引入事宜，及时、耽误校验以及赔偿机制担保数据的最终同等性。从架构看是很清楚的，可是对付整个改革进程是艰巨的，如同给航行的飞机改换动员机，以是我们也把这个进程形容为一个刮骨疗伤的阶段。

（2）不变性

付出处事都是由第三方付出通道提供的，付出通道存在不不变性。好比用户用付出宝付出了一笔订单，因为各类缘故起因，付出中心没有收到付出乐成的关照，用户又用微信再次付款，导致一再付出。

为了办理这个题目，付出中心回收按时扫描的计策，主动发明一再付出单并自动执行退款，不必要人工参加。退款流程中，退款单必要颠末申请、考核、挪用退款接口等流程，在调接口环节，也许会产生失败。挪用失败的退款单，会按照退避算法提倡重试，逐渐加大重试隔断，直到次数高出限定。失败单数目高出阈值、可能有订单处于失败时刻高出阈值时会触发报警。自动处理赏罚不了的退款单可以人工检测，或线下退款。

总结&瞻望

今朝，马蜂窝付出中心已经具备支持多营业、多场景、多付出方法的手段，但想要实现一个真正意义上「百花齐放」的平台，尚有许多处所必要改造和完美。

即将到来的付出中心3.0将以微处事的头脑把单体应用凭证营业举办解耦，会逐渐从一个高耦合的单一体系演变为浩瀚子体系构成的高并发、高可用、支持更多买卖营业付出场景的漫衍式体系。微处事化拆分后，在体系布局大将越发清楚，但对付整系一切的开拓打点和维护也将带来更大的挑衅。

陪伴马蜂窝「内容+买卖营业」的计谋进级，付出中心也会试探更多的付出方法和手段，一连为各营业线赋能。（来历：架构文摘 文/马蜂窝电商付出结算团队 编选：）

（编辑：湖南网）

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