單體架構(gòu)的痛點(diǎn)

缺點(diǎn)一：項(xiàng)目過于臃腫當(dāng)大大小小的功能模塊都集中在同一項(xiàng)目的時(shí)候，整個項(xiàng)目必然會變得臃腫，讓開發(fā)者難以維護(hù)。

缺點(diǎn)二：資源無法隔離就像剛剛小灰的經(jīng)歷一樣，整個單體系統(tǒng)的各個功能模塊都依賴于同樣的數(shù)據(jù)庫、內(nèi)存等資源，一旦某個功能模塊對資源使用不當(dāng)，整個系統(tǒng)都會被拖垮。

缺點(diǎn)三：無法靈活擴(kuò)展當(dāng)系統(tǒng)的訪問量越來越大的時(shí)候，單體系統(tǒng)固然可以進(jìn)行水平擴(kuò)展，部署在多臺機(jī)器上組成集群：

但是這種擴(kuò)展并非靈活的擴(kuò)展。比如我們現(xiàn)在的性能瓶頸是支付模塊，希望只針對支付模塊做水平擴(kuò)展，這一點(diǎn)在單體系統(tǒng)是做不到的。

什么是微服務(wù)？微服務(wù)（Microservice Architecture）是近幾年流行的一種架構(gòu)思想，關(guān)于它的概念很難一言以蔽之。

究竟什么是微服務(wù)呢？我們在此引用 ThoughtWorks 公司的首席科學(xué)家 Martin Fowler 的一段話：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

谷歌翻譯如下：

簡而言之，微服務(wù)架構(gòu)風(fēng)格是一種將單個應(yīng)用程序作為一套小型服務(wù)開發(fā)的方法，每種應(yīng)用程序都在自己的進(jìn)程中運(yùn)行，并與輕量級機(jī)制（通常是HTTP資源API）進(jìn)行通信。 這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過全自動部署機(jī)制獨(dú)立部署。 這些服務(wù)的集中管理最少，可以用不同的編程語言編寫，并使用不同的數(shù)據(jù)存儲技術(shù)。

說了這么多概念，微服務(wù)有什么樣的具體特點(diǎn)呢？

1.獨(dú)立部署，靈活擴(kuò)展傳統(tǒng)的單體架構(gòu)是以整個系統(tǒng)為單位進(jìn)行部署，而微服務(wù)則是以每一個獨(dú)立組件（例如用戶服務(wù)，商品服務(wù)）為單位進(jìn)行部署。

用一張經(jīng)典的圖來表現(xiàn)，就是下面這個樣子：

圖中左邊是單體架構(gòu)的集群，右邊是微服務(wù)集群。

什么意思呢？比如根據(jù)每個服務(wù)的吞吐量不同，支付服務(wù)需要部署20臺機(jī)器，用戶服務(wù)需要部署30臺機(jī)器，而商品服務(wù)只需要部署10臺機(jī)器。這種靈活部署只有微服務(wù)架構(gòu)才能實(shí)現(xiàn)。

而近幾年流行的Docker，為微服務(wù)架構(gòu)提供了有效的容器。

2.資源的有效隔離微服務(wù)設(shè)計(jì)的原則之一，就是每一個微服務(wù)擁有獨(dú)立的數(shù)據(jù)源，假如微服務(wù)A想要讀寫微服務(wù)B的數(shù)據(jù)庫，只能調(diào)用微服務(wù)B對外暴露的接口來完成。這樣有效避免了服務(wù)之間爭用數(shù)據(jù)庫和緩存資源所帶來的問題。

同時(shí)，由于每一個微服務(wù)實(shí)例在Docker容器上運(yùn)行，實(shí)現(xiàn)了服務(wù)器資源（內(nèi)存、CPU資源等）的有效隔離。

3.團(tuán)隊(duì)組織架構(gòu)的調(diào)整微服務(wù)設(shè)計(jì)的思想也改變了原有的企業(yè)研發(fā)團(tuán)隊(duì)組織架構(gòu)。傳統(tǒng)的研發(fā)組織架構(gòu)是水平架構(gòu)，前端有前端的團(tuán)隊(duì)，后端有后端的團(tuán)隊(duì)，DBA有DBA的團(tuán)隊(duì)，測試有測試的團(tuán)隊(duì)。

而微服務(wù)的設(shè)計(jì)思想對團(tuán)隊(duì)的劃分有著一定的影響，使得團(tuán)隊(duì)組織架構(gòu)的劃分更傾向于垂直架構(gòu)，比如用戶業(yè)務(wù)是一個團(tuán)隊(duì)來負(fù)責(zé)，支付業(yè)務(wù)是一個團(tuán)隊(duì)來負(fù)責(zé)。

當(dāng)然，這種垂直劃分只是一個理想的架構(gòu)，實(shí)際在企業(yè)中并不會把團(tuán)隊(duì)組織架構(gòu)拆分得這么絕對。

微服務(wù)與面向服務(wù)架構(gòu)SOA的區(qū)別

SOA是什么樣子呢？可以是下面這樣的Web Service：

也可以是下面這樣的ESB企業(yè)服務(wù)總線：

總之，SOA架構(gòu)強(qiáng)調(diào)的是異構(gòu)系統(tǒng)之間的通信和解耦合，而微服務(wù)架構(gòu)強(qiáng)調(diào)的是系統(tǒng)按業(yè)務(wù)邊界做細(xì)粒度的拆分和部署

。

微服務(wù)架構(gòu)的不足

單體架構(gòu)的痛點(diǎn)

