00-聚合支付架构从零到一
0 前言
聚合支付重要是就是一个将所有的第三方支付，通过借助形式融合在一起，相当于对接一个支付接口，就可以使用各种支付的场景。如便利店购物，贴个码，上有微信支付，支付宝等各种支付。
它重要是针对一个微小商户进行一个收款工具，让商家他那里会有一个收钱吧商户通，第一个可以实时的收听语音陈诉，当前用户付款多少钱，第二个就是他可以去实时查察账单，了解当天业务额。
还有一个产物就是pos机，重要是一款生态 pos，它内里不仅继续了我们一个我们这个具备支付体系提供的服务，就好比微信支付宝，它们还集成了一个刷卡的功能，就是磁条卡芯片卡，还有各种支付方式。本文聚合支付只涉及交易流，不涉及资金流。
1 V1.0体系
-
工期短
根本上所有新项目都这尿性，天天被领导鞭策赶进度
-
业务不熟
不知道聚合支付到底做啥的，支付流程啥样？究竟每个公司支付业务实在完全不一样，无法照搬！
-
交易量小
当时的交易量是只有前端的一两个产物在使用，天天的交易笔数也很小
-
人员缺乏
新成立的团队做新项目研发，那就只有我和另一十年老鸟同事
该背景下完成 V1.0体系架构，即虚线圈，具体分工：
直接操作 DB 没做甚至缓存的优化。
- 交易前置：支付焦点业务处理，如记录商户交易流水、对接各个支持服务
- 风控体系：交易单日/单笔限额、商户黑名单、欺诈行为辨认等风险因素控制
- 路由体系：通过设定的优先级、限额等路由规则，选择合适的渠道，保证成功率，降低本钱
- 交易网关：负责所有支付渠道的报文包装、数据加密、协议转换、署名验证、状态映射
当时就做这样简朴架构，第一个开发比较快，直接拿需求进行改代码，方便测试以及上线。经几个月交易猛增，发现
2 体系瓶颈
2.1 渠道隔离
当时对接了几个渠道，特别渠道不稳定的话，如资源不可用、网络问题，导致超时，就会把所有渠道交易全部影响，级联反应导致交易链路雪崩。体系哪边挂了之后立马要赶紧接洽。所以说这个渠道隔离放在第一位首要的。
2.2 接口膨胀
特别涉及相似业务的，如消费、撤销、退款接口，就每个业务类型都有这几个接口，随业务发展，也难维护，开发每次来个需求都思量到底是改哪个接口，要不要都改。
2.3 动态扩容
聚合支付很多交易异步，用户下单时，我们会立即返回就下单成功，大概下单失败，但是这个交易有没有消费成功，我们须要设置定时的任务去查询终极付款效果。
2.4 定时调度
它需定时、定点、定量拉取订单处理，如拉取数据太多OOM，太少很多交易得不到实行。分布式下如何充实提拔并发前提下充实使用呆板资源变紧迫。
2.5 设置分散
传统将设置文件存放在每个节点，每次升级都要运维手动改。风险高且不好维护。
3 V2.0体系
3.1 设计方向
- 稳定：支付体系的根基
- 支付体验：用户使用支付功能时感知零耽误
- 低耦合：模块间淘汰依靠，需求变更风险控制在最小范围
过程试了多种方案，终极演变如下体系架构：
服务划分三条线，绿色和中间赤色和最下面一条橙色：
-
绿色：交易焦点、交易网关
-
任务作业和查询网关，独立摆设
这俩业务线通过MQ解耦。
3.2 业务流程
业务发起一笔消费，先辈入支付焦点初始化流水、风控风险辨认、渠门路由、渠道网关报文组装、上送、渠道应答。异步交易发送消息至 MQ 集群，任务作业监听消息，put 缓存，定时任务拉取进行状态查询，业务方通过查询服务查察该笔交易支付状态。
3.3 前置优化水平方向
- 接入层：将共性接口统一。如下单，所有业务，不管微信支付还是啥，都归为下单，具体业务通过 serviceId 标识
- 服务层：共性逻辑，也就是焦点逻辑全部抽离出来，然后进行统一下沉，作为底层服务，上层业务全部通过 serviceId 设置化实现，这样的话尽量去少改动焦点业务逻辑
- 缓存层：随交易量增长，初代体系很多业务查询直连DB，有很大性能影响。所以就在 DB 之上将所有消费交易信息缓存，后续所有查询、更新操作全部打到缓存层，重要为提拔服务性能
3.4 前置优化垂直拆分
- 焦点交易：交易焦点链路，用户感知最显着。如支付失败，用户立马感知，投诉或电话客服，该模块也包含退款业务
- 任务作业：将处理中的交易进行状态同步，和焦点交易通过MQ解耦
- 查询服务：仅对公司内部提供一个交易状态查询功能
3.5 任务作业
内部查询计谋设计为两个队列、一个批处理：
-
内存队列：实现如耽误10s、隔断5s或很多银使用用 2 的 N 次方进行查询
该队列重要针对单笔交易实行快速状态同步，提拔用户体验
<blockquote class="multiquote-1" style="margin-top: 20px; margin-bottom: 20px; margin-left: 0px; margin-right: 0px; padding-top: 10px; padding-bottom: 10px; padding-left: 20px; padding-right: 10px; border-top-style: none; border-bottom-style: none; border-left-style: solid; border-right-style: none; border-top-width: 3px; border-bottom-width: 3px; border-left-width: 3px; border-right-width: 3px; border-top-color: rgba(0, 0, 0, 0.4); border-bottom-color: rgba(0, 0, 0, 0.4); border-left-color: rgba(0, 0, 0, 0.4); border-right-color: rgba(0, 0, 0, 0.4); border-top-left-radius: 0px; border-top-right-radius: 0px; border-bottom-right-radius: 0px; border-bottom-left-radius: 0px; background-attachment: scroll; background-clip: border-box; background-color: rgba(0, 0, 0, 0.05); background-image: none; background-origin: padding-box; background-position-x: 0%; background-position-y: 0%; background-repeat: no-repeat; background-size: auto; width: auto; height: auto; box-shadow: rgba(0, 0, 0, 0) 0px 0px 0px 0px; display: block; overflow-x: auto; overflow-y: auto;"> "2的N次方进行查询"这个计谋一样平常是在体系设计中对于状态查询的优化计谋。如一个操作须要查询外部体系以确认状态，第一次查询在操作完成后立即实行，若没有得到确认，那就等待一些时间后再查询一次。这里的"等待一些时间"就可能采取"2的N次方"的隔断计谋。 如第一次查询失败后，体系会等待2^1（也就是2）秒再查询一次，如果还是失败，那就等待2^2（也就是4）秒后再次查询，以此类推。这样做的利益在于可以制止在接口繁忙的时间造成过分查询，对接口进行压力保护，同时也节流了体系资源。
-
缓存队列：基于Redis集群，联合分布式调度框架 Elastic-Job 设计。重要针对状态耽误的订单，进行批量状态同步
-
DB批处理：联合 Elastic-Job 设计，重要提供人工干预的入口，当渠道耽误比较长、大概渠道异常的环境下，实行批量状态同步
任务分片：把一个任务分散到不同呆板运行，既办理单机计算能力上限问题，也降低部分任务失败对团体体系影响。
elastic-job 不直接提供数据处理的功能，只将分片项分配各个运行中的作业服务器（即Job 实例，摆设在一台呆板上的多个 Job 实例也能分片）。开发需自行处理分片项与真实数据对应关系。
数据分片：订单号取模存储（zset）
3.7 数据结构
- 有序集合（zset）：按分片逻辑，将订单号取模，存放至对应队列
- string：交易明细序列化存储
设计思路
- MQ 消费者（作业节点），吸收到消息后，将数据存入缓存
- 作业节点根据分片项、score 范围，定时从对应的缓存队列中获取指定数量的订单号
- 业务循环处理，根据订单号再去缓存中获取对应的具体信息
- 实行查询逻辑
<blockquote class="multiquote-1" style="margin-top: 20px; margin-bottom: 20px; margin-left: 0px; margin-right: 0px; padding-top: 10px; padding-bottom: 10px; padding-left: 20px; padding-right: 10px; border-top-style: none; border-bottom-style: none; border-left-style: solid; border-right-style: none; border-top-width: 3px; border-bottom-width: 3px; border-left-width: 3px; border-right-width: 3px; border-top-color: rgba(0, 0, 0, 0.4); border-bottom-color: rgba(0, 0, 0, 0.4); border-left-color: rgba(0, 0, 0, 0.4); border-right-color: rgba(0, 0, 0, 0.4); border-top-left-radius: 0px; border-top-right-radius: 0px; border-bottom-right-radius: 0px; border-bottom-left-radius: 0px; background-attachment: scroll; background-clip: border-box; background-color: rgba(0, 0, 0, 0.05); background-image: none; background-origin: padding-box; background-position-x: 0%; background-position-y: 0%; background-repeat: no-repeat; background-size: auto; width: auto; height: auto; box-shadow: rgba(0, 0, 0, 0) 0px 0px 0px 0px; display: block; overflow-x: auto; overflow-y: auto;"> zset元素数据过期，需业务自己处理，可单独创建检测机制，也可每次实行业务时实行判断，过期则移除，否则集合越来越大。
4 高可用设计
4.1 渠道隔离
高并发访问下，体系所依靠渠道稳定性对体系影响很大，外部依靠存在大量不可控因素，如网络连接变慢，资源突然繁忙，暂时不可用，选型容错开源框架 Hystrix，隔离方案选择 thread。
4.2 查询网关
交易体系中，查询业务量一样平常是支付业务的 6 倍，甚至更高，这样对查询服务性能就会有更高的要求。淘汰对焦点交易影响，提拔稳定性。
4.3 通道商户缓存
通道信息（机构号、商户号、密钥等）属静态信息，初次使用时存入分布式缓存体系（设置TTL，防止僵尸数据），同时增加手动修改的入口，方便人工干预。
- 千里之堤毁于蚁穴：用容错就是制止蚁穴变大，依靠服务不可用时，服务调用方通过技术手段，向上提供有损服务，保证业务柔性可用
- 线程池资源隔离：Java 的 Servlet 容器 Tomcat或 Jetty 都是多线程模型，用 Worker 线程处理哀求。当业务哀求打满 Worker 线程的最大值后，剩余哀求被放到等待队列（或拒绝），若等待队列也满，那这台 Web Server 就会拒绝服
QPS 较高的服务，那根本上这种场景下，你的服务也会跟着被拖垮。假如上游服务也没有设置合理的超时时间，故障就会扩散。这种故障逐级放大的过程，就是服务雪崩效应。接纳容错框架 Hystrix 办理此问题。 通过 Hystrix 命令模式，将每个类型的业务哀求封装成对应的命令哀求。每个命令哀求对应一个线程池，创建好的线程池是被放入到 ConcurrentHashMap 中。
<blockquote class="multiquote-1" style="margin-top: 20px; margin-bottom: 20px; margin-left: 0px; margin-right: 0px; padding-top: 10px; padding-bottom: 10px; padding-left: 20px; padding-right: 10px; border-top-style: none; border-bottom-style: none; border-left-style: solid; border-right-style: none; border-top-width: 3px; border-bottom-width: 3px; border-left-width: 3px; border-right-width: 3px; border-top-color: rgba(0, 0, 0, 0.4); border-bottom-color: rgba(0, 0, 0, 0.4); border-left-color: rgba(0, 0, 0, 0.4); border-right-color: rgba(0, 0, 0, 0.4); border-top-left-radius: 0px; border-top-right-radius: 0px; border-bottom-right-radius: 0px; border-bottom-left-radius: 0px; background-attachment: scroll; background-clip: border-box; background-color: rgba(0, 0, 0, 0.05); background-image: none; background-origin: padding-box; background-position-x: 0%; background-position-y: 0%; background-repeat: no-repeat; background-size: auto; width: auto; height: auto; box-shadow: rgba(0, 0, 0, 0) 0px 0px 0px 0px; display: block; overflow-x: auto; overflow-y: auto;"> 只管线程池提供线程隔离，也要有超时设置，不能无穷阻塞以致于线程池一直饱和。
Hystrix 线程监控
实时展示各业务线程池资源，研发以此为参考评估资源是否够用、是否需升级呆板资源等：
2.0全面对接内部监控平台，关注：
- 节点耗时监控：如哪个时间点、哪个节点耗时较多，通过百分比直观看出瓶颈
- 成功率监控：折线图定时革新数据，将各个时间点的交易记录数、成功笔数、失败笔数进行汇总计算，渠道接口异常时可以第一时间发出告警
- 应答码监控：应答码 TOP 排行榜，方便研发分析数据，提前将问题通知给渠道，淘汰后续可能出现更大的问题；部分应答码重点监控，通过设定告警阀值，凌驾阀值短信及电话告警，研发第一时间接入处理，淘汰可能造成的损失
- 邮件巡检陈诉：用于第二天研发自助数据分析
5 规划
-
动态分片：包罗数据分片、任务分片，业务量一连倍数增长环境，各环节分片计谋如何做到主动化，充实压榨各呆板性能
-
智能路由：遇到渠道异常、临时停用渠道等case，需将用户切换至其他渠道，当下是人工拉数据手工操作，后续思索如何让路由更智能
-
全链路的监控：我们现在链路监控只是从前端到后端有一个哀求的跟踪号，但是这个都分散在我们业务日志内里的。所以说我们下一步就准备做一个全链路的监控，就相当于把每一个每笔交易，它具体在哪个时间点在哪个呆板上，然后在哪个渠道，然后它状态做的什么变更，做一个完整的记录，通过一个可视化的界面提供出来，方便客服、运营等其他协作部分使用
获取更多干货内容，记得关注我哦。
本文由 mdnice 多平台发布
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
