「第二部:容器和微服务架构](11) 微服务架构中的通信

在单个进程上运行的单片应用程序中，组件使用语言级方法或函数调用彼此调用。如果使用代码创建对象（例如，new ClassName（）），则可以强耦合这些对象；如果使用依赖注入，则可以通过引用抽象而不是具体的对象实例，以分离的方式调用这些对象。不管怎样，对象都在同一进程中运行。当从单一应用程序转变为基于微服务的应用程序时，最大的挑战在于改变通信机制。从进程内方法调用到服务的RPC调用的直接转换将导致在分布式环境中性能不佳的聊天和不高效的通信。正确设计分布式系统的挑战是众所周知的，甚至还有一个被称为分布式计算谬误的经典，它列出了开发人员在从单一设计转向分布式设计时经常做出的假设。

没有一个解决方案，只有几个。一种解决方案是尽可能地隔离业务微服务。然后在内部微服务之间使用异步通信，并用粗粒度通信替换对象之间的进程内通信中的典型细粒度通信。您可以通过对调用进行分组并将聚合多个内部调用结果的数据返回给客户端来完成此操作。

基于微服务的应用程序是在多个进程或服务上运行的分布式系统，通常甚至跨多个服务器或主机运行。每个服务实例通常是一个流程。因此，服务必须使用进程间通信协议（如HTTP、AMQP）或二进制协议（如TCP）进行交互，具体取决于每个服务的性质。

微服务社区提倡“智能端点和哑管道”的理念这一口号鼓励设计尽可能在微服务之间分离，并在单个微服务中尽可能具有凝聚力。如前所述，每个微服务都拥有自己的数据和域逻辑。但是，组成端到端应用程序的微服务通常只是通过使用REST通信而不是复杂的协议（如WS-*和灵活的事件驱动通信）进行编排，而不是使用集中的业务流程编排器。

这两种常用的协议是HTTP请求/响应和资源api（在大多数情况下查询时），以及在跨多个微服务通信更新时的轻量级异步消息传递。以下各节将更详细地解释这些问题。

通信类型

客户机和服务可以通过多种不同类型的通信进行通信，每种通信都针对不同的场景和目标。最初，这些类型的通信可以分为两个轴。