先看看維基百科是如何定義微服務(wù)的。微服務(wù)的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他們定義了微服務(wù)是
①由單一應(yīng)用程序構(gòu)成的小服務(wù)，這個(gè)理論的定義看著有點(diǎn)暈？沒(méi)關(guān)系，接下來(lái)我來(lái)幫你理解到底什么是微服務(wù)？
單體應(yīng)用
在開(kāi)聊微服務(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）兩大流派。無(wú)論是 LAMP 還是 MVC，都是為單體應(yīng)用架構(gòu)設(shè)計(jì)的，其優(yōu)點(diǎn)是學(xué)習(xí)成本低，開(kāi)發(fā)上手快，測(cè)試、部署、運(yùn)維也比較方便，甚至一個(gè)人就可以完成一個(gè)網(wǎng)站的開(kāi)發(fā)與部署。
以 MVC 架構(gòu)為例，業(yè)務(wù)通常是通過(guò)部署一個(gè) WAR 包到 Tomcat 中，然后啟動(dòng) Tomcat，監(jiān)聽(tīng)某個(gè)端口即可對(duì)外提供服務(wù)。早期在業(yè)務(wù)規(guī)模不大、開(kāi)發(fā)團(tuán)隊(duì)人員規(guī)模較小的時(shí)候，采用單體應(yīng)用架構(gòu)，團(tuán)隊(duì)的開(kāi)發(fā)和運(yùn)維成本都可控。
然而隨著業(yè)務(wù)規(guī)模的不斷擴(kuò)大，團(tuán)隊(duì)開(kāi)發(fā)人員的不斷擴(kuò)張，單體應(yīng)用架構(gòu)就會(huì)開(kāi)始出現(xiàn)問(wèn)題。我估計(jì)經(jīng)歷過(guò)業(yè)務(wù)和團(tuán)隊(duì)快速增長(zhǎng)的同學(xué)都會(huì)對(duì)此深有感觸。從我的角度來(lái)看，大概會(huì)有以下幾個(gè)方面的問(wèn)題。
.......
想要解決上面這些問(wèn)題，服務(wù)化的思想也就應(yīng)運(yùn)而生。
什么是服務(wù)化？
通俗地講，服務(wù)化就是把傳統(tǒng)的單機(jī)應(yīng)用中通過(guò) JAR 包依賴產(chǎn)生的本地方法調(diào)用，改造成通過(guò) RPC 接口產(chǎn)生的遠(yuǎn)程方法調(diào)用。一般在編寫業(yè)務(wù)代碼時(shí)，對(duì)于一些通用的業(yè)務(wù)邏輯，我會(huì)盡力把它抽象并獨(dú)立成為專門的模塊，因?yàn)檫@對(duì)于代碼復(fù)用和業(yè)務(wù)理解都大有裨益。
在過(guò)去的項(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)問(wèn)題，整個(gè)單體應(yīng)用都會(huì)受到影響。
為此，首先可以把用戶模塊從單體應(yīng)用中拆分出來(lái)，獨(dú)立成一個(gè)服務(wù)部署，以 RPC 接口的形式對(duì)外提供服務(wù)。微博和消息模塊調(diào)用用戶接口，就從進(jìn)程內(nèi)的調(diào)用變成遠(yuǎn)程 RPC 調(diào)用。這樣，用戶模塊就可以獨(dú)立開(kāi)發(fā)、測(cè)試、上線和運(yùn)維，可以交由專門的團(tuán)隊(duì)來(lái)做，與主模塊不耦合。進(jìn)一步的可以再把消息模塊也拆分出來(lái)作為獨(dú)立的模塊，交由專門的團(tuán)隊(duì)來(lái)開(kāi)發(fā)和維護(hù)。
可見(jiàn)通過(guò)服務(wù)化，可以解決單體應(yīng)用膨脹、團(tuán)隊(duì)開(kāi)發(fā)耦合度高、協(xié)作效率低下的問(wèn)題。
什么是微服務(wù)？
從 2014 年開(kāi)始，得益于以 Docker 為代表的容器化技術(shù)的成熟以及 DevOps 文化的興起，服務(wù)化的思想進(jìn)一步演化，演變?yōu)榻裉煳覀兯熘奈⒎?wù)。
那么微服務(wù)相比于服務(wù)化又有什么不同呢？
在我看來(lái)，可以總結(jié)為以下四點(diǎn)：
繼續(xù)以前面舉的微博系統(tǒng)為例，可以進(jìn)一步對(duì)內(nèi)容模塊的功能進(jìn)行拆分，比如內(nèi)容模塊又包含了 feed 模塊、評(píng)論模塊和個(gè)人頁(yè)模塊。通過(guò)微服務(wù)化，將這三個(gè)模塊變成三個(gè)獨(dú)立的服務(wù)，每個(gè)服務(wù)依賴各自的資源，并獨(dú)立部署在不同的服務(wù)池中，可以由不同的開(kāi)發(fā)人員進(jìn)行維護(hù)。當(dāng)評(píng)論服務(wù)需求變更時(shí)，只需要修改評(píng)論業(yè)務(wù)相關(guān)的代碼，并獨(dú)立上線發(fā)布；而 feed 服務(wù)和個(gè)人頁(yè)服務(wù)不需要變更，也不會(huì)受到發(fā)布可能帶來(lái)的變更影響。
由此可見(jiàn)，微服務(wù)化給服務(wù)的發(fā)布和部署，以及服務(wù)的保障帶來(lái)了諸多好處。
總結(jié)
今天，我介紹了微服務(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)方向。
總結(jié)來(lái)說(shuō)，微服務(wù)架構(gòu)是將復(fù)雜臃腫的單體應(yīng)用進(jìn)行細(xì)粒度的服務(wù)化拆分，每個(gè)拆分出來(lái)的服務(wù)各自獨(dú)立打包部署，并交由小團(tuán)隊(duì)進(jìn)行開(kāi)發(fā)和運(yùn)維，從而極大地提高了應(yīng)用交付的效率，并被各大互聯(lián)網(wǎng)公司所普遍采用。
聯(lián)系客服
