协调服务间通信

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

目录

概 述

同步通信——请求响应方法

在同步通信中，需要一个预定义的源服务地址，指明请求要发送到何处，并且 两边的服务（调用方和被调用方）都应处于启动和运行状态。尽管协议可能是同步的，但 I/O 操作可以是异步的，其中客户端不必等待响应。这是 I/O 和协议 之间的区别。Web API 常见的通用请求 - 响应方法包括 REST、GraphQL 和 gRPC。

异步通信

在异步通信的情况下，调用方不必有被调用方的具体地址。这样就可以相对容易地一次处理多个消费者（因为服务可能会增加消费者数量）。此外，如果接收服务关闭，消息就会进入队列，然后在接收服务打开时继续处理。从 松散耦合、多服务通信以及应对部分服务器故障 的角度来看，这尤其重要。正是这些决定性的因素让 微服务倾向于异步通信。诸如 MQTT、STOMP、AMQP 之类的异步协议由 Apache Kafka Stream、RabbitMQ 之类的平台处理。

消息与事件
在异步通信中，常见的机制是消息传递和事件流。

小结

聊聊微服务的通信模式
消息

消息 是发送到特定目的地的数据项目，它封装了 意图 / 动作（需要发生的事情），并通过消息传递之类的渠道分发。队列负责存储消息，直到它们得到处理和删除。在消息驱动的系统中，可寻址的收件人等待消息到达并做出响应，否则将处于休眠状态。

事件

事件封装了状态的变化（发生了什么），而事件侦听器会附加到事件源上，以便在事件发出时调用它们。
域事件：与应用程序生成的业务域相关的事件（下图中的 OrderRequested、CreditReserved、InventoryReserved）。这些事件是事件源关注的。
更改事件：从数据库生成的事件，指示状态转换。这些事件是更改数据捕获所关心的。

在这种情况下，处理器是 dumb 类型（从某种意义上说，它仅充当消息路由器），并且客户端 / 服务拥有以域为中心的，负责 转储处理器与活跃客户端 的逻辑。这样就避免了复杂的集成平台，例如传统 SOA 设计中使用的 ESB。

微服务社区提出了智能端点和哑管道的理念。Martin Fowler 是他称为微服务通信的智能端点和哑管道的拥护者。

参考资料和推荐阅读

1.链接: 参考资料.