grpc同一个通道可以同时支持同步和异步得请求_gRPC系列(一)什么是RPC？

本系列分为四大部分&＃xff1a;

• gRPC系列(一) 什么是RPC&＃xff1f;
• gRPC系列(二) 如何用Protobuf组织内容
• gRPC系列(三) 如何借助HTTP2实现传输
• gRPC系列(四) 框架如何赋能分布式系统 (尽情期待)

初步印象

RPC的语义是远程过程调用&＃xff0c;在一般的印象中&＃xff0c;就是将一个服务调用封装在一个本地方法中&＃xff0c;让调用者像使用本地方法一样调用服务&＃xff0c;对其屏蔽实现细节。而具体的实现是通过调用方和服务方的一套约定&＃xff0c;基于TCP长连接进行数据交互达成。

上面的解释似云里雾里&＃xff0c;仅仅了解到这种程度是远远不够的&＃xff0c;还需要更进一步&＃xff0c;以相对底层和抽象的视角来理解RPC。

三个特点

广义上来讲&＃xff0c;所有本应用程序外的调用都可以归类为RPC&＃xff0c;不管是分布式服务&＃xff0c;第三方服务的HTTP接口&＃xff0c;还是读写Redis的一次请求。从抽象的角度来讲&＃xff0c;它们都一样是RPC&＃xff0c;由于不在本地执行&＃xff0c;都有三个特点&＃xff1a;

• 需要事先约定调用的语义(接口语法)
• 需要网络传输
• 需要约定网络传输中的内容格式

以一次Redis调用为例&＃xff0c;执行redis.set("rpc", 1)这个调用&＃xff0c;其中&＃xff1a;

• set及其参数("rpc", 1)&＃xff0c;就是对调用语义的约定&＃xff0c;由redis的API给出
• RedisServer会监听一个服务端口&＃xff0c;通过TCP传输内容&＃xff0c;用异步事件驱动实现高并发
• 底层库会约定数据如何进行编解码&＃xff0c;如何标识命令和参数&＃xff0c;如何表示结果&＃xff0c;如何表示数据的结尾等等

这三个特点都是因为调用不在本地而不得不衍生出来的问题&＃xff0c;也因此决定了RPC的形态。所有的RPC解决方案都是在解决这三个问题&＃xff0c;不断地在提出更加优良的解决方案&＃xff0c;试图达到更好的性能&＃xff0c;更低的使用成本。 本文也将围绕这三个特点来展开内容。

常规的RPC一般都是基于一个大的内部服务&＃xff0c;进行分布式拆分&＃xff0c;由于其语义上以本地方法的作为入口&＃xff0c;那么天然的就更倾向于具备高性能、支持复杂参数和返回值、跨语言等特性。下图是RPC调用的过程示意图&＃xff1a;

内容组织约定

Stub会负责封装命令和参数&＃xff0c;并以特定的数据格式进行打包。其中命令、参数和返回值的需要客户端和服务端的Stub事先进行协商&＃xff0c;双方都需要维护一份完全一样的方法及参数列表。更进一步需要知道对方如何进行压缩打包&＃xff0c;如何压缩结构体&＃xff0c;如何压缩Class等等&＃xff0c;并严格按照标准进行解压缩&＃xff0c;中途有任何一丝的差错都会的导致调用失败。所以一般情况下可能会对数据进行一定的校验&＃xff0c;同时要协商方法、参数等错误时如何返回。 这是一个比较繁杂的过程&＃xff0c;混合了调用语法和 内容解压缩两部分内容&＃xff0c;可被理解为如何组织内容的问题。

网络传输

搞定了协议约定问题后&＃xff0c;接下来就是要通过Runtime进行内容传输了&＃xff0c;这又是一大难题&＃xff0c;一般是需要通过Socket编程来实现&＃xff0c;使用TCP或UDP来进行传输&＃xff0c;如果是UDP可以用数据报来区分每一次请求和回复。但如果是字节流的TCP&＃xff0c;就需要用特殊的方式来标示请求或回复的末尾&＃xff0c;用来区分不同的请求。同时当对调用性能有要求时&＃xff0c;可能会使用Socket的异步编程模型&＃xff0c;消除等待中的消耗&＃xff0c;这会引入事件机制&＃xff0c;通过状态机来解析处理或回复请求。当出现超时、丢包等情况时还进行做重试、重传、报错等等。

拆解到协议约定和网络传输时&＃xff0c;就会发现实现RPC调用是一件非常复杂的事情&＃xff0c;自己实现千难万难&＃xff0c;接下来就了解一番已有的&＃xff0c;针对协议约定和网络传输的解决方案。

当然&＃xff0c;在技术高度成熟的今天&＃xff0c;已经又很多先烈将传输问题解决掉了&＃xff0c;接下来就介绍几款常见的案例组合。

ONC RPC

ONC RPC是相对早期的RPC解决方案&＃xff0c;通过外部数据表示法来约定数据的压缩方式&＃xff1a;

被传输的所有内容都需要通过上面的约定进行压缩&＃xff0c;这样接收方就能顺利地按照同样的协议进行解压缩。

