大众点评支付渠道网关系统的实践之路

最近读了大众点评的一篇网关系统优化的文章,特记录一些有用的知识点

核心思路是大系统做小,做简单

能用阶段

短平快,直接对接渠道,无过多可以描述的

可用阶段

存在的问题:
1、所有的业务逻辑都在同一个物理部署单元,不同业务之间相互影响(如避免退款业务出现问题拖垮支付业务)
2、随着业务流量增大,数据库压力增大,偶尔波动,对用户支付体验大
3、支付退款等状态的同步依赖第三方支付的异步通知,一旦第三方支付出现问题较被动

解决方案
问题1:拆服务
按照渠道拆分,不同的第三方支付渠道独立一个物理部署单元,例如微信一个,支付宝一个。。。
按照业务类型拆分,不同业务独立一个物理部署单元,例如退款一个,支付一个

最终选择了按照业务拆分,这才是正常的选择!包括查询服务等之类都应该进行拆分

问题2:
解决方案Master-Slave 使用了中间件Zebra来做负载均衡和灾备切换,其实数据库还是一个瓶颈的,而且真正短时间内数据库服务挂掉的话,是否还是不敢将从库切为主库?

问题3:
主动查询,后台补单,较正常的操作

柔性可用阶段

新的挑战:
1、新同学按照自己习惯接入,尤其第三方渠道对接http服务就多个。。。
2、故障服务,会使之RPC连接池占用,拖垮重启服务后,依旧会被故障渠道击垮
3、针对SDK业务,渠道网关无法获悉用户未支付是否因为某个第三方网关内部故障
4、共享DB,容易被其他业务影响
5、退款链路异常case未进行统一收集、整理并分类,缺乏清晰的退款链路监控。

解决方案:
问题1:
收集整理不同的应用场景,抽象出一套接入框架。定义请求组装、请求执行、响应解析和错误重试等一整套网关交互流程,屏蔽了底层的HTTP或Socket交互细节,并提供响应的扩展点。

针对银行接入存在前置机这种特殊应用场景,基于Netty抽象出连接池(Conn Pool)和简单的负载均衡机制(LB,提供Round Robin路由策略)。

不同渠道在接入时可插入自定义的组装策略(扩展已有的HttpReq、HttpsReq或NettyReq),执行策略[扩展已有(Http、Https或Netty)Sender/Receiver],解析策略(扩展已有的HttpResp、HttpsResp或NettyResp),并复用框架已提供的内容解析(binary/xml/json parser)、证书加载(keystore/truststore loader)和加解密签名(encrypt/decrypt/sign/verify sign)组件,从而在达到提高渠道接入效率的同时,尽可能减少新渠道接入带来的风险。

问题2:隔离
我们直接将渠道隔离的最小粒度定义到支付渠道 -> 支付方式 -> 银行。

在fail-fast事务执行过程中,级联有2个fail-fast断路开关:
静态开关,根据人工配置(on/off),断定某个支付请求是否需快速失败。
动态开关,根据历史统计信息,确定当前健康状态,进而断定是否快速失败当前支付请求。

动态断路开关抽象了3种健康状态(closed-放行所有请求;half_open-部分比例的请求放行;open-快速失败所有请求),并依据历史统计信息(总请求量/请求失败量/请求异常量/请求超时量),在其内部维护了一个健康状态变迁的状态机。我们在此基础上增加了自动切换,主备两个渠道,优先自动切换,如果切换后备渠道还是有问题,那么开始执行类似部分比例放行这种情况

状态机的每一次状态变迁都会产生一个健康状态事件,收银台服务可以监听这个健康状态事件,实现支付渠道的联动上下线切换。

每一笔支付请求结束后都会动态更新历史统计信息。

问题3:
成功率监控

问题4:
独享DB

问题5:
退款异常case收集

总结

在整个渠道网关系统一步步的完善过程中,踩过很多坑,吃过很多教训,几点小的收获:
坚持核心思想,拆分、解耦,大系统做小,做简单;
系统总会有出问题的时候,重要的是如何快速定位、恢复、解决问题,这是一个长期而又艰巨的任务;
高可用性的最大敌人不仅是技术,还是使用技术实现系统的人,如何在业务、系统快速迭代的过程中,保证自我驱动,不掉队;
高流量,大并发对每一个工程师既是挑战,更是机遇。

感谢!文章参考整理:序列化与反序列化

0条留言