故事開始

回憶我第一次接觸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行，用到第三方框架

• netty 服務端客戶端收發訊息
• lombok 減少程式碼量
• curator zookeeper客戶端
• fastjson 序列化
• cglib 動態代理
• slf4j 日誌
• commons-pool2 客戶端Channel連線池

github frost

技術總結

實現功能：簡易（choulou）客戶端，服務端，客戶端連線池（開始是用netty自帶的，用不好就換了），服務註冊，服務發現。

難點：剛開始做的時候並沒有考慮請求的一發一收會有延遲出現空指標，導致測試直接空指標，但是我立馬也想到了原因，先是驗證，我在客戶端每次接收響應地時候都Sleep1秒。驗證完成，空指標沒了。然後就開始漫長搜尋，通過學習AbstractQueuedSynchronizer，ReentrantLock，CountDownLatch瞭解到非同步地具體實現解決問題。

計劃：

• 1.最簡單的先把資料壓縮做了。
• 2.改造服務註冊服務發現，（現在我的只能註冊一個服務，發現也就是去拿這一條?）目標就是模仿dubbo或者brpc。
• 3.改造連線池。（還沒方向）

還是希望在功能完備地情況下，程式碼量越少越好，專案結構越清晰越好。

完