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

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

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

PlatformsamazonDeployment

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

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

配置中心服務(wù)目前網(wǎng)絡(luò)上關(guān)于配置管理的解決方案已經(jīng)非常成熟，我這里就不過多解釋了。唯一需要提到的就是，我們的配置中心服務(wù)還沒有完全融入到整個交付過程中來，微服務(wù)的配置文件仍然需要手工介入。持續(xù)集成的消息通知顯然，團隊希望CI服務(wù)器在執(zhí)行了持續(xù)集成后能夠及時的將集成結(jié)果通知團隊成員，Jenkins本身是有ircnotification插件的，但是國內(nèi)開發(fā)者可能使用IRC的并不多；微信是小團隊使用比較多的溝通工具，我們可以使用微信公眾號進行消息通知；或者使用國內(nèi)的LessChart等交流工具，它們本身支持webhook調(diào)用。開發(fā)環(huán)境的搭建tlJIFKA.微服務(wù)架構(gòu)導(dǎo)致軟件模塊增多，增加了開發(fā)環(huán)境搭建的難度，同時也導(dǎo)致了團隊新成員上手門檻的提高。我們目前是利用docker-compose維護本地開發(fā)環(huán)境來解決這個問題的。它不僅實現(xiàn)了開發(fā)環(huán)境與生產(chǎn)環(huán)境的邏輯一致性，同時也可以讓相應(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^