微服务架构的通信设计模式

昨天我们一起学习的微服务数据模式，今天我们来学习一下微服务的通信设计模式，通信是保证服务请求核心要素，选择合适的一个通信协议对系统来说可以达到事半功倍。

---

一、RPC调用模式

目前各种微服务通信社区上，很多种支持RPC模式。有同步请求/响应通信机制，例如基于 HTTP 的 REST 或 GraphQL，或 gRPC。或者可以使用异步的、基于消息的通信机制，例如 AMQP（高级消息队列协议）或 STOMP（简单/流式面向文本的消息传递协议）。此外，还有许多不同的消息格式。这些格式可以是可读的，例如 JSON 和 XML。他们还可以使用更高效的二进制格式，例如 Avro 或 Protobuf。

1.1 RPC 选择因素

在选择 RPC 机制之前，考虑一下服务与其客户端之间的交互方式是很有必要的。客户服务交互有两个维度。

1.1.1 一对一还是一对多

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

1.1.2 同步的还是异步的

• 同步：客户端在等待服务响应时可能会阻塞。
• 异步 ：客户端不会阻塞，并且响应（如果有）并不是立即发送。

1.2 一对一互动

1. 同步请求/响应 ：服务客户端请求服务并等待响应。服务的紧密耦合是这种交互方式的结果。
2. 异步请求/响应 ：服务客户端向服务发送请求，服务异步回复。
3. 单向通知 ：客户端向服务发送请求，但不期待响应。

1.3 一对多交互

1. 异步发布/订阅 ：客户端发布通知消息，由一个或多个订阅服务使用。
2. 异步发布/异步响应 ：在这种情况下，客户端发布一条消息，然后等待来自感兴趣服务的响应。

1.4 消息格式

RPC 本质上是一种消息交换。其中一个重要的设计是消息包含数据的格式。消息格式的选择会影响 RPC 的效率、API 的可用性及其可演化性。

消息格式有两种主要类型：文本和二进制。

1.4.1 基于文本的消息格式

JSON 和 XML 是最流行的基于文本的格式。

基于文本的消息格式的优点

• 可读性高，可自我描述。

基于文本的消息格式的缺点

• 消息很冗长。
• 除了它们的值之外，没有必要的属性及其他标签都会包含其中。
• 解析文本性能开销很大。

1.4.2 二进制消息格式

Thrift、Protocol Buffers (Protobuf) 和 Avro 是最流行的二进制格式。

二进制消息格式的优点

• 元数据很少，因此有效负载很小。
• 比基于文本的消息解析要快。

二进制消息格式的缺点

• 可读性差，不可自我描述

---

二、远程过程调用模式

当客户端请求服务时，服务会处理请求并发回响应。虽然一些客户端可能会在等待响应时阻塞，但其他客户端可能具有反应性、非阻塞架构。

代理接口通常封装底层通信协议。

有多种通信协议可供选择，例如 REST、gRPC 和 GraphQL 等。

---

三、使用同步模式进行通信

3.1 REST（代表性状态转移）

REST 基于资源的概念，它表示单个业务对象。HTTP（超文本传输​协议）用于实现 REST。REST 使用 HTTP 来操作由 URL 引用的资源。

3.2 HTTP 调用方式

1. GET： GET 方法向特定的资源发出请求。GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问
2. HEAD： HEAD 方法向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3. POST： POST请求数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
4. PUT： PUT 方法用请求有效负载替换目标资源的所有当前表示。
5. DELETE： DELETE 方法请求服务器删除Request-URL所标识的资源
6. CONNECT： CONNECT 方法建立由目标资源标识的服务器的隧道。
7. OPTIONS： OPTIONS 方法描述了目标资源的通信选项。
8. TRACE： TRACE 方法沿到目标资源的路径执行消息环回测试。
9. PATCH： PATCH 方法将部分修改应用于资源。

3.3 指定 REST API

API 必须使用 IDL（接口定义语言）定义。最流行的 REST IDL 之一是开放 API 规范，它是从Swagger开源项目演变而来的。

3.4 挑战一：在单个请求中获取多个资源

由于 REST API 通常基于业务对象，因此在一个请求中请求多个相关对象是设计 REST API 时的常见难题之一。客户端必须至少对相关对象发出多次请求。

