微服務(wù)架構(gòu)的持續(xù)集成交付

微服務(wù)架構(gòu)的持續(xù)集成交付首先介紹下微服務(wù)架構(gòu)的優(yōu)勢(shì)與劣勢(shì)。相較于單體應(yīng)用來說，微服務(wù)架構(gòu)有這么幾個(gè)優(yōu)點(diǎn)：易于開發(fā)、理解。由于每個(gè)服務(wù)只負(fù)責(zé)單一功能，開發(fā)者可以聚焦于自己負(fù)責(zé)的幾個(gè)服務(wù)模塊，對(duì)于其他服務(wù)，只需要理解接口即可。當(dāng)然，單體應(yīng)用經(jīng)過良好設(shè)計(jì)也可以達(dá)到這個(gè)效果，但是，與單體應(yīng)用的進(jìn)程內(nèi)通信或單機(jī)內(nèi)的進(jìn)程間通信不同的是，微服務(wù)的各服務(wù)之間一般采用RESTfulAPI或者異步消息隊(duì)列進(jìn)行通信，無論RESTful接口還是異步消息隊(duì)列都是開發(fā)語(yǔ)言無關(guān)的，極易理解的通信方式。全局穩(wěn)定性提高。由于每個(gè)服務(wù)負(fù)責(zé)的功能單一，各服務(wù)的資源需求也相對(duì)更低。從而可以選擇將服務(wù)分散的部署到多臺(tái)中低配的服務(wù)器上，而不是一臺(tái)高配的機(jī)器上。如果某個(gè)機(jī)器上的服務(wù)故障，譬如說內(nèi)存泄漏，故障只會(huì)影響該機(jī)器上的某一個(gè)或幾個(gè)服務(wù)，對(duì)全局影響不大。不受限于任何技術(shù)棧，極大的提高團(tuán)隊(duì)搭建的速度。這一點(diǎn)對(duì)初創(chuàng)公司尤為重要，組建開發(fā)團(tuán)隊(duì)對(duì)初創(chuàng)公司來說本來就是個(gè)頭疼的問題，如何還要求團(tuán)隊(duì)的技術(shù)棧一致，招聘難度可想而知。但是，如果產(chǎn)品架構(gòu)采用微服務(wù)架構(gòu)，那么我們可以允許不同的服務(wù)模塊采用不同的技術(shù)棧，只需要定義好對(duì)外接口即可。局部的修改很容易部署，從而大大的提高了功能的交付效率。說完了微服務(wù)架構(gòu)的優(yōu)點(diǎn)，我們?cè)賮碛懻撓缕淙秉c(diǎn)或者說復(fù)雜的地方：如何確定軟件功能切分的粒度，邊界。太多的微服務(wù)模塊會(huì)導(dǎo)致服務(wù)間通信成本和運(yùn)維成本的增加，過猶不及；但是若粒度過大，又違背了微服務(wù)的初衷。多種技術(shù)棧（譬如C，Java，Python，Scala等）我們需要為每種語(yǔ)言準(zhǔn)備編譯環(huán)境，運(yùn)行環(huán)境等，增加了維護(hù)成本。這個(gè)可以通過Docker隔離來解決，我們后面會(huì)詳細(xì)展開。微服務(wù)模塊多了，會(huì)導(dǎo)致全局的上線次數(shù)變多，從而需要更復(fù)雜的版本管理和Bug跟蹤等，間接導(dǎo)致項(xiàng)目管理成本增加。持續(xù)交付持續(xù)集成和交付(CI/CD)是一種軟件開發(fā)實(shí)踐，使用得當(dāng)，它會(huì)極大的提高軟件開發(fā)效率并保障軟件開發(fā)質(zhì)量；持續(xù)集成和交付分為持續(xù)集成和持續(xù)交付兩部分，這里我們不再具體探討這兩者的區(qū)別，統(tǒng)一按持續(xù)交付來處理。Jenkins是一個(gè)開源項(xiàng)目，它提供了一種易于使用的持續(xù)集成系統(tǒng)；除Jenkins夕卜，常見的持續(xù)集成系統(tǒng)還有：Travis:/Codeship:/Stridercd:/另外，常見的交付方式一般有：源代碼交付：源代碼交付需要將源代碼以tar包等方式download到服務(wù)器，然后在服務(wù)器上借助程序的構(gòu)建腳本去構(gòu)建可執(zhí)行程序，顯然這種方式會(huì)經(jīng)常因服務(wù)器環(huán)境差異，構(gòu)建環(huán)境初始化失敗等問題導(dǎo)致無法構(gòu)建可執(zhí)行程序。嚴(yán)重依賴于構(gòu)建腳本的完備程度。Linux標(biāo)準(zhǔn)包交付：將項(xiàng)目的依賴通過Linuxdeb或者rpm來管理，由于這種方式更符合Linux規(guī)范，間接的提高了項(xiàng)目在服務(wù)器上部署的成功率，但是有些時(shí)候仍然需要解決包沖突問題。虛擬鏡像交付：虛擬鏡像交付指的是我們將項(xiàng)目在虛擬機(jī)里測(cè)試成功后直接將該虛擬鏡像部署到服務(wù)器上。顯然，這種方式部署成功率接近100%而且隔離性好。但是隨之而來的問題就是虛擬鏡像本身對(duì)服務(wù)器資源的消耗。

