https://www.cnblogs.com/charlieroro/p/14707910.html
本文介绍了几种典型的微服务间通信方式，并提供了几种相应的实现方式。
微服务的进程间通信架构图：
IPC：进程间通信
MSA：微服务架构
服务间通信包含两大类：
视角 #1
一对一通信
一对多通信
视角 #2
一对一通信类型
一对多通信类型
服务API是服务端和客户端之间的合约。
服务APIs使用版本语法来命名APIs的版本。版本语法包含三个部分：MAJOR.MINOR.PATCH。
IPC的本质是消息的交互。消息有两种格式：文本格式和二进制格式。
在实现时必须注意消息格式的跨语言协作，因此不推荐使用JavaSerializer。
远程调用服务的方法，但对调用者来说，就像使用本地方法一样。
流程：
REST是一种理念，而非协议。REST用到了HTTP。
REST的一个主要理念是资源，它代表一个单独的业务实体，如Movie，Customer等，或一个对象集合。
REST使用HTTP verb来操作资源，如：
POST /movies : Create a moviePUT /movies : Update a movieGET /movies : Get all moviesGET /movies/{movieId} : Get a moviegRPC是一个基于二进制的消息协议，因此必须优先处理API(定义API)。首先使用IDL定义接口，然后编译生成期望语言的客户端和服务端stubs。
是一个RPI代理，用于在连续发送的错误超过一定阈值时，在一定时间内拒绝调用。
常用的断路器库如下：
为了构建同步通信的健壮性，需要考虑如下模式：
问题
服务A需要通过API调用服务B，因此服务A需要知道服务B的地址。
传统方式
最简单的方式是静态配置实例的网络地址，这样调用者可以在配置文件中指定该地址。
传统方式的问题
现在，由于在自动扩容、失败和升级时会动态创建服务实例，并为实例动态分配网络位置，因此引出了服务发现的需求。
服务发现
服务发现的概念非常简单，最主要的组件是服务注册表，存储了应用服务实例的网络位置。
服务发现的两种主要实现方式：
服务发现模式：
基于消息的应用通常会使用一个消息代理(broker)，作为服务间的中间人。另一种方式是使用无消息代理架构。
发送端会向一个channel写入消息，接收者会从该channel中读取消息。
消息包含首部和消息体。
首部是一个键值对集合，此外还包含一个唯一消息Id(来自发送端或由消息基础设施生成)。
消息体包含需要发送的数据。
消息通过channel进行交互。channel有两种类型：
异步请求响应
发布订阅
消息代理是所有消息流的中间人。
好处
典型的开源消息代理
在选择消息代理时需要考虑的因素
本文来自博客园，作者：charlieroro，转载请注明原文链接：https://www.cnblogs.com/charlieroro/p/14707910.html