点击下方“JavaEdge”，选择“设为星标”

第一时间关注技术干货！

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都国企技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：中央/分销预订系统性能优化；活动&优惠券等营销中台建设；交易平台及数据中台等架构和开发设计 目前主攻降低软件复杂性设计、构建高可用系统方向。

”

3.2 业务流程

业务发起一笔消费，先进入支付核心初始化流水、风控风险识别、渠道路由、渠道网关报文组装、上送、渠道应答。异步交易发送消息至 MQ 集群，任务作业监听消息，put 缓存，定时任务拉取进行状态查询，业务方通过查询服务查看该笔交易支付状态。

3.3 前置优化水平方向

• 接入层：将共性接口统一。如下单，所有业务，不管微信支付还是啥，都归为下单，具体业务通过 serviceId 标识

• 服务层：共性逻辑，也就是核心逻辑全部抽离出来，然后进行统一下沉，作为底层服务，上层业务全部通过 serviceId 配置化实现，这样的话尽量去少改动核心业务逻辑

• 缓存层：随交易量增长，初代系统很多业务查询直连DB，有很大性能影响。所以就在 DB 之上将所有消费交易信息缓存，后续所有查询、更新操作全部打到缓存层，主要为提升服务性能

3.4 前置优化垂直拆分

• 核心交易：交易核心链路，用户感知最明显。如支付失败，用户立马感知，投诉或电话客服，该模块也包含退款业务

• 任务作业：将处理中的交易进行状态同步，和核心交易通过MQ解耦

• 查询服务：仅对公司内部提供一个交易状态查询功能

3.5 任务作业

内部查询策略设计为两个队列、一个批处理：

• 内存队列：实现如延迟10s、间隔5s或很多银行使用 2 的 N 次方进行查询

  该队列主要针对单笔交易执行快速状态同步，提升用户体验

  "2的N次方进行查询"这个策略一般是在系统设计中对于状态查询的优化策略。如一个操作需要查询外部系统以确认状态，第一次查询在操作完成后立刻执行，若没有得到确认，那就等待一些时间后再查询一次。这里的"等待一些时间"就可能采取"2的N次方"的间隔策略。如第一次查询失败后，系统会等待2^1（也就是2）秒再查询一次，如果还是失败，那就等待2^2（也就是4）秒后再次查询，以此类推。这样做的好处在于可以避免在接口繁忙的时候造成过度查询，对接口进行压力保护，同时也节省了系统资源。

• 缓存队列：基于Redis集群，结合分布式调度框架 Elastic-Job 设计。主要针对状态延迟的订单，进行批量状态同步

• DB批处理：结合 Elastic-Job 设计，主要提供人工干预的入口，当渠道延迟比较长、或者渠道异常的情况下，执行批量状态同步

3.6 分片策略

任务分片：把一个任务分散到不同机器运行，既解决单机计算能力上限问题，也降低部分任务失败对整体系统影响。

elastic-job 不直接提供数据处理的功能，只将分片项分配各个运行中的作业服务器（即Job 实例，部署在一台机器上的多个 Job 实例也能分片）。开发需自行处理分片项与真实数据对应关系。

数据分片：订单号取模存储（zset）

3.7 数据结构

• 有序集合（zset）：按分片逻辑，将订单号取模，存放至对应队列

• string：交易明细序列化存储

设计思路

• MQ 消费者（作业节点），接收到消息后，将数据存入缓存

• 作业节点根据分片项、score 范围，定时从对应的缓存队列中获取指定数量的订单号

• 业务循环处理，根据订单号再去缓存中获取对应的详细信息

• 执行查询逻辑

zset元素数据过期，需业务自己处理，可单独建立检测机制，也可每次执行业务时执行判断，过期则移除，不然集合越来越大。

4 高可用设计

4.1 渠道隔离

高并发访问下，系统所依赖渠道稳定性对系统影响很大，外部依赖存在大量不可控因素，如网络连接变慢，资源突然繁忙，暂时不可用，选型容错开源框架 Hystrix，隔离方案选择 thread。