dockerimage交付：dockerimage交付是虛擬鏡像交付的進(jìn)一步演進(jìn)，在保證系統(tǒng)隔離的同時(shí)，dockerimage對(duì)服務(wù)器的資源消耗更低。當(dāng)然，docker的隔離機(jī)制是進(jìn)程級(jí)別的，可能不適合一些強(qiáng)隔離場(chǎng)景。我們團(tuán)隊(duì)目前正在使用這種方式進(jìn)行交付。Deployment

PlatformsamazonDeployment

Platformsamazon上圖（圖片來自于網(wǎng)絡(luò)）展示了圍繞Docker鏡像倉(cāng)庫(kù)的持續(xù)交付流程：首先開發(fā)者將代碼推送到代碼倉(cāng)庫(kù)，譬如github代碼倉(cāng)庫(kù)的更新會(huì)觸發(fā)新的代碼構(gòu)建，生成新的docker鏡像并推送到docker鏡像倉(cāng)庫(kù)接下來會(huì)基于新的docker鏡像進(jìn)行集成測(cè)試測(cè)試通過后，docker鏡像被交付到公有或者私有云上通過上述持續(xù)交付的方式交付微服務(wù)架構(gòu)的軟件，能夠很好的解決前面提到的第二與第三個(gè)問題，即結(jié)合Docker解決多技術(shù)棧的環(huán)境維護(hù)問題；按微服務(wù)模塊交付來提高軟件的交付效率引入“版本服務(wù)”來可視化各微服務(wù)的版本信息引入“ReleaseNote服務(wù)”來發(fā)布各微服務(wù)的feature更新實(shí)踐微服務(wù)架構(gòu)有多種，數(shù)人云的微服務(wù)架構(gòu)有如下特點(diǎn)：RESTAPI與消息隊(duì)列結(jié)合使用。微服務(wù)與外部用戶通過RESTAPI通信，內(nèi)部微服務(wù)之間通過消息隊(duì)列通信。全部Docker交付，這解決了多技術(shù)棧的環(huán)境維護(hù)問題。一個(gè)微服務(wù)對(duì)應(yīng)于一個(gè)持續(xù)交付的Job，這保證了各服務(wù)在交付環(huán)節(jié)無相互依賴，單獨(dú)觸發(fā)。同時(shí)可以利用不同的Docker鏡像為不同的Job提供相應(yīng)環(huán)境。版本信息自動(dòng)更新ReleaseNote自動(dòng)發(fā)布構(gòu)建環(huán)境Docker化，與底層隔離，保證宿主機(jī)環(huán)境的一致性，降低運(yùn)維成本利用Docker—compose維護(hù)本地開發(fā)環(huán)境，從而實(shí)現(xiàn)開發(fā)環(huán)境與生產(chǎn)環(huán)境的邏輯一致性數(shù)人云的架構(gòu)設(shè)計(jì)模式如圖所示。用戶通過瀏覽器或者直接通過RESTAPI與后臺(tái)通信，后臺(tái)是一個(gè)微服務(wù)集合，對(duì)外服務(wù)的接口一律采用RESTAPI，內(nèi)部服務(wù)之間的接口采用消息隊(duì)列。各微服務(wù)負(fù)責(zé)維護(hù)自身的狀態(tài)集，有自己獨(dú)立的緩存和DB（如有必要）。微服務(wù)本身盡量無狀態(tài)化，以保證橫向擴(kuò)展能力。Docker5K作ADocker5K作A：配耕?，心/莎.J*rnkict?^ilSJ-rA上圖是我們目前采用的持續(xù)交付架構(gòu)圖。A,B,C,D四個(gè)github代碼庫(kù)分別存儲(chǔ)著四個(gè)微服務(wù)的源代碼，相應(yīng)的我們?yōu)槊恳粋€(gè)代碼庫(kù)創(chuàng)建了獨(dú)立的構(gòu)建作業(yè)，代碼更新觸發(fā)構(gòu)建時(shí)，構(gòu)建作業(yè)將執(zhí)行如下的大致步驟：從Docker私有鏡像倉(cāng)庫(kù)拉取相應(yīng)的構(gòu)建鏡像從github源碼庫(kù)拉取相應(yīng)代碼并掛載到構(gòu)建容器里，觸發(fā)特定腳本來執(zhí)行構(gòu)建若構(gòu)建成功，立刻從Docker私有鏡像倉(cāng)庫(kù)拉取相應(yīng)的runtime鏡像，將構(gòu)建成功的可執(zhí)行程序Docker化成新一版的微服務(wù)鏡像將上述微服務(wù)鏡像推送到Docker私有鏡像倉(cāng)庫(kù)若已經(jīng)設(shè)置了自動(dòng)交付則通過Marathon的RESTfulAPI接口觸發(fā)線上微服務(wù)的更新更新版本服務(wù)里面對(duì)應(yīng)微服務(wù)的版本信息自動(dòng)更新ReleaseNote服務(wù)里面對(duì)應(yīng)微服務(wù)的ReleaseNote。開發(fā)者在實(shí)現(xiàn)了相應(yīng)功能時(shí)已經(jīng)將對(duì)應(yīng)的ReleaseNote放在了代碼庫(kù)特定目錄下面（這個(gè)后面會(huì)詳細(xì)提到）Meseaaitjve節(jié)點(diǎn)為 歐斯9加ve節(jié)點(diǎn) Meseaaitjve節(jié)點(diǎn)■就就 M今I命遍而I今yMasosMasidrMea-oaMasosMasidrMea-oa也JenkinsMosierFramworic助hr曲「偶的命令宣

