微服務(wù)很火，但火不代表適合你

最近幾年，微服務(wù)這個(gè)詞真的是火得不行。開(kāi)技術(shù)會(huì)議，不聊聊微服務(wù)好像就顯得落伍了；寫(xiě)簡(jiǎn)歷，不寫(xiě)個(gè)"負(fù)責(zé)微服務(wù)架構(gòu)設(shè)計(jì)"好像就找不到工作了。就連我見(jiàn)過(guò)的一些創(chuàng)業(yè)公司，員工總共就5個(gè)人，也要搞什么微服務(wù)架構(gòu)。

但說(shuō)句實(shí)話(huà)，作為一個(gè)在這個(gè)行業(yè)摸爬滾打了十多年的老兵，我見(jiàn)過(guò)太多企業(yè)盲目跟風(fēng)上微服務(wù)，最后搞得焦頭爛額的案例。今天就跟大家聊聊這個(gè)話(huà)題，希望能幫正在糾結(jié)的朋友們避開(kāi)一些不必要的坑。

真實(shí)場(chǎng)景：那些年我們一起踩過(guò)的微服務(wù)坑

微服務(wù)的隱性成本，你算過(guò)嗎？

某外企的"微服務(wù)忽悠"

去年幫一家外企公司做技術(shù)咨詢(xún)，這個(gè)案例真的讓我印象深刻。這家公司原本有一個(gè)運(yùn)行得很好的內(nèi)部審批系統(tǒng)，雖然功能不算復(fù)雜，但勝在穩(wěn)定可靠，基本沒(méi)什么故障。

結(jié)果某大型軟件外包公司的銷(xiāo)售找上門(mén)來(lái)，PPT做得特別漂亮，各種buzzword滿(mǎn)天飛：微服務(wù)、云原生、DevOps、敏捷開(kāi)發(fā)…把他們的IT團(tuán)隊(duì)和業(yè)務(wù)部門(mén)忽悠得一愣一愣的。銷(xiāo)售說(shuō)："你們現(xiàn)在這個(gè)系統(tǒng)太落后了，完全不符合現(xiàn)代化架構(gòu)理念。我們幫你們重構(gòu)成微服務(wù)架構(gòu)，保證能提升3倍開(kāi)發(fā)效率，5倍運(yùn)行性能！"

IT團(tuán)隊(duì)一聽(tīng)，這么高大上的技術(shù)我們也要有！業(yè)務(wù)部門(mén)一聽(tīng)，效率能提升3倍？那還等什么！于是就這樣，一個(gè)簡(jiǎn)單的審批業(yè)務(wù)被硬生生拆成了8個(gè)微服務(wù)：

• 用戶(hù)認(rèn)證服務(wù)
• 權(quán)限管理服務(wù)
• 流程引擎服務(wù)
• 表單服務(wù)
• 通知服務(wù)
• 文件存儲(chǔ)服務(wù)
• 審批記錄服務(wù)
• 報(bào)表統(tǒng)計(jì)服務(wù)

聽(tīng)起來(lái)很專(zhuān)業(yè)對(duì)吧？但實(shí)際使用起來(lái)就是災(zāi)難。

開(kāi)發(fā)階段的痛苦：原來(lái)改個(gè)審批流程，后端改一下邏輯，前端改一下表單，半天就搞定?，F(xiàn)在呢？要同時(shí)修改流程引擎服務(wù)、表單服務(wù)、通知服務(wù)…一個(gè)簡(jiǎn)單的需求變更，涉及4-5個(gè)服務(wù)的代碼修改。

測(cè)試階段的噩夢(mèng)：測(cè)試人員要測(cè)試一個(gè)完整的審批流程，需要確保8個(gè)服務(wù)都正常運(yùn)行。有一次測(cè)試環(huán)境的文件存儲(chǔ)服務(wù)掛了，整個(gè)審批功能都不能用，測(cè)試人員愣是找了半天才發(fā)現(xiàn)問(wèn)題在哪里，最后對(duì)客戶(hù)說(shuō)法是小概率事件。

部署和運(yùn)維的地獄：原來(lái)一個(gè)jar包部署就完事了，現(xiàn)在要部署8個(gè)服務(wù)，還要配置服務(wù)發(fā)現(xiàn)、負(fù)載均衡、監(jiān)控告警…運(yùn)維工程師直接從1個(gè)人忙的不要不要的，而且要求比以前高多了，各種腳本都得備著。

性能反而下降了：承諾的"5倍性能提升"完全是空話(huà)。原來(lái)一個(gè)審批請(qǐng)求，在單體應(yīng)用里就是幾次數(shù)據(jù)庫(kù)查詢(xún)?，F(xiàn)在要經(jīng)過(guò)8個(gè)服務(wù)的網(wǎng)絡(luò)調(diào)用，光是網(wǎng)絡(luò)延遲就比原來(lái)高了幾倍。

