微服務(wù)架構(gòu)如何和持續(xù)交付過(guò)程相結(jié)合，是我們?cè)趯?shí)施微服務(wù)架構(gòu)的時(shí)候必須要考慮的問(wèn)題，如果是一個(gè)簡(jiǎn)單的單體應(yīng)用的自動(dòng)化編譯構(gòu)建和發(fā)布，相對(duì)來(lái)說(shuō)要簡(jiǎn)單的多，但是在實(shí)施微服務(wù)架構(gòu)后，整個(gè)持續(xù)交付過(guò)程本身會(huì)增加一定的復(fù)雜度。

我們舉一個(gè)供應(yīng)鏈系統(tǒng)開(kāi)發(fā)的場(chǎng)景來(lái)說(shuō)明。

該供應(yīng)鏈系統(tǒng)劃分為了門(mén)戶(hù)應(yīng)用，招投標(biāo)中心，采購(gòu)中心，供應(yīng)商中心，用戶(hù)中心和流程中心幾個(gè)大的微服務(wù)模塊?；谖⒎?wù)架構(gòu)本身進(jìn)行模塊拆分的要求可以看到，以上的六個(gè)微服務(wù)模塊要做到完全的獨(dú)立自治，獨(dú)立的配置管理庫(kù)，并能夠獨(dú)立進(jìn)行編譯構(gòu)建打包測(cè)試和最終的版本發(fā)布操作，而最終的六個(gè)微服務(wù)模塊一起組成一個(gè)完整的供應(yīng)鏈管理業(yè)務(wù)應(yīng)用。

這個(gè)和多年前我們談到的私有云PaaS平臺(tái)里面的組件化開(kāi)發(fā)思路是完全一樣的。基于這種微服務(wù)模塊劃分，我們來(lái)看如何和持續(xù)交付過(guò)程和DevOps支撐平臺(tái)相結(jié)合。

每個(gè)微服務(wù)模塊獨(dú)立進(jìn)行配置和源代碼管理，獨(dú)立數(shù)據(jù)庫(kù)，獨(dú)立進(jìn)行編譯構(gòu)建和部署發(fā)布。

在這種思路下可以看到，我們首先要有應(yīng)用集的概念，即本次構(gòu)建的供應(yīng)鏈管理就是一個(gè)大的應(yīng)用集，但是這個(gè)應(yīng)用集下面卻可以有多個(gè)微服務(wù)模塊。整個(gè)思路是要先構(gòu)建一個(gè)獨(dú)立的應(yīng)用集，并規(guī)劃應(yīng)用集的版本。然后才是在應(yīng)用集下面創(chuàng)建6個(gè)獨(dú)立的研發(fā)項(xiàng)目版本，分別對(duì)應(yīng)上面的6個(gè)微服務(wù)模塊，并制定獨(dú)立的svn或git源代碼目錄分支。

針對(duì)每一個(gè)微服務(wù)模塊都要獨(dú)立創(chuàng)建編譯，構(gòu)建，發(fā)布等任務(wù)，同時(shí)針對(duì)每一個(gè)微服務(wù)模塊創(chuàng)建一個(gè)獨(dú)立的從編譯構(gòu)建測(cè)試到發(fā)布的流水線(xiàn)任務(wù)作業(yè)。該流水線(xiàn)每觸發(fā)執(zhí)行一次，即可以完成該獨(dú)立的微服務(wù)模塊的自動(dòng)化編譯構(gòu)建打包，自動(dòng)化的代碼檢查測(cè)試并發(fā)布到測(cè)試環(huán)境進(jìn)一步供測(cè)試人員進(jìn)行測(cè)試。

每一個(gè)微服務(wù)模塊只部署到一個(gè)Docker容器里面，不再進(jìn)一步進(jìn)行組件拆分部署到多個(gè)Docker容器中。但是容器本身可以在后期進(jìn)行資源動(dòng)態(tài)擴(kuò)展。即微服微模塊編譯構(gòu)建通過(guò)，打包制作鏡像到一個(gè)鏡像文件，并在后續(xù)對(duì)鏡像文件進(jìn)行部署。

問(wèn)題是在實(shí)際的DevOps支撐里面，可以考慮將打包和鏡像制作過(guò)程隱含掉，畢竟用戶(hù)并不關(guān)心該過(guò)程。

對(duì)于6個(gè)微服務(wù)模塊間有接口調(diào)用，在前面我們思路里面是內(nèi)部6個(gè)模塊間的交互不用啟用API網(wǎng)關(guān)進(jìn)行交互，而直接走微服務(wù)架構(gòu)里面的服務(wù)注冊(cè)和配置中心即可。

在多模塊交互協(xié)同下，所有的微服務(wù)模塊在觸發(fā)自動(dòng)編譯構(gòu)建并部署后都需要自動(dòng)化單元測(cè)試，這里面最重要的就是對(duì)接口的單元測(cè)試，這種單元測(cè)試包括南向接口和北向接口兩個(gè)部分的內(nèi)容，只有兩部分單元測(cè)試都通過(guò)，該模塊本身才處于一種穩(wěn)定可測(cè)狀態(tài)。

自動(dòng)化單元測(cè)試不通過(guò)應(yīng)該先開(kāi)發(fā)進(jìn)行檢查并解決，因此在多模塊分工下更加應(yīng)該首先對(duì)規(guī)劃好的接口進(jìn)行實(shí)現(xiàn)并發(fā)布，只有這樣才不會(huì)影響到其它模塊的并行開(kāi)發(fā)工作。

