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

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

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

真實場景：那些年我們一起踩過的微服務(wù)坑

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

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

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

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

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

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

聽起來很專業(yè)對吧？但實際使用起來就是災(zāi)難。

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

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

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

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

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

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

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

運維復(fù)雜度指數(shù)級增長

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

我見過一個團隊，原來1個運維工程師就能搞定的系統(tǒng)，上了微服務(wù)后需要2個運維工程師，人力成本直接翻倍。

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

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

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

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

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

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

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

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

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

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

1. 團隊規(guī)模足夠大

• 技術(shù)團隊超過30人
• 能夠支撐多個獨立的小團隊
• 有專門的運維和基礎(chǔ)設(shè)施團隊

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

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

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

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

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

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

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

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

給正在糾結(jié)的團隊一些實用建議

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

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

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

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

循序漸進，不要一步到位

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

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

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

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

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

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

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

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

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

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

寫在最后

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

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

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

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

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

想清楚這些問題，相信你會做出正確的選擇。

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