微服务架构中的进程间通信（交互方式、消息格式）

一、交互方式

在为服务选择的API选择进程间通信机制之前，首先要考虑服务与其客户端的交互方式。

交互方式的选择影响应用程序的可用性。

交互方式可以帮助选择合适的集成测试策略。

交互方式分为两个维度：

1、一对一和一对多

一对一：每个客户端请求由一个服务实例处理；

一对多：每个客户端请求由多个服务实例处理。

2、同步和异步

同步：客户端请求需要服务端实时响应，客户端等待响应时可能导致阻塞；

异步：客户端请求不会阻塞进程，服务端的响应可以是非实时的。

交互方式组合见表格：

	一对一	一对多
同步模式	请求/响应（服务紧耦合）	无
异步模式	异步请求/响应 单向通知	发布/订阅 发布/异步响应

 

二、API版本

如何定义API取决于使用的进程间通信机制。如果使用的是消息机制，则API由消息通道、消息类型、消息格式组成；如果使用的是HTTP，则API由URL、HTTP动词以及请求和响应格式组成。

语义化版本控制

作用：指定如何使用版本号、并且以正确的方式递增版本号。

要求：版本号由三部分组成-MAJOR.MINOR.PATCH。必须按照如下方式递增版本号：

MAJOR：对API进行不兼容的更改时

MINOR：对API进行向后兼容的增强时

PATCH：向后兼容的错误修复时；

 三、消息格式

消息格式的选择会对进程间通信的效率、API的可用性、可演化性产生影响。

消息的格式分为两类：文本、二进制。

基于文本的消息格式

常用的：JSON、XML

好处：可读性高、自描述的，允许消息的接收方只挑选它们感兴趣的值。对消息结构的修改可以做到很好的后向兼容。

弊端：消息过于冗长，特别是XML；解析文本引入的额外开销，尤其是消息较大时。

JSON消息：命名属性的集合；XML消息：命名元素和值的集合。

二进制消息格式

常用的：Protocol Buffers、Avro（提供类强类型定义的IDL-接口描述文件，用于定义消息的格式）

 笔记来自：《微服务架构设计模式》一书，作者 [美] 克里斯·理查森 著，喻勇译  第三章P63-70