什么時候不應該使用微服務？

Question

在哪種情況下，我們不應該使用微服務架構？ 到目前為止，我可以看到微服務的設計，看起來很好用於許多用例。

我不會推薦POC（概念證明）項目的基本用例之一。

Answer 1

這是一個非常廣泛的，可能是非常自以為是的問題。 當您擁有一個通常始終作為一個單元部署的許多共享依賴項的應用程序時，我不會提倡使用微服務。

微服務很棒，而且它們有自己的位置 - 但如果你的應用程序具有這樣的性質，它總是作為一個單元部署，微服務可以嚴重擴展復雜性 - 現在你正在部署大量單獨的工件，一次性而不只是一個應用程序。 我想到的例子是ERP系統。

編輯：為了擴展這一點，微服務不應該是應用程序的默認架構。 保持盡可能簡單，如果遇到可擴展性問題，或其他證明微服務路由合理的事情，那就去做吧。 保持盡可能簡單。 那么，恕我直言，答案是“什么時候不應該使用微服務？” 是“當你不需要它們時”。

見YAGNI 。

Answer 2

在哪種情況下，我們不應該使用微服務架構？

您不必將微服務架構樣式應用於沒有樣式試圖解決的問題的場景。 那些問題是哪些？

在給出答案之前 - 微服務是一個流行詞，描述了一種建築風格，它試圖回答“如何將應用程序分解為邏輯組件”這一古老的問題。 雖然沒有確切的定義，但它通常歸結為具有特定域目的的獨立開發和可部署組件。 所以考慮到這一點 - 以下是微服務架構風格試圖解決的問題：

1. 最重要的問題是擴大大型組織的發展。 微服務允許獨立團隊在獨立的發布周期內快速移動。 將其與一個必須聚合所有依賴關系的大型“整體”進行比較，並且每隔幾個月最多可以發布一個版本。 因此，每當一家公司試圖組織數百名開發人員開發基於大型服務器的應用程序時，他們應該考慮設置負責微服務的團隊。 這是因為“建築遵循組織”（ 康威定律 ）。

2. 應用程序本身的可伸縮性。 與無狀態設計相結合，可以以集群方式大規模部署服務。 因此，每當用戶群隨着時間的推移而增長時，您很可能會從微服務架構風格中受益。

3. 強制分離關注點。 在“單片”開發中，通常最小化持久數據模式並使許多組件使用相同的數據庫持久性。 這通過添加間接依賴性來增加復雜性，從而增加了發布新軟件版本的通信和組織開銷。 不允許微服務共享數據持久性，因此可以避免此問題。

4. 溝通問題。 如果組件之間的通信沒有很好地定義，則重用組件的工作量會急劇增加。 特別是在組件的多個版本的生命周期中。 因此，微服務架構風格強烈關注與外界明確定義的界面。 這包括下游消費者的界面版本（主要/次要）的定義。

然后關於你的結論：

我不會推薦POC（概念證明）項目的基本用例之一。

基於以上幾點，您的陳述不一定適用。 如果它是一個擁有龐大團隊的POC開發，並且您預計會遇到任何上述問題，您仍將從微服務架構風格中受益。