高并发架构系列：如何从0到1设计一个类Dubbo的RPC框架

系统管理员 2022-03-20 09:58 107阅读 0赞

优知学院 2019-01-22 18:43:51

之前持续分享的几十期阿里Java面试题中，几乎每次必问Dubbo，比如：“如何从0到1设计一个Dubbo的RPC框架”，其实主要考验两点：

*  你对RPC框架的底层原理掌握程度。
 *  以及考验你的整体RPC框架系统设计能力。

# **RPC和RPC框架** #

**1.RPC(Remote Procedure Call)**

即远程过程调用, 主要解决远程通信间的问题，不需要了解底层网络的通信机制。

**2.RPC框架**

RPC框架负责屏蔽底层的传输方式（TCP或者UDP）、序列化方式、以及通信细节。

实际使用中，并不需要关心底层通信细节和调用过程，让业务端专注于业务代码的实现。

国内大家熟知的PRC框架，阿里的HSF和**Dubbo(开源)**

# **Dubbo的发展由来** #

**1. 业务规模小**

比如早期一个应用Java War包，将所有功能都打包，部署在一个单机服务器，调用接口也比较方便，不涉及到任何分布式场景。

![高并发架构系列：如何从0到1设计一个类Dubbo的RPC框架][0_1_Dubbo_RPC]

**2.业务规模变大**

随着业务的快速发展，业务越来越多、子系统也越来越多时。比如：淘宝的交易系统、商品系统、用户系统、评价系统...上百个系统的出现。

系统变得越来越复杂，业务代码依然耦合在一起。比如最早期的淘宝denali工程，包含所有业务系统的代码，就仅打包部署都需要很长的时间。

并且，随着每个业务线的快速发展，业务代码耦合在一起，上线后出现问题急需要回滚代码，拉分支、大量的代码merge工作，这个过程极其痛苦。

这个时候，你会发现技术已经成了业务的瓶颈，急需把业务单独抽离出来，各自单独部署。

**3.Dubbo和HSF的出现**

应用系统一旦涉及到拆分部署，问题就来了，急需一种高效的应用程序间的通讯手段来完成这种需求，这就会涉及到**分布式远程调用**。

于是，淘宝就把denali按照业务为单位拆分成了类似这样的系统：UM(UserManger)、SM(ShopManager)..等等几十个工程代码。

再按照业务为单位，把所有调用相关的接口以业务为单元进行拆分：UIC(用户中心服务)、SIC(店铺中心服务)...等等以业务为单位集群部署，按照业务提供服务。

![高并发架构系列：如何从0到1设计一个类Dubbo的RPC框架][0_1_Dubbo_RPC 1]

所以，RPC的框架来了，阿里内部使用HSF，以及开源的RPC 框架：Dubbo。

# **RPC框架的核心设计** #

前面优知mikechen提到了RPC的核心目标：主要是解决分布式系统中服务之间的调用问题。

其实，走到这一步涉及的知识体系非常的多：要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。

**1.RPC框架三个核心角色**

![高并发架构系列：如何从0到1设计一个类Dubbo的RPC框架][0_1_Dubbo_RPC 2]

**1)服务提供者（Server）**

对外提供后台服务，将自己的服务信息，注册到注册中心

**2)注册中心（Registry）**

用于服务端注册远程服务以及客户端发现服务。

目前主要的注册中心可以借由 zookeeper，eureka，consul，etcd 等开源框架实现。

比如：阿里的Dubbo就是采用zookeeper实现注册中心。

**3)服务消费者（Client）**

从注册中心获取远程服务的注册信息，然后进行远程过程调用。

**2.RPC远程调用过程**

![高并发架构系列：如何从0到1设计一个类Dubbo的RPC框架][0_1_Dubbo_RPC 3]

1）服务调用方（client）调用以本地调用方式调用服务；

2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；在Java里就是序列化的过程

3）client stub找到服务地址，并将消息通过网络发送到服务端；

4）server stub收到消息后进行解码,在Java里就是反序列化的过程；

5）server stub根据解码结果调用本地的服务；

6）本地服务执行处理逻辑；

7）本地服务将结果返回给server stub；

8）server stub将返回结果打包成消息，Java里的序列化；

9）server stub将打包后的消息通过网络并发送至消费方

10）client stub接收到消息，并进行解码, Java里的反序列化；

11）服务调用方（client）得到最终结果。

**RPC框架的目标就是要2~10这些步骤都封装起来。**

# **RPC框架涉及技术** #

**1.建立通信**

首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。

**2.服务寻址**

**1）服务注册**

首先需要把服务注册到服务中心。其实就是在注册中心进行一个登记，注册中心存储了该服务的IP、端口、调用方式(协议、序列化方式)等。在zookeeper中，进行服务注册，实际上就是在zookeeper中创建了一个znode节点，该节点存储了上面所说的服务信息。

**2）服务发现**

服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的IP地址列表，并缓存到本地，以供后续使用。当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。

**3）注册服务**

可靠的寻址方式（主要是提供服务的发现）是RPC的实现基石，比如可以zookeeper来实现注册服务等等。

![高并发架构系列：如何从0到1设计一个类Dubbo的RPC框架][0_1_Dubbo_RPC 4]

*  服务提供者启动后主动向服务（注册）中心注册机器ip、端口以及提供的服务列表。
 *  服务消费者启动时向服务（注册）中心获取服务提供方地址列表，可实现软负载均衡和Failover。
 *  提供者需要定时向注册中心发送心跳，一段时间未收到来自提供者的心跳后，认为提供者已经停止服务，从注册中心上摘取掉对应的服务等等。

**3.网络传输**

数据传输采用什么协议，数据该如何序列化和反序列化

**4.NIO通信**

当前很多RPC框架都直接基于netty这一IO通信框架，比如阿里巴巴的HSF、dubbo，Hadoop Avro，推荐使用Netty 作为底层通信框架。

5.**服务调用**

比如：B机器进行本地调用（通过代理Proxy）之后得到了返回值，此时还需要再把返回值发送回A机器，同样也需要经过序列化操作，然后再经过网络传输将二进制数据发送回A机器，而当A机器接收到这些返回值之后，则再次进行反序列化操作

总之，要实现一个RPC不算难，难的是实现一个高性能高可靠的RPC框架**，**后续将剖析Dubbo，看看Dubbo是如何来解决这些难题。

--------------------

更多Redis、Spring Cloud、MySQL数据库分库分表等高并发架构设计，具体请参考：

# 高并发架构系列专题 #

![高并发架构系列：如何从0到1设计一个类Dubbo的RPC框架][0_1_Dubbo_RPC 5]

# 该资料获取方式 #

**转发+私信关键词 【高并发】即可获取！**

[0_1_Dubbo_RPC]: /images/20220320/371fdc87b31d43879fc4eed69db5cb5a.png
[0_1_Dubbo_RPC 1]: http://p1.pstatp.com/large/pgc-image/e8066f3ebffe4d6a916b5aab03c6d9fc
[0_1_Dubbo_RPC 2]: http://p1.pstatp.com/large/pgc-image/813bac7fd4274a099296577a1f06fb6a
[0_1_Dubbo_RPC 3]: http://p9.pstatp.com/large/pgc-image/b0263579cc9d4eff98922f479a17beac
[0_1_Dubbo_RPC 4]: /images/20220320/ff83a8b791fb49ac8b7c7ef2621b9200.png
[0_1_Dubbo_RPC 5]: http://p1.pstatp.com/large/pgc-image/dba48e4ed4df4d6587c155efb93078cd