RPC選型思考

一、背景

市面上開源RPC框架非常多，有技術實力的公司大部分都是採用自研，還有部分公司受歷史項目影響，一直都是老舊的框架

常見RPC框架：

1. RMI(淘汰)

2. Restful + http(1.1~3) + tls

3. gRPC

4. motan

5. tars

6. thrift

7. SOFA-RPC

8. Dubbo(1~3)

9. Hessian

   ...

接着上文，因爲技術在不斷迭代，佬框架如果沒有維護，那麼就會慢慢被歷史淘汰（沒錯，說的就是Dubbo），新框架崛起，那對於企業來說切換成本的考慮，技術風險都是非常重要的，現在k8s是事實上的容器編排標準，作爲谷歌的親兒子gRPC越來越到歡迎，只要是跟k8s關聯，都要主動接入gRPC，基於DNS的註冊發現都是RPC框架需要考慮的。

大企業的技術迭代也不是一步到位，要在不斷迭代，演進式發展，畢竟初創企業能付出的成本是非常小。

二、選型

技術選型考慮點：

1. 初期團隊技術實力弱，開發週期短，RPC必須足夠簡單
2. 後期切換RPC要足夠簡單，改動代碼要少
3. RPC的性能要承載業務未來發展
4. 未來技術要能兼容

路線：restful + http -> dubbo

對於IDL的定義，個人對於gRPC的proto定義和代碼生成機制比較反感，我選擇Java IDL的方式定義接口，項目初期使用feign定義接口，後期通過替換feign的target實現類來完成RPC升級，dubbo3雖然在Triple性能未來性能會越來越好，但是還是弱於tcp類的RPC，協議層就決定了

Dubbo基準測試

Dubbo官網