吐槽公司自研RPC框架

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

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

推薦閱讀更多精彩內(nèi)容

  • # 背景 # 關(guān)鍵設(shè)計點(diǎn) ## 模塊化 ## 資源隔離 ## 權(quán)限控制 ### RPC框架的需求分析和概要設(shè)計 #...
    65902f77f84d閱讀 1,228評論 0 0
  • 一 傳統(tǒng)垂直mvc項目 1.垂直架構(gòu)圖 通常mvc并不包括數(shù)據(jù)訪問層,運(yùn)行也比較簡單,直接運(yùn)行在一個tomcat等...
    千鋒陳老師閱讀 496評論 0 0
  • 自打我進(jìn)簡書以來 就獨(dú)得簡叔的恩寵 這后宮佳麗三千啊 簡叔就偏偏寵我一人 我勸簡叔一定要雨露均沾 可簡叔非是不聽吶...
    此木梅花閱讀 832評論 6 18
  • 今天早晨,早起洗漱之后,去參加了一次技術(shù)大會,看到了云計算領(lǐng)域發(fā)展的最新的動態(tài),聽到了軟件業(yè)內(nèi)的目前最具優(yōu)勢的演講...
    LiHongxi閱讀 89評論 0 0
  • 平時喜歡打籃球,知道自己上肢力量比較弱,為了在對抗中能保持優(yōu)勢,辦了張健身房的卡,通過訓(xùn)練以加強(qiáng)上肢力量。 去過健...
    學(xué)習(xí)之術(shù)閱讀 382評論 0 0