為什麼大多數公司最好避免使用微服務? -GreekDataGuy

微服務似乎是完美的解決方案。從理論上講，它們可以提高開發速度，同時允許您獨立擴充套件應用程式的不同部分。

但實際上，微服務帶有隱藏的成本。也就是說，我認為如果不親自構建它們，您就無法真正理解它們的複雜性。

這是我使用微服務構建（有時失敗）的經驗。

管理資料是一場噩夢

跨微服務保持數​​據同步可能具有挑戰性。

每個微服務一個資料庫是推薦的模式。它允許鬆散耦合並允許特定於服務的團隊獨立運作，而不會減慢在共享程式碼上的協作速度。

但是，當應該同步啟動的兩個微服務之一出現故障時會發生什麼？例如，其中一個微服務更新其資料庫，而另一個不更新。

此類情況會導致資料不一致。

根據個人經驗，調查跨服務的資料不一致可能會很痛苦。錯誤的跨服務性質需要一個人跨多個服務工作以糾正錯誤。不幸的是，這會使微服務的優勢之一——特定於團隊的服務無效。

通過將兩個資料庫呼叫包裝在單個原子事務中，可以輕鬆防止單體應用程式中的相同情況，因此所有插入都成功或都不成功。十分簡單。

但是對於微服務，鬆散耦合使這變得更加困難。

花費更多時間在設定上

構建微服務架構比將相同的功能整合到單體中需要更長的時間。

雖然單個服務很簡單，但互動的服務集合比類似的單體要複雜得多。

單體中的函式可以呼叫任何其他公共函式。但是一個微服務中的函式僅限於呼叫同一個微服務中的函式。

這需要服務之間的通訊。構建 API 或訊息傳遞系統來促進這一點並非易事。

此外，無法避免跨微服務的程式碼重複。單體應用可以定義一個模組並多次匯入，而微服務就是它自己的應用程式——需要在每個應用程式中定義模組和庫。

微服務最適合大型團隊

將微服務分配給單個團隊的奢侈是針對大型工程部門的。

儘管這是微服務體系結構的一大吹捧優勢，但只有當您擁有足夠多工程人員數，並將多名工程師專用於每項服務時才可行。減少開發人員的程式碼範圍，可為他們提供了更好地理解他們的程式碼並提高開發速度的頻寬。

但大多數初創公司沒有這種奢侈。

在資源不足的早期公司中，一些工程師需要跨所有服務工作。

不幸的是，這會降低工作效率，因為跨應用程式可能會導致嚴重的上下文切換。

我發現在我有一段時間沒有研究過的微服務中的尋找錯誤令人筋疲力盡。

DevOps 更加複雜

選擇微服務的最令人信服的原因之一是能夠在不同型別的伺服器上執行不同的服務。

為什麼？與訓練機器學習模型的服務相比，React 前端可能具有非常不同的記憶體、CPU 和正常執行時間要求。為每項服務選擇正確型別的基礎設施可以大大降低成本。

但它也帶來了自己的挑戰。

舉個例子：在我職業生涯的早期，我曾經因為忘記重新啟動程式碼已經更新了的服務而丟失了大量的生產資料。過時的程式碼通過 API 請求接收資料，但隨後以靜默方式失敗，而不是將其記錄在其資料庫中。這樣這些默默被處理的資料永遠丟失了。

我提出這一點是為了說明與單個單體應用程式相比，配置、維護和監控多個微服務需要更多的工作。擁有多個應用程式也會增加黑客的攻擊向量。

理論上，“鬆散耦合”服務允許每個服務在其他服務失敗時繼續執行。但這是一廂情願的想法——真正的鬆耦合對於與客戶的複雜業務來說幾乎是不可能的。

最後，您的應用程式架構僅取決於最薄弱的部分的可靠性。可移動的部件越多，出錯的機會就越大。

總結

許多公司在並不真正需要它們的情況下使用微服務。儘管它們目前很受歡迎，但微服務並不適合初學者。

大多數公司最好構建一個單體應用，然後在絕對必要時將單體應用的各個部分拆分為微服務。

讓資金雄厚的大型科技公司從頭開始構建微服務架構。