微信公眾號(hào)：一個(gè)優(yōu)秀的廢人
如有問(wèn)題或建議，請(qǐng)后臺(tái)留言，我會(huì)盡力解決你的問(wèn)題。

微服務(wù)

前言

最近公司某個(gè)項(xiàng)目的架構(gòu)越來(lái)越龐大，維護(hù)起來(lái)非常難受。我主動(dòng)想領(lǐng)導(dǎo)提出要把這個(gè)項(xiàng)目重構(gòu)在工作中需要把原來(lái)的項(xiàng)目重構(gòu)成微服務(wù)架構(gòu)，因此學(xué)習(xí)微服務(wù)相關(guān)知識(shí)，在這里記錄下來(lái)，權(quán)當(dāng)筆記的同時(shí)也希望能對(duì)你有啟發(fā)。今天就來(lái)聊聊什么是微服務(wù)？

單體應(yīng)用

在聊微服務(wù)之前，我先給你們梳理下什么是單體應(yīng)用。如果你不知道單體應(yīng)用的痛，那也不會(huì)深刻理解微服務(wù)的價(jià)值。

單體應(yīng)用

上圖為我司某項(xiàng)目架構(gòu)，包含了四個(gè)模塊?？梢钥闯鑫宜敬隧?xiàng)目的架構(gòu)完完全全屬于傳統(tǒng)的 MVC 架構(gòu)，所有的子系統(tǒng)都集成在一個(gè)很繁雜的 JVM 進(jìn)程中。

優(yōu)點(diǎn)

這種單體架構(gòu)的優(yōu)點(diǎn)在于方便管理，所有代碼在同一項(xiàng)目中，但是當(dāng)需求越來(lái)越多，項(xiàng)目規(guī)模越來(lái)越大，其壞處也很明顯。

缺點(diǎn)

1. 項(xiàng)目過(guò)于臃腫，部署效率低下

當(dāng)大大小小的功能模塊都集中在同一項(xiàng)目的時(shí)候，整個(gè)項(xiàng)目必然會(huì)變得臃腫，讓開(kāi)發(fā)者難以維護(hù)。單體應(yīng)用的代碼越來(lái)越多，依賴(lài)的資源越來(lái)越多時(shí)，應(yīng)用編譯打包、部署測(cè)試一次非常耗時(shí)。

2. 系統(tǒng)高可用性差，資源無(wú)法隔離

整個(gè)單體系統(tǒng)的各個(gè)功能模塊都依賴(lài)于同樣的數(shù)據(jù)庫(kù)、內(nèi)存等資源，一旦某個(gè)功能模塊對(duì)資源使用不當(dāng)，整個(gè)系統(tǒng)都會(huì)被拖垮。

3. 開(kāi)發(fā)成本高

早期在團(tuán)隊(duì)開(kāi)發(fā)人員只有兩三個(gè)人的時(shí)候，協(xié)作修改代碼，打包部署，更新發(fā)布這完全可以控制。但是團(tuán)隊(duì)一旦擴(kuò)張，還是按照早期的方法去開(kāi)發(fā)，那如果測(cè)試階段只要有一塊功能有問(wèn)題，就得重新編譯打包部署。所有的開(kāi)發(fā)人員又都得參與其中，效率低下，開(kāi)發(fā)成本極高。

4. 無(wú)法靈活拓展

當(dāng)系統(tǒng)的訪(fǎng)問(wèn)量越來(lái)越大的時(shí)候，單體系統(tǒng)固然可以進(jìn)行水平擴(kuò)展，部署在多臺(tái)機(jī)器上組成集群：

單體應(yīng)用集群

但是這種擴(kuò)展并非靈活的擴(kuò)展。比如我們現(xiàn)在的性能瓶頸是支付模塊，希望只針對(duì)支付模塊做水平擴(kuò)展，這一點(diǎn)在單體系統(tǒng)是做不到的。因此，急需一種方法將應(yīng)用的不同模塊進(jìn)行解耦，從而降低開(kāi)發(fā)和部署成本。

要解決上面單體應(yīng)用的問(wèn)題，就必須引入服務(wù)化的概念。

什么是服務(wù)化？

