微服务的进程间通信(IPC)
本文介绍了几种典型的微服务间通信方式，并提供了几种相应的实现方式。
微服务的进程间通信架构图：
术语
IPC：进程间通信
MSA：微服务架构
概述
服务间通信包含两大类：
- 基于同步请求/响应的通信，如REST，gRPC
- 基于异步消息的通信，如AMQP或STOMP
通信视角
视角 #1
-
一对一通信
-
一对多通信
视角 #2
- 同步通信
- 异步通信
一对一通信类型
- 请求/响应通信
- 异步请求响应
- 单方面通知
一对多通信类型
- 发布/订阅
- 发布/异步响应
APIs
服务API是服务端和客户端之间的合约。
- 理想情况下，首先应该定义服务的接口，然后再实现服务
服务APIs使用版本语法来命名APIs的版本。版本语法包含三个部分：MAJOR.MINOR.PATCH。
消息格式
IPC的本质是消息的交互。消息有两种格式：文本格式和二进制格式。
- 文本格式：JSON，XML
- 二进制格式：Avro，Protobuf和Thrift
在实现时必须注意消息格式的跨语言协作，因此不推荐使用JavaSerializer。
RPC
远程调用服务的方法，但对调用者来说，就像使用本地方法一样。
流程：
- 客户端的业务逻辑调用RPI代理接口
- RPI代理通过网络调用RPI服务，即调用服务端的业务逻辑
- 服务端将结果返回给RPI代理，最终由RPI代理返回给客户端的业务逻辑。
REST
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 movie
gRPC
gRPC是一个基于二进制的消息协议，因此必须优先处理API(定义API)。首先使用IDL定义接口，然后编译生成期望语言的客户端和服务端stubs。
断路器
是一个RPI代理，用于在连续发送的错误超过一定阈值时，在一定时间内拒绝调用。
常用的断路器库如下：
- Netflix Hystrix ( Java )
- Polly ( .Net )
- Hystrix Go (Go lang)
API通信的健壮性
为了构建同步通信的健壮性，需要考虑如下模式：
- 网络超时
- 重试
- 断路器
- 回滚
- 可靠性测试
服务发现
问题
服务A需要通过API调用服务B，因此服务A需要知道服务B的地址。
传统方式
最简单的方式是静态配置实例的网络地址，这样调用者可以在配置文件中指定该地址。
传统方式的问题
现在，由于在自动扩容、失败和升级时会动态创建服务实例，并为实例动态分配网络位置，因此引出了服务发现的需求。
服务发现
服务发现的概念非常简单，最主要的组件是服务注册表，存储了应用服务实例的网络位置。
服务发现的两种主要实现方式：
- 服务端和客户端直接与服务注册表交互
- 通过部署平台(如kubernetes)进行交互
服务发现模式：
- 自注册
- 客户端发现
- 服务端发现
异步消息
基于消息的应用通常会使用一个消息代理(broker)，作为服务间的中间人。另一种方式是使用无消息代理架构。
概念
发送端会向一个channel写入消息，接收者会从该channel中读取消息。
消息
消息包含首部和消息体。
首部是一个键值对集合，此外还包含一个唯一消息Id(来自发送端或由消息基础设施生成)。
消息体包含需要发送的数据。
消息类型
- 文档
- 目录
- 事件
Channels
消息通过channel进行交互。channel有两种类型：
- 点到点channel
- 发布订阅channel
异步通信实现
异步请求响应
发布订阅
无消息代理
- 服务可以直接进行交互
- ZeroMQ就是一个典型的无消息代理技术
基于消息代理的通信
消息代理是所有消息流的中间人。
好处
- 发送端不需要知道消费端的位置
- 在消息被消费者处理前，消息代理会对消息进行缓存
典型的开源消息代理
- ActiveMQ
- RabbitMQ
- Apache Kafka
在选择消息代理时需要考虑的因素
- 支持的编程语言
- 支持的消息标准
- 消息顺序
- 保证消息的发送
- 持久化
- 稳定性
- 可扩展性
- 延迟
- 产品竞争力