最近經(jīng)常在項目或是社區(qū)里聽到大家談?wù)撐⒎?wù)架構(gòu)，但談?wù)摰慕裹c(diǎn)更多集中在微服務(wù)拆分，分布式架構(gòu)，微服務(wù)門檻，DevOps配套設(shè)施等話題上。

但是在我眼里，真正能稱之為微服務(wù)架構(gòu)的少之又少。原因也很簡單，我所見到的很多所謂的微服務(wù)架構(gòu)項目，大多都沒有做到微服務(wù)架構(gòu)的一個基本要求：服務(wù)的獨(dú)立部署(交付)。

這里的獨(dú)立部署和自動化部署還不是一個概念，服務(wù)的自動化部署相對簡單，已有大量的工具可以幫助我們做到。但是這里所談的獨(dú)立部署，我認(rèn)為關(guān)鍵和難點(diǎn)并不在于“部署”，而在于“獨(dú)立”。

如果失去了服務(wù)獨(dú)立部署(交付)的能力，一個微服務(wù)架構(gòu)的威力將大打折扣，我們的系統(tǒng)雖然在物理上被拆分成了多個小的服務(wù)，但是如果從最終交付的角度來看，仍然是以一個整體存在的，就像單體應(yīng)用一樣，存在諸多的問題。

為什么服務(wù)的獨(dú)立交付并不簡單?

那為什么不能讓每一個服務(wù)都獨(dú)立部署到產(chǎn)品環(huán)境呢?問題的答案是：不是不能，而是不敢!

為了表達(dá)清楚，讓我們來看個例子吧。

像下圖一樣，我現(xiàn)在就是那個程序員帥哥(本色出演)，突然有一天心血來潮，動手開發(fā)了一個網(wǎng)上商城。代碼Push到Github并通過CI構(gòu)建持續(xù)交付流水線，最終自動化部署到云端產(chǎn)品環(huán)境，供用戶訪問使用。

隨著用戶和訪問量的增加，需求和功能也越來越多，系統(tǒng)也變得越發(fā)復(fù)雜。

從網(wǎng)上了解到最近有個叫微服務(wù)的架構(gòu)非?；鸨乙糙s了回時髦，當(dāng)然也覺得這種架構(gòu)確實可以幫助我解決現(xiàn)在的一些問題。

經(jīng)過對系統(tǒng)的分析，我將商城的后臺部分拆分出了3個服務(wù)，為了簡單我們就稱之為ABC三個服務(wù)。

我們假設(shè)一個比較極端的情況，三個服務(wù)相互調(diào)用(先不考慮這樣是否合理)，每個服務(wù)通過自己的持續(xù)交付流水線獨(dú)立部署到產(chǎn)品環(huán)境。當(dāng)前產(chǎn)品環(huán)境的各個服務(wù)的版本是：

A：1.0、B：2.0、C：3.0

一切都非常***是不是?看!我們已經(jīng)做到了服務(wù)的獨(dú)立部署!So easy~

當(dāng)然，事情肯定不會那么簡單。

問題出現(xiàn)在當(dāng)我對A服務(wù)做了一次新的提交之后，A服務(wù)的***版本升級到了1.1。不幸的是，這個新的版本意外的破壞了A與B之間的契約，錯誤的調(diào)用了B的接口，導(dǎo)致出現(xiàn)了錯誤。

雖然我的A服務(wù)和B服務(wù)都有比較完備的UT(單元測試)，但因為UT無法發(fā)現(xiàn)服務(wù)之間的集成是否被破壞，所以只有UT作為質(zhì)量保障的A服務(wù)持續(xù)交付流水線也自然沒有能力發(fā)現(xiàn)AB服務(wù)集成被破壞的這個問題。最終導(dǎo)致存在問題的A1.1版本被部署到了產(chǎn)品環(huán)境，產(chǎn)品環(huán)境出現(xiàn)了嚴(yán)重的Bug。

請問在座的同學(xué)，碰到這樣的情況，你會如何處理?

“加集成測試啊!”

這位同學(xué)說的極是，我這么聰明自然也想到了這一點(diǎn)，不就是要測集成嗎?UT干不了就加集成測試不就成了。

為了統(tǒng)一語言，畢竟對于各種測試的叫法太容易引起混淆，參考Martin Fowler在《微服務(wù)測試策略》中的定義，我們在本文中將這種測試多服務(wù)集成的測試統(tǒng)一稱作端到端測試(End-to-End tests，簡稱E2E測試)。

添加了E2E測試之后，我的交付流水線就變成了下面這個樣子。

