[[403138]]

過去幾年，胖哥經(jīng)歷過幾個(gè)初創(chuàng)的公司。其中不乏使用微服務(wù)進(jìn)行初期的試錯(cuò)。我想很多人也跟我一樣會(huì)有疑問微服務(wù)真的能夠解決初創(chuàng)公司面臨的問題嗎?

作為一名軟件工程師，我非常喜歡微服務(wù)的理念。甚至在17年就嘗試了Spring Cloud來編寫腳手架。

我一度認(rèn)為微服務(wù)是一種“靈丹妙藥”，可以幫助公司走上正軌?，F(xiàn)實(shí)打了我一巴掌，不到五十萬的用戶量，日活最高過千，屈指可數(shù)的成交量，甚至監(jiān)控大盤從來沒都沒看見過流量洪峰和閾值警報(bào)。而每天卻要和網(wǎng)絡(luò)、集群打交道，完全和公司業(yè)務(wù)體量不搭界。

甚至我見過拆分了10多個(gè)微服務(wù)模塊卻共用著一個(gè)臺(tái)服務(wù)器，空載就已經(jīng)達(dá)到了硬件的閾值;我還見過微服務(wù)有模有樣地跑在一個(gè)數(shù)據(jù)庫Schema上;甚至還聽說過公司只有一個(gè)開發(fā)卻支撐了一個(gè)微服務(wù)架構(gòu)。雖然從技術(shù)角度允許這樣做，但事實(shí)上這不僅違背了微服務(wù)的設(shè)計(jì)理念而且拖累了整個(gè)項(xiàng)目。

我們閱讀到的大多數(shù)微服務(wù)相關(guān)的文章都在談?wù)摻怦?、消除開發(fā)團(tuán)隊(duì)之間的依賴關(guān)系、更好的水平可擴(kuò)展性等等。卻忽視了業(yè)務(wù)邊界劃分的難度以及設(shè)計(jì)、開發(fā)、部署微服務(wù)的復(fù)雜性。從可靠性的角度來看，當(dāng)我們使用微服務(wù)時(shí)，不同服務(wù)之間的通信過程中出現(xiàn)故障的可能性更高。另一個(gè)痛點(diǎn)是運(yùn)行微服務(wù)的成本，可能需要更多的硬件資源，而這往往是小公司、初創(chuàng)公司不太愿意投入的。還需要更多優(yōu)秀的工程師，而初創(chuàng)公司往往無法投入過多的人力。同時(shí)各個(gè)服務(wù)的編排和監(jiān)控同樣對(duì)運(yùn)維能力提出了更高的要求。

那么何時(shí)應(yīng)該轉(zhuǎn)向微服務(wù)?我個(gè)人認(rèn)為，當(dāng)單體項(xiàng)目已經(jīng)足夠復(fù)雜，而且公司的運(yùn)營(yíng)數(shù)據(jù)逐漸有了起色就可以著手準(zhǔn)備切入到微服務(wù)。在早期階段，微服務(wù)只會(huì)增加我們的負(fù)擔(dān)。

那些成功的獨(dú)角獸，包括國(guó)外微服務(wù)踐行的最好的Netflix、Airbnb都是從單體架構(gòu)開始的，他們業(yè)務(wù)增長(zhǎng)到了一個(gè)良性的階段，他們就轉(zhuǎn)向了微服務(wù)。如果一個(gè)初創(chuàng)公司還在試錯(cuò)，我還是建議使用單體架構(gòu)，除非你跟這家公司有仇。

本文轉(zhuǎn)載自微信公眾號(hào)「碼農(nóng)小胖哥」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系碼農(nóng)小胖哥公眾號(hào)。