10分钟带你了解RPC 架构的基本结构 _架构

当你在构建一个分布式系统时，势必需要考虑的一个问题是：如何实现服务与服务之间的调用？当然，你可以使用 Dubbo 或 Spring Cloud 等分布式服务框架来封装技术实现的复杂性，以此完成这个目标。不过，假如现在没有这些框架，需要你自己来实现远程调用，你会怎么做呢？
很多人会选择实现一套 RPC 框架来调用远程服务。
那么你了解 RPC 架构的基本结构吗？如果你想要自己实现 RPC 框架来完成远程调用，又该构建怎么样的技术体系呢？接下来，我就给你具体介绍一下。

文章首发公众号：码猿技术专栏

RPC 架构的基本结构想要构建一套完整的 RPC 架构，就需要明确该架构所具备的基本结构，而 RPC 架构的基本结构中又存在很多组件。因此接下来，我就通过 RPC 基本结构演进的过程，来给你一一讲解下。
首先，我们通常把发生调用关系的两个服务分别称为服务的提供者（Provider）和消费者（Consumer）。所以，简单来说， RPC 就是服务的消费者向提供者发起远程调用并获取结果的过程，这是 RPC 最简单的一种表现形式。

文章插图
如果想要实现服务提供者和消费者之间的有效交互，那么两者之间就需要确立与网络通信相关的网络协议以及通信通道。同时，服务的提供者需要把自己的服务调用入口暴露出来，并时刻准备接收来自消费者的请求。
这里，我们把通信通道和网络协议分别命名为 RpcChannel 和 RpcProtocol ，而把服务提供者接收请求的组件称为 RpcAcceptor ，把消费者发起请求的组件称为 RpcConnector 。这样， RPC 架构就演变成了这个样子：

文章插图
然后，对于服务提供者和消费者而言，为了双方能够正常识别所发送的请求和所接收到的响应结果，需要定义统一的契约。我们把这种契约称为远程 API（Remote API），以便与本地 API 加以区别。如此一来，基于同一套远程 API 的定义， RPC 架构就具备了根据业务来定义通信契约的能力。

文章插图
类似地，为了更好地区分 RPC 架构中的角色，我们把真正提供业务服务的组件称为 RpcServer ，而把发起真实客户端请求的组件称为 RpcClient 。这样， RpcServer 负责实现远程 API ，而 RpcClient 负责调用远程 API 。

文章插图
当然，对于远程 API 而言，服务提供者和消费者的处理方式显然是不一样的。提供者需要根据消费者的请求来调用 RpcServer 的具体实现并返回结果，这部分的工作由 RpcInvoker 来执行，而消费者通过 RpcCaller 组件对请求进行编码之后，发送给服务方并等待结果。

文章插图
最后，为了降低开发人员的开发难度，让远程调用的执行过程看上去就像在执行本地方法一样，在主流的 RPC 实现机制中，通常都会在客户端添加代理机制，以此提供远程服务本地化访问的入口，我们把这个代理组件称为 RpcProxy 。
另外，在服务器端，为了更好地控制业务方法执行过程，通常也会引入具备线程管理、超时控制等机制的 RpcProcessor 组件。