故障排查成了噩夢(mèng)：最要命的是故障排查。有一次系統(tǒng)突然變慢，用戶(hù)投訴不斷。原來(lái)在單體應(yīng)用里看看日志就能定位問(wèn)題，現(xiàn)在要在8個(gè)服務(wù)的日志里找線(xiàn)索，就像大海撈針。最后花了6個(gè)小時(shí)才發(fā)現(xiàn)是通知服務(wù)的一個(gè)小bug導(dǎo)致的連鎖反應(yīng)。

成本直接翻倍：這個(gè)外包公司最初報(bào)價(jià)是原系統(tǒng)重構(gòu)的1.5倍，結(jié)果實(shí)際交付成本是原來(lái)的4倍。后期維護(hù)成本更是高得離譜，光是服務(wù)器資源就比原來(lái)多用了兩倍，以前一臺(tái)搞定，現(xiàn)在prod，dev，uat一起搞了6臺(tái)，好在最后砍了uat的兩臺(tái)。

很多人看到微服務(wù)的好處，但往往忽略了它帶來(lái)的復(fù)雜度成本。讓我們算算這筆賬：

運(yùn)維復(fù)雜度指數(shù)級(jí)增長(zhǎng)

單體應(yīng)用：1個(gè)應(yīng)用，1個(gè)數(shù)據(jù)庫(kù)，1套監(jiān)控  微服務(wù)：N個(gè)應(yīng)用，N個(gè)數(shù)據(jù)庫(kù)（可能，我說(shuō)的這個(gè)項(xiàng)目是2個(gè)，一般1個(gè)也正學(xué)常），N套監(jiān)控，還有服務(wù)注冊(cè)發(fā)現(xiàn)、負(fù)載均衡、熔斷器…

我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)，原來(lái)1個(gè)運(yùn)維工程師就能搞定的系統(tǒng)，上了微服務(wù)后需要2個(gè)運(yùn)維工程師，人力成本直接翻倍。

開(kāi)發(fā)效率的隱性下降

聽(tīng)起來(lái)很矛盾，微服務(wù)不是應(yīng)該提高開(kāi)發(fā)效率嗎？理論上是這樣，但前提是你的團(tuán)隊(duì)規(guī)模和組織架構(gòu)要匹配。

小團(tuán)隊(duì)搞微服務(wù)，經(jīng)常出現(xiàn)這種情況：

• 改個(gè)功能需要同時(shí)修改3個(gè)服務(wù)
• 本地調(diào)試變得極其復(fù)雜，要同時(shí)啟動(dòng)一堆服務(wù)
• 聯(lián)調(diào)測(cè)試成本大幅增加
• 接口版本管理變成噩夢(mèng)，這個(gè)是最瘋狂的。

分布式系統(tǒng)的經(jīng)典問(wèn)題

網(wǎng)絡(luò)分區(qū)、數(shù)據(jù)一致性、分布式事務(wù)…這些問(wèn)題單體應(yīng)用根本不會(huì)遇到，但微服務(wù)架構(gòu)下都是必須面對(duì)的挑戰(zhàn)。

我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)為了解決分布式事務(wù)問(wèn)題，光是技術(shù)方案就討論了兩個(gè)月，最后實(shí)現(xiàn)的復(fù)雜度比業(yè)務(wù)邏輯還高。

什么時(shí)候才真正需要微服務(wù)？

說(shuō)了這么多微服務(wù)的"壞話(huà)"，但我并不是反對(duì)微服務(wù)。微服務(wù)確實(shí)有它的價(jià)值，關(guān)鍵是要在合適的時(shí)候用。

符合這些條件，可以考慮微服務(wù)：

1. 團(tuán)隊(duì)規(guī)模足夠大

• 技術(shù)團(tuán)隊(duì)超過(guò)30人
• 能夠支撐多個(gè)獨(dú)立的小團(tuán)隊(duì)
• 有專(zhuān)門(mén)的運(yùn)維和基礎(chǔ)設(shè)施團(tuán)隊(duì)

2. 業(yè)務(wù)復(fù)雜度足夠高

• 系統(tǒng)有明確的業(yè)務(wù)邊界
• 不同模塊的更新頻率差異很大
• 單體應(yīng)用已經(jīng)成為開(kāi)發(fā)瓶頸

3. 技術(shù)能力足夠強(qiáng)

• 團(tuán)隊(duì)對(duì)分布式系統(tǒng)有深入理解
• 有完善的監(jiān)控、日志、調(diào)試工具鏈
• 自動(dòng)化運(yùn)維能力成熟

4. 業(yè)務(wù)規(guī)模足夠大

