两个应用之间交互怎样才算做健壮

本文探讨了A与B应用间消息交互的健壮性设计。面对消息发送与接收的潜在问题,A应用采取了重试机制与容错处理策略,确保系统稳定运行。通过自我严格要求与对外部宽容,构建了一个在异常处理上得心应手的系统。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

今天重新review了一下之前写的代码,脱离开具体的业务逻辑:

A应用与B应用消息交互,A先发消息给B,B处理后发另一个消息给A,

站在A应用的立场来考虑,怎么设计这个系统算做健壮,我们分情况来说,

第一种情况,A应用发送给B应用的消息有问题(例如因为A应用自身的bug导致必填字段为空),或B应用处理消息的逻辑出bug了。

      最终的结果是B应用没有成功消费到消息。

                解决的办法是A增加重试机制,在页面中增加一个后台重发按钮,可以根据必要的值(比如单据号和单据类型)重新组装消息发给B,

                或者自己建一个message_retry表,保存关键字(比如单据号和单据类型)作为后来重发的依据

第二种情况,B应用发送给A应用的消息有问题(例如因为B应用自身的bug导致必填字段为空),或A应用处理消息的逻辑出bug了。

      最终的结果是A应用没有成功消费到消息。

                不要求B应用有同样的重试机制,A应用自己做一个容错处理,比如自己在页面中增加按钮来处理激活对应的表的修改,必要是可以调用B应用的RPC接口来查询必要的信息

站在A应用的角度,这样看上去我们用一个词来形容,就是“严以律己,宽以待人”

为什么要这样做呢,这里不展开沟通的问题,总之多个应用多个团队维护,很难要求别人写代码做到健壮(有时候推动别人把事情做完可以,推动对方做好很难,做完和做好是两个概念)

如果A应用做到这么苛刻的程度,这个系统就非常健壮了,在后续处理异常问题的时候得心应手。

看完后不禁为自己的代码感动的落泪。

转载于:https://www.cnblogs.com/qiyu/p/6928156.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值