0x01 如下RPC通信场景：业务线向交易中台发起交易。当交易完成后，zhongtai-trans要将交易结果通知给业务线。
那么，在程序实现上，zhongtai-trans如何通知业务线呢？
0x02 这个问题暂且不表。我们先来看跨企业通信的业务回调通知。这里，我们以商户对接微信支付来举例。用户在扫描商户网页上的微信支付二维码进行支付。用户支付完成后，腾讯会以HTTP的形式主动回调商户API，将支付结果通知给商户系统。
微信官网明确了支付通知的参数。商户系统收到通知请求后，根据请求参数进行自己的逻辑处理。也就是说，腾讯作为通知请求方，定义了统一的通知参数，一视同仁，不管你是商户A的系统，还是商户B的系统，腾讯不会以某个商户的意志而改变。
0x03 回过头来，我们继续来看企业应用内部服务间的业务回调。举一反三，也应按照跨企业间的业务回调通知这样来设计。即，zhongtai-trans定义统一的TransNotifyDTO，封装交易通知数据。各业务线服务内对接收到的TransNotifyDTO对象进行判断处理，或转换为自己的内部对象来进行逻辑处理。
话虽如此，在实现方面，这会遇到一个问题。我们使用dubbo作为RPC框架。dubbo规定了provider服务和consumer服务都依赖由provider提供的rpcapi。按照上面的设计，由于zhongtai-trans要调用各业务线的rpcapi，而TransNotifyDTO由zhongtai-trans-rpcapi定义，这就出现各业务线的rpcapi要依赖zhongtai-trans-rpcapi。rpcapi之间一旦存在互相依赖，那么，如果缺乏严格控制，后续开发过程中极易出现循环依赖（circular dependency）。不得不说，rpcapi之间存在jar包依赖是一个败笔。下图直观的看出来（实线代表jar包依赖）。
那么，如何搞定这个败笔呢？一个为所有rpcapi所共用的基础module发挥作用了，这里我命名为base-rpcapistyle。base-rpcapistyle的作用：定义rpcapi的通用部分，如rpcapi的返回值模型Result，基础的枚举，共同的dto对象，等。本案中的TransNotifyDTO就要放在base-rpcapistyle里。
0x04 如此清新，到这里，是时候可以贴出来示意代码了。
1）产品线rpcapi，以BizA为例
/**
* 接收来自zhongtai-trans的回调通知
* @param transNotifyDTO
* @return
*/
Result<Void> notifyPayResult(TransNotifyDTO transNotifyDTO);
AI 代码解读
2）zhongtai-trans里通知业务线代码
/**
* 交易完成，回调通知业务线
* @param transOrder
*/
public void notifyPayResultToBiz(TransOrder transOrder) {
Assert.isTrue(TransPayStatusEnum.isFinal(transOrder.getPayStatus()));
TransNotifyDTO transNotifyDTO = new TransNotifyDTO();
transNotifyDTO.setOrderNo(transOrder.getOrderNo())
.setPayStatus(transOrder.getPayStatus())
.setPayTime(transOrder.getPayTime())
.setTransAmount(transOrder.getTransAmount())
.setStatusDesc(transOrder.getTransMsg());
Result<Void> result = null;
switch (transOrder.getBiz()) {
case BizA:
result = bizAApi.notifyPayResult(transNotifyDTO);
break;
case BizB:
result = bizBApi.notifyPayResult(transNotifyDTO);
break;
case BizC:
result = bizCApi.notifyPayResult(transNotifyDTO);
break;
}
log.info("通知业务线完成，响应结果={}", result);
}
AI 代码解读
0x05 设计要点
1）最重要的一点是，针对这种业务回调，通知参数由业务中台来决定，而非各业务线。这样，当新增业务线时，业务中台只是增加一个case和rpc请求的代码。否则，业务中台会严重违反开闭原则。
2）严防rpcapi直接的互相依赖，一定要抽象出来rpcapi的基础module，用来定义rpcapi的公用部分。
3）业务回调，本案以dubbo的rpc调用为例。除此之外，用消息中间件也是不错的选择，例如基于rabbitmq的fanout / routingKey。当然，消息msg也是由业务中台来决定。以本案为例，我们的最佳实践，是各方依然依赖TransNotifyDTO进行消息的序列化和反序列化。这样在IDE里show-usages快捷功能可以容易追踪各使用方，增强代码可理解性。
【EOF】
