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ǔ),如果有不滿足公司特定需求的可基于開源組件改造