概述
本文来自srpc作者李颖欣。
只要涉及到网络通信,必然涉及到网络协议,应用层也是一样。在应用层最标准和常用的就是HTTP协议。但在很多性能要求较高的场景各大企业内部也会自定义的 RPC 协议。举个例子,就是相当于各个省不但用官方普通话,还都有自己的方言,RPC就相当于是一个方言。
RPC 的全称是 Remote Procedure Call,翻译过来就是远程过程调用,其实这个名称过分强调了和LPC(本地过程调用)的对比。没有突出出来 RPC 本身涉及到的一些技术特点。现在从三个角度聊聊 RPC
- RPC是什么:通过和HTTP的对比来帮大家了解RPC
- RPC有什么:介绍了RPC用到的用户桩代码、IDL序列化、压缩、协议、通信等技术点
- RPC生命周期:详细探讨RPC从请求发出到收到返回的全过程
RPC是什么
RPC可以分为两部分:用户调用接口 + 具体网络协议。前者为开发者需要关心的,后者由框架来实现。
1. 用户调用接口
举个例子,定义一个函数希望函数如果输入为“Hello World”的话,输出给一个“OK”,那么这个函数是个本地调用。如果一个远程服务收到“Hello World”可以给我们返回一个“OK”,那么这是一个远程调用。我们会和服务约定好远程调用的函数名。因此,我们的用户接口就是:输入、输出、远程函数名。
2. 具体网络协议
这是框架来实现的,把开发者要发出和接收的内容以某种应用层协议打包进行网络收发。这里可以和HTTP进行一个明显的对比:
RPC是一种自定义网络协议,由具体框架来定,比如SRPC里支持的RPC协议有:SRPC / thrift / BRPC / tRPC,并且也是tRPC协议目前唯一的开源实现,拿其中的SogouRPC-std protocol为例给大家看看RPC协议的大概样子:
HTTP也是一种网络协议,但包的内容是固定的,必须是:请求行 + 请求头 + 请求体;
3. 进一步思考
上图对应的颜色,所实现的功能是类似的。为什么大家都长差不多呢?
这里就需要搞清楚,我们想要实现用户接口,需要怎么做?最重要需要支持以下三个功能:
- 定位要调用的服务;
- 把完整的消息切下来;
- 让我们的消息向前/向后兼容;
这样既可以让消息内保证一定的灵活性,又可以方便拿下一块数据,去调用用户想要的服务。
我们用一个表格来看一下HTTP和RPC分别是怎么解决的:
定位要调用的服务 | 消息长度 | 消息前后兼容 | |
---|---|---|---|
HTTP | URL | header里Content-Length | body里自己解决 |
RPC | 指定Service和Method名 | 协议header里自行约定 | 交给具体IDL |
因此,大家都会需要类似的结构去组装一条完整的用户请求,而第三部分的body只要框架支持,RPC协议和HTTP是可以互通的!因此开发者完全可以根据自己的业务需求进行选型,接下来我们看一下RPC的层次架构,就可以明白为什么不同RPC框架之间的互通、以及RPC和HTTP协议又是如何做到互通的。
RPC有什么
我们可以借SRPC的架构,看一下RPC框架从用户到系统都有哪些层次,以及SRPC目前所横向支持的功能是什么:
- 用户代码(client的发送函数/server的函数实现)
- IDL序列化(protobuf/thrift serialization)
- 数据组织 (protobuf/thrift/json)
- 压缩(none/gzip/zlib/snappy/lz4)
- 协议 (Sogou-std/Baidu-std/Thrift-framed/TRPC)
- 通信 (TCP/HTTP)
我们先关注以下三个层级:
如图从左到右,是用户接触的最多到最少的层次。IDL层会根据开发者定义的请求/回复结构进行代码生成,目前用得比较多的是protobuf和thrift,而刚才说到的用户接口和前后兼容问题,都是IDL层来解决的。SRPC对于这两个IDL的用户接口实现方式是:
- thrift:IDL纯手工解析,用户使用srpc是不需要链thrift的库的
- protobuf:service的定义部分纯手工解析
中间那列是具体的网络协议,而各RPC能互通,就是因为大家实现了对方的“语言”,因此可以协议互通。
而RPC作为和HTTP并列的层次,第二列和第三列理论上是可以两两结合的,只需要第二列的具体RPC协议在发送时,把HTTP相关的内容进行特化,不要按照自己的协议去发,而按照HTTP需要的形式去发,就可以实现RPC与HTTP互通。
RPC的生命周期
到此我们可以通过SRPC看一下,把request通过method发送出去并处理response再回来的整件事情是怎么做的:
根据上图,可以更清楚地看到刚才提及的各个层级,其中压缩层、序列化层、协议层其实是互相解耦打通的,在SRPC代码上实现得非常统一,横向增加任何一种压缩算法或IDL或协议都不需要也不应该改动现有的代码。