最近我一直在思考，如果將整個(gè)持續(xù)交付過(guò)程規(guī)劃為研發(fā)過(guò)程管理工具和DevOps支撐平臺(tái)工具兩個(gè)工具平臺(tái)來(lái)支撐的話(huà)，實(shí)際上很多內(nèi)容很難在兩個(gè)平臺(tái)間協(xié)同好。DevOps平臺(tái)更多是技術(shù)平臺(tái)，僅僅解決的是構(gòu)建和發(fā)布過(guò)程，而實(shí)際上很難去解決我們說(shuō)的多個(gè)組件間的協(xié)同和研發(fā)過(guò)程管理。

開(kāi)發(fā)人員和測(cè)試人員，一種思路是測(cè)試人員手工執(zhí)行流水線(xiàn)，在執(zhí)行完成后進(jìn)行測(cè)試操作;還有一種思路是開(kāi)發(fā)人員去跑流水線(xiàn)，在自測(cè)沒(méi)有問(wèn)題后提交測(cè)試。可以看到更好的做法應(yīng)該是開(kāi)發(fā)去跑流水線(xiàn)，提交測(cè)試后選擇已經(jīng)完成的需求或修復(fù)的Bug，自動(dòng)變更狀態(tài)。而測(cè)試人員只需要在測(cè)試環(huán)境對(duì)待驗(yàn)證的問(wèn)題進(jìn)行測(cè)試和驗(yàn)證就可以了。即只有問(wèn)題狀態(tài)是待驗(yàn)證，那么當(dāng)前的測(cè)試環(huán)境版本一定就是可以驗(yàn)證的一個(gè)版本。

開(kāi)發(fā)人員的流水線(xiàn)為：

代碼更新-》編譯構(gòu)建-》代碼檢查-》鏡像打包-》部署-》自動(dòng)化單元測(cè)試-》人工驗(yàn)證并提交測(cè)試

在人工驗(yàn)證后提交測(cè)試，同時(shí)對(duì)相關(guān)需求和Bug的狀態(tài)進(jìn)行變更。測(cè)試人員可以進(jìn)入到測(cè)試環(huán)節(jié)。實(shí)際上我們大部分重復(fù)迭代都應(yīng)該在這個(gè)階段，直到所有的需求全部實(shí)現(xiàn)，所有的Bug缺陷都關(guān)閉。

而基于上篇文章思考，在該流水線(xiàn)上可以再增加一個(gè)測(cè)試驗(yàn)證環(huán)節(jié)，即測(cè)試驗(yàn)證通過(guò)后自動(dòng)進(jìn)行環(huán)境遷移，將最新的版本發(fā)布到UAT環(huán)境以方便進(jìn)行UAT測(cè)試操作。如果考慮到流水線(xiàn)松耦合，那么可以將測(cè)試驗(yàn)證后發(fā)布UAT環(huán)境作為一個(gè)獨(dú)立的流水線(xiàn)，即：

選擇鏡像(可以選擇多個(gè)鏡像)-》配置修改-》發(fā)布生產(chǎn)環(huán)境

在這個(gè)過(guò)程中鏡像從鏡像庫(kù)選擇，對(duì)應(yīng)到當(dāng)前項(xiàng)目的最新基線(xiàn)版本(基線(xiàn)版本為測(cè)試通過(guò)后的版本)，即在開(kāi)發(fā)流水線(xiàn)上仍然需要增加了一個(gè)打基線(xiàn)標(biāo)簽的人工操作，這個(gè)可以由測(cè)試人員來(lái)完成。

開(kāi)發(fā)構(gòu)建，發(fā)布和SIT測(cè)試是單微服務(wù)模塊視角。但是整體的應(yīng)用版本規(guī)劃，UAT測(cè)試則是全應(yīng)用集視角。即不論是新增還是后續(xù)變更版本的規(guī)劃，我們都希望能夠看到整個(gè)應(yīng)用集的視角，包括這次變更究竟影響到哪些微服務(wù)模塊，哪些會(huì)重新構(gòu)建或發(fā)生版本變化，這些都必須清楚。

如果一個(gè)功能變更導(dǎo)致我們所有的微服務(wù)模塊都必須重新編譯構(gòu)建和發(fā)布，那么我們進(jìn)行微服務(wù)模塊拆分，按微服務(wù)方式獨(dú)立自治管理的目的就根本沒(méi)有達(dá)到。一個(gè)簡(jiǎn)單的原則就是影響到哪個(gè)模塊就哪個(gè)模塊進(jìn)行更新，如果影響到接口，就接口對(duì)應(yīng)的模塊也配套更新。可見(jiàn)微服務(wù)模塊間的接口一定得松耦合，如果拆分為微服務(wù)模塊，但是之間的接口交互異常復(fù)雜，那么仍然是強(qiáng)耦合關(guān)系，沒(méi)有意義。

唯一需要說(shuō)明的是一種變更是變動(dòng)了底層基礎(chǔ)組件的接口規(guī)格，那么這種情況下往往才會(huì)出現(xiàn)大量的微服務(wù)模塊都出現(xiàn)重新編譯構(gòu)建?；A(chǔ)組件變更，如果接口沒(méi)有變更，那么上層的應(yīng)用組件同樣不應(yīng)該重新構(gòu)建，即相互之間應(yīng)該是基于服務(wù)接口的依賴(lài)，而不能是基于Jar包的依賴(lài)。Jar包依賴(lài)容易導(dǎo)致的問(wèn)題就是在使用Maven的時(shí)候會(huì)觸發(fā)自動(dòng)的重新編譯構(gòu)建操作。

從部署到DEV環(huán)境，再到部署到SIT環(huán)境，再到部署到UAT環(huán)境，整個(gè)過(guò)程必須進(jìn)行全程跟蹤。形成基于當(dāng)前項(xiàng)目版本的可視化追蹤視圖。這個(gè)功能實(shí)際在持續(xù)集成的時(shí)候也是必備的關(guān)鍵功能。