用于云應用程序開發的微服務架構是一種將軟件應用程序構建為小型（"微型"）、松散耦合服務集合的架構方法。架構中的每個服務都代表一種特定的業務能力或功能，例如向數據庫添加庫存項目或檢查新客戶的信用。它們通常作為獨立的流程運行，通過應用程序接口或輕量級協議與其他服務通信。

微服務源于面向服務的架構和構建更好應用程序的需求。它成為構建全新應用程序最受歡迎的方法也是情有可原。我喜歡使用微服務架構，因為它提供了松散的耦合和隔離。

優勢

服務的設計是松散耦合的。它們可以獨立運行，無需直接依賴其他服務中的內部實施細節。服務允許團隊單獨開發、部署和擴展服務，從而提高敏捷性。由于服務可以獨立運行，因此還能帶來更多的好處，如提高復原能力。

這就說明了獨立性和隔離性的好處，它們與松散耦合直接相關。每個服務都可以獨立開發、測試、部署和擴展。

老實說，這在出現時并不具有革命性。它更像是架構最佳實踐的演進，始于 20 世紀 70 年代的結構化開發，然后是面向對象的開發、基于組件的開發、服務的使用和微服務。每種方法都會對以下方法產生影響；希望我們能一路改進。

劣勢

當然，開發過程中沒有免費的午餐。每一種方法、工具、語言和架構都有其利弊，在進行應用時，開發人員也必須考慮到微服務的缺點對項目的影響。這些缺點有時會因為對微服務的大肆炒作而被忽視。讓我們來探討一下微服務架構的缺點。

最大的問題是復雜性。與單體架構相比，微服務更加復雜。系統被分解成無數個服務；架構變得更加錯綜復雜，理解不同服務之間的交互可能具有挑戰性。

如果考慮到我們還要處理復雜的分布式系統作為部署微服務的平臺，這就變得更加困難。這幾乎是所有企業構建和部署多云的副產品。

分布是另一個應該考慮的不利因素。使用微服務時，服務之間的通信通常通過網絡進行，這會導致延遲、網絡故障和設備壓力增加。正是因為這個原因，我不得不在部署基于微服務的應用程序后升級網絡，但又進一步增加了應用成本。

數據管理也更加復雜。微服務可能擁有自己的數據庫或數據存儲，從而使各種服務之間的數據一致性變得更加復雜。維護數據完整性通常需要付出額外的努力，而企業往往在遭受損失時才明白這一點。這當然是可以解決的，但需要的資源比大多數人理解的要多得多。

服務依賴性可能會為企業帶來麻煩。由于微服務通過應用程序接口（API）進行交互，一個服務的變化可能會對其他服務產生影響。結果是什么？版本挑戰和潛在的兼容性問題，尤其是在升級或服務變更期間。

最后是資源開銷。對于大多數已部署的應用來說，運行多個微服務實例所消耗的資源要多于單個單體應用。這會增加基礎設施成本，尤其是在管理效率不高的情況下。

現在應該怎么辦？

我發現，云計算開發人員和架構師對微服務架構的態度近乎狂熱。當然，微服務架構并不適合所有應用，在許多情況下，微服務架構會成為一種勉為其難的選擇。在對已經遷移到云或正在遷移到云的應用程序進行現代化改造時，它們需要的資源遠遠超出了應有的水平。這就是由微服務的許多缺點造成的。

盡管如此，它們往往是使用的典范架構。但是，在使用之前，您必須充分地權衡利弊，而且必須專注于核心應用需求。遺憾的是，我們并沒有關注很多應該關注的事情，最終導致核心應用需求的不匹配而導致效率低下。

微服務與其他任何方法一樣，只能根據具體情況來考慮，同時還要牢記應用這種架構的目的，什么時候該用，什么時候不該用。

原文標題：The downsides of microservices architecture

原文作者： David Linthicum