微服務(wù)架構(gòu)有什么優(yōu)勢(shì)？

就目前來看微服務(wù)并沒有一個(gè)嚴(yán)格的定義,每一個(gè)人對(duì)微服務(wù)的理解都是不一樣的. Martin Fowler 在它的博客中是這樣表述微服務(wù)的

微服務(wù)架構(gòu)風(fēng)格是一種將一個(gè)單一應(yīng)用程序開發(fā)為一組小型服務(wù)的方法,每一個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中，服務(wù)間通信采用的輕量級(jí)通信機(jī)制(通常用 HTTP 資源 API)。 這些服務(wù)圍繞業(yè)務(wù)能力構(gòu)建并且可通過全自動(dòng)部署機(jī)制獨(dú)立部署。這些服務(wù)公用一個(gè)最小型的集中式的管理,服務(wù)可用不同的語言開發(fā)，使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)， 微服務(wù)架構(gòu)如下圖所示：

微服務(wù)的優(yōu)點(diǎn)

·易于開發(fā)和維護(hù): 一個(gè)微服務(wù)只會(huì)關(guān)注一個(gè)特定的業(yè)務(wù)功能，所以它業(yè)務(wù)清晰、代碼量少。開發(fā)和維護(hù)單個(gè)微服務(wù)相當(dāng)簡(jiǎn)單。而整個(gè)應(yīng)用是若干個(gè)微服務(wù)構(gòu)建而成的，所以整個(gè)應(yīng)用也被維持在一個(gè)可控狀態(tài)。

·單個(gè)微服務(wù)啟動(dòng)較快: 單個(gè)微服務(wù)代碼量較少，所以啟動(dòng)會(huì)比較快。

·局部修改容易部署: 單個(gè)應(yīng)用只要有修改，就得重新部署整個(gè)應(yīng)用，微服務(wù)解決了這樣的問題。一般來說，對(duì)某個(gè)微服務(wù)進(jìn)行修改，只需要重新部署這個(gè)服務(wù)即可。

·技術(shù)棧不受限: 在微服務(wù)架構(gòu)中，可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)，合理選擇技術(shù)棧。例如某些服務(wù)可以使用關(guān)系型數(shù)據(jù)庫(kù) Mysql,有些服務(wù)可以使用非關(guān)系型數(shù)據(jù)庫(kù)如 redis;甚至可根據(jù)需求，部分微服務(wù)使用 Java 開發(fā)，部分微服務(wù)使用 Node.js 開發(fā)。按需收縮: 可根據(jù)需求，實(shí)現(xiàn)細(xì)粒度的擴(kuò)展。例如，系統(tǒng)中的某個(gè)微服務(wù)遇到了瓶頸，可以結(jié)合這個(gè)微服務(wù)的業(yè)務(wù)特點(diǎn)，增加內(nèi)存、升級(jí) CPU 或者增加節(jié)點(diǎn)。

微服務(wù)的缺點(diǎn)

·運(yùn)維要求較高: 更多的服務(wù)意味著更多的運(yùn)維投入。在單體架構(gòu)中，只需要保證一個(gè)應(yīng)用的正常運(yùn)行。而在微服務(wù)中，需要保證幾十甚至幾百個(gè)服務(wù)正常運(yùn)行與協(xié)作，這給運(yùn)維帶來了很大的挑戰(zhàn)。

·分布式固有的復(fù)雜性: 使用微服務(wù)構(gòu)建的是分布式系統(tǒng)。對(duì)于一個(gè)分布式系統(tǒng)，系統(tǒng)容錯(cuò)、網(wǎng)絡(luò)延遲等都會(huì)帶來巨大的挑戰(zhàn)。

·接口調(diào)整成本高: 微服務(wù)之間通過接口進(jìn)行通信。如果修改某一個(gè)微服務(wù) API，可能所有使用該接口的微服務(wù)都需要調(diào)整。

猜你喜歡：

java中級(jí)程序員學(xué)習(xí)線路圖

SpringBoot整合NoSQL 數(shù)據(jù)庫(kù)(Redis)實(shí)現(xiàn)緩存