微服務是軟件架構的銀彈嗎？或許不是。這個世界上很少有東西是百分百正確的，微服務也不例外。最近，技術作家邁克爾·丘奇曼（Michael Churchman）發文分享了在設計或重構應用程序時，哪些場景可以使用微服務，哪些場景要避免使用微服務。以下爲原文編譯內容。
微服務是一個具體的軟件服務，通常是基於應用程序上下文而定義的一個規模合理的最小化服務。一個應用程序可以由多個微服務組成，這些服務的部署和管理是獨立的，它們組合在一起實現了應用程序的功能。
這意味着我們可以在不重新設計或更新整個應用程序的情況下更新單個微服務，也意味着單個微服務（或多個微服務）發生故障並不會導致整個應用程序癱瘓，一個受到攻擊的微服務也不會導致整個應用程序變脆弱。對於複雜的大型應用程序來說，微服務架構比單體架構（傳統的非微服務架構）具備更高的可管理性。
既然微服務這麼好，爲什麼不都使用微服務架構呢？事實證明，適用於大型系統的架構不一定適用於規模較小的系統，在設計新系統時所使用的設計方式並不一定適合用來維護或更新已有的系統。具體來說，以下這五種場景是不適合採用微服務的。
1. 複雜性不足
Martin Fowler 曾經說過：“……除非你的系統複雜到難以管理，否則不要考慮採用微服務……”換句話說，相比其他因素，複雜性是採用微服務架構最關鍵的考慮因素。
微服務架構需要額外的開銷，比如服務設計、服務通信、服務管理和系統資源的使用。採用微服務架構是有代價的，如果一個應用程序無法充分利用微服務的優勢，那麼採用微服務架構所付出的代價就有點太高了。
2. 小團隊，大工作
試想有一箇中等規模、中等複雜度的應用程序，這個應用程序由一個相對較小的團隊負責開發和維護。如果它是一個單體系統，服務之間的通信可以很直接，可以對一些特定的任務進行優化。對於熟悉代碼的小團隊來說，維護任務就相對容易。可能有時候開發會有點麻煩，但大多數時候是可控的。
如果讓這個小團隊開發和維護同樣的應用程序，但改成了微服務架構，那麼他們的工作量就會顯著增加。即使是做一個很小的改動也需要更多的時間，甚至還可能需要修改微服務編排和管理系統。這可能會給運維和開發人員造成壓力。
3. 小到無法拆分
並不是所有的應用程序都大到足以被拆分成微服務，如果當前規模已經恰到好處了，把它們進一步拆分成微服務不僅不會降低複雜性，反而會讓系統變得更復雜。
4. 與遺留系統共舞
大部分軟件開發人員幾乎每天都要面對遺留代碼。如果你正在維護一個遺留系統，那麼無論它的原始設計多麼隨意，無論它現在變得多麼糟糕，在把它重構成微服務之前，都要認真地思考一下。它正處在生命週期的什麼階段？它是一個任務關鍵型系統嗎（比如包含了一個不可替代的遺留數據庫）？你需要多長時間來替換整個系統？更新或者替換過程需要一個長期詳盡的計劃嗎？
微服務架構在更新或替換遺留系統方面扮演着重要的角色，但整個過程可能很長，一個沒有策略指引的遷移很可能會造成災難性的後果。
5. 緊密集成
有些應用程序要求各個組件和服務之間緊密集成，比如那些需要快速處理實時數據的應用程序。在服務之間添加新層會導致處理速度變慢。如果系統需要快速處理數據流中的數據（例如來自自動駕駛汽車的傳感器數據），那麼延遲可能是災難性的。
嵌入式應用程序通常在響應時間和可用資源方面具有很嚴格的限制，所以它們的後端通常不太適合採用微服務架構。在設計嵌入式應用程序時，從一開始就要考慮如何讓維護變得更簡單以及如何讓資源使用最優化。微服務通常在資源比較充裕的系統中容易發揮作用，可以降低系統的複雜性。
以上就是今天的內容，總之，如果你的應用程序非常大，非常複雜，爲了更好地管理它，可以考慮採用微服務架構，但如果它運行得很好，那就不要盲目追趕這個潮流。