因為有了E2E測試的存在，問題迎刃而解，當(dāng)A服務(wù)的新版本破壞了與B服務(wù)的集成時，E2E測試就會及時診斷出來，并阻止A服務(wù)的***版本向產(chǎn)品環(huán)境流動，保證產(chǎn)品環(huán)境不被破壞。

這樣看似沒有什么問題，通過添加E2E測試，解決了服務(wù)間集成的驗證問題，但在不知不覺中，我們也失去了微服務(wù)架構(gòu)的那個重要的特性：“服務(wù)的獨(dú)立交付”。

怎么講?別急，我們再往下看。

假設(shè)A服務(wù)的修復(fù)過程中，B和C服務(wù)也提交了新的代碼，我們假設(shè)這兩個提交是沒有問題的，但因為A服務(wù)的1.1版本導(dǎo)致E2E測試掛掉的問題還沒有被修復(fù)，所以B和C的新版本也被E2E測試攔了下來，此時的E2E測試就像是一個亮起紅燈的路口，阻塞了所有服務(wù)通往產(chǎn)品環(huán)境的通道。

所以說，隨著集中E2E測試的添加，質(zhì)量被保障的同時，我們的“微服務(wù)架構(gòu)”也已悄然失去了服務(wù)獨(dú)立交付的能力，殺敵一千自損八百，損失慘重!

這并不是我假想的場景，在我自己經(jīng)歷的幾個真實項目中，這個問題都在一直困擾著我們。帶來了各種各樣的衍生問題，例如E2E測試長時間失敗，無人修復(fù)，修復(fù)難度大，服務(wù)交付堵塞，為了保持交付通路暢通還不得不引入同樣存在很大副作用的CodeFrezze機(jī)制和提交Token機(jī)制等。

可以看到，雖然我們能夠在代碼庫，在部署結(jié)構(gòu)上，甚至在組織上進(jìn)行服務(wù)化拆分，但就因為這***一個交付的十里路口，***這一個紅綠燈，讓所有的服務(wù)又糾纏在了一起，所有的服務(wù)化拆分形同虛設(shè)，最終我們得到的也只是一個看起來像微服務(wù)架構(gòu)的單體應(yīng)用而已。

拆除紅綠燈，各行其道，收復(fù)失地!

那，如何才能將這個“紅綠燈”拆除，讓服務(wù)可以在有質(zhì)量保障的前提下還可以做到獨(dú)立交付呢?這就是本文要解決的問題，讓我們繼續(xù)往下看。

我的解決方法其實也很簡單：Inline E2E tests。

即并不添加新的集中的Pipeline做E2E測試，而是為每一個服務(wù)的Pipeline都添加一個相同的E2E測試的Stage，就相當(dāng)于將E2E測試Inline到每個服務(wù)各自的部署流水線中，如下圖所示。

其實Inline E2E測試還不是最關(guān)鍵的，最關(guān)鍵的變化點(diǎn)就是假設(shè)A服務(wù)有了新的提交，運(yùn)行到A服務(wù)自己Pipeline的E2E測試的時候，此時的E2E測試并不是像之前一樣獲取B和C服務(wù)的***代碼庫版本做集成驗證，而獲取當(dāng)前產(chǎn)品環(huán)境上的B和C服務(wù)的已部署當(dāng)前版本做集成驗證。

例如，如圖所示A服務(wù)的版本從1.0升級到了1.1，當(dāng)前產(chǎn)品環(huán)境的B和C的版本是2.0和3.0。在執(zhí)行A服務(wù)Pipeline上的E2E測試時，驗證出A1.1和B2.0集成存在問題，測試變紅，Pipeline掛掉，從而阻斷了A服務(wù)的1.1版本部署到產(chǎn)品環(huán)境，保證了產(chǎn)品環(huán)境不會被A的1.1版本破壞。

同樣，假設(shè)A還沒有被修復(fù)之前，B也有了新的提交，產(chǎn)生了一個新的版本B2.1，這時在B服務(wù)Pipeline上的E2E測試并不獲取當(dāng)前A服務(wù)的代碼庫***版本1.1做集成測試，而是獲取產(chǎn)品環(huán)境上的當(dāng)前版本A1.0版本做集成測試。我們假設(shè)B2.1和A1.0之間的集成沒有問題，測試通過，所以B的2.1版本就被成功的交付到了產(chǎn)品環(huán)境，而此時產(chǎn)品環(huán)境的A服務(wù)的版本仍是1.0。

