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

一、交互方式

在为服务选择的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

猜你喜欢

转载自blog.csdn.net/qq_24166417/article/details/106884631