RPC框架小结

为什么说要搞定微服务架构，先搞定RPC框架？

1. 为什么说要搞定微服务架构，先搞定RPC框架？

如果没有统一的服务框架，RPC框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的低效。

所以，统一RPC框架把上述“业务之外”的技术劳动统一处理，是服务化首要解决的问题。

RPC框架能够让调用方“像调用本地函数一样调用远端的函数（服务）”。

2. RPC框架职责

通过上面的讨论，RPC框架要向调用方屏蔽各种复杂性，要向服务提供方也屏蔽各类复杂性：

1）调用方感觉就像调用本地函数一样

2）服务提供方感觉就像实现一个本地函数一样来实现服务

    所以整个RPC框架又分为client部分与server部分，负责把整个非（1）（2）的各类复杂性屏蔽，这些复杂性就是RPC框架的职责。

    再细化一些，

client端又包含：序列化、反序列化、连接池管理、负载均衡、故障转移、队列管理，超时管理、异步管理等等等等职责。

server端包含：服务端组件、服务端收发包队列、io线程、工作线程、序列化反序列化、上下文管理器、超时管理、异步回调等等等等职责。

转自：https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959553&idx=1&sn=c1084e91875721c5f6baf544450afa38&scene=21#wechat_redirect

微服务架构之RPC-client序列化细节

1. 为什么要进行序列化

    工程师通常使用“对象”来进行数据的操纵，但当需要对数据进行存储（固化存储，缓存存储）或者传输（跨进程网络传输）时，“对象”就不这么好用了，往往需要把数据转化成连续空间的二进制字节流，一些典型的场景是：

1）数据库索引的磁盘存储：数据库的索引在内存里是b+树或者hash的格式，但这个格式是不能够直接存储到磁盘上的，所以需要把b+树或者hash转化为连续空间的二进制字节流，才能存储到磁盘上

2）缓存的KV存储：redis/memcache是KV类型的缓存，缓存存储的value必须是连续空间的二进制字节流，而不能够是User对象

3）数据的网络传输：socket发送的数据必须是连续空间的二进制字节流，也不能是对象

所谓序列化（Serialization），就是将“对象”形态的数据转化为“连续空间二进制字节流”形态数据的过程，以方便存储与传输。这个过程的逆过程叫做反序列化。

2. 怎么进行序列化

1）很容易想到的一个方法是xml（或者json）这类具有自描述特性的标记性语言

2）第二个方法是自己实现二进制协议来进行序列化，还是以上面的User对象为例，可以设计一个这样的通用协议：

   （1）头4个字节表示序号

（2）序号后面的4个字节表示key的长度m

（3）接下来的m个字节表示key的值

（4）接下来的4个字节表示value的长度n

（5）接下来的n个字节表示value的值

（6）像xml一样递归下去，直到描述完整个对象

实际的序列化协议要考虑的细节远比这个多，例如：强类型的语言不仅要还原属性名，属性值，还要还原属性类型；复杂的对象不仅要考虑普通类型，还要考虑对象嵌套类型等。however，序列化的思路都是类似的。

3. 序列化协议要考虑什么因素

不管使用成熟协议xml/json，还是自定义二进制协议来序列化对象，序列化协议设计时要考虑哪些因素呢？

1）解析效率：这个应该是序列化协议应该首要考虑的因素，像xml/json解析起来比较耗时，需要解析doom树，二进制自定义协议解析起来效率就很高

2）压缩率，传输有效性：同样一个对象，xml/json传输起来有大量的xml标签，信息有效性低，二进制自定义协议占用的空间相对来说就小多了

3）扩展性与兼容性：是否能够方便的增加字段，增加字段后旧版客户端是否需要强制升级，都是需要考虑的问题，xml/json和上面的二进制协议都能够方便的扩展

4）可读性与可调试性：这个很好理解，xml/json的可读性就比二进制协议好很多

5）跨语言：上面的两个协议都是跨语言的，有些序列化协议是与开发语言紧密相关的，例如dubbo的序列化协议就只能支持Java的RPC调用

6）通用性：xml/json非常通用，都有很好的第三方解析库，各个语言解析起来都十分方便，上面自定义的二进制协议虽然能够跨语言，但每个语言都要写一个简易的协议客户端

7）欢迎大家补充…

4. 业内常见的序列化方式

