微服务架构中的进程间通信——基于同步RPI的进程间通信机制学习总结

使用远程过程调用（RPI）的进程间通信机制时，客户端向服务器发送请求，服务端处理请求并返回响应。远程过程调用的通信原理如图1所示：

图1 RPI调用原理

客户端的业务逻辑通过调用代理接口（通常由远程过程调用代理适配器类实现）向服务端发出请求，有远程过程调用服务器适配器类来处理请求。该适配器类通过接口调用服务的业务逻辑，并通过远程过程调用代理将结果返回给客户端。注：代理接口通常封装了底层的通信协议

常用的RPI通信方式有REST和RCP

一 REST

REST是一种使用HTTP协议的进程间通信机制。

 REST提供了一系列架构约束，当作为整体使用时，它强调组件交互的可扩展性、接口的通用性、组件的独立部署，以及那些能减少交互延迟的中间件，它强化了安全性，也能封装遗留系统。

在REST中，关键的概念是资源 。REST使用HTTP动词（GET、PUT等）来操作资源，通过URL来定位资源。REST成熟度模型将REST分为了4个层次：

成熟度模型

    Level 0:客户端只向服务端发起HTTP POST请求进行服务调用。每个请求指明了需要执行的操作，该操作针对的目标和必要的参数

    Level 1: 引入资源的概念。客户端需要对资源执行操作，客户端发出要执行的操作和包含任何参数的POST请求。

    Level2:使用HTTP动词来执行操作。请求查询参数和主体（如果有的话）执行操作的参数。这让服务能够借助web基础设置服务来换成GET请求。

    Level3:基于HATEOAS（Hypertext As The Engine Of Application State）原则设计，基本思想是由GET请求返回的信息中包含链接，这些链接能够执行该资源允许的操作（如通过返回的链接取消订单、确认消息等） 

REST好处和弊端

好处：

• 简单易用
• 可以通过postman、curl之类的命令行来测试接口
• 直接支持请求/响应方式的通信
• HTTP对防火墙友好
• 不需要中间代理，简化了系统架构

弊端：

• 只支持请求/响应方式的通信
• 可能导致可用性降低。由于客户端和服务端没有采用代理来缓存消息（直接通信），因此在调用REST API期间，客户端和服务端必须保持在线
• 客户端必须知道服务端的URL
• 在单个请求中获取多个资源实现起来比较复杂，具有挑战性
• 很多将一个接口的多个操作映射到http动词

二 RPC

     RPC有点向调用本地的函数的一样去调用远程函数，区别是本地调用是进程内调用，函数体是直接通过函数指针来指定的。但是RPC是进程间的调用，无法通过函数指针，因为两个进程的地址空间是不一样的。在RPC中，给每个函数分配了一个ID来解决这个问题，这个ID在所有进程中是惟一的。

图2.1 RPC 调用流程

 

    Call ID映射

    客户端在做远程过程调用时，附上这个ID。客户端和服务端分别维护一个 {函数 <--> Call ID} 的对应表。两者的表不一定相同，但相同的函数对应的Call ID必须相同。当客户端需要进行远程调用时，找出相应的Call ID，传给服务端；服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。

序列化和反序列化

    客户端如何把参数传递给服务端，而服务端又如何把结果返回给客户端了。熟悉的同学，应该都知道这是通过序列化和反序列化来完成的。客户端把参数序列化后通过网络传递给服务端，服务端反序列化该参数，然后根据Call ID找到对应的函数，把参数产地进去，输出结果。服务端将结果序列化通过网络传递给客户端，客户端反序列化后得到结果。

网络传输

    远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端

gRPC

    gRPC是REST的一种替代方案。gRPC是一种基于二进制消息的协议。不同于REST API，gRPC可以容易设计支持多个更新/复杂操作的API。

    gRPC API由一个或多个服务和请求/响应消息定义组成。服务的定义类似于java接口。gRPC除了支持简单的请求/响应RPC，还支持流式RPC，即可以使用消息流回复客户端，客户端也可以向服务端发送消息流。

    gRPC使用Protocol Buffers作为消息格式。Protocol Buffers的每个字段都有自己的编号，消息接收方可以提前所需的字段，可以过滤掉无法识别的字段，这为API保持向后兼容提供可能。

gRPC好处和弊端

  好处：

•     设计具有复杂更新操作的API很简单
•     具有高效、紧凑的进程间通信机制
•     支持在远程过程调用和消息传递过程中使用双向流式消息方式
•     实现了客户端和用各种语言编写的服务端之间的互操作性

  弊端：

•     对于JS客户端而言，JS客户端使用基于gRPC的API比使用REST API要复杂些
•     旧式的防火墙不一定支持HTTP 2

持续学习，持续更新。。。。