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

微服務(wù)源于面向服務(wù)的架構(gòu)和構(gòu)建更好應(yīng)用程序的需求。它成為構(gòu)建全新應(yīng)用程序最受歡迎的方法也是情有可原。我喜歡使用微服務(wù)架構(gòu)，因?yàn)樗峁┝怂缮⒌鸟詈虾透綦x。

優(yōu)勢(shì)

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

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

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

劣勢(shì)

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

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

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

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

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

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

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

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

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

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

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