用通俗的語(yǔ)言來(lái)說(shuō)，服務(wù)化就是把傳統(tǒng)單體應(yīng)用中通過(guò) JAR 包依賴(lài)產(chǎn)生的本地方法調(diào)用，改造成 RPC 接口產(chǎn)生的遠(yuǎn)程方法調(diào)用。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過(guò)全自動(dòng)部署機(jī)制獨(dú)立部署。 這些服務(wù)的集中管理最少，可以用不同的編程語(yǔ)言編寫(xiě)，并使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。

以我司項(xiàng)目為例，這個(gè)項(xiàng)目包含的四個(gè)模塊都是相互依賴(lài)的，當(dāng)這些模塊的代碼耦合到一起時(shí)，需要去加載每個(gè)模塊的代碼以及連接資源，任何一個(gè)出了問(wèn)題，整個(gè)應(yīng)用都會(huì)受到影響。

為此，可以把耦合度較高的模塊，獨(dú)立數(shù)據(jù)源，獨(dú)立成一個(gè)服務(wù)部署，以 RPC 接口的形式對(duì)外提供服務(wù)。例如訂單模塊和用戶(hù)模塊：

服務(wù)化

可見(jiàn)通過(guò)服務(wù)化，可以解決單體應(yīng)用膨脹、團(tuán)隊(duì)開(kāi)發(fā)耦合度高、協(xié)作效率底下的問(wèn)題。

什么是微服務(wù)？

簡(jiǎn)而言之，微服務(wù)架構(gòu)風(fēng)格是一種將單個(gè)應(yīng)用程序作為一套小型服務(wù)開(kāi)發(fā)的方法，每種應(yīng)用程序都在自己的進(jìn)程中運(yùn)行，并與輕量級(jí)機(jī)制（通常是HTTP資源API）進(jìn)行通信。得益于以 Docker 為代表的容器化技術(shù)的成熟以及 DevOps 文化的的興起，服務(wù)化的思想進(jìn)一步演化，演變成我們今天所熟知的微服務(wù)。

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

1. 服務(wù)拆分粒度更細(xì)

微服務(wù)可以說(shuō)是更細(xì)維度的服務(wù)化，小到一個(gè)子模塊，只要該模塊依賴(lài)的資源與其他模塊都沒(méi)有關(guān)系，那么就可以拆分為一個(gè)微服務(wù)。

2. 服務(wù)獨(dú)立部署

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

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

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

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

3. 服務(wù)獨(dú)立維護(hù)，分工明確

每個(gè)微服務(wù)都可以交由一個(gè)小團(tuán)隊(duì)進(jìn)行開(kāi)發(fā)，測(cè)試維護(hù)部署，并對(duì)整個(gè)生命周期負(fù)責(zé)。比如在單體應(yīng)用時(shí)期，我們的研發(fā)團(tuán)隊(duì)是如下圖這樣傳統(tǒng)的水平架構(gòu)：

水平團(tuán)隊(duì)組織架構(gòu)

而微服務(wù)時(shí)期，我們可以根據(jù)其思想把團(tuán)隊(duì)劃分成垂直組織架構(gòu)：

垂直團(tuán)隊(duì)組織架構(gòu)

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

后語(yǔ)

文章介紹了微服務(wù)的發(fā)展由來(lái),它是由單體應(yīng)用進(jìn)化到服務(wù)化拆分部署,后期隨著移動(dòng)互聯(lián)網(wǎng)規(guī)模的不斷擴(kuò)大,敏捷開(kāi)發(fā)、持續(xù)交付、DevOps 理論的發(fā)展和實(shí)踐,以及基于 Docker 容器化技術(shù)的成熟,微服務(wù)架構(gòu)開(kāi)始流行,逐漸成為應(yīng)用架構(gòu)的未來(lái)演進(jìn)方向。

以上就是我對(duì)微服務(wù)的理解，希望對(duì)你們有幫助。最后，對(duì) Python 、Java 感興趣請(qǐng)長(zhǎng)按二維碼關(guān)注一波，我會(huì)努力帶給你們價(jià)值，如果覺(jué)得本文對(duì)你哪怕有一丁點(diǎn)幫助，請(qǐng)幫忙點(diǎn)個(gè)贊。

一個(gè)優(yōu)秀的廢人