业务中台如何实现业务结果的回调通知

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<T>，基础的枚举，共同的dto对象，等。本案中的TransNotifyDTO就要放在base-rpcapistyle里。

 

0x04 如此清新，到这里，是时候可以贴出来示意代码了。

1）产品线rpcapi，以BizA为例

    /**
     * 接收来自zhongtai-trans的回调通知
     * @param transNotifyDTO
     * @return
     */
    Result<Void> notifyPayResult(TransNotifyDTO transNotifyDTO);

 

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);
    }

 

0x05 设计要点

1）最重要的一点是，针对这种业务回调，通知参数由业务中台来决定，而非各业务线。这样，当新增业务线时，业务中台只是增加一个case和rpc请求的代码。否则，业务中台会严重违反开闭原则。

2）严防rpcapi直接的互相依赖，一定要抽象出来rpcapi的基础module，用来定义rpcapi的公用部分。

3）业务回调，本案以dubbo的rpc调用为例。除此之外，用消息中间件也是不错的选择，例如基于rabbitmq的fanout / routingKey。当然，消息msg也是由业务中台来决定。以本案为例，我们的最佳实践，是各方依然依赖TransNotifyDTO进行消息的序列化和反序列化。这样在IDE里show-usages快捷功能可以容易追踪各使用方，增强代码可理解性。

 

【EOF】

**秉烛两夜，绞尽脑汁生产完毕...本页设计文稿物料：https://www.processon.com/diagraming/618

 

**知识就是力量，但更重要的是...， 欢迎关注我的微信公众号「靠谱的程序员」，解密靠谱程序员的日常，让我们一起做靠谱的程序员。