微服务的进程间通信(IPC)

本文介绍了几种典型的微服务间通信方式，并提供了几种相应的实现方式。 译自：Microservice 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 movie
• PUT /movies : Update a movie
• GET /movies : Get all movies
• GET /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

在选择消息代理时需要考虑的因素

• 支持的编程语言
• 支持的消息标准
• 消息顺序
• 保证消息的发送
• 持久化
• 稳定性
• 可扩展性
• 延迟
• 产品竞争力