4.2  查询网关

交易系统中，查询业务量一般是支付业务的 6 倍，甚至更高，这样对查询服务性能就会有更高的要求。减少对核心交易影响，提升稳定性。

4.3 通道商户缓存

通道信息（机构号、商户号、密钥等）属静态信息，初次使用时存入分布式缓存系统（设置TTL，防止僵尸数据），同时增加手动修改的入口，方便人工干预。

• 千里之堤毁于蚁穴：用容错就是避免蚁穴变大，依赖服务不可用时，服务调用方通过技术手段，向上提供有损服务，保证业务柔性可用

• 线程池资源隔离：Java 的 Servlet 容器 Tomcat或 Jetty 都是多线程模型，用 Worker 线程处理请求。当业务请求打满 Worker 线程的最大值后，剩余请求被放到等待队列（或拒绝），若等待队列也满，那这台 Web Server 就会拒绝服

QPS 较高的服务，那基本上这种场景下，你的服务也会跟着被拖垮。假如上游服务也没有设置合理的超时时间，故障就会扩散。这种故障逐级放大的过程，就是服务雪崩效应。采用容错框架 Hystrix 解决此问题。通过 Hystrix 命令模式，将每个类型的业务请求封装成对应的命令请求。每个命令请求对应一个线程池，创建好的线程池是被放入到 ConcurrentHashMap 中。

尽管线程池提供线程隔离，也要有超时设置，不能无限阻塞以致于线程池一直饱和。

Hystrix 线程监控

实时展示各业务线程池资源，研发以此为参考评估资源是否够用、是否需升级机器资源等：

2.0全面对接内部监控平台，关注：

• 节点耗时监控：如哪个时间点、哪个节点耗时较多，通过百分比直观看出瓶颈

• 成功率监控：折线图定时刷新数据，将各个时间点的交易记录数、成功笔数、失败笔数进行汇总计算，渠道接口异常时可以第一时间发出告警

• 应答码监控：应答码 TOP 排行榜，方便研发分析数据，提前将问题通知给渠道，减少后续可能出现更大的问题；部分应答码重点监控，通过设定告警阀值，超过阀值短信及电话告警，研发第一时间接入处理，减少可能造成的损失

• 邮件巡检报告：用于第二天研发自助数据分析

5 规划

• 动态分片：包括数据分片、任务分片，业务量持续倍数增长情况，各环节分片策略如何做到自动化，充分压榨各机器性能

• 智能路由：遇到渠道异常、临时停用渠道等case，需将用户切换至其他渠道，当下是人工拉数据手工操作，后续思考如何让路由更智能

• 全链路的监控：我们现在链路监控只是从前端到后端有一个请求的跟踪号，但是这个都分散在我们业务日志里面的。所以说我们下一步就准备做一个全链路的监控，就相当于把每一个每笔交易，它具体在哪个时间点在哪个机器上，然后在哪个渠道，然后它状态做的什么变更，做一个完整的记录，通过一个可视化的界面提供出来，方便客服、运营等其他协作部门使用

写在最后

编程严选网（www.javaedge.cn），程序员的终身学习网站已上线！

点击阅读原文，即可访问网站！

欢迎长按图片加好友，我会第一时间和你分享软件行业趋势，面试资源，学习途径等等。

添加好友备注【技术群交流】拉你进群，更多教程资源应有尽有

关注公众号后，在后台私信：

• 回复【架构师】，获取架构师学习资源教程

• 回复【面试】，获取最新最全的互联网大厂面试资料

• 回复【简历】，获取各种样式精美、内容丰富的简历模板

• 回复 【路线图】，获取直升Java P7技术管理的全网最全学习路线图

• 回复 【大数据】，获取Java转型大数据研发的全网最全思维导图

• 微信【ssshflz】私信 【副业】，进副业交流群

• 点击【阅读原文】，即可访问程序员一站式学习网站

最近在准备面试，为大家准备一份2024最新最全Java学习路线一条龙