阅读 1386

小马过河-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万多行。/黑人问号/🐶/👐🏻

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

万事俱备,这一点也不难(我当时地年轻想法🐶)

故事最后

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

frpc调用过程

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

github frost

技术总结

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

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

计划:

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

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

文章分类
后端
文章标签