先看看維基百科是如何定義微服務(wù)的。微服務(wù)的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他們定義了微服務(wù)是

這個(gè)理論的定義看著有點(diǎn)暈？沒關(guān)系，接下來我來幫你理解到底什么是微服務(wù)？

單體應(yīng)用

在開聊微服務(wù)之前，先要你介紹一下單體應(yīng)用。如果你不知道單體應(yīng)用的痛，那也不會(huì)深刻理解微服務(wù)的價(jià)值。

早些年，各大互聯(lián)網(wǎng)公司的應(yīng)用技術(shù)棧大致可分為 LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat）兩大流派。無論是 LAMP 還是 MVC，都是為單體應(yīng)用架構(gòu)設(shè)計(jì)的，其優(yōu)點(diǎn)是學(xué)習(xí)成本低，開發(fā)上手快，測試、部署、運(yùn)維也比較方便，甚至一個(gè)人就可以完成一個(gè)網(wǎng)站的開發(fā)與部署。

以 MVC 架構(gòu)為例，業(yè)務(wù)通常是通過部署一個(gè) WAR 包到 Tomcat 中，然后啟動(dòng) Tomcat，監(jiān)聽某個(gè)端口即可對(duì)外提供服務(wù)。早期在業(yè)務(wù)規(guī)模不大、開發(fā)團(tuán)隊(duì)人員規(guī)模較小的時(shí)候，采用單體應(yīng)用架構(gòu)，團(tuán)隊(duì)的開發(fā)和運(yùn)維成本都可控。

然而隨著業(yè)務(wù)規(guī)模的不斷擴(kuò)大，團(tuán)隊(duì)開發(fā)人員的不斷擴(kuò)張，單體應(yīng)用架構(gòu)就會(huì)開始出現(xiàn)問題。我估計(jì)經(jīng)歷過業(yè)務(wù)和團(tuán)隊(duì)快速增長的同學(xué)都會(huì)對(duì)此深有感觸。從我的角度來看，大概會(huì)有以下幾個(gè)方面的問題。

.......

想要解決上面這些問題，服務(wù)化的思想也就應(yīng)運(yùn)而生。

什么是服務(wù)化？

通俗地講，服務(wù)化就是把傳統(tǒng)的單機(jī)應(yīng)用中通過 JAR 包依賴產(chǎn)生的本地方法調(diào)用，改造成通過 RPC 接口產(chǎn)生的遠(yuǎn)程方法調(diào)用。一般在編寫業(yè)務(wù)代碼時(shí)，對(duì)于一些通用的業(yè)務(wù)邏輯，我會(huì)盡力把它抽象并獨(dú)立成為專門的模塊，因?yàn)檫@對(duì)于代碼復(fù)用和業(yè)務(wù)理解都大有裨益。

在過去的項(xiàng)目經(jīng)歷里，我對(duì)此深有體會(huì)。以微博系統(tǒng)為例，微博既包含了內(nèi)容模塊，也包含了消息模塊和用戶模塊等。其中消息模塊依賴內(nèi)容模塊，消息模塊和內(nèi)容模塊又都依賴用戶模塊。當(dāng)這三個(gè)模塊的代碼耦合在一起，應(yīng)用啟動(dòng)時(shí)，需要同時(shí)去加載每個(gè)模塊的代碼并連接對(duì)應(yīng)的資源。一旦任何模塊的代碼出現(xiàn) bug，或者依賴的資源出現(xiàn)問題，整個(gè)單體應(yīng)用都會(huì)受到影響。

為此，首先可以把用戶模塊從單體應(yīng)用中拆分出來，獨(dú)立成一個(gè)服務(wù)部署，以 RPC 接口的形式對(duì)外提供服務(wù)。微博和消息模塊調(diào)用用戶接口，就從進(jìn)程內(nèi)的調(diào)用變成遠(yuǎn)程 RPC 調(diào)用。這樣，用戶模塊就可以獨(dú)立開發(fā)、測試、上線和運(yùn)維，可以交由專門的團(tuán)隊(duì)來做，與主模塊不耦合。進(jìn)一步的可以再把消息模塊也拆分出來作為獨(dú)立的模塊，交由專門的團(tuán)隊(duì)來開發(fā)和維護(hù)。

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

什么是微服務(wù)？

從 2014 年開始，得益于以 Docker 為代表的容器化技術(shù)的成熟以及 DevOps 文化的興起，服務(wù)化的思想進(jìn)一步演化，演變?yōu)榻裉煳覀兯熘奈⒎?wù)。

那么微服務(wù)相比于服務(wù)化又有什么不同呢？

在我看來，可以總結(jié)為以下四點(diǎn)：

繼續(xù)以前面舉的微博系統(tǒng)為例，可以進(jìn)一步對(duì)內(nèi)容模塊的功能進(jìn)行拆分，比如內(nèi)容模塊又包含了 feed 模塊、評(píng)論模塊和個(gè)人頁模塊。通過微服務(wù)化，將這三個(gè)模塊變成三個(gè)獨(dú)立的服務(wù)，每個(gè)服務(wù)依賴各自的資源，并獨(dú)立部署在不同的服務(wù)池中，可以由不同的開發(fā)人員進(jìn)行維護(hù)。當(dāng)評(píng)論服務(wù)需求變更時(shí)，只需要修改評(píng)論業(yè)務(wù)相關(guān)的代碼，并獨(dú)立上線發(fā)布；而 feed 服務(wù)和個(gè)人頁服務(wù)不需要變更，也不會(huì)受到發(fā)布可能帶來的變更影響。

由此可見，微服務(wù)化給服務(wù)的發(fā)布和部署，以及服務(wù)的保障帶來了諸多好處。

總結(jié)

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

總結(jié)來說，微服務(wù)架構(gòu)是將復(fù)雜臃腫的單體應(yīng)用進(jìn)行細(xì)粒度的服務(wù)化拆分，每個(gè)拆分出來的服務(wù)各自獨(dú)立打包部署，并交由小團(tuán)隊(duì)進(jìn)行開發(fā)和運(yùn)維，從而極大地提高了應(yīng)用交付的效率，并被各大互聯(lián)網(wǎng)公司所普遍采用。