2019年7月底入職了新的公司，是一家創(chuàng)業(yè)公司，在架構(gòu)組負(fù)責(zé)一些架構(gòu)方面的工作。公司人員流動略大，公司自研的RPC框架是前人留下的坑，開發(fā)團(tuán)隊已全部跑路，因為最近也是第一次接觸，寫一下自己的吐槽與思考

吐槽點(diǎn)

微服務(wù)框架為什么要自研

我覺得沒理由，目前開源成熟的服務(wù)框架非常多，具有代表性的：

• spring-cloud體系：強(qiáng)大且易用
• dubbo(可接入spring-cloud)：阿里多年前開源的SOA框架，被很多大公司所用，已是apache頂級項目
• servicecomb：華為的開源項目，已是apache頂級項目

成熟的開源產(chǎn)品完全能滿足一般創(chuàng)業(yè)公司的使用，因此，對于現(xiàn)公司，我覺得完全沒有理由自研一套

自研卻缺少文檔

自研也就算了，沒有任何使用說明文檔，入門時一臉懵逼，加上開發(fā)團(tuán)隊全部跑路，只能向使用過的同學(xué)學(xué)習(xí)如何使用

自研的非常差

自研就自研，但是能不能做好一點(diǎn)呢？從該rpc報出的異常棧以及調(diào)用方式就能看出其實現(xiàn)非常粗糙丑陋，毫無優(yōu)雅性可言

這里先說一說微服務(wù)框架的幾個考慮點(diǎn)，自底向上分別是：

• 序列化/反序列化
• 服務(wù)端/客戶端的抽象，用于處理接受請求與發(fā)送請求，封裝request/response語義
• 通信協(xié)議，可選擇基于tcp或者h(yuǎn)ttp，或者其它
• RPC協(xié)議，定義RPC過程中的數(shù)據(jù)傳輸方式，支持多種調(diào)用方式，比如同步調(diào)用，異步調(diào)用，不關(guān)心返回值以及是否成功的調(diào)用等
• 對集群的抽象，封裝負(fù)載均衡與失敗處理，負(fù)載均衡可使用roundover, hash等，失敗處理可提供failover, failfast等方式，現(xiàn)在的服務(wù)框架的負(fù)載均衡都使用了軟負(fù)載
• 服務(wù)主冊與服務(wù)發(fā)現(xiàn)
• api/stub/與已有框架的結(jié)合等
• 服務(wù)治理

但該rpc完全沒有考慮上述問題，或者說考慮的非常之少，該rpc的相關(guān)情況：

• 序列化/反序列化：json，半自動化，往往還需要人工做json反序列化
• 服務(wù)端/客戶端的抽象：幾乎沒有，使用靜態(tài)方法調(diào)用，也沒有IO處理，依賴應(yīng)用本身的tomcat，不是說這樣不行，但是太粗糙
• 通信協(xié)議：基于http，依賴應(yīng)用的tomcat以及8080端口，不是說不能使用http協(xié)議，使用http協(xié)議是沒問題的，但是依賴應(yīng)用的tomcat并不是一個好的方案，因為這樣導(dǎo)致應(yīng)用系統(tǒng)需要關(guān)心rpc框架的細(xì)節(jié)，比如想要寫一個Servlet Filter對請求進(jìn)行攔截，我們需要考慮該Filter會不會攔截到rpc請求
• 負(fù)載均衡與失敗處理：無考慮，根據(jù)異常棧就能看出該rpc的服務(wù)注冊與服務(wù)發(fā)現(xiàn)過于粗糙，它是通過域名做http調(diào)用，負(fù)載均衡依賴nginx，沒有軟負(fù)載，不支持失敗處理
• 服務(wù)注冊與服務(wù)發(fā)現(xiàn)：基于域名的而不是基于服務(wù)的，粒度太粗了，這就導(dǎo)致沒法實現(xiàn)對服務(wù)的精細(xì)化管控，比如A/B測試，兼容性的平滑處理等
• api實現(xiàn)極其丑陋，沒有stub或者遠(yuǎn)程代理這樣的概念，rpc的調(diào)用是純手動處理的json，調(diào)用方式如下：

String jsonResult = RemoteClientUtil.callRpc(”appName.serviceName“, JSON.toJsonString(params));
Result result = JSON.parseObject(jsonResult, Result.class);

• 完全沒有服務(wù)治理能力，且沒法接入spring-cloud體系，利用spring-cloud的相關(guān)能力

毫無擴(kuò)展性

該自研的rpc框架非常不完善，并且很難與已有的開源項目結(jié)合，對于流程管控、服務(wù)治理的需求，該rpc框架難以滿足
如果要重構(gòu)，那基本上是重寫，目前大量系統(tǒng)在使用，涉及到的系統(tǒng)改造非常大，基本上不現(xiàn)實

總結(jié)

對于這樣的rpc框架，如果只論技術(shù)，它做的非常差，在rpc框架中，它就是demo級別的存在，不有參考價值。
當(dāng)然，你可以說小公司不需要dubbo，不需要spring-cloud，但是我不這樣認(rèn)為，我認(rèn)為我們當(dāng)前對spring-cloud中的組件還是有需求的，但是該rpc沒有考慮如何融入到成熟的微服務(wù)體系，抬高了我們使用這些成熟組件的門檻

雖然我沒有自研過rpc框架，但見到該rpc框架后也要吸取教訓(xùn)，自研基礎(chǔ)組件一定要考慮周全，盡量避免與應(yīng)用共享資源，需要考慮擴(kuò)展性

最后建議優(yōu)先選擇開源體系作為微服務(wù)架構(gòu)的基礎(chǔ)，如果有不滿足公司特定需求的可基于開源組件改造