初創公司真的適合用微服務嗎？

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

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

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

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

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

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

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

不過說句題外話，真理和決策權往往不掌握在理性之人的手中。

Spring Security 實戰干貨：如何獲取當前用戶信息

2021-05-31

線上SQL腳本執行錯了出事之后互相甩鍋怎么辦?

2021-05-28

微服務

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。