使用查询参数，API 可以使客户端在获取资源时检索相关资源。由于这种方法缺乏可扩展性，GraphQL和Netflix Falcor等替代 API 技术变得越来越受欢迎。

3.5 挑战二：映射操作到 HTTP 动词

另一个常见的 REST API 设计问题是将要对业务对象执行的操作映射到 HTTP 请求上。REST API 使用 PUT 来更新，但是有多种方法可以操作订单，包括取消订单、修改订单等。一种解决方案是定义一个子资源，如 /orders/{orderId}/cancel 或 /orders/{orderId}/revise 以更新资源的特定方面或在 URL 查询参数中指定动词。但这些解决方案并不是真正的 RESTful。

由于这个问题，REST 的替代品（例如gRPC）越来越受欢迎。

3.5 REST 的优势

1. 目前很多微服务框架都支持REST，实现起来相对容易
2. Postman 等插件可以轻松地在浏览器中测试 HTTP API。
3. 它支持直接请求/响应通信。

3.6 REST 的缺点

1. 仅支持请求/响应通信。
2. 由于要求客户端和服务器同时在线，可用性降低。
3. 客户端必须使用服务发现来发现服务实例的 URL。
4. 在一个请求中获取多个资源可能具有挑战性。
5. 将多个更新操作映射到 HTTP 动词可能具有挑战性。

---

四、gRPC

由于 HTTP 仅提供一组有限的请求方式，因此设计支持多个更新操作的 REST API 可能具有挑战性。

谷歌推出的跨语言客户端和服务器的框架 gRPC 可以解决这个问题。使用基于协议缓冲区的 IDL 定义 gRPC API，这是 Google 用于序列化结构化数据的语言设计机制。是一种同步通信机制。使用 HTTP/2，客户端和服务器以协议缓冲区格式交换二进制消息。

4.1 gRPC 的优势

1. 易于设计具有丰富更新操作集的 API 。
2. 消息格式紧凑且高效。
3. 双向流使 RPC 和消息传递成为可能。
4. 它支持以多种语言编写的客户端和服务的互操作性。

4.2 gRPC 的缺点

1. JS 客户端必须做更多的工作来使用基于 gRPC 的 API，而不是基于 REST/JSON 的 API。

---

五、GraphQL

GraphQL 解决了使用单个请求获取多个资源的问题。GraphQL 主要用于从客户端应用程序查询数据库。在后端，GraphQL 向 API 指定如何将数据呈现给客户端。GraphQL 重新定义了开发人员使用 API 的方式，提供更大的灵活性和更快的上线速度；改进了客户端-服务器交互，使前者能够进行精确的数据请求，并只获得他们需要的数据。

GraphQL 服务器为客户端提供模式：可以请求的数据模型。

5.1 GraphQL 的优势

1. 客户端可以准确地从服务器指定他们需要什么，服务器将以可预测的方式反馈该数据。
2. API 使用者确切地知道哪些数据可用以及它是什么形式，因为它是强类型的。

5.2 GraphQL 的缺点

1. 无论查询成功与否，它总是返回一个 HTTP 状态码 200。
2. 没有内置缓存支持
3. 它比 REST 更复杂

---

六、使用异步消息传递模式进行通信

使用消息传递时，服务会异步交换消息。基于消息的应用程序通常使用像 RabbitMQ 这样的消息代理，充当服务之间的中介。服务客户端通过向服务发送消息来向服务发出请求。如果期望响应，服务实例将向客户端发送单独的消息。由于通信是异步的，客户端不会等待响应。相反，客户端是假设不会立即收到响应的。

6.1 单向通知

异步消息传递使实现单向通知变得容易。通常，客户端向服务拥有的点对点通道发送消息。服务订阅频道处理消息。没有响应被发回。

6.2 发布/订阅

发布/订阅交互样式内置于消息传递中。客户端将消息发布到由多个订阅者读取的发布-订阅通道。

6.3 发布/异步响应

结合了发布/订阅和请求/响应的元素，形成了更高层次的交互风格。客户端将指定回复通道头的消息发布到发布-订阅通道。消费者将包含相关 id 的回复消息写入回复通道。客户端利用相关 id 将回复消息与收集响应的请求进行匹配。