送到Meg&翱eveMfiralhtiri 賣例另外，從架構(gòu)圖中我們可以看出，程序的構(gòu)建環(huán)境和運(yùn)行環(huán)境正在共享同一個(gè)Mesos資源池，提高了資源利用率。把Jenkins運(yùn)行在Mesos上有如下幾個(gè)考慮：把Jenkins運(yùn)行到ApacheMesos上，或者說利用ApacheMesos向Jenkins提供slave資源，最主要的目的是利用Mesos的彈性資源分配來提高資源利用率。術(shù)棧的軟件情況下尤其重要，可以極大降低運(yùn)維成本。Marathon會(huì)對(duì)發(fā)布到它之上的應(yīng)用程序進(jìn)行健康檢查，從而在應(yīng)用程序由于某些原因意外崩潰后自動(dòng)重啟該應(yīng)用。這樣，選擇利用Marathon管理JenkinsMaster保證了該構(gòu)建系統(tǒng)的全局高可用。而且，JenkinsMaster本身也通過Marathon部署運(yùn)行在Mesos資源池內(nèi)，進(jìn)一步實(shí)現(xiàn)了資源共享，提高了資源利用率。關(guān)于怎樣將jenkins運(yùn)行在mesos上，大家可以參考我以前在csdn發(fā)布的一篇文章/article/2015-06-18/2824998Docker承擔(dān)了什么角色Docker在整個(gè)體系中承擔(dān)了如下幾個(gè)角色：各代碼庫(kù)的編譯載體：我們已經(jīng)提前將各代碼庫(kù)的編譯環(huán)境制作成了docker鏡像交付介質(zhì)：編譯成功的可執(zhí)行程序?qū)⒈淮虬蒬ocker鏡像，鏡像的tag對(duì)應(yīng)于程序版本信息Runtime環(huán)境：運(yùn)行環(huán)境已經(jīng)被打包到docker鏡像中了，啟動(dòng)的docker容器將作為微服務(wù)的runtime環(huán)境資源隔離：docker本身支持進(jìn)程級(jí)別隔離，已經(jīng)滿足內(nèi)部應(yīng)用需求為了保證單機(jī)開發(fā)環(huán)境與線上環(huán)境的配置/架構(gòu)一致，我們?cè)趩螜C(jī)開發(fā)環(huán)境利用docker-compose來編排整個(gè)微服務(wù)環(huán)境，以便于調(diào)試版本調(diào)試在實(shí)踐微服務(wù)架構(gòu)時(shí)，我們碰到了這么一個(gè)問題：各微服務(wù)模塊頻繁交付，如何確認(rèn)線上各微服務(wù)的版本，即我們需要對(duì)各微服務(wù)進(jìn)行版本控制。目前團(tuán)隊(duì)迭代出了如下解決方案:交付成功后，交付job會(huì)截取docker鏡像里相應(yīng)的tag（代表著版本信息），并把該信息推送到一個(gè)NginxServer的靜態(tài)文件里面，前端頁(yè)面訪問該靜態(tài)文件來獲取相應(yīng)微服務(wù)的版本信息。另外，同一個(gè)微服務(wù)會(huì)部署到開發(fā)，測(cè)試和生產(chǎn)三個(gè)環(huán)境上，所以基于不同的環(huán)境，我們會(huì)維護(hù)三個(gè)不同的靜態(tài)文件。ReleaseNote服務(wù)在多人協(xié)作的微服務(wù)項(xiàng)目開發(fā)中，由于多人頻繁的merge代碼，ReleaseNote的管理也會(huì)成為團(tuán)隊(duì)的負(fù)擔(dān)。我這里推薦的做法是這樣：文檔規(guī)約：團(tuán)隊(duì)達(dá)成一個(gè)agreement:對(duì)重大feature或bug-fix的提交都需要在目錄pending-release里面創(chuàng)建相應(yīng)的markdown文件，并將改動(dòng)添加到里面。這樣，我們可以控制交付Job在交付時(shí)掃描pending-release目錄并將其中的文本merge到一起生成這次交付的ReleaseNote。gitpre-commit-hook:同時(shí)，為了避免團(tuán)隊(duì)成員忘記這個(gè)agreement，我們還可以在本地的git-precommit-hook中添加相應(yīng)的掃描提醒。

