调用webservice服务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. 对于⼤并发，或者需要平衡前后端消息发送和处理速度，需要消息缓冲场景采⽤异步消息接⼝。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。