2019年7月底入職了新的公司做祝，是一家創(chuàng)業(yè)公司砾省，在架構(gòu)組負(fù)責(zé)一些架構(gòu)方面的工作。公司人員流動(dòng)略大混槐，公司自研的RPC框架是前人留下的坑编兄，開(kāi)發(fā)團(tuán)隊(duì)已全部跑路，因?yàn)樽罱彩堑谝淮谓佑|声登，寫(xiě)一下自己的吐槽與思考
吐槽點(diǎn)
微服務(wù)框架為什么要自研
我覺(jué)得沒(méi)理由狠鸳，目前開(kāi)源成熟的服務(wù)框架非常多，具有代表性的：
- spring-cloud體系：強(qiáng)大且易用
- dubbo(可接入spring-cloud)：阿里多年前開(kāi)源的SOA框架悯嗓，被很多大公司所用件舵，已是apache頂級(jí)項(xiàng)目
- servicecomb：華為的開(kāi)源項(xiàng)目，已是apache頂級(jí)項(xiàng)目
成熟的開(kāi)源產(chǎn)品完全能滿(mǎn)足一般創(chuàng)業(yè)公司的使用脯厨，因此铅祸，對(duì)于現(xiàn)公司，我覺(jué)得完全沒(méi)有理由自研一套
自研卻缺少文檔
自研也就算了，沒(méi)有任何使用說(shuō)明文檔临梗，入門(mén)時(shí)一臉懵逼涡扼，加上開(kāi)發(fā)團(tuán)隊(duì)全部跑路，只能向使用過(guò)的同學(xué)學(xué)習(xí)如何使用
自研的非常差
自研就自研盟庞，但是能不能做好一點(diǎn)呢吃沪？從該rpc報(bào)出的異常棧以及調(diào)用方式就能看出其實(shí)現(xiàn)非常粗糙丑陋，毫無(wú)優(yōu)雅性可言
這里先說(shuō)一說(shuō)微服務(wù)框架的幾個(gè)考慮點(diǎn)什猖，自底向上分別是：
- 序列化/反序列化
- 服務(wù)端/客戶(hù)端的抽象票彪，用于處理接受請(qǐng)求與發(fā)送請(qǐng)求，封裝request/response語(yǔ)義
- 通信協(xié)議卸伞，可選擇基于tcp或者h(yuǎn)ttp抹镊，或者其它
- RPC協(xié)議，定義RPC過(guò)程中的數(shù)據(jù)傳輸方式荤傲，支持多種調(diào)用方式垮耳，比如同步調(diào)用，異步調(diào)用遂黍，不關(guān)心返回值以及是否成功的調(diào)用等
- 對(duì)集群的抽象终佛，封裝負(fù)載均衡與失敗處理，負(fù)載均衡可使用roundover, hash等雾家，失敗處理可提供failover, failfast等方式铃彰，現(xiàn)在的服務(wù)框架的負(fù)載均衡都使用了軟負(fù)載
- 服務(wù)主冊(cè)與服務(wù)發(fā)現(xiàn)
- api/stub/與已有框架的結(jié)合等
- 服務(wù)治理
但該rpc完全沒(méi)有考慮上述問(wèn)題，或者說(shuō)考慮的非常之少芯咧，該rpc的相關(guān)情況：
- 序列化/反序列化：json牙捉，半自動(dòng)化，往往還需要人工做json反序列化
- 服務(wù)端/客戶(hù)端的抽象：幾乎沒(méi)有敬飒，使用靜態(tài)方法調(diào)用邪铲，也沒(méi)有IO處理，依賴(lài)應(yīng)用本身的tomcat无拗，不是說(shuō)這樣不行带到，但是太粗糙
- 通信協(xié)議：基于http，依賴(lài)應(yīng)用的tomcat以及8080端口英染，不是說(shuō)不能使用http協(xié)議揽惹，使用http協(xié)議是沒(méi)問(wèn)題的，但是依賴(lài)應(yīng)用的tomcat并不是一個(gè)好的方案四康，因?yàn)檫@樣導(dǎo)致應(yīng)用系統(tǒng)需要關(guān)心rpc框架的細(xì)節(jié)搪搏，比如想要寫(xiě)一個(gè)Servlet Filter對(duì)請(qǐng)求進(jìn)行攔截，我們需要考慮該Filter會(huì)不會(huì)攔截到rpc請(qǐng)求
- 負(fù)載均衡與失敗處理：無(wú)考慮箭养，根據(jù)異常棧就能看出該rpc的服務(wù)注冊(cè)與服務(wù)發(fā)現(xiàn)過(guò)于粗糙慕嚷，它是通過(guò)域名做http調(diào)用，負(fù)載均衡依賴(lài)nginx，沒(méi)有軟負(fù)載喝检，不支持失敗處理
- 服務(wù)注冊(cè)與服務(wù)發(fā)現(xiàn)：基于域名的而不是基于服務(wù)的嗅辣，粒度太粗了，這就導(dǎo)致沒(méi)法實(shí)現(xiàn)對(duì)服務(wù)的精細(xì)化管控挠说，比如A/B測(cè)試澡谭，兼容性的平滑處理等
- api實(shí)現(xiàn)極其丑陋，沒(méi)有stub或者遠(yuǎn)程代理這樣的概念损俭，rpc的調(diào)用是純手動(dòng)處理的json蛙奖，調(diào)用方式如下：
String jsonResult = RemoteClientUtil.callRpc(”appName.serviceName“, JSON.toJsonString(params));
Result result = JSON.parseObject(jsonResult, Result.class);
- 完全沒(méi)有服務(wù)治理能力，且沒(méi)法接入spring-cloud體系杆兵，利用spring-cloud的相關(guān)能力
毫無(wú)擴(kuò)展性
該自研的rpc框架非常不完善雁仲，并且很難與已有的開(kāi)源項(xiàng)目結(jié)合，對(duì)于流程管控琐脏、服務(wù)治理的需求攒砖，該rpc框架難以滿(mǎn)足
如果要重構(gòu)，那基本上是重寫(xiě)日裙，目前大量系統(tǒng)在使用吹艇，涉及到的系統(tǒng)改造非常大，基本上不現(xiàn)實(shí)
總結(jié)
對(duì)于這樣的rpc框架昂拂，如果只論技術(shù)受神，它做的非常差，在rpc框架中格侯，它就是demo級(jí)別的存在鼻听，不有參考價(jià)值。
當(dāng)然联四，你可以說(shuō)小公司不需要dubbo精算，不需要spring-cloud，但是我不這樣認(rèn)為碎连，我認(rèn)為我們當(dāng)前對(duì)spring-cloud中的組件還是有需求的，但是該rpc沒(méi)有考慮如何融入到成熟的微服務(wù)體系驮履，抬高了我們使用這些成熟組件的門(mén)檻
雖然我沒(méi)有自研過(guò)rpc框架鱼辙，但見(jiàn)到該rpc框架后也要吸取教訓(xùn)，自研基礎(chǔ)組件一定要考慮周全玫镐，盡量避免與應(yīng)用共享資源倒戏，需要考慮擴(kuò)展性
最后建議優(yōu)先選擇開(kāi)源體系作為微服務(wù)架構(gòu)的基礎(chǔ)，如果有不滿(mǎn)足公司特定需求的可基于開(kāi)源組件改造
