谁能用通俗的语言解释一下什么是 RPC 框架？

文章写作背景

最近在学习 Swoft 框架,看到里面有一个 RPC 的名称,之前在学习其他的东西时也看到了这个名词,当时没特别在意。便有兴趣去看看到底是何物?结合网上的知识点总结总结。不过大部分是来源网络整理。

什么是 RPC 框架(从功能上来分析)

关于RPC RPC框架，首先了解什么叫RPC，为什么要RPC，RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

比如说，一个方法可能是这样定义的： Employee getEmployeeByName(String fullName) 那么：

• 首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
• 第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
• 第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。
• 第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。
• 第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用

（图片来源：https://www.cs.rutgers.edu/~pxk/417/notes/03-rpc.html）

为什么RPC呢？就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用，

RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API。

关于Netty 而Netty框架不局限于RPC，更多的是作为一种网络协议的实现框架，比如HTTP，由于RPC需要高效的网络通信，就可能选择以Netty作为基础。除了网络通信，RPC还需要有比较高效的序列化框架，以及一种寻址方式。如果是带会话（状态）的RPC调用，还需要有会话和状态保持的功能。

大体上来说，Netty就是提供一种事件驱动的，责任链式（也可以说是流水线）的网络协议实现方式。网络协议包含很多层次，很多部分组成，如传输层协议，编码解码，压缩解压，身份认证，加密解密，请求的处理逻辑，怎么能够更好的复用，扩展，业界通用的方法就是责任链，

一个请求应答网络交互通常包含两条链，一条链（Upstream）是从传输层，经过一系列步骤，如身份认证，解密，日志，流控，最后到达业务层，一条链（DownStream）是业务层返回后，又经过一系列步骤，如加密等，又回到传输层。

（图片来源：ChannelPipeline (The Netty Project API Reference (3.2.6.Final))）

这样每一层都有一个处理接口，都可以进行不同的操作，比如身份认证，加解密，日志，流控，将不同的处理实现像拼积木那样插接起来就可以实现一个网络协议了（快速开发）。每一层都有自己的实现，上层不需要关注面向网络的操作（可维护）。Netty已经提供了很多实现。

（图片来源：http://docs.jboss.org/netty/3.1/guide/html/architecture.html） 当然Netty还有许多好处，比如对非阻塞IO（NIO）的支持，比如在链上传递时最大程度的减少buffer的copy（高性能）。

什么是 RPC 框架(从项目发展进度上来分析)

1.我们在做一个访问量不大的项目的时候,一台服务器部署上一个应用+数据库也就够了.那么访问量稍微大一点之后呢,为了解决用户反馈的卡,反应慢的情况,我们就上集群.架设 nginx,部署多个服务,由 nginx 负责把请求转发到其他服务上,这样就解决了用户说的卡慢问题.

2.过了一段时间之后呢,我们发现数据库已经扛不住了,应用服务完好,数据库有时候宕机. 那这个时候呢,我们就上数据库读写分离,再架设几台数据库服务器,做主从,做分库分表. 然后数据库也不宕机了,服务又恢复了流畅.

3.又过了一段时间,公司事业增增日上,服务访问量越来越高,且大部分都是查询, 吸取之前宕机且为了办证数据库的健壮性,我们这个时候又加上了缓存, 把用户高频次访问的数据放到缓存里.后来,项目功能越来越多,整个项目也愈发庞大,修改一个类就需要全盘上传,切换 nginx 重启,这样的发布流程越来越长,越来越繁杂.然后我们开始把模块拆分,用户信息分个项目,订单系统分一个项目.这样就达到了,用户模块代码修改的时候,只需要更新用户信息服务就好了.但是还是需要切换顶层的 nginx.把要重启的服务的流量切到可用服务上. 这个时候我们就想到了 RPC 那么 RPC 解决了什么呢? 所有的服务在启动的时候注册到一个注册机里面,然后顶层处理在接收到 nginx 的请求时,去注册机找一个可用的服务,并调用接口. 这样子呢,在不加新功能的时候,顶层处理服务我们就不需要动了? 那修改了用户信息项目的时候,我们只需要一个个更新用户信息项目的服务群就好了?