我手写了一个RPC框架。成功帮助读者斩获字节、阿里等大厂offer。

时间 2020-08-28

标签手写一个 rpc 框架成功帮助读者斩获字节阿里大厂 offer 栏目微服务繁體版

原文原文链接

本着开源精神，本项目README已经同步了英文版本。另外，项目的源代码的注释大部分也修改成了英文。java

如访问速度不佳，可放在 Gitee 地址：https://gitee.com/SnailClimb/... 。若是要提交 issue 或者 pr 的话，请在 Github 提交：https://github.com/Snailclimb... 。git

前言

虽然说 RPC 的原理实际不难，可是，本身在实现的过程当中本身也遇到了不少问题。guide-rpc-framework 目前只实现了 RPC 框架最基本的功能，一些可优化点都在下面提到了，有兴趣的小伙伴能够自行完善。github

经过这个简易的轮子，你能够学到 RPC 的底层原理和原理以及各类 Java 编码实践的运用。面试

你甚至能够把 guide-rpc-framework 当作你的毕设/项目经验的选择，这是很是不错！对比其余求职者的项目经验都是各类系统，造轮子确定是更加能赢得面试官的青睐。算法

若是你要将 guide-rpc-framework 当作你的毕设/项目经验的话，我但愿你必定要搞懂，而不是直接复制粘贴个人思想。你能够 fork 个人项目，而后进行优化。若是你以为的优化是有价值的话，你能够提交 PR 给我，我会尽快处理。docker

介绍

guide-rpc-framework 是一款基于 Netty+Kyro+Zookeeper 实现的 RPC 框架。代码注释详细，结构清晰，而且集成了 Check Style 规范代码结构，很是适合阅读和学习。apache

因为 Guide哥自身精力和能力有限，若是你们以为有须要改进和完善的地方的话，欢迎 fork 本项目，而后 clone 到本地，在本地修改后提交 PR 给我，我会在第一时间 Review 你的代码。json

咱们先从一个基本的 RPC 框架设计思路提及！安全

一个基本的 RPC 框架设计思路

注意：咱们这里说的 RPC 框架指的是：可让客户端直接调用服务端方法就像调用本地方法同样简单的框架，好比我前面介绍的 Dubbo、Motan、gRPC 这些。若是须要和 HTTP 协议打交道，解析和封装 HTTP 请求和响应。这类框架并不能算是“RPC 框架”，好比 Feign。

一个最简单的 RPC 框架使用示意图以下图所示,这也是 guide-rpc-framework 目前的架构：

服务提供端 Server 向注册中心注册服务，服务消费者 Client 经过注册中心拿到服务相关信息，而后再经过网络请求服务提供端 Server。

做为 RPC 框架领域的佼佼者Dubbo的架构以下图所示,和咱们上面画的大致也是差很少的。

通常状况下， RPC 框架不只要提供服务发现功能，还要提供负载均衡、容错等功能，这样的 RPC 框架才算真正合格的。

简单说一下设计一个最基本的 RPC 框架的思路：

注册中心 ：注册中心首先是要有的，推荐使用 Zookeeper。注册中心负责服务地址的注册与查找，至关于目录服务。服务端启动的时候将服务名称及其对应的地址(ip+port)注册到注册中心，服务消费端根据服务名称找到对应的服务地址。有了服务地址以后，服务消费端就能够经过网络请求服务端了。
网络传输 ：既然要调用远程的方法就要发请求，请求中至少要包含你调用的类名、方法名以及相关参数吧！推荐基于 NIO 的 Netty 框架。
序列化 ：既然涉及到网络传输就必定涉及到序列化，你不可能直接使用 JDK 自带的序列化吧！JDK 自带的序列化效率低而且有安全漏洞。因此，你还要考虑使用哪一种序列化协议，比较经常使用的有 hession二、kyro、protostuff。
动态代理 ：另外，动态代理也是须要的。由于 RPC 的主要目的就是让咱们调用远程方法像调用本地方法同样简单，使用动态代理能够屏蔽远程方法调用的细节好比网络传输。也就是说当你调用远程方法的时候，实际会经过代理对象来传输网络请求，否则的话，怎么可能直接就调用到远程方法呢？
负载均衡 ：负载均衡也是须要的。为啥？举个例子咱们的系统中的某个服务的访问量特别大，咱们将这个服务部署在了多台服务器上，当客户端发起请求的时候，多台服务器均可以处理这个请求。那么，如何正确选择处理该请求的服务器就很关键。假如，你就要一台服务器来处理该服务的请求，那该服务部署在多台服务器的意义就不复存在了。负载均衡就是为了不单个服务器响应同一请求，容易形成服务器宕机、崩溃等问题，咱们从负载均衡的这四个字就能明显感觉到它的意义。
......

项目基本状况和可优化点

为了按部就班，最初的是时候，我是基于传统的 BIO 的方式 Socket 进行网络传输，而后利用 JDK 自带的序列化机制 来实现这个 RPC 框架的。后面，我对原始版本进行了优化，已完成的优化点和能够完成的优化点我都列在了下面 👇。

为何要把可优化点列出来？ 主要是想给哪些但愿优化这个 RPC 框架的小伙伴一点思路。欢迎你们 fork 本仓库，而后本身进行优化。

