百億級企業級 RPC 框架開源了！

ityouknow發表於2019-05-05

今天給大家介紹給一款效能卓越的 RPC 開源框架，其作者就是我推薦每個 Java 程式設計師都應該看的《Java 生態核心知識點整理》的原作者張玉龍。

說實話我第一次看到這個資料的時候，就感覺作者是一位真正的技術愛好者，後來通過朋友介紹終於認識了他。交談之中得知他在美團工作，最初和朋友一起整理這份資料的初衷是為了面試，估計每天需要面試太多的應聘者，這份資料成了助手。強烈建議沒有看這份資料的同學學習下，作為 Java 生態知識體系構建也是一份不錯的資源。

後來得知業餘時間他在研發一款開源的 RPC 開源框架，並且經過測試可支援百億級別的呼叫，並且於近期終於完成推出 1.0 版本。這款開源軟體名字叫做 Koalas，原始碼地址：koalas-rpc，下面對這款開源軟體做詳細介紹，內容來源於 Koalas 。

Koalas 介紹

企業生產級百億日 PV 高可用可擴充的 RPC 框架。理論上併發數量接近伺服器頻寬，客戶端採用 thrift 協議，服務端支援 netty 和 thrift 的 TThreadedSelectorServer 半同步半非同步執行緒模型，支援動態擴容，服務上下線，權重動態，可用性配置，頁面流量統計，支援 trace 跟蹤等，天然接入 cat 支援資料大盤展示等，持續為個人以及中小型公司提供可靠的 RPC 框架技術方案。

Thrift 是一種介面描述語言和二進位制通訊協議，它被用來定義和建立跨語言的服務。它被當作一個遠端過程呼叫（RPC）框架來使用，是由 Facebook 為“大規模跨語言服務開發”而開發的。

為什麼叫 koalas

樹袋熊英文翻譯，希望考拉 RPC 給那些不太喜歡動手自己去造輪子的人提供可靠的 RPC 使用環境。

為什麼要寫這個 RPC

市面上常見的 RPC 框架很多，grpc，motan，dubbo 等，但是隨著越來越多的元素加入，複雜的架構設計等因素似使得這些框架和 spring 一樣，雖然號稱是輕量級，但是用起來卻是讓我們很蹩腳，大量的配置，繁雜的 API 設計，其實，我們根本用不上這些東西！！！

我也算得上是在很多個網際網路企業廝殺過，見過很多很多的內部 RPC 框架，有些優秀的設計讓我非常讚賞，有一天我突然想著，為什麼不對這些設計原型進行聚合歸類，於是自己搞一套【輕量級】 RPC 框架呢，於是利用業餘時間開發此專案，希望原始碼對大家對認識 RPC 框架起到推進的作用。

技術棧

thrift 0.8.0
spring-core-4.2.5，spring-context-4.2.5，spring-beans-4.2.5
log4j，slf4j
org.apache.commons(v2.0+)
io.netty4
fastJson
zookeeper
點評cat（V3.0.0+ 做資料大盤統計上報等使用，可不配置）
AOP，反射代理等

技術架構

Koalas 架構圖

序列化

考察了很多個序列化元件，其中包括jdk原生，kryo、hessian、protoStuff,thrift，json等，最終選擇了Thrift，原因如下：原生JDK序列化反序列化效率堪憂，其序列化內容太過全面kryo和hessian，json相對來說比原生JDK強一些，但是對跨語言支援一般，所以捨棄了，最終想在protoBuf和Thrift協議裡面選擇一套框架，這倆框架很相通，支援跨語言，需要靜態編譯等等。但是protoBuf不帶RPC服務，本著提供多套服務端模式（thrift rpc，netty）的情況下，最終選擇了Thrift協議。

IO執行緒模型

原生socket可以模擬出簡單的RPC框架，但是對於大規模併發，要求吞吐量的系統來說，也就算得上是一個demo級別的，所以BIO肯定是不考慮了，NIO的模型在序列化技術選型的時候已經說了，Thrift本身支援很多個io執行緒模型，同步，非同步，半同步非同步等（SimpleServer，TNonblockingServer，THsHaServer，TThreadedSelectorServer，TThreadPoolServer），其中吞吐量最高的肯定是半同步半非同步的IO模TThreadedSelectorServer了，具體原因大家可自行google，這次不做多的闡述，選擇好了模型之後，發現thrift簡直就是神器一樣的存在，再一想，對於服務端來說，IO模型怎麼能少得了Netty啊，所以下決心也要支援Netty，但是很遺憾Netty目前沒有對Thrift的序列化解析，拆包粘包的處理，但是有protoBuf，和http協議的封裝，怎麼辦，自己在netty上寫對thrift的支援唄，雖然工作量大了一些，但是一想netty不就是幹這個事兒的嘛- -！

服務發現

支援叢集的RPC框架裡面，像dubbo，或者是其他三方框架，對服務發現都進行的封裝，那麼自研RPC的話，服務發現就要自己來寫了，那麼簡單小巧容易上手的zookeeper肯定是首選了。