手写一个RPC框架

一、CAP理论和BASE理论

（1）CAP理论：
CAP理论又称为布鲁尔定理，于1998年第一次提出；它指在分布式系统下不可能同时满足一下3种情况：
<1>一致性（Consistency）：每次读到的信息是最新的；
<2>可用性（Availability）：每个请求都会得到非错误响应；
<3>分区容错性（Partition tolerance）：尽管节点间的网络不通导致分区，系统仍然正常运行。
依据以上理论，我们必须保证P，然后需要在C和A之间权衡。
（2）BASE理论：
BASE是Basically Available（基本可用）、Soft State（软状态）和Eventual Consistency（最终一致性）三个短语的简称；解释如下：
<1>基本可用：可能部分功能不可用或者响应时间长；
<2>软状态：不同节点之间存在过度阶段；
<3>最终一致性：经过系统内部协调，所有节点最终保证一致。

二、RPC概念

RPC是remote procedure call（远程过程调用）的简称；这里的“过程”指的是业务处理，RPC的目的是像调用本地方法一样调用远程的方法。一个RPC的处理流程如下：

所以如上图所示，RPC中需要处理这样几个问题：
（1）client stub和server stub的开发；
（2）参数如何编组为消息以及如何解组消息；
（3）如何发现需要调用的服务；
（4）消息如何发送；
（5）过程中如何表示调用异常以及如何处理；
（6）如何实现安全的访问控制。
为了解决这些问题，出现了一些RPC框架；很好的帮助开发者避免考虑这些问题而把注意力保持在业务中，目前流行的RPC框架有Dubbo和Spring Cloud。了解完RPC基本概念以及要解决的问题后，接下来我们就可以自己设计一个RPC框架。

三、设计实现一个RPC框架

1.客户端

前面说了RPC的目的就是像调用本地方法一样调用远程的方法，所以我们需要利用“代理对象”帮我们完成，而客户端只需要调用这个代理对象即可，如下图所示：

对于客户端的设计，我们需要思考以下几点：
（1）ClientStubInvocationHandler中需要完成哪些事情？
  答： 客户端需要完成编组消息和发送网络请求；
（2）请求的内容编组为消息和发送消息由谁做？
  答： 由消息协议层去编组，由网络层去发送；
（3）消息协议固定不变吗?它与说明有关？
  答： 消息协议看框架支持的广度，可能A服务用协议1，B服务用协议2；
（4）某个服务用什么协议从哪里获取？
  答： 需要一个服务的发现者（即服务注册中心），这里可以包括服务使用什么协议；可以做如下设计：

（5）要支持多种协议，类如何设计？
  答： 可以使用策略模式，即提供一个接口，包括编组、解组等方法；再以多种类实现此接口，每个类支持一种协议。
（6）框架标准的请求类、响应类应该包含什么？
  答： 请求类需要包含如：服务名、方法名、头部信息、参数类型和参数值等；响应类需要包含如：响应状态、头部信息、返回值类型、返回值和异常等。
（7）协议层如何设计？
  答： 协议层需要独立出来，因为客户端和服务端都需要；协议层接口需要包含四个方法：编组请求、解组请求、编组响应和解组响应。
（8）网络层的工作是什么？
  答： 网络层负责发送请求和获得响应，并且需要知道调用服务的地址；网络层也需要独立出来，因为客户端和服务端都需要。
以下是客户端的完整类图：

上图中，ServiceInfoDiscovery为服务发现者，MessageProtocol为协议层，NetClient为网络层；其中ClientStubProxyFactory为核心类，我们进行RPC调用只用调用它即可。

2.服务端

在客户端的请求发送到服务端后，服务端就需要处理请求并返回响应；对于服务端的设计，我们需要思考以下几点：
（1）服务端提供的服务如何被客户端发现？
  答： 服务端需要一个注册模块，维护服务名到服务对象的关系，并且向注册中心注册自己的服务名；
（2）服务端接收到请求后做什么工作？
  答： 服务端接收到请求后，先去解组消息，接着确定请求调用哪个方法，最后返回响应或者异常；
依据以上思考，我们可以得出以下服务端的架构图：

以下是服务端的完整类图：

【注】在此附上手写RPC的代码：手写RPC 提取码：ivv4