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

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

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

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

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

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

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

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

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

從網(wǎng)上了解到最近有個(gè)叫微服務(wù)的架構(gòu)非常火爆，我也趕了回時(shí)髦，當(dāng)然也覺(jué)得這種架構(gòu)確實(shí)可以幫助我解決現(xiàn)在的一些問(wèn)題。

經(jīng)過(guò)對(duì)系統(tǒng)的分析，我將商城的后臺(tái)部分拆分出了3個(gè)服務(wù)，為了簡(jiǎn)單我們就稱(chēng)之為ABC三個(gè)服務(wù)。

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

A：1.0、B：2.0、C：3.0

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

當(dāng)然，事情肯定不會(huì)那么簡(jiǎn)單。

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

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

請(qǐng)問(wèn)在座的同學(xué)，碰到這樣的情況，你會(huì)如何處理?

“加集成測(cè)試啊!”

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

為了統(tǒng)一語(yǔ)言，畢竟對(duì)于各種測(cè)試的叫法太容易引起混淆，參考Martin Fowler在《微服務(wù)測(cè)試策略》中的定義，我們?cè)诒疚闹袑⑦@種測(cè)試多服務(wù)集成的測(cè)試統(tǒng)一稱(chēng)作端到端測(cè)試(End-to-End tests，簡(jiǎn)稱(chēng)E2E測(cè)試)。

添加了E2E測(cè)試之后，我的交付流水線(xiàn)就變成了下面這個(gè)樣子。

因?yàn)橛辛薊2E測(cè)試的存在，問(wèn)題迎刃而解，當(dāng)A服務(wù)的新版本破壞了與B服務(wù)的集成時(shí)，E2E測(cè)試就會(huì)及時(shí)診斷出來(lái)，并阻止A服務(wù)的***版本向產(chǎn)品環(huán)境流動(dòng)，保證產(chǎn)品環(huán)境不被破壞。

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

怎么講?別急，我們?cè)偻驴础?/p>

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

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

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

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

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

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

我的解決方法其實(shí)也很簡(jiǎn)單：Inline E2E tests。

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

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

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

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

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

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

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

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

“持續(xù)集成”和”持續(xù)交付”，這兩個(gè)概念相信大家一定都不陌生，在軟件領(lǐng)域也被提了不少年頭了，不算什么新概念新技術(shù)。但對(duì)于這兩個(gè)概念，我們經(jīng)常一起提及，也經(jīng)常混淆，搞不清楚兩者的區(qū)別到底是什么，可能認(rèn)為持續(xù)交付只不過(guò)是持續(xù)集成的演進(jìn)版，新瓶裝舊酒而已。

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

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

而“持續(xù)交付”關(guān)注的應(yīng)該不是集成單元***版本之間的集成問(wèn)題，而是某個(gè)集成單元的***版本是否可以(能和敢)部署到產(chǎn)品環(huán)境。換句話(huà)說(shuō)就是維持產(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測(cè)試下放到每一個(gè)服務(wù)自己的Pipeline中，靠譜么?是不是太重了?根據(jù)測(cè)試金字塔，E2E測(cè)試應(yīng)該是屬于靠近金字塔頂端的測(cè)試種類(lèi)，無(wú)論從數(shù)量和覆蓋范圍應(yīng)該也都不會(huì)太多，怎么能靠它來(lái)保障服務(wù)之間的所有集成點(diǎn)和契約呢?

主角登場(chǎng)-契約測(cè)試

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

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

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

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

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

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

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

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

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

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

用契約測(cè)試替換E2E測(cè)試

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

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

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

等等，別著急，還沒(méi)完……

因?yàn)槲覀冞€需要考慮A作為Provider的情況，做法還是通過(guò)A的1.1版本的***代碼生成A版本作為Provider端的契約測(cè)試(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)去開(kāi)。

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

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

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

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

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

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