微服务的交互模式。

服务与服务之间的交互模式可以分为以下3类。

同步调用模式

在同步调用模式中，服务1调用服务2，服务1的线程阻塞等待服务2返回处理结果，如果服务2一直不返回处理结果，则服务1一直等待超时为止。

同步调用模式如下图所示。

同步调用模式适用于大规模、高并发的短小操作，而不适用于后端负载较高的场景，例如：几乎所有JDBC的实现完全使用BIO同步阻塞模式。

接口异步调用模式

在接口异步调用模式中，服务1请求服务2受理某项任务，服务2受理后即可返回个i服务1其受理结果，如果受理成功，则服务1继续做其他任务，而服务2异步的处理这项任务，直到服务2处理完这项任务后，才反向的通知服务1任务已经完成，服务1再后续处理。

接口异步调用模式如下图所示。

接口异步调用模式适用于非核心链路上负载较高的处理环节，这个环节经常耗时较长，并对时效性要求不高。例如：在B2C电商系统中，一件商品售卖成功后，需要给相应的商户入账收入，这个过程对时效性要求不高，可以使用接口异步调用模式。

消息队列异步处理模式

消息队列异步处理模式利用消息队列作为通信机制，在这种交互模式中，通常服务1只需将某种事件传递给服务2，而不需要等待服务2返回结果。在这样的场景下，服务1与服务2可以充分解耦，并且在大规模、高并发的微服务系统中，消息队列对流量具有消峰的功能。

消息队列异步处理模式如下图所示。

消息队列异步处理模式与接口异步调用模式类似，多应用于非核心链路上负载较高的处理环节中，并且服务的上游不关心下游的处理结果，下游也不需要向上游返回处理结果。例如：在电商系统中，用户下订单支付且交易成功后，后续的物流处理适合使用消息队列异步处理模式，因为物流发货属于物流和配送系统的职责，不应该影响交易，所以交易系统不需要对其有感知。

以上三种交互模式普遍应用于服务化和微服务架构中，他们之间没有绝对的好坏，只需要在特定场景下做出更适合的选择。