微服务间的通信协议和消息格式

服务之间的通信遵循 IPC（Inter-Process Communication，进程间通信）标准。它们之间的通信方式，可以按照以下多个维度进行分析。

首先按照同步和异步方式来划分。同步模式只有一对一，异步模式有一对一和一对多。

还可以从消息格式和通信协议来划分。消息格式有基于文本和基于二进制两种。通信协议有同步和异步两种。同步通信协议有 HTTP REST 和 gRPC。异步通信协议有 AMQP 或 STMP。

进程间通信的本质是交换消息。而消息通常包括数据，因此消息的格式选择对于传输进程间数据的效率关系很大。基于文本的消息格式。优点是可读性高，缺点是消息冗长，尤其是 XML。如果在对效率和性能敏感的场景下，需要使用二进制消息传递格式。基于二进制的消息传递格式。如果我们需要考虑避免 API 版本变更带来的问题，要尽量使用 Protocol Buffer。在同步方式中，无论是 REST 还是 gPRC，都需要遵循远程过程调用的 RPI 机制。

REST 是一种使用 HTTP 协议的进程间通信机制，使用 HTTP 动词（如 GET、POST、PUT 等）操作资源，使用 URL 调用这些资源。

REST 的优点：操作简单、可以使用浏览器扩展 postman 插件或者 curl 命令行来测试 HTTP API、直接支持请求/响应方式的通信、HTTP 对防火墙友好、不需要中间代理简化了系统架构。

REST 的缺点：只支持请求/响应方式的通信；可能导致可用性降低；因为客户端和服务端在 REST API 调用期间都必须保持在线，没有代理缓冲消息；客户端必须知道服务实例的位置（URL）；客户端必须用服务发现机会来定位服务实例；在单个请求中获取多个资源具有挑战性；很难将多个更新操作映射到 HTTP 动词。

正是因为 REST 方式中，HTTP 仅提供有限数量的动词，设计支持多个更新操作的 REST API 并不容易，因此 gRPC 应运而生。gRPC 使用 Protocol Buffer 消息传递格式。

微服务间的异步通信协议。我们在消息中间件传递消息，使用 XML 或 JSON 文本消息。在一个分布式系统中，服务之间相互异步通信的最常见方式是发送消息。我们把负责将发送方的正式消息传递协议转换为接收方的正式消息传递协议的工具叫作 Message Broker（消息代理）。市面上有不少 Message Broker 软件，如 ActiveMQ、RabbitMQ、Kafka 等。

服务之间消息传递主要有两种模式：队列（Queue）和主题（Topic）。

• Queue 模式是一种一对一的传输模式。在这种模式下，消息的生产者（Producer）的消息传递的目的地类型是 Queue。Queue 中一条消息只能传递给一个消费者（Consumer），如果没有消费者在监听队列，消息将会一直保留在队列中，直至消息消费者连接到队列为止，消费者会从队列中请求获得消息。

• Topic 模式是一种一对多的消息传输模式。在这种模式下，消息的生产者（Producer）的消息传递的目的地类型是 Topic。消息到达 Topic 后，消息服务器将消息发送至所有订阅此主题的消费者。

目前业内主要的异步消息传递协议如下。

• Java 消息传递服务（Java Messaging Service，JMS），它面向 Java 平台的标准消息传递 API。

• 面向流文本的消息传输协议（Streaming Text Oriented Messaging Protocol，STOMP）：WebSocket 通信标准。

• 高级消息队列协议（Advanced Message Queueing Protocol，AMQP）：独立于平台的底层消息传递协议，用于集成多平台应用程序。

• 消息队列遥测传输（Message Queueing Telemetry Transport，MQTT）：为小型无声设备之间通过低带宽发送短消息而设计。使用 MQTT 可以管理 IoT 设备。

市面上消息中间件的种类很多，Apache ActiveMQ Artemis 是最流行的开源、基于 Java 的消息服务器。ActiveMQ Artemis 支持点对点的消息传递（Queue）和订阅/发布模式（Topic）。支持标准 Java NIO（New I/O，同步非阻塞模式）和 Linux AIO 库（Asynchronous I/O，异步非阻塞 I/O 模型）。AMQ 支持多种协议，包括 MQTT、STOMP、AMQP 1.0、JMS 1.1 和 TCP。