配置中心服務(wù)目前網(wǎng)絡(luò)上關(guān)于配置管理的解決方案已經(jīng)非常成熟，我這里就不過多解釋了。唯一需要提到的就是，我們的配置中心服務(wù)還沒有完全融入到整個(gè)交付過程中來，微服務(wù)的配置文件仍然需要手工介入。持續(xù)集成的消息通知顯然，團(tuán)隊(duì)希望CI服務(wù)器在執(zhí)行了持續(xù)集成后能夠及時(shí)的將集成結(jié)果通知團(tuán)隊(duì)成員，Jenkins本身是有ircnotification插件的，但是國(guó)內(nèi)開發(fā)者可能使用IRC的并不多；微信是小團(tuán)隊(duì)使用比較多的溝通工具，我們可以使用微信公眾號(hào)進(jìn)行消息通知；或者使用國(guó)內(nèi)的LessChart等交流工具，它們本身支持webhook調(diào)用。開發(fā)環(huán)境的搭建tlJIFKA.微服務(wù)架構(gòu)導(dǎo)致軟件模塊增多，增加了開發(fā)環(huán)境搭建的難度，同時(shí)也導(dǎo)致了團(tuán)隊(duì)新成員上手門檻的提高。我們目前是利用docker-compose維護(hù)本地開發(fā)環(huán)境來解決這個(gè)問題的。它不僅實(shí)現(xiàn)了開發(fā)環(huán)境與生產(chǎn)環(huán)境的邏輯一致性，同時(shí)也可以讓相應(yīng)模塊的開發(fā)者聚焦于自己的業(yè)務(wù)，不必糾結(jié)于如何啟停其它微服務(wù)。下面是我們的docker-compose文件的一部分。tlJIFKA.1.1.4tOHLSil.-BWHrHA-Wl：-...:/Lriir/-BJ*wra/n|]|irrtArtaHl:ra-WronEA皿wrV/'jfanaufvial/AilccenLirt￡ai:.t-crL!^eL-c/rulra/i-slcertlfkraEc.crt-ro- .Zl^rmtHn<lircanFJmw.daS^acn. /■tc/r^lnxZnni.diacaaa*!-la-na-paakphmjM.k呷:reUaKbe-EtuabBr--PPP--w*tr*L￡■Ef，7，nBWI;Ma-clM-rterVdlluMEh二-?t r用mjugW5e5BLie- 由1毛砒■,girt;/mG/njIeAF J_t；E-“./ dactOHwi.tD-->ifMk<|Mssp4K^5<.key:/■uz/natna/mA.曲Lanan.l^noopos-iphnise.k?￥:?<cLu|kt4r;皿11”-^nalLMn=ut?rfv.l._ltrics±-iiiirMts._?jrsql_i■■ces^re*i&_L:red!i?PPF'butId:-VQllUHM；■■-./omg￡h->mjp/cm?03->-apD ?:/■to'ow^