使用 Netty（基于 NIO）替代 BIO 实现网络传输；
使用开源的序列化机制 Kyro（也能够用其它的）替代 JDK 自带的序列化机制；
使用 Zookeeper 管理相关服务地址信息
Netty 重用 Channel 避免重复链接服务端
使用 CompletableFuture 包装接受客户端返回结果（以前的实现是经过 AttributeMap 绑定到 Channel 上实现的）详见：使用 CompletableFuture 优化接受服务提供端返回结果
增长 Netty 心跳机制 : 保证客户端和服务端的链接不被断掉，避免重连。
客户端调用远程服务的时候进行负载均衡 ：调用服务的时候，从不少服务地址中根据相应的负载均衡算法选取一个服务地址。ps：目前只实现了随机负载均衡算法。
处理一个接口有多个类实现的状况 ：对服务分组，发布服务的时候增长一个 group 参数便可。
集成 Spring 经过注解注册服务
增长服务版本号 ：建议使用两位数字版本，如：1.0，一般在接口不兼容时版本号才须要升级。为何要增长服务版本号？为后续不兼容升级提供可能，好比服务接口增长方法，或服务模型增长字段，可向后兼容，删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需经过变动版本号升级。
对 SPI 机制的运用
增长可配置好比序列化方式、注册中心的实现方式,避免硬编码 ：经过 API 配置，后续集成 Spring 的话建议使用配置文件的方式进行配置
使用注解进行服务消费
客户端与服务端通讯协议（数据包结构）从新设计
，能够将原有的
```
RpcRequest
```
和
```
RpcReuqest
```
对象做为消息体，而后增长以下字段（能够参考：《Netty 入门实战小册》和 Dubbo 框架对这块的设计）：
- 魔数：一般是 4 个字节。这个魔数主要是为了筛选来到服务端的数据包，有了这个魔数以后，服务端首先取出前面四个字节进行比对，可以在第一时间识别出这个数据包并不是是遵循自定义协议的，也就是无效数据包，为了安全考虑能够直接关闭链接以节省资源。
- 序列化器编号 ：标识序列化的方式，好比是使用 Java 自带的序列化，仍是 json，kyro 等序列化方式。
- 消息体长度 ：运行时计算出来。
- ......
编写测试为重构代码提供信心

项目模块概览

运行项目

导入项目

fork 项目到本身的仓库，而后克隆项目到本身的本地：git clone git@github.com:username/guide-rpc-framework.git，使用 IDEA 打开，等待项目初始化完成。

初始化 git hooks

这一步主要是为了在 commit 代码以前，跑 Check Style，保证代码格式没问题，若是有问题的话就不能提交。

如下演示的是 Mac/Linux 对应的操做，Window 用户须要手动将 config/git-hooks 目录下的 pre-commit 文件拷贝到项目下的 .git/hooks/ 目录。

执行下面这些命令：

➜  guide-rpc-framework git:(master) ✗ chmod +x ./init.sh
➜  guide-rpc-framework git:(master) ✗ ./init.sh

init.sh 这个脚本的主要做用是将 git commit 钩子拷贝到项目下的 .git/hooks/ 目录，这样你每次 commit 的时候就会执行了。

CheckStyle 插件下载和配置

IntelliJ IDEA-> Preferences->Plugins->搜索下载 CheckStyle 插件，而后按照以下方式进行配置。

配置完成以后，按照以下方式使用这个插件！

下载运行 zookeeper

这里使用 Docker 来下载安装。

下载：

docker pull zookeeper:3.5.8

运行：

docker run -d --name zookeeper -p 2181:2181 zookeeper:3.5.8

使用

服务提供端

实现接口：

@Slf4j
@RpcService(group = "test1", version = "version1")
public class HelloServiceImpl implements HelloService {
    static {
        System.out.println("HelloServiceImpl被建立");
    }

    @Override
    public String hello(Hello hello) {
        log.info("HelloServiceImpl收到: {}.", hello.getMessage());
        String result = "Hello description is " + hello.getDescription();
        log.info("HelloServiceImpl返回: {}.", result);
        return result;
    }
}
    
@Slf4j
public class HelloServiceImpl2 implements HelloService {

    static {
        System.out.println("HelloServiceImpl2被建立");
    }

    @Override
    public String hello(Hello hello) {
        log.info("HelloServiceImpl2收到: {}.", hello.getMessage());
        String result = "Hello description is " + hello.getDescription();
        log.info("HelloServiceImpl2返回: {}.", result);
        return result;
    }
}

发布服务(使用 Netty 进行传输)：

/**
 * Server: Automatic registration service via @RpcService annotation
 *
 * @author shuang.kou
 * @createTime 2020年05月10日 07:25:00
 */
@RpcScan(basePackage = {"github.javaguide.serviceimpl"})
public class NettyServerMain {
    public static void main(String[] args) {
        // Register service via annotation
        new AnnotationConfigApplicationContext(NettyServerMain.class);
        NettyServer nettyServer = new NettyServer();
        // Register service manually
        HelloService helloService2 = new HelloServiceImpl2();
        RpcServiceProperties rpcServiceProperties = RpcServiceProperties.builder()
                .group("test2").version("version2").build();
        nettyServer.registerService(helloService2, rpcServiceProperties);
        nettyServer.start();
    }
}

服务消费端

ClientTransport rpcClient = new NettyClientTransport();
RpcServiceProperties rpcServiceProperties = RpcServiceProperties.builder()
  .group("test1").version("version1").build();
RpcClientProxy rpcClientProxy = new RpcClientProxy(rpcClient, rpcServiceProperties);
HelloService helloService = rpcClientProxy.getProxy(HelloService.class);
String hello = helloService.hello(new Hello("111", "222"));