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

微服务架构的通信设计模式_第1张图片

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


一、RPC调用模式

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

1.1 RPC 选择因素

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

1.1.1 一对一还是一对多

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

1.1.2 同步的还是异步的

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

微服务架构的通信设计模式_第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 是最流行的二进制格式。

二进制消息格式的优点

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

二进制消息格式的缺点

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

二、远程过程调用模式

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

微服务架构的通信设计模式_第3张图片

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

有多种通信协议可供选择,例如 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 这样的消息代理,充当服务之间的中介。服务客户端通过向服务发送消息来向服务发出请求。如果期望响应,服务实例将向客户端发送单独的消息。由于通信是异步的,客户端不会等待响应。相反,客户端是假设不会立即收到响应的。

微服务架构的通信设计模式_第4张图片

6.1 单向通知

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

微服务架构的通信设计模式_第5张图片

6.2 发布/订阅

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

微服务架构的通信设计模式_第6张图片

6.3 发布/异步响应

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

微服务架构的通信设计模式_第7张图片

你可能感兴趣的:(架构师,微服务,架构,设计模式)