微服务系统之间的通知这样设计合理且可靠

最新推荐文章于 2025-01-07 09:33:47 发布

原创

最新推荐文章于 2025-01-07 09:33:47 发布 · 581 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#微服务 #java #spring boot

场景

一般我们的项目都是微服务架构，微服务之前的通讯有同步Fegin调用，这种本身就是同步机制；
通过调用的HTTP状态码或者业务返回状态码就可以确定失败或者成功，直接同步处理；
但是有些场景我们一个业务调用对方系统不是返回处理成功或者失败，而是告诉你请求已受理。
这时候获取结果一般有两种方式：主动轮询去查询结果状态，银行业务很常见这种机制
另一种就是被动接受对方系统的回调通知；
如果我们是被调用系统：我们如何保证业务受理之后通知请求方能尽最大可能收到通知呢？最大可能不影响本系统性能呢？

方案

微服务都是内部系统，可以考虑重量级的分布式事务！
不考虑分布式事务，就靠补偿和重试和幂等等机制实现最终一致性！
消息的状态切换有两种方式：请求接受处理后，第一种是被动轮训查询到最终状态，业务侧自动幂等控制，以及及时解除轮询。第二种就是被动通知可靠：通知采用异步通知，通知失败记录补偿记录表，定时任务调度去完成补偿处理，补偿机制使用阶梯式最大努力策略，设置最大通知次数，防止通知不成功一直死循环式去调度不会成功的业务接口地址。

实现细节

数据库补偿机制表

CREATE TABLE `tx_order_push_info` (
  `order_no` varchar(64) DEFAULT NULL COMMENT '交易单号',
  `order_id` decimal(11,0) DEFAULT NULL COMMENT '交易单Id',
  `push_status` decimal(2,0) DEFAULT NULL COMMENT '推送状态',
  `push_count` decimal(2,0) DEFAULT NULL COMMENT '推送次数',
  `push_address` varchar(255) DEFAULT NULL COMMENT '推送地址',
  `request_body` varchar(1000) DEFAULT NULL COMMENT '推送报文',
  `next_push_time` datetime DEFAULT NULL COMMENT '下次通知时间',
  `mid` int<