微服務(wù)（Microservices）架構(gòu)是一項(xiàng)在云中部署應(yīng)用和服務(wù)的新技術(shù)，它是一種架構(gòu)風(fēng)格，將應(yīng)用程序拆分為一系列小型的、可單獨(dú)部署的服務(wù)，每個(gè)服務(wù)都運(yùn)行在自己的應(yīng)用程序中，并通過(guò)輕量級(jí)設(shè)備與HTTP型API進(jìn)行溝通。

2014年，Martin Fowler與James Lewis共同提出了微服務(wù)的概念，定義了微服務(wù)是由以單一應(yīng)用程序構(gòu)成的小服務(wù)，自己擁有自己的進(jìn)程與輕量化處理，服務(wù)依業(yè)務(wù)功能設(shè)計(jì)，以全自動(dòng)的方式部署，與其他服務(wù)使用HTTP API通信。同時(shí)服務(wù)會(huì)使用最小規(guī)模的集成管理能力（例如Docker等容器），服務(wù)可以用不同的編程語(yǔ)言與數(shù)據(jù)庫(kù)等組件實(shí)現(xiàn)。

由于云商考慮到微服務(wù)的廣闊市場(chǎng)前景，這些年來(lái)，微服務(wù)在分布式計(jì)算領(lǐng)域熾手可熱，幾乎是云計(jì)算市場(chǎng)的標(biāo)配商品。然而它也存在著一些顯而易見(jiàn)的缺點(diǎn)：

復(fù)雜性是最大的問(wèn)題。與更單一的架構(gòu)相比，微服務(wù)引入了更高級(jí)別的復(fù)雜性。系統(tǒng)被分解為眾多的服務(wù)；架構(gòu)變得更加復(fù)雜，理解不同服務(wù)之間的交互可能具有挑戰(zhàn)性。開(kāi)發(fā)過(guò)程中沒(méi)有免費(fèi)的午餐，每種方法、工具、語(yǔ)言和架構(gòu)都有有其必然的優(yōu)缺點(diǎn)，而缺點(diǎn)往往會(huì)在炒作中被忽視。

分配是另一個(gè)造成缺陷的因素。對(duì)于微服務(wù)而言，服務(wù)之間的通信通常通過(guò)網(wǎng)絡(luò)進(jìn)行，從而導(dǎo)致延遲、網(wǎng)絡(luò)故障和壓力增加。出于這個(gè)原因，開(kāi)發(fā)者必須在部署基于微服務(wù)的應(yīng)用程序后升級(jí)網(wǎng)絡(luò)。然而，它的成本可不便宜。

數(shù)據(jù)管理也比較復(fù)雜。微服務(wù)可能有自己的數(shù)據(jù)庫(kù)或數(shù)據(jù)存儲(chǔ)，這將使各種服務(wù)之間的數(shù)據(jù)一致性變得復(fù)雜。通常需要付出額外的精力和成本來(lái)維護(hù)數(shù)據(jù)完整性，而大多數(shù)開(kāi)發(fā)者在遭遇數(shù)據(jù)損失之前并不了解這一點(diǎn)。的過(guò)程

服務(wù)依賴的過(guò)程可能會(huì)很痛苦。當(dāng)微服務(wù)通過(guò)API進(jìn)行交互時(shí)，一項(xiàng)服務(wù)的更改可能會(huì)對(duì)其他服務(wù)產(chǎn)生影響。這無(wú)疑增加了版本迭代的挑戰(zhàn)和潛在的兼容性問(wèn)題，尤其是在升級(jí)或更改應(yīng)用期間。

最后是資源開(kāi)銷問(wèn)題。對(duì)于大多數(shù)已部署微服務(wù)的應(yīng)用程序來(lái)說(shuō)，運(yùn)行多個(gè)微服務(wù)實(shí)例將比單一結(jié)構(gòu)的應(yīng)用程序消耗更多的資源。這必然會(huì)增加基礎(chǔ)設(shè)施資源投入，如果管理不當(dāng)，很容易陷入云商的“廣告陷阱”而付出更多金錢成本。

我們發(fā)現(xiàn)這些年開(kāi)發(fā)人員和架構(gòu)師對(duì)于微服務(wù)的使用充滿了“過(guò)分”的熱情。盡管在當(dāng)代開(kāi)發(fā)思想的主導(dǎo)下，微服務(wù)作為解耦、削峰的理念之一必不可少，但是我們都應(yīng)該牢記架構(gòu)的目的是什么，以及何時(shí)使用，何時(shí)不應(yīng)該使用。

文/水哥