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

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

PlatformsamazonDeployment

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

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

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