java 异步接口设计_服务设计-同步和异步(3.10)

今天谈下在接口服务设计的时候同步和异步选择的问题。

对于服务设计，在原来谈MQ和消息中间件的时候，更多谈的都是异步消息接口，其核心目的就是通过消息中间件实现消息发送方和接收方的彻底解耦。同时还通过消息中间件实现了重试，容错，消息发布订阅，后端流控等多方面的能力。

但是异步消息最大的一个问题就是任何一次消息交付都必须设计两个消息接口，一个是消息发送接口，一个是消息回执接口。举例来说如果我们要将采购订单从采购系统中发送到ERP系统，那么至少要设计两个消息接口。

1. 采购订单发送消息接口

2. 采购订单接收和处理结果消息接口

如果ERP在接收到采购订单后还需要发起定时请求进行异步处理，那么往往还需要将回写接口拆分为两个接口，即消息接收回写接口，消息接收后处理结果回写接口。

只有当采购系统收到采购接收后处理成果的消息回写，才代表ERP已经接收并处理成功该张订单信息，如果收到的是失败，则采购系统需要重新发送消息。如果长时间没有收到消息回写，往往就只有人工去检查和分析问题究竟出在哪里。

所以异步接口虽然带来了彻底的解耦，但是也附带出现了接口交互过程复杂，问题排查麻烦问题。

但是我们看到，对于消息推送场景，如果我们采用同步的Web Service服务接口，例如在ERP系统中提供一个采购订单导入信息服务接口，那么以上说的多个接口可以合并为一个，即采购系统在调用服务后同步等待ERP系统的结果返回，如果处理失败，那么异常和错误信息可以通过服务输出实时返回给采购系统。采购系统在拿到返回信息后再决定是否发起重新调用。

同时对于同步接口可以看到还带来另外一个好处，就是对于使用采购系统前端界面提交采购订单的业务用户来说，他们可以实时的就知悉订单是否成功导入到了ERP系统，而不是等待后续定时去查询获取导入结果信息。

可以看到对于查询类场景，更多的都是需要实时的同步的获取到查询结果信息，或者显示在查询界面上，或者导入到消费方的数据库中。对于这种场景基于消息的异步接口是无法满足的。

如果真要使用异步接口，则做法是至少需要提供三个消息接口才能满足需要。举例来说采购系统需要将ERP系统中的会计科目信息查询到并导入自己的数据库表中，对于这种场景采用异步设计则变化为：

1. 查询请求和查询条件消息推送接口

2. 查询结果信息消息返回推送接口

3. 查询结果信息接收结果信息回写接口

即使这种方式也看到，如果是业务用户在前台界面，需要实时查询ERP当前的会计科目信息，那么异步接口显然是无法满足需要的。而如果采取同步服务接口则只需要设计一个接口就可以满足要求。

对于消息1对多的发布订阅是消息中间件的优势，即发送方只需要将消息推送到消息中间件即可，而由消息中间件根据消息的订阅情况来完成消息的一对多推送。对于这种场景往往采用异步消息模式是最合适的。

但是我们看到，即使采用异步消息模式，我们提供给消息发送方的仍然可以是WS服务接口，只是说消息发送方调用WS服务后将消息推送到消息中间件即返回，而消息中间件通过内部的MQ进行消息存储和缓存，再通过订阅情况将消息逐个分发到下游的消息订阅方。

也就是说在引入ESB总线后，提升了原来单纯的消息中间件或MQ的能力。对于消息发送和接收业务系统，仍然可以采用同步的WS服务接口，但是当这些WS服务接口接入到ESB服务总线后，通过总线内部的消息中间件和MQ实现了服务调用的彻底解耦。

当然你也可以保留原有的类似JMS消息发送和接收模式。总之，对于消息发布和订阅场景，将其设计为异步服务接口是最合适的，一是做到彻底解耦，二是可以实现1对多的消息发布订阅机制。

关于服务设计时同步或异步接口选择的问题

基于前面的分析可以看到，对于同步还是异步服务接口选择，还是需要根据实际的业务场景需求出发进行选择，从解耦的角度尽量选择异步接口，但是考虑到方便性有些仍然要选择同步服务接口为主，具体为：

1. 对于查询类接口，建议全部采用Web Service同步服务接口设计。

2. 对于导入类接口，如果目标系统本身处理是异步的，尽量采用异步消息接口模式。

3. 对于导入类接口，如果目标系统能够实时处理并返回结果，采用同步服务接口设计。

4. 对于数据1对多分发类接口，尽量采用异步消息接口模式进行设计。

5. 对于消息和通知类推送(即完全不需要目标系统返回结果)的业务场景，全部采用异步消息模式进行。

6. 对于基础设施和网络条件复杂，需要高容错设计场景，尽量采用异步消息接口。

7. 对于大并发，或者需要平衡前后端消息发送和处理速度，需要消息缓冲场景采用异步消息接口。