RPC 的主要功能目标是让构建分布式计算(应用)更容易,在提供强大的远程调用能力时不损失本地调用的语义简洁性。 为实现该目标,RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用。 下面我们将具体细化 stub 结构的实现。
RPC 调用分以下两种:
同步调用
用户方等待调用执行完成并返回结果。
异步调用
用户方调用后不用等待执行结果返回,但仍然可以通过回调通知等方式获取返回结果。 若用户方不关心调用返回结果,则变成单向异步调用,单向调用不用返回结果。
异步和同步的区分在于能否等待服务端执行完成并返回结果。
如下图所示。
RPC 服务方通过 RpcServer
去导出(export)远程接口方法,而用户方通过 RpcClient
去引入(import)远程接口方法。 用户方像调用本地方法一样去调用远程接口方法,RPC 框架提供接口的代理商实现,实际的调用将委托给代理商 RpcProxy
。 代理商封装调用信息并将调用转交给 RpcInvoker
去实际执行。 在用户端的 RpcInvoker
通过连接器 RpcConnector
去维持与服务端的通道 RpcChannel
, 并使用 RpcProtocol
执行协议编码(encode)并将编码后的请求消息通过通道发送给服务方。
RPC 服务端接收器 RpcAcceptor
接收用户端的调用请求,同样使用 RpcProtocol
执行协议解码(decode)。 解码后的调用信息传递给 RpcProcessor
去控制解决调用过程,最后再委托调用给 RpcInvoker
去实际执行并返回调用结果。
上面我们进一步拆解了 RPC 实现结构的各个组件组成部分,下面我们详细说明下每个组件的职责划分。
RpcServer
负责导出(export)远程接口
RpcClient
负责导入(import)远程接口的代理商实现
RpcProxy
远程接口的代理商实现
RpcInvoker
用户方实现:负责编码调用信息和发送调用请求到服务方并等待调用结果返回
服务方实现:负责调用服务端接口的具体实现并返回调用结果
RpcProtocol
负责协议编/解码
RpcConnector
负责维持用户方和服务方的连接通道和发送数据到服务方
RpcAcceptor
负责接收用户方请求并返回请求结果
RpcProcessor
负责在服务方控制调用过程,包括管理调用线程池、超时时间等
RpcChannel
数据传输通道
在进一步拆解了组件并划分了职责之后,这里以在 java 平台实现该 RPC 框架概念模型为例,详细分析下实现中需要考虑的因素。
导出远程接口
导出远程接口的意思是指只有导出的接口可以供远程调用,而未导出的接口则不能。 在 java 中导出接口的代码片段可能如下:
DemoService demo = new ...;RpcServer server = new ...;server.export(DemoService.class, demo, options);
我们可以导出整个接口,也可以更细粒度一点只导出接口中的某些方法,如:
// 只导出 DemoService 中签名为 hi(String s) 的方法server.export(DemoService.class, demo, "hi", new Class<?>[] { String.class }, options);
java 中还有一种比较特殊的调用就是多态,也就是一个接口可能有多个实现,那么远程调用时究竟调用哪个? 这个本地调用的语义是通过 jvm 提供的引用多态性隐式实现的,那么对于 RPC 来说跨进程的调用就没法隐式实现了。 假如前面 DemoService 接口有 2 个实现,那么在导出接口时就需要特殊标记不同的实现,如:
DemoService demo = new ...;DemoService demo2 = new ...;RpcServer server = new ...;server.export(DemoService.class, demo, options);server.export("demo2", DemoService.class, demo2, options);
上面 demo2 是另一个实现,我们标记为 demo2 来导出, 那么远程调用时也需要传递该标记才能调用到正确的实现类,这样就处理了多态调用的语义。
导入远程接口与用户端代理商
导入相对于导出远程接口,用户端代码为了能够发起调用必需要取得远程接口的方法或者过程定义。 目前,大部分跨语言平台 RPC 框架采用根据 IDL 定义通过 code generator 去生成 stub 代码, 这种方式下实际导入的过程就是通过代码生成器在编译期完成的。 我所使用过的少量跨语言平台 RPC 框架如 CORBAR、WebService、ICE、Thrift 均是此类方式。
代码生成的方式对跨语言平台 RPC 框架而言是必然的选择,而对于同一语言平台的 RPC 则可以通过共享接口定义来实现。 在 java 中导入接口的代码片段可能如下:
RpcClient client = new ...;DemoService demo = client.refer(DemoService.class);demo.hi("how are you?");
在 java 中 import
是关键字,所以代码片段中我们用 refer 来表达导入接口的意思。 这里的导入方式本质也是一种代码生成技术,只不过是在运行时生成,比静态编译期的代码生成看起来更简洁些。 java 里至少提供了两种技术来提供动态代码生成,一种是 jdk 动态代理商,另外一种是字节码生成。 动态代理商相比字节码生成使用起来更方便,但动态代理商方式在性能上是要逊色于直接的字节码生成的,而字节码生成在代码可读性上要差很多。 两者权衡起来,个人认为牺牲少量性能来取得代码可读性和可维护性显得更重要。
协议编解码
用户端代理商在发起调用前需要对调用信息进行编码,这就要考虑需要编码些什么信息并以什么格式传输到服务端才能让服务端完成调用。 出于效率考虑,编码的信息越少越好(传输数据少),编码的规则越简单越好(执行效率高)。 我们先看下需要编码些什么信息:
调用编码
接口方法
包括接口名、方法名
方法参数
包括参数类型、参数值
调用属性
包括调用属性信息,例如调用附件隐式参数、调用超时时间等
返回编码
返回结果
接口方法中定义的返回值
返回码
异常返回码
返回异常信息
调用异常信息
除了以上这些必需的调用信息,我们可能还需要少量元信息以方便程序编解码以及未来可能的扩展。 这样我们的编码消息里面就分成了两部分,一部分是元信息、另一部分是调用的必要信息。 假如设计一种 RPC 协议消息的话,元信息我们把它放在协议消息头中,而必要信息放在协议消息体中。 下面给出一种概念上的 RPC 协议消息设计格式:
消息头
消息体
采用序列化编码,常见有以下格式
格式确定后编解码就简单了,因为头长度肯定所以我们比较关心的就是消息体的序列化方式。 序列化我们关心三个方面:
序列化和反序列化的效率,越快越好。
序列化后的字节长度,越小越好。
序列化和反序列化的兼容性,接口参数对象若添加了字段,能否兼容。
上面这三点有时是鱼与熊掌不可兼得,这里面涉及到具体的序列化库实现细节,就不在本文进一步开展分析了。
协议编码之后,自然就是需要将编码后的 RPC 请求消息传输到服务方,服务方执行后返回结果消息或者确认消息给用户方。 RPC 的应用场景实质是一种可靠的请求应答消息流,和 HTTP 相似。 因而选择长连接方式的 TCP 协议会更高效,与 HTTP 不同的是在协议层面我们定义了每个消息的唯一 id,因而可以更容易的复用连接。
既然使用长连接,那么第一个问题是究竟 client 和 server 之间需要多少根连接? 实际上单连接和多连接在使用上没有区别,对于数据传输量较小的应用类型,单连接基本足够。 单连接和多连接最大的区别在于,每根连接都有自己私有的发送和接收缓冲区, 因而大数据量传输时分散在不同的连接缓冲区会得到更好的吞吐效率。 所以,假如你的数据传输量不足以让单连接的缓冲区一直处于饱和状态的话,那么使用多连接并不会产生任何显著的提升, 反而会添加连接管理的开销。
连接是由 client 端发起建立并维持。 假如 client 和 server 之间是直连的,那么连接一般不会中断(当然物理链路故障除外)。 假如 client 和 server 连接经过少量负载中转设施,有可能连接一段时间不活跃时会被这些中间设施中断。 为了保持连接有必要定时为每个连接发送心跳数据以维持连接不中断。 心跳消息是 RPC 框架库使用的内部消息,在前文协议头结构中也有一个专门的心跳位, 就是用来标记心跳消息的,它对业务应用透明。
client stub 所做的事情仅仅是编码消息并传输给服务方,而真正调用过程发生在服务方。 server stub 从前文的结构拆解中我们细分了 RpcProcessor
和 RpcInvoker
两个组件, 一个负责控制调用过程,一个负责真正调用。 这里我们还是以 java 中实现这两个组件为例来分析下它们究竟需要做什么?
java 中实现代码的动态接口调用目前一般通过反射调用。 除了原生的 jdk 自带的反射,少量第三方库也提供了性能更优的反射调用, 因而 RpcInvoker 就是封装了反射调用的实现细节。
调用过程的控制需要考虑哪些因素,RpcProcessor 需要提供什么样地调用控制服务呢? 下面提出几点以启发思考:
效率提升
每个请求应该尽快被执行,因而我们不能每请求来再创立线程去执行,需要提供线程池服务。
资源隔离
当我们导出多个远程接口时,如何避免单一接口调用占据所有线程资源,而引发其余接口执行阻塞。
超时控制
当某个接口执行缓慢,而 client 端已经超时放弃等待后,server 端的线程继续执行此时显得毫无意义。
无论 RPC 怎么努力把远程调用假装的像本地调用,但它们仍然有很大的不同点,而且有少量异常情况是在本地调用时绝对不会碰到的。 在说异常解决之前,我们先比较下本地调用和 RPC 调用的少量差异:
本地调用肯定会执行,而远程调用则不肯定,调用消息可能由于网络起因并未发送到服务方。
本地调用只会抛出接口公告的异常,而远程调用还会跑出 RPC 框架运行时的其余异常。
本地调用和远程调用的性能可能差距很大,这取决于 RPC 固有消耗所占的比重。
正是这些区别决定了使用 RPC 时需要更多考量。 当调用远程接口抛出异常时,异常可能是一个业务异常, 也可能是 RPC 框架抛出的运行时异常(如:网络中断等)。 业务异常表明服务方已经执行了调用,可能由于某些起因导致未能正常执行, 而 RPC 运行时异常则有可能服务方根本没有执行,对调用方而言的异常解决策略自然需要区分。
因为 RPC 固有的消耗相对本地调用高出几个数量级,本地调用的固有消耗是纳秒级,而 RPC 的固有消耗是在毫秒级。 那么对于过于轻量的计算任务就并不合适导出远程接口由独立的进程提供服务, 只有花在计算任务上时间远远高于 RPC 的固有消耗才值得导出为远程接口提供服务。
至此我们提出了一个 RPC 实现的概念框架,并详细分析了需要考虑的少量实现细节。 无论 RPC 的概念是如何优雅,但是“草丛中仍然有几条蛇隐藏着”,只有深刻了解了 RPC 的本质,才能更好地应用。
欢迎大家关注我的公众号【风平浪静如码】,海量Java相关文章,学习资料都会在里面升级,整理的资料也会放在里面。
觉得写的还不错的就点个赞,加个关注呗!点关注,不迷路,持续升级!!!
海量面试、架构资料分享