微服务间通信

微服务架构基于多个服务构建应用，这些服务必须经常协作才能处理各种外部请求。因为服务实例通常是在多台机器上运行的进程，所以它们必须使用进程间通信进行交互。因此，进程间通信技术在微服务架构中比单体架构中扮演着更重要的角色。本文将探讨各种进程间通信机制，并讨论如何进行权衡。注意，需要牢记“没有银弹”这个大原则。
选择合适的进程间通信机制是一个重要的架构决策。它会影响应用程序可用性。更重要的是，进程间通信甚至与实务管理相互影响。一个理想的微服务架构应该是在内部由松耦合的若干服务组成，这些服务使用异步消息相互通信。REST等同步协议主要用于服务与外部其他应用的通信。

微服务间通信概述

微服务架构以进程为一等公民，也就是说每个微服务实例都是一个独立的进程。微服务间通信就是进程间通信。有很多进程间通信技术可供选择。服务间可以使用基于同步请求/响应的通信机制，如HTTP REST或gRPC。另外，也可以使用异步的基于消息的通信机制，常见的消息通信协议有：AMRP或STOMP等。本文将从服务的交互方式、API定义、消息的格式等方面来介绍微服务间通信。

交互方式

在为服务选择进程间通信机制之前，首先应考虑服务与客户端的交互方式。考虑交互方式将有助于专注于需求，并避免陷入特定进程间通信技术的细节。交互方式的选择会影响应用的可用性。此外，交互方式还可以帮助选择更合适的集成测试策略。
有多种客户端与服务的交互方式。这里从两个维度介绍。第一个维度关注的是映射关系。具体可以分为两类：一对一和一对多。

(1) 一对一：每个客户端请求由一个服务实例来处理。
(2) 一对多：每个客户端请求由多个服务实例来处理。

第二个维度关注的是同步和异步。

(1) 同步模式：客户端请求需要服务器实时响应，客户端等待响应时可能导致阻塞。  
(2) 异步模式：客户端请求不会阻塞进程，服务器的响应可以是非实时的。  

一对一的交互方式有以下几种类型：
(1) 请求/响应：一个客户端向服务器发起请求，等待响应；客户端期望服务器很快发送响应。在一个基于线程的应用中，等待可能造成线程阻塞。
(2) 请求/异步响应：客户端发送请求到服务器，服务器异步响应请求。客户端在等待响应时不会阻塞线程，因为服务器的响应不会马上返回。
(3) 通知(单向通知)：客户端的请求发送到服务器，但并不期望服务器做出任何响应。
一对多的交互方式有以下几种类型：
(1) 发布/订阅： 客户端发送通知消息，被零个或多个感兴趣的服务订阅。
(2) 发布/异步响应：客户端发送请求消息，然后等待从感兴趣的服务发回的响应。
每个服务通常使用的都是以上这些交互方式的组合，而不是单独使用一个交互方式。