1）xml/json：解析效率，压缩率都较差；扩展性、可读性、通用性较好

2）thrift：没有用过，欢迎大家补充

3）protobuf：Google出品，必属精品，各方面都不错，强烈推荐，属于二进制协议，可读性差了点，但也有类似的to-string协议帮助调试问题

4）Avro：没有用过，欢迎大家补充

5）CORBA：没有用过，欢迎大家补充

6）mc_pack：懂的同学就懂，不懂的就不懂了，09年用过，传说各方面都超越protobuf，懂行的同学可以说一下现状

7）…

转自：https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959558&idx=1&sn=610f06c6d62a5c22311d27cf40f758ef&scene=21#wechat_redirect

RPC-client异步收发核心细节

1. RPC-client主要功能：

1）序列化反序列化的部分（上图中的1、4）

2）发送字节流与接收字节流的部分（上图中的2、3）

2. 客户端调用又分为同步调用与异步调用

    同步调用的代码片段为：

Result = Add(Obj1, Obj2);// 得到Result之前处于阻塞状态

    异步调用的代码片段为：

Add(Obj1, Obj2, callback);// 调用后直接返回，不等结果

处理结果通过回调得到：

callback(Result){// 得到处理结果后会调用这个回调函数

…

}

3. RPC-client同步调用

    所谓同步调用，在得到结果之前，一直处于阻塞状态，会一直占用一个工作线程，上图简单的说明了一下组件、交互、流程步骤。

上图中的左边大框，就代表了调用方的一个工作线程。

    左边粉色中框，代表了RPC-client组件。

    右边橙色框，代表了RPC-server。

    蓝色两个小框，代表了同步RPC-client两个核心组件，序列化组件与连接池组件。

    白色的流程小框，以及箭头序号1-10，代表整个工作线程的串行执行步骤：

1）业务代码发起RPC调用，Result=Add(Obj1,Obj2)

2）序列化组件，将对象调用序列化成二进制字节流，可理解为一个待发送的包packet1

3）通过连接池组件拿到一个可用的连接connection

4）通过连接connection将包packet1发送给RPC-server

5）发送包在网络传输，发给RPC-server

6）响应包在网络传输，发回给RPC-client

7）通过连接connection从RPC-server收取响应包packet2

8）通过连接池组件，将conneciont放回连接池

9）序列化组件，将packet2范序列化为Result对象返回给调用方

10）业务代码获取Result结果，工作线程继续往下走

RPC框架需要支持负载均衡、故障转移、发送超时，这些特性都是通过连接池组件去实现的。

    连接池组件

    典型连接池组件对外提供的接口为：

int ConnectionPool::init(…);

Connection ConnectionPool::getConnection();

intConnectionPool::putConnection(Connection t);

【INIT】

和下游RPC-server（一般是一个集群），建立N个tcp长连接，即所谓的连接“池”

【getConnection】

从连接“池”中拿一个连接，加锁（置一个标志位），返回给调用方

【putConnection】

将一个分配出去的连接放回连接“池”中，解锁（也是置一个标志位）

如何实现负载均衡？

回答：连接池中建立了与一个RPC-server集群的连接，连接池在返回连接的时候，需要具备随机性。

如何实现故障转移？

回答：连接池中建立了与一个RPC-server集群的连接，当连接池发现某一个机器的连接异常后，需要将这个机器的连接排除掉，返回正常的连接，在机器恢复后，再将连接加回来。

如何实现发送超时？

回答：因为是同步阻塞调用，拿到一个连接后，使用带超时的send/recv即可实现带超时的发送和接收。

总的来说，同步的RPC-client的实现是相对比较容易的，序列化组件、连接池组件配合多工作线程数，就能够实现。还有一个问题，就是【“工作线程数设置多少最为合适？”】，这个问题在之前的文章中讨论过，此处不再深究。

4. PC-client异步回调

    所谓异步回调，在得到结果之前，不会处于阻塞状态，理论上任何时间都没有任何线程处于阻塞状态，因此异步回调的模型，理论上只需要很少的工作线程与服务连接就能够达到很高的吞吐量。

上图中左边的框框，是少量工作线程（少数几个就行了）进行调用与回调。

    中间粉色的框框，代表了RPC-client组件。

    右边橙色框，代表了RPC-server。

    蓝色六个小框，代表了异步RPC-client六个核心组件：上下文管理器，超时管理器，序列化组件，下游收发队列，下游收发线程，连接池组件。

    白色的流程小框，以及箭头序号1-17，代表整个工作线程的串行执行步骤：

