我們先看下維基百科和百度百科給出的定義：
維基百科：2014年，Martin Fowler 與 James Lewis 共同提出了微服務(wù)的概念，定義了微服務(wù)是由以單一應(yīng)用程序構(gòu)成的小服務(wù)，自己擁有自己的行程與輕量化處理，服務(wù)依業(yè)務(wù)功能設(shè)計，以全自動的方式部署，與其他服務(wù)使用 HTTP API 通信。同時服務(wù)會使用最小的規(guī)模的集中管理 (例如 Docker) 能力，服務(wù)可以用不同的編程語言與數(shù)據(jù)庫等組件實(shí)現(xiàn)。
百度百科：所謂的微服務(wù)是SOA架構(gòu)下的最終產(chǎn)物，該架構(gòu)的設(shè)計目標(biāo)是為了肢解業(yè)務(wù)，使得服務(wù)能夠獨(dú)立運(yùn)行。
微服務(wù)設(shè)計原則：1、各司其職 2、服務(wù)高可用和可擴(kuò)展性
概念還是比較抽象的，接下來，我將從單體應(yīng)用開始，講解為什么會有微服務(wù)以及什么是微服務(wù)。
一、單體應(yīng)用
在初期，互聯(lián)網(wǎng)公司的應(yīng)用技術(shù)棧大致分為 LAMP(Linux + Apache + MySQL + PHP)和 MVC(Spring + iBatis/Hibernate + Tomcat)兩大流派。兩者都是為單體應(yīng)用架構(gòu)設(shè)計的，其優(yōu)點(diǎn)是學(xué)習(xí)成本低，開發(fā)上手快，測試、部署、運(yùn)維也比較方便。
以 MVC 架構(gòu)為例，業(yè)務(wù)通常是通過部署一個 War 包到 Tomcat 中，然后啟動 Tomcat，監(jiān)聽某個端口即可對外提供服務(wù)。早期在業(yè)務(wù)規(guī)模不大、開發(fā)團(tuán)隊人員規(guī)模較小的時候，采用單體應(yīng)用架構(gòu)，團(tuán)隊的開發(fā)和運(yùn)維成本都可控。
然而隨著業(yè)務(wù)規(guī)模的不斷擴(kuò)大，團(tuán)隊開發(fā)人員的不斷擴(kuò)張，單體應(yīng)用架構(gòu)就會開始出現(xiàn)問題，大概會有以下幾個方面的問題。
部署效率低：當(dāng)單體應(yīng)用的代碼越來越多，依賴的資源越來越多時，應(yīng)用編譯打包、部署測試一次，甚至需要 10 分鐘以上。
團(tuán)隊協(xié)作開發(fā)成本高：當(dāng)團(tuán)隊人員擴(kuò)張，多人修改代碼，然后一起打包部署，測試階段只要有一塊功能有問題，就得重新編譯打包部署，然后重新預(yù)覽測試，所有相關(guān)的開發(fā)人員又都得參與其中，效率低下，開發(fā)成本極高。
系統(tǒng)高可用性差：因?yàn)樗械墓δ荛_發(fā)最后都部署到同一個 War 包里，運(yùn)行在同一個 Tomcat 進(jìn)程之中，一旦某一功能涉及的代碼或者資源有問題，那就會影響整個 WAR 包中部署的功能。
線上發(fā)布變慢：一旦代碼膨脹，服務(wù)啟動的時間就會變長。因此，急需一種方法能夠?qū)?yīng)用的不同模塊的解耦，降低開發(fā)和部署成本。
想要解決上面這些問題，服務(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ù)代碼時，對于通用的業(yè)務(wù)邏輯，把它抽象并獨(dú)立成為專門的模塊，對于代碼復(fù)用和業(yè)務(wù)理解有很大的好處。
以微博系統(tǒng)為例，微博既包含了內(nèi)容模塊，也包含了消息模塊和用戶模塊等。其中消息模塊依賴內(nèi)容模塊，消息模塊和內(nèi)容模塊又都依賴用戶模塊。當(dāng)這三個模塊的代碼耦合在一起，應(yīng)用啟動時，需要同時去加載每個模塊的代碼并連接對應(yīng)的資源。一旦任何模塊的代碼出現(xiàn) bug，或者依賴的資源出現(xiàn)問題，整個單體應(yīng)用都會受到影響。
為此，首先可以把用戶模塊從單體應(yīng)用中拆分出來，獨(dú)立成一個服務(wù)部署，以 RPC 接口的形式對外提供服務(wù)。微博和消息模塊調(diào)用用戶接口，就從進(jìn)程內(nèi)的調(diào)用變成遠(yuǎn)程 RPC 調(diào)用。這樣，用戶模塊就可以獨(dú)立開發(fā)、測試、上線和運(yùn)維，可以交由專門的團(tuán)隊來做，與主模塊不耦合。進(jìn)一步的可以再把消息模塊也拆分出來作為獨(dú)立的模塊，交由專門的團(tuán)隊來開發(fā)和維護(hù)。
可見通過服務(wù)化，可以解決單體應(yīng)用膨脹、團(tuán)隊開發(fā)耦合度高、協(xié)作效率低下的問題。
三、微服務(wù)
從 2014 年開始，容器化技術(shù)的成熟以及 DevOps 文化的興起，服務(wù)化的思想進(jìn)一步演變?yōu)槲⒎?wù)。
微服務(wù)相比于服務(wù)化的不同可總結(jié)為以下四點(diǎn)：
服務(wù)拆分粒度更細(xì)：微服務(wù)可以說是更細(xì)維度的服務(wù)化，小到一個子模塊，只要該模塊依賴的資源與其他模塊都沒有關(guān)系，那么就可以拆分為一個微服務(wù)。
服務(wù)獨(dú)立部署：每個微服務(wù)都嚴(yán)格遵循獨(dú)立打包部署的準(zhǔn)則，互不影響。比如一臺物理機(jī)上可以部署多個 Docker 實(shí)例，每個 Docker 實(shí)例可以部署一個微服務(wù)的代碼。
服務(wù)獨(dú)立維護(hù)：每個微服務(wù)都可以交由一個小團(tuán)隊甚至個人來開發(fā)、測試、發(fā)布和運(yùn)維，并對整個生命周期負(fù)責(zé)。
服務(wù)治理能力要求高：因?yàn)椴鸱譃槲⒎?wù)之后，服務(wù)的數(shù)量變多，因此需要有統(tǒng)一的服務(wù)治理平臺，來對各個服務(wù)進(jìn)行管理。
以微博系統(tǒng)為例，可以進(jìn)一步對內(nèi)容模塊的功能進(jìn)行拆分，比如內(nèi)容模塊又包含了 feed 模塊、評論模塊和個人頁模塊。通過微服務(wù)化，將這三個模塊變成三個獨(dú)立的服務(wù)，每個服務(wù)依賴各自的資源，并獨(dú)立部署在不同的服務(wù)池中，可以由不同的開發(fā)人員進(jìn)行維護(hù)。當(dāng)評論服務(wù)需求變更時，只需要修改評論業(yè)務(wù)相關(guān)的代碼，并獨(dú)立上線發(fā)布;而 feed 服務(wù)和個人頁服務(wù)不需要變更，也不會受到發(fā)布可能帶來的變更影響。
由此可見，微服務(wù)化給服務(wù)的發(fā)布和部署，以及服務(wù)的保障帶來了諸多好處。
四、單體應(yīng)用和微服務(wù)應(yīng)用的區(qū)別
單體式應(yīng)用微服務(wù)應(yīng)用進(jìn)程數(shù)將所有功能放到同一個進(jìn)程中將功能的每個元素放置到分離的多個服務(wù)進(jìn)程中拓展方式通過復(fù)制整個應(yīng)用到多臺服務(wù)器實(shí)現(xiàn)拓展通過將不同的服務(wù)分布于不同的服務(wù)器，并按需復(fù)制服務(wù)的方式實(shí)現(xiàn)拓展快速響應(yīng)變更部分更新，都需要重新部署整個應(yīng)用部署和升級都是獨(dú)立的，有助于大大提高系統(tǒng)變更的敏捷性團(tuán)隊結(jié)構(gòu)團(tuán)隊結(jié)構(gòu)呈現(xiàn)垂直化，每個團(tuán)隊專門負(fù)責(zé)專門的一塊團(tuán)隊結(jié)構(gòu)呈現(xiàn)扁平化，每個團(tuán)隊服務(wù)一整個業(yè)務(wù)能力可用性一個服務(wù)的不穩(wěn)定可能導(dǎo)致整個應(yīng)用出現(xiàn)問題一個服務(wù)不穩(wěn)定，影響范圍比較小創(chuàng)新性很難引入新的技術(shù)和框架，所有功能都使用的同一種框架每個微服務(wù)可以使用不同的語言和框架，引入新技術(shù)方便
五、總結(jié)
由單體應(yīng)用進(jìn)化到服務(wù)化拆分部署，隨著移動互聯(lián)網(wǎng)規(guī)模的不斷擴(kuò)大，敏捷開發(fā)、持續(xù)交付、DevOps 理論的發(fā)展和實(shí)踐，以及容器化技術(shù)的成熟，微服務(wù)架構(gòu)開始流行。
微服務(wù)的核心在于服務(wù)治理，微服務(wù)架構(gòu)是將復(fù)雜臃腫的單體應(yīng)用進(jìn)行細(xì)粒度的服務(wù)化拆分，每個拆分出來的服務(wù)各自獨(dú)立打包部署，并交由小團(tuán)隊進(jìn)行開發(fā)和運(yùn)維，從而極大地提高了應(yīng)用交付的效率。
【責(zé)任編輯：武曉燕 TEL：（010）68476606】