圖1: Martin Fowler微服務(wù)VS 單體服務(wù)
? 相比單體服務(wù)，微服務(wù)的特點(diǎn)
一組小服務(wù)
服務(wù)粒度要小,，每個(gè)服務(wù)是針對(duì)一個(gè)單一職責(zé)的業(yè)務(wù)能力的封裝,，專注做好一件事情。但是又不能太小,，否則易發(fā)生“服務(wù)爆炸”,。通常在工程實(shí)踐中,，如果一個(gè)功能被兩個(gè)或兩個(gè)以上的服務(wù)調(diào)用，它就可以被封裝為服務(wù),。
獨(dú)立的進(jìn)程
每個(gè)服務(wù)能夠獨(dú)立部署并運(yùn)行在一個(gè)進(jìn)程內(nèi),。這種運(yùn)行和部署方式能夠賦予系統(tǒng)靈活的代碼組織方式和發(fā)布節(jié)奏，使得快速交付和應(yīng)對(duì)變化成為可能,。
輕量級(jí)的通信
使用REST/RPC,，拋棄重量級(jí)的SOAP。
獨(dú)立開發(fā)和演化
技術(shù)選型靈活,，不受遺留系統(tǒng)技術(shù)約束,。合適的業(yè)務(wù)問題選擇合適的技術(shù)可以獨(dú)立演化。服務(wù)與服務(wù)之間采取與語言無關(guān)的API進(jìn)行集成,。相對(duì)單體架構(gòu),，微服務(wù)架構(gòu)是更面向業(yè)務(wù)創(chuàng)新的一種架構(gòu)模式。
? 微服務(wù)的優(yōu)點(diǎn)
每個(gè)微服務(wù)都很小,，這樣能聚焦一個(gè)指定的業(yè)務(wù)功能或業(yè)務(wù)需求,。
微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開發(fā)，這個(gè)小團(tuán)隊(duì)可以是2到5人的開發(fā)人員組成,。
微服務(wù)是松耦合的,，是有功能意義的服務(wù)，無論是在開發(fā)階段或部署階段都是獨(dú)立的,。
微服務(wù)能使用不同的語言開發(fā),。
微服務(wù)允許容易且靈活的方式集成自動(dòng)部署，通過持續(xù)集成工具,，如Jenkins, bamboo,。
微服務(wù)易于被一個(gè)開發(fā)人員理解，修改和維護(hù),，這樣小團(tuán)隊(duì)能夠更關(guān)注自己的工作成果,。無需通過合作才能體現(xiàn)價(jià)值。
微服務(wù)允許你利用融合最新技術(shù),。
微服務(wù)能夠即時(shí)被要求擴(kuò)展,。
微服務(wù)能部署中低端配置的服務(wù)器上。
易于和第三方集成,。
每個(gè)微服務(wù)都有自己的存儲(chǔ)能力,，可以有自己的數(shù)據(jù)庫(kù)。也可以有統(tǒng)一數(shù)據(jù)庫(kù),。
? 微服務(wù)的缺點(diǎn)
運(yùn)維開銷及成本增加：?jiǎn)误w服務(wù)可能只需部署至一小片應(yīng)用服務(wù)區(qū)集群,，而微服務(wù)架構(gòu)可能變成需要構(gòu)建/測(cè)試/部署/運(yùn)行數(shù)十個(gè)獨(dú)立的服務(wù)，并可能需要支持多種語言和環(huán)境,。
隱式接口及接口匹配問題：把系統(tǒng)分為多個(gè)協(xié)作組件后會(huì)產(chǎn)生新的接口,，這意味著簡(jiǎn)單的交叉變化可能需要改變?cè)S多組件,，并需協(xié)調(diào)一起發(fā)布。
分布式系統(tǒng)的復(fù)雜性：作為一種分布式系統(tǒng),，微服務(wù)引入了復(fù)雜性和其他若干問題,，例如網(wǎng)絡(luò)延遲、容錯(cuò)性,、消息序列化、不可靠的網(wǎng)絡(luò),、異步機(jī)制,、版本化、差異化的工作負(fù)載等,，開發(fā)人員需要考慮以上的分布式系統(tǒng)問題,。
異步機(jī)制：微服務(wù)往往使用異步編程、消息與并行機(jī)制,，如果應(yīng)用存在跨微服務(wù)的事務(wù)性處理,，其實(shí)現(xiàn)機(jī)制會(huì)變得復(fù)雜化。
可測(cè)性的挑戰(zhàn)：在動(dòng)態(tài)環(huán)境下服務(wù)間的交互會(huì)產(chǎn)生非常微妙的行為,，難以可視化及全面測(cè)試,。
微服務(wù)架構(gòu)
幸運(yùn)的是我們從零開始構(gòu)建微服務(wù)。
目前比較好的微服務(wù)框架,，如spring cloud,、dubbo等，已經(jīng)提供了完整的微服務(wù)生態(tài)鏈,。
圖2: 微服務(wù)框架
在上圖中,，我們將微服務(wù)框架的能力分為2類，第一類是基礎(chǔ)能力,，這部分能力并不是微服務(wù)特有的,，而是很多系統(tǒng)都必需的一些基礎(chǔ)能力，例如：
第二類是微服務(wù)框架的核心能力,，主要解決微服務(wù)架構(gòu)中的特有問題,，例如：
服務(wù)注冊(cè)與發(fā)現(xiàn)
在微服務(wù)架構(gòu)中，一般每一個(gè)服務(wù)都有多個(gè)拷貝來做負(fù)載均衡,。一個(gè)服務(wù)隨時(shí)可能下線,，也可能應(yīng)對(duì)臨時(shí)訪問壓力增加新的服務(wù)節(jié)點(diǎn)。那么,，服務(wù)之間如何相互感知,？服務(wù)如何管理？這就是服務(wù)發(fā)現(xiàn)的問題了,。
一般有兩類做法,，也各有優(yōu)缺點(diǎn),。基本都是通過zookeeper等類似技術(shù)做服務(wù)注冊(cè)信息的分布式管理,。當(dāng)服務(wù)上線時(shí),，服務(wù)提供者將自己的服務(wù)信息注冊(cè)到ZK（或類似框架），并通過心跳維持長(zhǎng)鏈接,，實(shí)時(shí)更新鏈接信息,。服務(wù)調(diào)用者通過ZK尋址，根據(jù)可定制算法,，找到一個(gè)服務(wù),，還可以將服務(wù)信息緩存在本地以提高性能。當(dāng)服務(wù)下線時(shí),，ZK會(huì)發(fā)通知給服務(wù)客戶端,。
圖3: 服務(wù)注冊(cè)與服務(wù)調(diào)用
配置集成
目前大部分公司都是把配置寫到配置文件中，遇到需要修改配置的時(shí)候,，成本會(huì)很高,。并且沒有修改配置的記錄，出了問題很難溯源,。
微服務(wù)架構(gòu)中,，使用配置中心統(tǒng)一管理配置參數(shù)。實(shí)現(xiàn)方式有兩種,，一種是push,，一種是pull。下圖所示為某公司配置中心架構(gòu)圖:
圖4 ：配置中心
調(diào)用鏈埋點(diǎn)
使用埋點(diǎn)技術(shù)追蹤微服務(wù)的調(diào)用鏈,，其理論基礎(chǔ)來源于Google公司發(fā)表的論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》,。目前比較流行的調(diào)用鏈監(jiān)控框架有zikpin等。
限流熔斷
假設(shè)服務(wù)A依賴于服務(wù)B和服務(wù)C,，而服務(wù)B和服務(wù)C有可能繼續(xù)依賴于其他服務(wù),，這樣一條調(diào)用鏈上，如果某個(gè)服務(wù)不可用或者延遲較高,，則會(huì)導(dǎo)致調(diào)用服務(wù)A的請(qǐng)求被堵住,，占用系統(tǒng)的CPU、IO等資源,。當(dāng)該類請(qǐng)求越來越多,，占用的系統(tǒng)資源越來越多，會(huì)導(dǎo)致系統(tǒng)瓶頸出現(xiàn),，造成其他的請(qǐng)求也不可用,。最終導(dǎo)致業(yè)務(wù)系統(tǒng)崩潰。
一般情況下，對(duì)于服務(wù)依賴的保護(hù)主要有兩種方式：限流熔斷與線程隔離,。目前比較流行的熔斷框架是Hystrix,。
下圖中，服務(wù)A和服務(wù)B都依賴于服務(wù)C2和C3,，服務(wù)A另外依賴于服務(wù)C1,，當(dāng)服務(wù)C1不可用或者延遲較高時(shí)，啟動(dòng)熔斷機(jī)制,，釋放占用的線程資源,，保證不影響服務(wù)B的正常功能。
圖5：熔斷與隔離
容器技術(shù)有時(shí)會(huì)被稱為輕量化虛擬技術(shù),。但不同于基于Hypervisor的傳統(tǒng)虛擬化技術(shù),容器技術(shù)并不會(huì)虛擬硬件,。容器本身和容器內(nèi)的進(jìn)程都是運(yùn)行在宿主Linux 系統(tǒng)的內(nèi)核之 上。但與直接運(yùn)行的進(jìn)程不同,運(yùn)行在容器內(nèi)的進(jìn)程會(huì)被隔離和約束,。從而以直接運(yùn)行的高效實(shí)現(xiàn)了虛擬技術(shù)的大部分效果,。
圖6: 容器與傳統(tǒng)虛擬化
Docker 的出現(xiàn)并非創(chuàng)造了一個(gè)新的容器技術(shù),而是在LXC (LinuX Container),、cgroups,、namespaces 技術(shù)之上所構(gòu)建的一種技術(shù)。
Docker 簡(jiǎn)化了容器的運(yùn)行:它通過一個(gè)簡(jiǎn)單的命令就能夠運(yùn)行起一個(gè)容器,。
Docker 簡(jiǎn)化了容器鏡像的構(gòu)建和分發(fā):提供了Dockerfile和docker commit兩種方式構(gòu)建鏡像,并且提供了Docker image registry機(jī)制以保存和分發(fā)鏡像,。
Docker主要由Docker Hub和Docker引擎組成。前者是Docker官方提供的容器鏡像倉(cāng)庫(kù);后者運(yùn)行在宿主機(jī)上,可分為服務(wù)器端和客戶端兩部分,。服務(wù)器端負(fù)責(zé)構(gòu)建,、運(yùn)行和分發(fā)Docker容器等重要工作,客戶端負(fù)責(zé)接收用戶的命令和服務(wù)程序進(jìn)行通信。
圖7: Docker的組成
Docker使用了如下幾個(gè)重要技術(shù),，實(shí)現(xiàn)了不同層次的隔離：
namespaces
Linux容器通過Kernel的namespaces 技術(shù),為一個(gè)或一組進(jìn)程創(chuàng)建獨(dú)立的pid,、net 等namespaces,從而與其它進(jìn)程相互隔離。
cgroups
namespaces對(duì)進(jìn)程分組以實(shí)現(xiàn)資源隔離,但這隔離還是不夠的,。一個(gè)進(jìn)程可以通過占用過度的硬件資源的方式去影響另一個(gè)分組中的進(jìn)程,。所以,要想實(shí)現(xiàn)完善的資源隔離,不僅要對(duì)資源分組,還要能對(duì)這一組內(nèi)的進(jìn)程所使用的資源進(jìn)行約束。cgroups可限制進(jìn)程對(duì)CPU,、內(nèi)存,、塊存儲(chǔ)和網(wǎng)絡(luò)的使用。
Docker的出現(xiàn)帶動(dòng)了一些列技術(shù)的發(fā)展,形成了一個(gè)龐大的生態(tài)圈,。這個(gè)生態(tài)圈中的產(chǎn)品可大致分為如下幾類：
容器編排管理
以Google Kubernets和Apache Mesos為代表,。主要解決基于容器組成分布式集群應(yīng)用的管理工作，例如對(duì)容器的運(yùn)行狀態(tài)的監(jiān)控,、容器自動(dòng)化的故障恢復(fù),、基于容器的應(yīng)用 的擴(kuò)容和縮容、服務(wù)發(fā)現(xiàn)。
基于容器的操作系統(tǒng)
以CoreOS和Redhat Atomic為代表,。它們拋棄了Linux上面?zhèn)鹘y(tǒng)的包管理機(jī)制,而使用Docker作為應(yīng)用的運(yùn)行平臺(tái),。同時(shí)精簡(jiǎn)系統(tǒng)。CoreOS還引入了Ectd,、Fleet等組件 以更好地支持分布式系統(tǒng),。
網(wǎng)絡(luò)
如何管理大量的Docker容器所使用的網(wǎng)絡(luò)，便成為新的挑戰(zhàn),。在這個(gè)領(lǐng)域主要有Pipework,、Weave和Flannel等技術(shù)。
配置管理
像Puppet,、Ansible這樣的配置管理工具已經(jīng)升級(jí)了對(duì)Docker的支持,。
微服務(wù)區(qū)別于單體架構(gòu)的地方就在于“分而治之”，即通過切分服務(wù)以明確模塊或者功能邊界,。
然而,，僅有“分”是不行的，軟件系統(tǒng)是一個(gè)整體,，很多功能來自若干服務(wù)模塊的配合,，因此必然要有“合”的手段，這對(duì)矛盾會(huì)體現(xiàn)在多個(gè)方面,。
應(yīng)用開發(fā)
微服務(wù)很好地支持了語言技術(shù)棧的多元化,，它通過切分系統(tǒng)的方式，為不同功能模塊劃定了清晰的邊界,，邊界之間的通信方式很容易做到獨(dú)立于某種技術(shù)棧,，因此也就為納入其它技術(shù)帶來了空間。
但是不同技術(shù)棧的微服務(wù)之間,，除了需要考慮通信機(jī)制,，還要確保這些技術(shù)能以較低成本結(jié)合成一個(gè)系統(tǒng)。最終在線上,，它們應(yīng)當(dāng)成為一個(gè)整體,。
Docker將所有應(yīng)用都標(biāo)準(zhǔn)化為可管理、可測(cè)試,、易遷移的鏡像/容器,，因此為不同技術(shù)棧提供了整合管理的途徑。在這種情況下,，開發(fā)人員可以自由選擇或者保持自己的常用工具,，不必因?yàn)槲⒎?wù)的分裂產(chǎn)生過高的學(xué)習(xí)成本。
組織結(jié)構(gòu)
說到團(tuán)隊(duì)和組織,，不能繞開的一個(gè)話題就是“康威定律”(Conway’s law)：
軟件系統(tǒng)的結(jié)構(gòu)受制于其生產(chǎn)者組織的溝通結(jié)構(gòu),。
從這個(gè)角度看,，微服務(wù)的拆分會(huì)對(duì)團(tuán)隊(duì)擴(kuò)張帶來幫助，這不難理解,，因?yàn)橄到y(tǒng)拆分為若干微服務(wù)會(huì)促進(jìn)這些微服務(wù)之間的邊界更清晰,，我們知道，邊界清晰等于在邊界之間協(xié)作信息量少,，如果按照微服務(wù)拆分團(tuán)隊(duì),，團(tuán)隊(duì)之間的協(xié)作成本將是比較低的。
?然而,，“邊界之間協(xié)作信息少”是有代價(jià)的,。這代價(jià)就是團(tuán)隊(duì)的每個(gè)人對(duì)系統(tǒng)失去了整體視角和掌控能力，在這一點(diǎn)上,，單體架構(gòu)顯然要好很多——每個(gè)開發(fā)者的開發(fā)環(huán)境都有完整的系統(tǒng)構(gòu)建,，所以很容易就可以獲得對(duì)系統(tǒng)的整體印象和理解。這是微服務(wù)的短板,，其核心在于構(gòu)建成本,，由于微服務(wù)來自不同團(tuán)隊(duì)和部門，因此如何搭建它就成為一個(gè)謎,，同時(shí)由于不能低成本的獲得一個(gè)完整的系統(tǒng),，系統(tǒng)整體的知識(shí)也就容易被開發(fā)者忽略，最終導(dǎo)致整體視角缺失,。
對(duì)于大多數(shù)外部服務(wù),，我們需要考慮建立自動(dòng)化系統(tǒng)構(gòu)建和測(cè)試的方法,，這是微服務(wù)架構(gòu)帶來的研發(fā)挑戰(zhàn),。
如果首先對(duì)各系統(tǒng)進(jìn)行Docker化，就很容易通過統(tǒng)一的docker build,，建立一致性的構(gòu)建服務(wù),，再結(jié)合compose等基礎(chǔ)設(shè)施處理服務(wù)依賴，這些工作最終就可以產(chǎn)生一個(gè)平臺(tái),，（自動(dòng)化的）將被微服務(wù)打散的整個(gè)系統(tǒng)再構(gòu)建出來（由于使用了微服務(wù),，構(gòu)建速度在理論上就可以是并行的，因此甚至?xí)葐误w架構(gòu)更敏捷）,。?
系統(tǒng)變更碎片化
理論上,，由于進(jìn)行了分解，微服務(wù)架構(gòu)的系統(tǒng)應(yīng)該更加有利于系統(tǒng)的“改良”,，不必動(dòng)輒就傷筋動(dòng)骨甚至另起爐灶,。但是實(shí)際上并不一定會(huì)這樣。例如服務(wù)接口的升級(jí),，所有依賴該服務(wù)的其他服務(wù)也不得不升級(jí),，我們都知道，部分升級(jí)有時(shí)候還不如整體升級(jí)。
如果使用docker,，由于每個(gè)服務(wù)打包可以封裝為一個(gè)docker鏡像,，每個(gè)運(yùn)行時(shí)的服務(wù)都表現(xiàn)為一個(gè)獨(dú)立容器，我們之前建立的容器依賴就可以很容易的對(duì)應(yīng)到服務(wù)依賴上,，基于這種統(tǒng)一性,，系統(tǒng)升級(jí)就很容易配合一些自動(dòng)化工具實(shí)現(xiàn)“整體升級(jí)”（甚至還可以“整體降級(jí)”）。
面對(duì)膨脹的未來,，微服務(wù)走了一條拆解之路,，但要想完整的實(shí)現(xiàn)你的業(yè)務(wù)，還要能夠在某些情況下自由融合,、彼此協(xié)作,，Docker開啟的正是這樣一個(gè)方便之門。
無論是協(xié)同不同語言技術(shù)棧,，降低運(yùn)維的成本,，還是支持分布式系統(tǒng)的自動(dòng)化測(cè)試和持續(xù)交付，甚至是從單體架構(gòu)向微服務(wù)的逐步演化,，Docker相關(guān)技術(shù)都可以為微服務(wù)提供有力幫助,。
