B端请求功能拆分思路

拆分的必要性

通常来说，我们在进行微服务内部调用以及调用第三方接口时都是直接写在各自的业务模块中的。当然有的公司会有接口总线，将第三方调用的参数转换业务写在接口总线中，然后业务模块去远程调用接口总线。

总之无论如何，上面都是在业务模块中通过硬编码的方式去编写调用逻辑。当然这种方式对于那些流程非常标准化的业务来讲是没有任何问题的，比如对于C端的业务来讲。

但是对于B端来说，定制工作量最大的地方往往就是在上下游接口交互上。比如一家软件公司同时拥有ERP系统、WMS系统。那么对于自家的产品来讲，ERP系统与WMS系统的交互工作肯定是集成自家的WMS系统。

但是对于甲方爸爸来讲，可能并不会将这家公司的ERP和WMS产品全部购买对吧，人家可能只购买你的ERP产品，然后再去购买别的公司的WMS产品。然后让你们两家的产品做集成。

如果像上面所说，直接将接口调用的业务写在业务模块中的话，那在与第三方WMS系统交互时就需要去修改我们自己的ERP产品包。那么就要对业务产品包拉分支了对吧，如果有一百个项目呢？就要拉一百的分支。

如果后面这些客户需要对这个业务产品包做升级呢？那我们的交付团队就有活干了哈哈！！

所以我们要想一个办法，既能让我们的业务产品包能够流畅的升级，也能应对各个项目的定制化接口交互需求。那么我们就需要对功能做一定的拆分，将接口交互的功能拆分出来单独维护。然后统一给这些接口交互业务拉分支。这样就能保证我们的业务包流畅的升级。

好了，开干！！！

怎么拆

既然要做到将产品业务和接口交互业务进行拆分，那么这两个模块之间要通过什么方式进行交互呢？相信大家肯定一下子就能想到使用Redis发布订阅或者使用消息队列对吧。在产品包的核心业务方法最后一行将消息发布出去，然后再接口相互模块中写消费者去接收消息然后处理。

但是我觉得这样不太合理哈。

首先我们先聊一聊消息队列最主要的作用是什么？我觉得是对大量上游消息的流控处理。而一般来说，B端的上下游交互业务基本上不会出现高并发的情况，而且这里的重点我觉得是考虑上游怎么给下游发，而不是下游怎么去应对上游的海量消息。

其次，如果上下游之间需要同步交互呢？敢问MQ大哥该如何应对呀。

所以我的方案是搞一个单独的模块来承担这个事情。这个模块分为两部分：处理引擎和定制开发层。

1. 处理引擎层主要编写请求处理的业务，它作为一个标准产品包，可以进行升级迭代。

2. 定制开发层主要编写接口交互的定制化业务。

Demo

Demo中包含了业务模块、处理引擎、定制开发三层。

处理引擎Demo

首先我们提供一个列表界面和编辑页面，用来维护对于的Topic。是不是和MQ很像呀。其实我这样设计也是为了减小交付团队开发同学的学习成本。因为MQ大家都熟悉，所以按照MQ的思路进行设计可以帮助大家快速的上手。

这种方式的好处是可以实现请求策略的热刷新。比如说我修改了降级策略，那么下一次请求的时候可以直接去查询数据库或者缓存进行相应的处理。

然后就是编写核心的请求业务和一系列请求策略的代码了。

我的想法是只需要交付团队的同学们关注交互过程中请求参数的转换集合，所以这里用了模板方法，将构建请求对象的方法抽取出来让交付团队的同学去定制使用。这样也能节省一定的工作量。

1.首先定义一个接口，buildRequest中用来编写封装请求对象的业务。

2.然后提供一个模板，将核心处理业务封装好。

3.定义消费者注解

定制开发层Demo

1. 定制开发层在pom中引入处理引擎层。这样就可以拿到处理引擎层封装好的消费者注解@ CustomerHandle和接口ICustomerHandle。
2. 编写消费者组件。只需要使用@CustomerHandle标识这个类并实现ICustomerHandle接口以及重写buildRequest方法就完成了定制任务。

业务模块Demo

业务模块只需要在核心业务逻辑最后调用send方法就可以将消息发送给对应的topic。