看!服務(wù)之間的阻塞被神奇的解決了，服務(wù)再也不會被堵在一個統(tǒng)一的十字路口，而是各行其道，A的車道出了事故，是A的問題，應(yīng)該由A來承擔(dān)后果和解決問題，不應(yīng)該影響到其他服務(wù)，其他服務(wù)依然可以持續(xù)的交付到產(chǎn)品環(huán)境。

向前看是持續(xù)集成，向后看是持續(xù)交付!

看到這里可能有些小伙伴會感到有些失望。咋呼半天，不就是將E2E測試整到每個服務(wù)的Pipeline里，再把獲取版本從***代碼改成產(chǎn)品環(huán)境么?有啥厲害的。

但是，在我看來，這個看似簡單的變化，意義卻是重大的：它揭示了“持續(xù)集成”和“持續(xù)交付”的一個主要區(qū)別。

“持續(xù)集成”和”持續(xù)交付”，這兩個概念相信大家一定都不陌生，在軟件領(lǐng)域也被提了不少年頭了，不算什么新概念新技術(shù)。但對于這兩個概念，我們經(jīng)常一起提及，也經(jīng)?；煜悴磺宄烧叩膮^(qū)別到底是什么，可能認(rèn)為持續(xù)交付只不過是持續(xù)集成的演進(jìn)版，新瓶裝舊酒而已。

但其實它們卻有著本質(zhì)的區(qū)別。

“持續(xù)集成”關(guān)注的是各個集成單元之前***版本的集成問題，即是不是某個集成單元的***版本破壞了系統(tǒng)整體的集成，我管這種視角叫：向“前”看。

而“持續(xù)交付”關(guān)注的應(yīng)該不是集成單元***版本之間的集成問題，而是某個集成單元的***版本是否可以(能和敢)部署到產(chǎn)品環(huán)境。換句話說就是維持產(chǎn)品環(huán)境的其他服務(wù)不變，只將當(dāng)前集成單元的***版本部署到產(chǎn)品環(huán)境，產(chǎn)品是否依然可用，不被破壞。所以在“持續(xù)交付”的視角下，應(yīng)該關(guān)注的是當(dāng)前集成單元與產(chǎn)品環(huán)境上的其他服務(wù)的版本是否兼容，我管這種視角叫：向“后”看。

向前看是持續(xù)集成，向后看才是持續(xù)交付，如果前后都不看那就是在裸奔。

但是肯定早有同學(xué)在心里疑惑，將E2E測試下放到每一個服務(wù)自己的Pipeline中，靠譜么?是不是太重了?根據(jù)測試金字塔，E2E測試應(yīng)該是屬于靠近金字塔頂端的測試種類，無論從數(shù)量和覆蓋范圍應(yīng)該也都不會太多，怎么能靠它來保障服務(wù)之間的所有集成點(diǎn)和契約呢?

主角登場-契約測試

細(xì)心的同學(xué)肯定已經(jīng)發(fā)現(xiàn)上面***一張圖中，我已經(jīng)悄悄的把E2E測試變?yōu)榱薈T，即Contract Test，契約測試。

契約測試也是這兩年伴隨微服務(wù)架構(gòu)的興起，經(jīng)常被提及的一種比較新的測試類型。在測試金字塔中，他的位置介于E2E和Component Tests(可以理解成單個服務(wù)的API測試)之間。

簡單的理解，契約測試就是一種可以用類似于單元測試的技術(shù)驗證兩兩服務(wù)之間集成的測試技術(shù)。它相比于更低層次的單元測試的優(yōu)勢是可以測集成(兩兩服務(wù)之間)，相比于更高層次的E2E測試的優(yōu)勢是實現(xiàn)方式上又類似于單元測試，更輕量，跑的更快，覆蓋的范圍也自然可以更廣更細(xì)。

使用契約測試替換掉E2E測試之后，整個架構(gòu)也會變得更復(fù)雜一些，目前契約測試的框架也有很多，如大家常常提到的Pact或是SpringContracts等等。這里我先以Pact為例予以說明，其他框架實現(xiàn)上可能有些差別，但是思路是一致的。

A服務(wù)調(diào)用B服務(wù)的一個API，我們就稱為A和B之間存在了一個契約，即B應(yīng)該按照這個契約提供一個滿足契約要求的API，而A也應(yīng)該按照這個契約約定的方式來調(diào)用B的這個API。在這個過程中A作為調(diào)用方，我們稱之為Consumer端。B作為被調(diào)用方，我們稱之為Provider端。