缺點(diǎn)一：項(xiàng)目過于臃腫當(dāng)大大小小的功能模塊都集中在同一項(xiàng)目的時(shí)候，整個項(xiàng)目必然會變得臃腫，讓開發(fā)者難以維護(hù)。

缺點(diǎn)二：資源無法隔離就像剛剛小灰的經(jīng)歷一樣，整個單體系統(tǒng)的各個功能模塊都依賴于同樣的數(shù)據(jù)庫、內(nèi)存等資源，一旦某個功能模塊對資源使用不當(dāng)，整個系統(tǒng)都會被拖垮。

缺點(diǎn)三：無法靈活擴(kuò)展當(dāng)系統(tǒng)的訪問量越來越大的時(shí)候，單體系統(tǒng)固然可以進(jìn)行水平擴(kuò)展，部署在多臺機(jī)器上組成集群：

但是這種擴(kuò)展并非靈活的擴(kuò)展。比如我們現(xiàn)在的性能瓶頸是支付模塊，希望只針對支付模塊做水平擴(kuò)展，這一點(diǎn)在單體系統(tǒng)是做不到的。

什么是微服務(wù)？微服務(wù)（Microservice Architecture）是近幾年流行的一種架構(gòu)思想，關(guān)于它的概念很難一言以蔽之。

究竟什么是微服務(wù)呢？我們在此引用 ThoughtWorks 公司的首席科學(xué)家 Martin Fowler 的一段話：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

谷歌翻譯如下：

簡而言之，微服務(wù)架構(gòu)風(fēng)格是一種將單個應(yīng)用程序作為一套小型服務(wù)開發(fā)的方法，每種應(yīng)用程序都在自己的進(jìn)程中運(yùn)行，并與輕量級機(jī)制（通常是HTTP資源API）進(jìn)行通信。 這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過全自動部署機(jī)制獨(dú)立部署。 這些服務(wù)的集中管理最少，可以用不同的編程語言編寫，并使用不同的數(shù)據(jù)存儲技術(shù)。

說了這么多概念，微服務(wù)有什么樣的具體特點(diǎn)呢？

1.獨(dú)立部署，靈活擴(kuò)展傳統(tǒng)的單體架構(gòu)是以整個系統(tǒng)為單位進(jìn)行部署，而微服務(wù)則是以每一個獨(dú)立組件（例如用戶服務(wù)，商品服務(wù)）為單位進(jìn)行部署。

用一張經(jīng)典的圖來表現(xiàn)，就是下面這個樣子：

圖中左邊是單體架構(gòu)的集群，右邊是微服務(wù)集群。

什么意思呢？比如根據(jù)每個服務(wù)的吞吐量不同，支付服務(wù)需要部署20臺機(jī)器，用戶服務(wù)需要部署30臺機(jī)器，而商品服務(wù)只需要部署10臺機(jī)器。這種靈活部署只有微服務(wù)架構(gòu)才能實(shí)現(xiàn)。

而近幾年流行的Docker，為微服務(wù)架構(gòu)提供了有效的容器。

2.資源的有效隔離微服務(wù)設(shè)計(jì)的原則之一，就是每一個微服務(wù)擁有獨(dú)立的數(shù)據(jù)源，假如微服務(wù)A想要讀寫微服務(wù)B的數(shù)據(jù)庫，只能調(diào)用微服務(wù)B對外暴露的接口來完成。這樣有效避免了服務(wù)之間爭用數(shù)據(jù)庫和緩存資源所帶來的問題。

同時(shí)，由于每一個微服務(wù)實(shí)例在Docker容器上運(yùn)行，實(shí)現(xiàn)了服務(wù)器資源（內(nèi)存、CPU資源等）的有效隔離。

3.團(tuán)隊(duì)組織架構(gòu)的調(diào)整微服務(wù)設(shè)計(jì)的思想也改變了原有的企業(yè)研發(fā)團(tuán)隊(duì)組織架構(gòu)。傳統(tǒng)的研發(fā)組織架構(gòu)是水平架構(gòu)，前端有前端的團(tuán)隊(duì)，后端有后端的團(tuán)隊(duì)，DBA有DBA的團(tuán)隊(duì)，測試有測試的團(tuán)隊(duì)。

而微服務(wù)的設(shè)計(jì)思想對團(tuán)隊(duì)的劃分有著一定的影響，使得團(tuán)隊(duì)組織架構(gòu)的劃分更傾向于垂直架構(gòu)，比如用戶業(yè)務(wù)是一個團(tuán)隊(duì)來負(fù)責(zé)，支付業(yè)務(wù)是一個團(tuán)隊(duì)來負(fù)責(zé)。

當(dāng)然，這種垂直劃分只是一個理想的架構(gòu)，實(shí)際在企業(yè)中并不會把團(tuán)隊(duì)組織架構(gòu)拆分得這么絕對。

微服務(wù)與面向服務(wù)架構(gòu)SOA的區(qū)別

SOA是什么樣子呢？可以是下面這樣的Web Service：

也可以是下面這樣的ESB企業(yè)服務(wù)總線：

總之，SOA架構(gòu)強(qiáng)調(diào)的是異構(gòu)系統(tǒng)之間的通信和解耦合，而微服務(wù)架構(gòu)強(qiáng)調(diào)的是系統(tǒng)按業(yè)務(wù)邊界做細(xì)粒度的拆分和部署

。

微服務(wù)架構(gòu)的不足

總結(jié)

以上是生活随笔為你收集整理的漫画：什么是微服务？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。