study-rpc-all（自己开源的rpc框架）快速开始

爱抄中间件代码的路人丙

已于 2022-12-01 17:53:17 修改

阅读量216

点赞数

分类专栏：个人开源项目study-rpc（剖析）文章标签： rpc 开源网络协议

于 2022-11-17 14:17:04 首次发布

本文链接：https://blog.csdn.net/whatjeans/article/details/127902930

版权

个人开源项目study-rpc（剖析）专栏收录该内容

4 篇文章 0 订阅

订阅专栏

study-rpc-all文档（study-rpc剖析：保姆级别+图解）

作者：爱抄中间件代码的路人丙

源码仓库地址：https://gitee.com/li-zhongwei/study-rpc-all

打个小广告，觉得有收获的小伙伴，希望给一个stater，这是笔者前进最大的动力！

阅读提醒：源码部分建议文章和代码一起食用

第一章快速开始

1.1、rpc是什么

相信能看到这篇文档的小伙伴，肯定也是对rpc非常感觉兴趣的！

如果小白的话，建议从头开始看（先去百度一下rpc的定义）；如果已经对rpc的流程有一些基本的了解的话，可以直接拉代码，跑起来看一下(有基础的小伙伴建议直接跳过)

RPC，全称Remote Procedure Call, 即远程过程调用。

大白话讲：rpc就是一个中间商，帮我们封装了远程调用过程的所有细节，使得中间商的2端不用去关心其中传输的细节；举个不太恰当的列子：	
	比如我们去租房，原本呢，是我们自己（即租客）去寻找房东（房屋提供者）进行租房这个动作，那简化一下就是：租客-》房东
	但是现在普遍租房的小伙伴会发现，我们租房的流程：租客-》租房中介-》房东（最终交互的时候，还是租客和房东在交涉具体的金额细节） ，其实这里租房中介就相当于rpc的作用，主要2件事，第一件，负责收集房东的房屋信息、价格、要求等（简称元信息）第二件，向租客提供其收集的房屋信息，并根据租客的条件做一些适配。
	没有对比就没有优劣！
	那我们简单对比一下有无中介的情况
	无中介：
		租客角度：大海捞针，去寻找自己满意的房源，导致浪费大量的时间，原因（手中房源资源太少）
		房东角度：不知道哪些同学会成为自己的租客，也不知道去哪里找
	有中介：
		租房角度：中介有大量房源，可以快速根据房源信息以及租客要求做配对，解决租客房源少的问题
		房东角度：只需要在中介注册自己的房源信息以及一些要求（要求可以理解为房屋状态信息）
		最后：租客在中介这里找到了合适的房源，然后通过房源信息主动的去和房东交流
	其实类比过来：
		rpc==》中介的角色，
		租客==》服务消费者（客户端），
		房东==》服务提供者（区别：服务提供者可以提供多次服务，房东的房子可能在周期内只租一次）

回到正题：我宏观的谈一下个人理解的rpc

rpc主要做4件事情（括号里还是用上面的列子来简单描述了一下）

第一件：rpc收集服务提供者的信息，或者从服务提供者的角度，叫服务暴露或者服务注册（房东向中介注册自家的房）

第二件：rpc向服务消费者提供 服提供者务的元信息，以便消费（租客去找中介，看看哪些房可以租且合适）

第三件：rpc封装了远程调用的细节（比如代理、序列化、反序列化、编码、解码等）（租客拿着中介提供的房源信息去找房东商量价钱）

第四件：rpc维护服务提供者的状态（中介清理已经租掉房屋或者添加一些新的房屋信息）

1.2、study-rpc功能介绍

所以就像上面的列子介绍的那样，rpc其实就是封装了远程调用过程的“中间商”，或者专业一点叫“中间件”，以至于我们可以像调用本地的函数一样，去调用其他主机上的函数

我们都知道，商人都是利益至上的，所以当他们发现这个商机后，他们就会开连锁，各个节点之间房源信息共享，提供更大的服务提供能力，可以理解为集群

当他们开了几百家连锁中介之后，发现各个节点之间进行信息同步好像出问题了，房源总是出现延迟…哈哈哈接下来就不瞎说了

1.3、study-rpc技术栈选型

首先说一下study-rpc支持使用的场景：暂时只支持Java生态

技术选型：spring boot （2.7.4）、netty（4.1.42.Final）、zookeeper（3.4.14）、jdk1.8、commons-pool（2.4.2）、curator（2.12.0）

        <java.version>1.8</java.version>
        <commons-pool.version>2.4.2</commons-pool.version>
        <curator.version>2.12.0</curator.version>
        <gson.version>2.8.5</gson.version>
        <netty.version>4.1.19.Final</netty.version>
        <hessian.version>4.0.38</hessian.version>

spring boot：

spring生态强大，无所不能，商业吹捧一下，其实选型之初最主要想用spring 生命周期的几个扩展点和spring boot-stater机制，这样的话，我们在使用的时候简单配置一下就可以用了

netty:

netty就不说了，Java网络通讯框架的老大哥，什么内存池、线程绑定、reactor模式、Select系统调用支持等

你看看哪些广为流传的开源框架基本上都用的netty做网络通讯层，比如racketmq、motan、dubbo、es、还有一些大数据的框架等

netty这么nb，我就不深入展开了（其实，主要是自己太菜，对于netty的理解还处于比较肤浅的阶段）

zookeeper

zk,分布式协调组件的老大哥，数据强一致性出名

关于为什么选他？
我觉得这个问题可以跟我的某一次大厂的面试问题联系起来，当时面试官问了我一个问题：你为什么选择我们公司？
我当时心里暗想：主要是我就只知道你们一家公司的名气

所以为什么选zk呢？ 因为当时只知道zk

后面了解到nameServer、nacos等其他组件的时候，其实用哪一个往往是由具体的业务场景来决定的
比如：我们系统对数据一致性要求比较高，性能可以差一点，那选择zk；其他的话类推