• 日活用戶(hù)至少十萬(wàn)級(jí)別
• 確實(shí)需要獨(dú)立擴(kuò)展某些服務(wù)
• 有足夠的資源投入到基礎(chǔ)設(shè)施建設(shè)

這些情況下，單體應(yīng)用更合適：

• 創(chuàng)業(yè)公司或小團(tuán)隊(duì)（<15人）
• 業(yè)務(wù)邏輯相對(duì)簡(jiǎn)單
• 系統(tǒng)負(fù)載不高（日活<10萬(wàn)）
• 團(tuán)隊(duì)對(duì)分布式系統(tǒng)經(jīng)驗(yàn)不足
• 快速迭代是主要訴求

給正在糾結(jié)的團(tuán)隊(duì)一些實(shí)用建議

先把單體應(yīng)用做好

很多團(tuán)隊(duì)連單體應(yīng)用都沒(méi)做好，就想著拆微服務(wù)。這就像房子地基都沒(méi)打牢，就想著加蓋二樓。

先把這些基礎(chǔ)工作做扎實(shí)：

• 模塊化設(shè)計(jì)
• 完善的單元測(cè)試和集成測(cè)試
• 自動(dòng)化部署流程
• 監(jiān)控和日志系統(tǒng)

循序漸進(jìn)，不要一步到位

如果確實(shí)需要向微服務(wù)演進(jìn)，建議采用"絞殺者模式"：

• 先從邊緣服務(wù)開(kāi)始拆分
• 選擇相對(duì)獨(dú)立、變化頻繁的模塊
• 積累經(jīng)驗(yàn)后再拆分核心服務(wù)

投資基礎(chǔ)設(shè)施

微服務(wù)成功的前提是完善的基礎(chǔ)設(shè)施：

• 服務(wù)發(fā)現(xiàn)和配置管理
• 分布式追蹤系統(tǒng)
• 統(tǒng)一的日志聚合
• 自動(dòng)化測(cè)試和部署
• 監(jiān)控告警體系

這些基礎(chǔ)設(shè)施的建設(shè)成本，往往比業(yè)務(wù)開(kāi)發(fā)成本還高。

組織架構(gòu)要匹配

康威定律說(shuō)得很對(duì)：組織架構(gòu)決定系統(tǒng)架構(gòu)。如果你的組織架構(gòu)還是傳統(tǒng)的職能型團(tuán)隊(duì)，強(qiáng)行上微服務(wù)只會(huì)增加溝通成本。

理想的微服務(wù)團(tuán)隊(duì)?wèi)?yīng)該是：

• 每個(gè)團(tuán)隊(duì)負(fù)責(zé)一個(gè)或幾個(gè)相關(guān)的服務(wù)
• 團(tuán)隊(duì)內(nèi)包含開(kāi)發(fā)、測(cè)試、運(yùn)維人員
• 有明確的服務(wù)邊界和責(zé)任劃分

寫(xiě)在最后

技術(shù)選型這件事，沒(méi)有銀彈，只有合適不合適。微服務(wù)確實(shí)是個(gè)好東西，但它不是萬(wàn)能藥，更不是炫技的工具。

我見(jiàn)過(guò)太多團(tuán)隊(duì)為了追求技術(shù)先進(jìn)性，盲目上馬微服務(wù)，最后搞得團(tuán)隊(duì)疲于奔命，業(yè)務(wù)發(fā)展受阻。也見(jiàn)過(guò)一些團(tuán)隊(duì)堅(jiān)持使用單體架構(gòu)，但通過(guò)良好的設(shè)計(jì)和實(shí)踐，一樣能支撐大規(guī)模的業(yè)務(wù)。

記住，技術(shù)是為業(yè)務(wù)服務(wù)的，不是相反。選擇什么架構(gòu)，要看你的團(tuán)隊(duì)能力、業(yè)務(wù)需求和發(fā)展階段。有時(shí)候，簡(jiǎn)單的方案反而是最好的方案。

如果你正在糾結(jié)要不要上微服務(wù)，不妨問(wèn)問(wèn)自己幾個(gè)問(wèn)題：

• 現(xiàn)在的單體應(yīng)用真的已經(jīng)成為瓶頸了嗎？
• 團(tuán)隊(duì)有足夠的能力駕馭分布式系統(tǒng)的復(fù)雜性嗎？
• 投入產(chǎn)出比真的劃算嗎？

想清楚這些問(wèn)題，相信你會(huì)做出正確的選擇。

說(shuō)這么多，無(wú)非是希望大家能少踩點(diǎn)坑，把有限的時(shí)間和精力用在真正有價(jià)值的地方。畢竟，我們的目標(biāo)是解決業(yè)務(wù)問(wèn)題，而不是制造技術(shù)問(wèn)題，現(xiàn)在有一個(gè)趨勢(shì)就是IT在不斷制作問(wèn)題。