1）业务代码发起异步RPC调用，Add(Obj1,Obj2, callback)

2）上下文管理器，将请求，回调，上下文存储起来

3）序列化组件，将对象调用序列化成二进制字节流，可理解为一个待发送的包packet1

4）下游收发队列，将报文放入“待发送队列”，此时调用返回，不会阻塞工作线程

5）下游收发线程，将报文从“待发送队列”中取出，通过连接池组件拿到一个可用的连接connection

6）通过连接connection将包packet1发送给RPC-server

7）发送包在网络传输，发给RPC-server

8）响应包在网络传输，发回给RPC-client

9）通过连接connection从RPC-server收取响应包packet2

10）下游收发线程，将报文放入“已接受队列”，通过连接池组件，将conneciont放回连接池

11）下游收发队列里，报文被取出，此时回调将要开始，不会阻塞工作线程

12）序列化组件，将packet2范序列化为Result对象

13）上下文管理器，将结果，回调，上下文取出

14）通过callback回调业务代码，返回Result结果，工作线程继续往下走

如果请求长时间不返回，处理流程是：

15）上下文管理器，请求长时间没有返回

16）超时管理器拿到超时的上下文

17）通过timeout_cb回调业务代码，工作线程继续往下走

    上下文管理器

    为什么需要上下文管理器？

回答：由于请求包的发送，响应包的回调都是异步的，甚至不在同一个工作线程中完成，需要一个组件来记录一个请求的上下文，把请求-响应-回调等一些信息匹配起来。

如何将请求-响应-回调这些信息匹配起来？

这是一个很有意思的问题，通过一条连接往下游服务发送了a，b，c三个请求包，异步的收到了x，y，z三个响应包：

   （1）怎么知道哪个请求包与哪个响应包对应？

   （2）怎么知道哪个响应包与哪个回调函数对应？

回答：这是通过【请求id】来实现请求-响应-回调的串联的。

      整个处理流程如上，通过请求id，上下文管理器来对应请求-响应-callback之间的映射关系：

1）生成请求id

2）生成请求上下文context，上下文中包含发送时间time，回调函数callback等信息

3）上下文管理器记录req-id与上下文context的映射关系，

4）将req-id打在请求包里发给RPC-server

5）RPC-server将req-id打在响应包里返回

6）由响应包中的req-id，通过上下文管理器找到原来的上下文context

7）从上下文context中拿到回调函数callback

8）callback将Result带回，推动业务的进一步执行

如何实现负载均衡，故障转移？

回答：与同步的连接池思路相同。不同在于，同步连接池使用阻塞方式收发，需要与一个服务的一个ip建立多条连接，异步收发，一个服务的一个ip只需要建立少量的连接（例如，一条tcp连接）。

     如何实现超时发送与接收？

回答：同步阻塞发送，可以直接使用带超时的send/recv来实现，异步非阻塞的nio的网络报文收发，如何实现超时接收呢？（由于连接不会一直等待回包，那如何知晓超时呢？）这时，超时管理器就上场啦。

     超时管理器

    超时管理器，用于实现请求回包超时回调处理。

每一个请求发送给下游RPC-server，会在上下文管理器中保存req-id与上下文的信息，上下文中保存了请求很多相关信息，例如req-id，回包回调，超时回调，发送时间等。

超时管理器启动timer对上下文管理器中的context进行扫描，看上下文中请求发送时间是否过长，如果过长，就不再等待回包，直接超时回调，推动业务流程继续往下走，并将上下文删除掉。

如果超时回调执行后，正常的回包又到达，通过req-id在上下文管理器里找不到上下文，就直接将请求丢弃（因为已经超时处理过了）。

however，异步回调和同步回调相比，除了序列化组件和连接池组件，会多出上下文管理器，超时管理器，下游收发队列，下游收发线程等组件，并且对调用方的调用习惯有影响（同步->回调）。

异步回调能提高系统整体的吞吐量，具体使用哪种方式实现RPC-client，可以结合业务场景来选取（对时延敏感的可以选用同步，对吞吐量敏感的可以选用异步）。

转自：https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959576&idx=1&sn=2be8d3f61effe7118abf920a175da710&scene=21#wechat_redirect