[[403138]]

過去幾年，胖哥經歷過幾個初創的公司。其中不乏使用微服務進行初期的試錯。我想很多人也跟我一樣會有疑問微服務真的能夠解決初創公司面臨的問題嗎?

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

我一度認為微服務是一種“靈丹妙藥”，可以幫助公司走上正軌。現實打了我一巴掌，不到五十萬的用戶量，日活最高過千，屈指可數的成交量，甚至監控大盤從來沒都沒看見過流量洪峰和閾值警報。而每天卻要和網絡、集群打交道，完全和公司業務體量不搭界。

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

我們閱讀到的大多數微服務相關的文章都在談論解耦、消除開發團隊之間的依賴關系、更好的水平可擴展性等等。卻忽視了業務邊界劃分的難度以及設計、開發、部署微服務的復雜性。從可靠性的角度來看，當我們使用微服務時，不同服務之間的通信過程中出現故障的可能性更高。另一個痛點是運行微服務的成本，可能需要更多的硬件資源，而這往往是小公司、初創公司不太愿意投入的。還需要更多優秀的工程師，而初創公司往往無法投入過多的人力。同時各個服務的編排和監控同樣對運維能力提出了更高的要求。

那么何時應該轉向微服務?我個人認為，當單體項目已經足夠復雜，而且公司的運營數據逐漸有了起色就可以著手準備切入到微服務。在早期階段，微服務只會增加我們的負擔。

那些成功的獨角獸，包括國外微服務踐行的最好的Netflix、Airbnb都是從單體架構開始的，他們業務增長到了一個良性的階段，他們就轉向了微服務。如果一個初創公司還在試錯，我還是建議使用單體架構，除非你跟這家公司有仇。

本文轉載自微信公眾號「碼農小胖哥」，可以通過以下二維碼關注。轉載本文請聯系碼農小胖哥公眾號。