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

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

優(yōu)勢

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

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

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

劣勢

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

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

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

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

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

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

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

現在應該怎么辦？

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

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

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

原文標題：The downsides of microservices architecture

原文作者： David Linthicum