对于命令和参数列表的约定&＃xff0c;会创建一份公共的协议文件&＃xff0c;里面会定义被调用的方法名&＃xff0c;参数列表&＃xff0c;对象的列表等等。然后用特定工具将文件进行解析生成Stub程序&＃xff0c;客户端和服务端都同时将Stub程序放在代码中。比如对方法名进行编号&＃xff0c;将GetUserName(userId)这个方法编号为1&＃xff0c;在调用时就将1传输给服务端&＃xff0c;服务端通过协议文件就知道调用的方法&＃xff0c;这样节省了大量的空间。

传输则通过对应的类库实现&＃xff0c;通过Socket编程实现的非常复杂的解决方案&＃xff0c;包含了超时、失败、异常处理、状态转换等等功能。

这种早期的方案&＃xff0c;在每一次代码更新时都需要重新生成Stub程序&＃xff0c;调用方和服务方都需要及时更新对应的文件。给某一个方法增加一个默认参数&＃xff0c;都需要全部使用者同步升级&＃xff0c;从迭代或多版本的场景看来&＃xff0c;这是一场噩梦。

RESTfull HTTP JSON

RESTfull是一种资源状态转换的架构风格&＃xff0c;也可以用来实现RPC&＃xff0c; 互联网对HTTP超广泛的支持&＃xff0c;使得这相当简单&＃xff0c;也是大多数情况下的首选。

通过HTTP协议来进行内容传输&＃xff0c;Header用来约定编码、body大小等&＃xff0c;彼此以rn来分割&＃xff0c;Header和body之间通过两个连续的rn来间隔&＃xff0c;能很容易地区分不同的请求。

通过Url和对应参数来标示要调用的方法和参数。在body中用JSON对内容进行编码&＃xff0c;极易跨语言&＃xff0c;不需要约定特定的复杂编码格式和Stub文件。在版本兼容性上非常友好&＃xff0c;扩展也很容易。

众多的优点使得这种方案广受欢迎。不过也有其无法避开的弱点&＃xff1a;

• HTTP的header和Json的数据冗余和低压缩率使得传输性能差
• JSON难以表达复杂的参数类型&＃xff0c;如结构体等

gRPC HTTP2.0 Protobuf

gRPC是一款RPC框架&＃xff0c;也是本系列的主角&＃xff0c;在性能和版本兼容上做了提升和让步&＃xff1a;

• Protobuf进行数据编码&＃xff0c;提高数据压缩率
• 使用HTTP2.0弥补了HTTP1.1的不足
• 同样在调用方和服务方使用协议约定文件&＃xff0c;提供参数可选&＃xff0c;为版本兼容留下缓冲空间

protobuf是一款用C&＃43;&＃43;开发的跨语言、二进制编码的数据序列化协议&＃xff0c;以超高的压缩率著称。它和早期的RPC方案一样&＃xff0c;需要双方维护一个协议约束文件&＃xff0c;以.proto结尾&＃xff0c;使用proto命令对文件进行解析&＃xff0c;会生成对应的Stub程序&＃xff0c;客户端和服务端都需要保存这份Stub程序用来进行编解码。对于这种协议文件导致的升级困难问题&＃xff0c;protobuf 3 中定义的字段默认都是可选的(可以不传)&＃xff0c;在接口升级时&＃xff0c;部分客户端不需要升级自己的Stub程序。

对于JSON等文本形式的序列化协议来说&＃xff0c;protobuf能有几十倍空间和性能提升&＃xff0c; 比如传输123&＃xff0c;文本类的需要3个字节(ascii 31 32 33)来传输&＃xff0c;而二进制类只需要一个字节(01111011)就可以表示。

同时protobuf会维护.proto文件&＃xff0c;这样在解析文件生成Stub程序时&＃xff0c;可以对方法名等进行编号&＃xff0c;传输时只传编号&＃xff0c;而不用传方法的名字&＃xff0c;这又可以节省大量字节&＃xff0c;还有其他更多的精巧压缩方法&＃xff0c;比如TLV&＃xff0c;详情可以参考proto encoding 。

解决了数据体积的问题后&＃xff0c;gRPC使用HTTP2来改善传输性能。 HTTP2是在HTTP1.1的基础上做了大量的改进&＃xff0c;HTTP1.1虽然引入了KeepAlive复用TCP连接&＃xff0c;但仍然有很多问题&＃xff1a;

• 使用KeepAlive的请求是串行执行(非pipeline时)&＃xff0c;pipeline时有队首阻塞问题
• 每次都需要发送不必要的Header
• 不能双向通信

简单补充一下pipeline&＃xff0c;HTTP1.1中允许多个请求复用连接&＃xff0c;同时可以一口气将请求全部发出去&＃xff0c;不用一个返回后再发送第二个&＃xff0c;提升并发性。而服务端需要将请求的结果&＃xff0c;按照pipeline中发送的顺序进行顺序返回&＃xff0c;如果靠前的请求阻塞了&＃xff0c;那么靠后请求返回就会被动等待。

