今天重新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应用做到这么苛刻的程度，这个系统就非常健壮了，在后续处理异常问题的时候得心应手。

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

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