1.7 微服务之间的通信

客户端与服务的交互方式

从关联服务实例数量维度来分

• 一对一：每个客户端请求由一个服务实例来处理。
• 一对多：每个客户端请求由多个服务实例来处理。

客户端请求从服务实例的响应来分

• 同步模式：客户端请求需要服务端实时响应，客户端等待响应时间可能导致堵塞。
• 异步模式：客户端请求不会阻塞进程，服务端的响应可以是非实时的。

一对一的交互方式有以下几种

• 请求/响应：一个客户端向服务端发起请求，等待响应；客户端期望服务端很快就会发送响应。在一个基于线程的应用中，等待过程可能会造成线程阻塞。这样的方式会导致服务的紧耦合。
• 异步请求/响应：客户端发送请求到服务端，服务端异步响应请求。客户端在等待响应时不会阻塞线程，因为服务端的响应不会马上就返回。
• 单向通知：客户端的请求发送到服务端，但是并不期望服务端做出任何响应。

一对多的交互方式有一下几种

• 发布/订阅方式：客户端发布通知消息，被零个或者多个感兴趣的服务订阅。
• 发布/异步响应方式：客户端发布请求信息，然后等待从感兴趣的服务发回的响应。

每个服务通常使用的是以上交互方式的组合。

实现服务发现有以下两种方式

• 服务及其客户直接与服务注册表交互。
  这种服务发现方法是两种模式的组合。第一种模式是自注册模式，服务实例调用服务注册表的注册API来注册其网络位置。第二种模式是客户端发现模式，当客户想要调用服务时会查询服务注册表以获取服务实例的列表，为了提高性能客户端会缓存服务实例，服务端会使用负载均衡算法来选择服务实例。
• 通过部署基础设施来处理服务发现。
  这种服务发现方法也是两种模式的组合。第一种模式是第三方注册模式，由第三方负责处理注册(不是服务本身向服务注册表注册自己)。第二种模式是注册模式，客户端不再需要查询服务注册表，而是向DNS名称发出请求后被解析到路由器。

由部署平台提供服务发现机制的优缺点：
优点，服务发现的所有工作都由部署平台处理，服务端和客户端不需要包含任何服务发现代码。
缺点，仅限于支持使用该平台部署的服务。

消息传递架构

无代理的架构

基于代理的架构

使用消息机制实现交互

请求消息发送

处理后返回

项目中如何设计服务之间的通信

如果想最大化一个系统的可用性，就应该设法最小化系统的同步操作量。最彻底的方式还是把所有服务都改成异步API。

如果必须同步，可以采用：

• 复制数据的方式解决，比如A->B->C，B同时保存B和C两个服务的数据，这样B可以在不与其他服务进行交互的情况下完成订单的创建。
• 创建pending数据解决，如区块链的交易先pending后异步处理。