HTTP2解决了这些问题&＃xff0c;引入了新的机制&＃xff1a;

• 在两端建立Header索引表&＃xff0c;每次只发送索引&＃xff0c;减小header体积
• 建立虚拟通道&＃xff0c;将数据拆分成多个流&＃xff0c;每个流有自己的ID和优先级&＃xff0c;并且流可以双向传输&＃xff0c;每个流可以进一步拆成多个帧。可以将多个请求切成不同的流发送&＃xff0c;每个流可以独立返回&＃xff0c;避开1.1的串行或队首阻塞问题。

同时&＃xff0c;基于HTTP2的数据流机制&＃xff0c;gRPC客户端和服务端可以实现批量操作优化&＃xff0c;客户端可以攒一些请求&＃xff0c;一口气发给服务端&＃xff0c;服务端也可以批量返回结果&＃xff0c;借此实现流式rpc。

RabbitMQ

rpc作为一种极常见的服务形态&＃xff0c;以异步和解耦著称的mq也自然不会放过这个场景&＃xff0c;rabbitmq就为rpc调用提供了很好的支持。

一般和rabbitmq的交互场景是发布或消费消息&＃xff0c;是一个单向的过程&＃xff0c;而rpc却是一种同步的双向交互过程&＃xff0c;在使用上有些差异。要理解rabbitmq如何实现rpc&＃xff0c;还是可以从上面三个抽象的特点出发&＃xff0c;万变不离其宗。

如何协商调用语义

mq中的消息是从exchange分发到queue中&＃xff0c;消费端在特定的queue中获取消息&＃xff0c;rpc的请求依然要走这条路径: 方法调用->exchange->queue->方法执行。

创建一个direct类型的exchange&＃xff0c;让每个rpc方法对应一个queue&＃xff0c;这个exchange通过routing_key分发到对应的queue中&＃xff0c; 让特定的消费者来实际执行rpc方法。这样rpc方法的语义就通过queue来约定&＃xff0c;而方法的参数&＃xff0c;可以放入消息中。

如何将结果传递回客户端

方法调用->exchange->queue->方法执行, 这条路是单行道&＃xff0c;方法执行端执行完rpc方法后不能按照原路将结果返回给客户端。要实现结果回传&＃xff0c;就得再开辟一条结果回传端->exchange->queue->结果等待端路径&＃xff0c;一条用来发送rpc请求&＃xff0c;另一条用来回传rpc结果&＃xff0c;方法调用者和方法执行者都会扮演生产者和消费者。

rabbitmq中有回调队列(Callback queue)来实现调用结果回传&＃xff0c;同时有关联ID(Correlation Id)来唯一标识每一份调用结果。

rpc调用方在发送请求时&＃xff0c;会在数据中带上回调队列信息(routing_key)和关联ID&＃xff0c;rpc执行方在执行完方法后&＃xff0c;就将关联ID掺入执行结果中&＃xff0c;并将结果通过exchange发往回调队列(通过routing_key)。 rpc调用方在发送请求后&＃xff0c;紧接着在设置的回调队列中等结果就行。 整个过程(两条路径)共用同一个exchange。

调用参数和调用结果的打包可以用JSON&＃xff0c;protobuf等等&＃xff0c;协商一致即可。完整示例代码

使用mq实现rpc&＃xff0c;有其独有的优势&＃xff0c;rpc执行端可以轻松地横向扩展&＃xff0c;rpc调用方也不用考虑负载均衡&＃xff0c;沿袭了mq解耦的优点。不过对于调用超时&＃xff0c;执行端崩溃等等情况得做额外处理。调用方在等待结果时需要设置超时间&＃xff0c;高性能的rpc调用还需要调用方能异步高效地通过关联ID将请求结果储存起来&＃xff0c;等待调用者获取。Spring框架的实现方案就是用一个HashMap将结果保存起来&＃xff0c;等待调用者以关联ID作为key来取结果。

工程落地

RPC作为分布式系统的桥梁&＃xff0c;在解决以上三大问题之外&＃xff0c;还得需要进行工程落地&＃xff0c;这就是RPC框架的核心职责。其要解决的问题有&＃xff1a;

• 集成服务发现的能力
• 负载均衡、限流、熔断等常规操作
• 服务方并发能力、稳定性
• 请求方资源利用、池化、容错等

整体的目标是将RPC调用落地&＃xff0c;为分布式系统赋能。这是一个系统性的工程。

总结

RPC从抽象的角度来看:

• 具有需要约定调用语法
• 需要约定内容编码方式
• 需要网络传输

这三大特点&＃xff0c;进一步可以归纳为协议约定问题和网络传输问题&＃xff0c;本文的主要内容都围绕这两大问题&＃xff0c;并介绍常见的解决方案&＃xff0c;借此对建立RPC更深的理解。

接下来的内容&＃xff0c;会走进gRPC这款强大的RPC框架&＃xff0c;分别介绍gRPC是如何解决上面的三个点&＃xff0c;并提供出框架级的能力&＃xff0c;为分布式系统赋能。