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

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

優(yōu)勢

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

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

老實說，這在出現(xiàn)時并不具有革命性。它更像是架構(gòu)最佳實踐的演進(jìn)，始于 20 世紀(jì) 70 年代的結(jié)構(gòu)化開發(fā)，然后是面向?qū)ο蟮拈_發(fā)、基于組件的開發(fā)、服務(wù)的使用和微服務(wù)。每種方法都會對以下方法產(chǎn)生影響；希望我們能一路改進(jìn)。

劣勢

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

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

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

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

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

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

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

現(xiàn)在應(yīng)該怎么辦？

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

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

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

原文標(biāo)題：The downsides of microservices architecture

原文作者： David Linthicum