小马过河-RPC之旅

回忆我第一次接触RPC已经过了快两年了，当时只是觉得很厉害，写个Demo就已经觉得很了不起了，对内部的构造，原理什么的一无所知，也没有探索的欲望，只是觉得能跑起来就行了。

慢慢的工作中接触的多了，知道了服务注册，服务发现，注册中心之类的名词和大概一个什么的执行流程。

再后来，公司的分布式框架我感觉已经用的很熟了，用Apache Tuscany改造的。这只是当时的一种幻觉，因为也没怎么碰到问题，无非是找不到服务，有关配置的小问题。只是CV的溜了。

CV是很爽，很快，但是那种门外汉的感觉每时每刻都让我感到不安。

开始买相关的书看，《真·看不下去》，基础啊，记不住啊。

这条路不行我就用最原始也是效果最好的，做Demo，先把这些听过的，叫的上名字的RPC框架都用一遍。

duang,duang,duang.... 从dubbo,springcloud到Thrift，grpc。这种门外汉的感觉还是没有消失。

故事转折

到这里我似乎已经把自己能用的招都放了，没效果啊。

但是我还知道一个最后最后最后绝招 看源码 ，这一招很考验基础功底，包括 英语阅读能力，原生库熟练程度 ，这些因素都会影响阅读理解开源框架的速度。

入坑，当时我觉得这些框架基本路数应该都差不多，所以就先随便找个别人分析源码的博客看看先。

一篇入魂，我找了一个关于grpc的源码解读系列文章。但是我被这长达6篇的系列文章死死地困在了第一篇 基础介绍 ，用了差不多爷爷奶油面包好好吃的次数做笔记，画图，做笔记，画图...。没有突破第一篇，但是我觉得做一个简单的RPC框架不难。我从反复做笔记，画图中了解了到了都需要什么，需要到的都是怎样实现的。

开坑，抄轮子。

先说说一个RPC框架都有些什么

1.可能是招聘信息上出现次数最多的RPC框架 dubbo

从图中看

• 1.Provider（服务端）
• 2.Registry（注册中心）
• 3.Consumer（客户端）
• 4.Monitor （监控）

2.再来一个从图上看更简洁地 grpc

• 1.gRPC Server （服务端）
• 2.gRPC Stub （客户端）

这些图地最大好处就是非常强大的概括核心地组件都有些啥。

但是光知道有些啥是远远不够地，理论知识再充足，看的再多，第一次下笔是不一样的难。

还有一个是，比如学炒菜，你可以看到从切菜点火到出锅地全过程，然后照着流程去自己实践。还有我们日常做的业务项目，怎么搭框架怎么写业务，都可以看到前辈实践。自己在做就很容易了。

我用代码统计软件看了下dubbo大概10多行，grpc java版33万多行。/黑人问号/:dog:/:open_hands|type_1_2:

我必须要找到一个结构 相对于我比较好理解的 ，代码量比较少的RPC框架，具体的了解RPC框架大体结构和具体如何实现的。运气比较好，没费多大劲我就找到了百度的 brpc ,代码量不大，而且结构对于我来说非常清晰。

万事俱备，这一点也不难（我当时地年轻想法:dog:）

故事最后

由于netty的强大客户端服务端收发数据实现非常方便，我也利用这些精美的高性能框架造了一个垃圾轮子。

frpc调用过程

核心代码不到700行，用到第三方框架

• netty 服务端客户端收发消息
• lombok 减少代码量
• curator zookeeper客户端
• fastjson 序列化
• cglib 动态代理
• slf4j 日志
• commons-pool2 客户端Channel连接池

github frost

技术总结

实现功能：简易（choulou）客户端，服务端，客户端连接池（开始是用netty自带的，用不好就换了），服务注册，服务发现。

难点：刚开始做的时候并没有考虑请求的一发一收会有延迟出现空指针，导致测试直接空指针，但是我立马也想到了原因，先是验证，我在客户端每次接收响应地时候都Sleep1秒。验证完成，空指针没了。然后就开始漫长搜索，通过学习AbstractQueuedSynchronizer，ReentrantLock，CountDownLatch了解到异步地具体实现解决问题。

计划：

• 1.最简单的先把数据压缩做了。
• 2.改造服务注册服务发现，（现在我的只能注册一个服务，发现也就是去拿这一条:dog:）目标就是模仿dubbo或者brpc。
• 3.改造连接池。（还没方向）

还是希望在功能完备地情况下，代码量越少越好，项目结构越清晰越好。