如果A和B都履行契約，按照契約定義的約定調(diào)用和被調(diào)用，我們就可以認(rèn)為集成不會有問題。但無論是B擅自修改了API破壞了契約，還是A擅自修改了調(diào)用API的方式破壞了契約，都會導(dǎo)致契約被破壞，反應(yīng)到測試上就是契約測試會失敗，反應(yīng)到產(chǎn)品上就是功能被破壞，出現(xiàn)Bug。

每個契約，例如A->B，都會有Consumer端和Provider端生成的兩個產(chǎn)出物：分別是a-b.consumer.json.1.1(由Consumer端生成的契約文件，所以版本也是Consumer端A的版本號)和a-b.provider.jar.2.0(由Provider端生成的契約驗證測試包，他由Provider端生成，所以版本是B的版本)。這個jar包其實就是一組測試，他的輸入是a-b.consumer.json，產(chǎn)出則是測試的結(jié)果，也就是契約的驗證結(jié)果：成功或是失敗。

可以把A服務(wù)產(chǎn)出的契約文件a-b.consumer.json.1.1想象成一把鑰匙，把B服務(wù)產(chǎn)出的Provider端的測試a-b.provider.jar.2.0想象成一把鎖。那契約測試的執(zhí)行過程就像是用這把鑰匙試著去打開這把鎖：如果可以打開，我們認(rèn)為這A1.1->B2.0的契約是滿足的，反之契約就是被破壞了。

值得注意的一點(diǎn)就是，契約測試不像E2E測試，它是有方向的，所以我們看到a-b和b-a是兩個不同的契約。

所以，只有當(dāng)A1.1->B2.0和B2.0->A1.1雙向的契約都被驗證通過后，我們才能認(rèn)為A1.1版本和B2.0版本的集成是沒有問題的。

用契約測試替換E2E測試

回到前面的例子上，假設(shè)我們已經(jīng)構(gòu)建了ABC三個服務(wù)兩兩之間的契約測試。此時，A服務(wù)有了新的提交升級到了1.1版本，那我們?nèi)绾尾拍芡ㄟ^契約測試來驗證A1.1版本能否交付到產(chǎn)品環(huán)境呢?

答案就是只要通過A的1.1版本的***代碼，生成所有A作為Consumer端的契約文件(a-b.consumer.json.1.1和a-c.consumer.json.1.1)，用這兩把“鑰匙”去試著開(作為輸入執(zhí)行Provider端測試)產(chǎn)品環(huán)境對應(yīng)的兩把“鎖”(a-b.provider.jar.2.0和a-c.provider.jar.3.0)。

如果都可以打開(測試通過)的話，就證明A的新版本1.1作為Consumer端與產(chǎn)品環(huán)境的B和C服務(wù)是兼容的。

等等，別著急，還沒完……

因為我們還需要考慮A作為Provider的情況，做法還是通過A的1.1版本的***代碼生成A版本作為Provider端的契約測試(b-a.provider.jar.1.1和c-a.provider.jar.1.1)，拿著這兩把“新鎖”，然后試著用產(chǎn)品環(huán)境上的兩把“鑰匙”(b-a.consumer.json.2.0和c-a.consumer.json3.0)去開。

如果也都可以打開(測試通過)的話，就證明A的新版本1.1作為Provider端與產(chǎn)品環(huán)境的B和C服務(wù)也是兼容的。

至此，當(dāng)驗證了A的新版本1.1無論是作為調(diào)用端還是被調(diào)用端都與產(chǎn)品環(huán)境上的其他服務(wù)契約滿足后，我們就認(rèn)為A1.1與B2.0和C3.0集成是沒有問題的，也就代表A1.1可以被放心地部署到產(chǎn)品環(huán)境中，替代現(xiàn)在的1.0版本。

***，敲黑板劃重點(diǎn)

• 微服務(wù)架構(gòu)下的獨(dú)立部署(交付)很重要，但往往容易被忽視，沒有被引起足夠重視。
• 為了實現(xiàn)微服務(wù)的獨(dú)立持續(xù)交付，我們要向“后”看，不要向“前”看，即關(guān)注當(dāng)前變更服務(wù)與部署環(huán)境中其他服務(wù)的兼容性而不是關(guān)注當(dāng)前變更服務(wù)與其他服務(wù)***版本的兼容性。
• 用契約測試來替代E2E測試，降低測試成本，提高測試覆蓋，盡早測試。并通過不斷地完善契約管理，保障微服務(wù)架構(gòu)質(zhì)量和避免微服務(wù)架構(gòu)腐化僵化。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文