小馬過河-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.改造連線池。（還沒方向）
還是希望在功能完備地情況下，程式碼量越少越好，專案結構越清晰越好。