你的微服務敢獨立交付么？
最近經常在項目或是社區里聽到大家談論微服務架構，但談論的焦點更多集中在微服務拆分，分布式架構，微服務門檻，DevOps配套設施等話題上。
但是在我眼里，真正能稱之為微服務架構的少之又少。原因也很簡單，我所見到的很多所謂的微服務架構項目，大多都沒有做到微服務架構的一個基本要求：服務的獨立部署(交付)。
這里的獨立部署和自動化部署還不是一個概念，服務的自動化部署相對簡單，已有大量的工具可以幫助我們做到。但是這里所談的獨立部署，我認為關鍵和難點并不在于“部署”，而在于“獨立”。
如果失去了服務獨立部署(交付)的能力，一個微服務架構的威力將大打折扣，我們的系統雖然在物理上被拆分成了多個小的服務，但是如果從最終交付的角度來看，仍然是以一個整體存在的，就像單體應用一樣，存在諸多的問題。
為什么服務的獨立交付并不簡單?
那為什么不能讓每一個服務都獨立部署到產品環境呢?問題的答案是：不是不能，而是不敢!
為了表達清楚，讓我們來看個例子吧。
像下圖一樣，我現在就是那個程序員帥哥(本色出演)，突然有一天心血來潮，動手開發了一個網上商城。代碼Push到Github并通過CI構建持續交付流水線，最終自動化部署到云端產品環境，供用戶訪問使用。
隨著用戶和訪問量的增加，需求和功能也越來越多，系統也變得越發復雜。
從網上了解到最近有個叫微服務的架構非常火爆，我也趕了回時髦，當然也覺得這種架構確實可以幫助我解決現在的一些問題。
經過對系統的分析，我將商城的后臺部分拆分出了3個服務，為了簡單我們就稱之為ABC三個服務。
我們假設一個比較極端的情況，三個服務相互調用(先不考慮這樣是否合理)，每個服務通過自己的持續交付流水線獨立部署到產品環境。當前產品環境的各個服務的版本是：
A：1.0、B：2.0、C：3.0
一切都非常***是不是?看!我們已經做到了服務的獨立部署!So easy~
當然，事情肯定不會那么簡單。
問題出現在當我對A服務做了一次新的提交之后，A服務的***版本升級到了1.1。不幸的是，這個新的版本意外的破壞了A與B之間的契約，錯誤的調用了B的接口，導致出現了錯誤。
雖然我的A服務和B服務都有比較完備的UT(單元測試)，但因為UT無法發現服務之間的集成是否被破壞，所以只有UT作為質量保障的A服務持續交付流水線也自然沒有能力發現AB服務集成被破壞的這個問題。最終導致存在問題的A1.1版本被部署到了產品環境，產品環境出現了嚴重的Bug。
請問在座的同學，碰到這樣的情況，你會如何處理?
“加集成測試啊!”
這位同學說的極是，我這么聰明自然也想到了這一點，不就是要測集成嗎?UT干不了就加集成測試不就成了。
為了統一語言，畢竟對于各種測試的叫法太容易引起混淆，參考Martin Fowler在《微服務測試策略》中的定義，我們在本文中將這種測試多服務集成的測試統一稱作端到端測試(End-to-End tests，簡稱E2E測試)。
添加了E2E測試之后，我的交付流水線就變成了下面這個樣子。
因為有了E2E測試的存在，問題迎刃而解，當A服務的新版本破壞了與B服務的集成時，E2E測試就會及時診斷出來，并阻止A服務的***版本向產品環境流動，保證產品環境不被破壞。
這樣看似沒有什么問題，通過添加E2E測試，解決了服務間集成的驗證問題，但在不知不覺中，我們也失去了微服務架構的那個重要的特性：“服務的獨立交付”。
怎么講?別急，我們再往下看。
假設A服務的修復過程中，B和C服務也提交了新的代碼，我們假設這兩個提交是沒有問題的，但因為A服務的1.1版本導致E2E測試掛掉的問題還沒有被修復，所以B和C的新版本也被E2E測試攔了下來，此時的E2E測試就像是一個亮起紅燈的路口，阻塞了所有服務通往產品環境的通道。
所以說，隨著集中E2E測試的添加，質量被保障的同時，我們的“微服務架構”也已悄然失去了服務獨立交付的能力，殺敵一千自損八百，損失慘重!
這并不是我假想的場景，在我自己經歷的幾個真實項目中，這個問題都在一直困擾著我們。帶來了各種各樣的衍生問題，例如E2E測試長時間失敗，無人修復，修復難度大，服務交付堵塞，為了保持交付通路暢通還不得不引入同樣存在很大副作用的CodeFrezze機制和提交Token機制等。
可以看到，雖然我們能夠在代碼庫，在部署結構上，甚至在組織上進行服務化拆分，但就因為這***一個交付的十里路口，***這一個紅綠燈，讓所有的服務又糾纏在了一起，所有的服務化拆分形同虛設，最終我們得到的也只是一個看起來像微服務架構的單體應用而已。
拆除紅綠燈，各行其道，收復失地!
那，如何才能將這個“紅綠燈”拆除，讓服務可以在有質量保障的前提下還可以做到獨立交付呢?這就是本文要解決的問題，讓我們繼續往下看。
我的解決方法其實也很簡單：Inline E2E tests。
即并不添加新的集中的Pipeline做E2E測試，而是為每一個服務的Pipeline都添加一個相同的E2E測試的Stage，就相當于將E2E測試Inline到每個服務各自的部署流水線中，如下圖所示。
其實Inline E2E測試還不是最關鍵的，最關鍵的變化點就是假設A服務有了新的提交，運行到A服務自己Pipeline的E2E測試的時候，此時的E2E測試并不是像之前一樣獲取B和C服務的***代碼庫版本做集成驗證，而獲取當前產品環境上的B和C服務的已部署當前版本做集成驗證。
例如，如圖所示A服務的版本從1.0升級到了1.1，當前產品環境的B和C的版本是2.0和3.0。在執行A服務Pipeline上的E2E測試時，驗證出A1.1和B2.0集成存在問題，測試變紅，Pipeline掛掉，從而阻斷了A服務的1.1版本部署到產品環境，保證了產品環境不會被A的1.1版本破壞。
同樣，假設A還沒有被修復之前，B也有了新的提交，產生了一個新的版本B2.1，這時在B服務Pipeline上的E2E測試并不獲取當前A服務的代碼庫***版本1.1做集成測試，而是獲取產品環境上的當前版本A1.0版本做集成測試。我們假設B2.1和A1.0之間的集成沒有問題，測試通過，所以B的2.1版本就被成功的交付到了產品環境，而此時產品環境的A服務的版本仍是1.0。
看!服務之間的阻塞被神奇的解決了，服務再也不會被堵在一個統一的十字路口，而是各行其道，A的車道出了事故，是A的問題，應該由A來承擔后果和解決問題，不應該影響到其他服務，其他服務依然可以持續的交付到產品環境。
向前看是持續集成，向后看是持續交付!
看到這里可能有些小伙伴會感到有些失望。咋呼半天，不就是將E2E測試整到每個服務的Pipeline里，再把獲取版本從***代碼改成產品環境么?有啥厲害的。
但是，在我看來，這個看似簡單的變化，意義卻是重大的：它揭示了“持續集成”和“持續交付”的一個主要區別。
“持續集成”和”持續交付”，這兩個概念相信大家一定都不陌生，在軟件領域也被提了不少年頭了，不算什么新概念新技術。但對于這兩個概念，我們經常一起提及，也經常混淆，搞不清楚兩者的區別到底是什么，可能認為持續交付只不過是持續集成的演進版，新瓶裝舊酒而已。
但其實它們卻有著本質的區別。
“持續集成”關注的是各個集成單元之前***版本的集成問題，即是不是某個集成單元的***版本破壞了系統整體的集成，我管這種視角叫：向“前”看。
而“持續交付”關注的應該不是集成單元***版本之間的集成問題，而是某個集成單元的***版本是否可以(能和敢)部署到產品環境。換句話說就是維持產品環境的其他服務不變，只將當前集成單元的***版本部署到產品環境，產品是否依然可用，不被破壞。所以在“持續交付”的視角下，應該關注的是當前集成單元與產品環境上的其他服務的版本是否兼容，我管這種視角叫：向“后”看。
向前看是持續集成，向后看才是持續交付，如果前后都不看那就是在裸奔。
但是肯定早有同學在心里疑惑，將E2E測試下放到每一個服務自己的Pipeline中，靠譜么?是不是太重了?根據測試金字塔，E2E測試應該是屬于靠近金字塔頂端的測試種類，無論從數量和覆蓋范圍應該也都不會太多，怎么能靠它來保障服務之間的所有集成點和契約呢?
主角登場-契約測試
細心的同學肯定已經發現上面***一張圖中，我已經悄悄的把E2E測試變為了CT，即Contract Test，契約測試。
契約測試也是這兩年伴隨微服務架構的興起，經常被提及的一種比較新的測試類型。在測試金字塔中，他的位置介于E2E和Component Tests(可以理解成單個服務的API測試)之間。
簡單的理解，契約測試就是一種可以用類似于單元測試的技術驗證兩兩服務之間集成的測試技術。它相比于更低層次的單元測試的優勢是可以測集成(兩兩服務之間)，相比于更高層次的E2E測試的優勢是實現方式上又類似于單元測試，更輕量，跑的更快，覆蓋的范圍也自然可以更廣更細。
使用契約測試替換掉E2E測試之后，整個架構也會變得更復雜一些，目前契約測試的框架也有很多，如大家常常提到的Pact或是SpringContracts等等。這里我先以Pact為例予以說明，其他框架實現上可能有些差別，但是思路是一致的。
A服務調用B服務的一個API，我們就稱為A和B之間存在了一個契約，即B應該按照這個契約提供一個滿足契約要求的API，而A也應該按照這個契約約定的方式來調用B的這個API。在這個過程中A作為調用方，我們稱之為Consumer端。B作為被調用方，我們稱之為Provider端。
如果A和B都履行契約，按照契約定義的約定調用和被調用，我們就可以認為集成不會有問題。但無論是B擅自修改了API破壞了契約，還是A擅自修改了調用API的方式破壞了契約，都會導致契約被破壞，反應到測試上就是契約測試會失敗，反應到產品上就是功能被破壞，出現Bug。
每個契約，例如A->B，都會有Consumer端和Provider端生成的兩個產出物：分別是a-b.consumer.json.1.1(由Consumer端生成的契約文件，所以版本也是Consumer端A的版本號)和a-b.provider.jar.2.0(由Provider端生成的契約驗證測試包，他由Provider端生成，所以版本是B的版本)。這個jar包其實就是一組測試，他的輸入是a-b.consumer.json，產出則是測試的結果，也就是契約的驗證結果：成功或是失敗。
可以把A服務產出的契約文件a-b.consumer.json.1.1想象成一把鑰匙，把B服務產出的Provider端的測試a-b.provider.jar.2.0想象成一把鎖。那契約測試的執行過程就像是用這把鑰匙試著去打開這把鎖：如果可以打開，我們認為這A1.1->B2.0的契約是滿足的，反之契約就是被破壞了。
值得注意的一點就是，契約測試不像E2E測試，它是有方向的，所以我們看到a-b和b-a是兩個不同的契約。
所以，只有當A1.1->B2.0和B2.0->A1.1雙向的契約都被驗證通過后，我們才能認為A1.1版本和B2.0版本的集成是沒有問題的。
用契約測試替換E2E測試
回到前面的例子上，假設我們已經構建了ABC三個服務兩兩之間的契約測試。此時，A服務有了新的提交升級到了1.1版本，那我們如何才能通過契約測試來驗證A1.1版本能否交付到產品環境呢?
答案就是只要通過A的1.1版本的***代碼，生成所有A作為Consumer端的契約文件(a-b.consumer.json.1.1和a-c.consumer.json.1.1)，用這兩把“鑰匙”去試著開(作為輸入執行Provider端測試)產品環境對應的兩把“鎖”(a-b.provider.jar.2.0和a-c.provider.jar.3.0)。
如果都可以打開(測試通過)的話，就證明A的新版本1.1作為Consumer端與產品環境的B和C服務是兼容的。
等等，別著急，還沒完……
因為我們還需要考慮A作為Provider的情況，做法還是通過A的1.1版本的***代碼生成A版本作為Provider端的契約測試(b-a.provider.jar.1.1和c-a.provider.jar.1.1)，拿著這兩把“新鎖”，然后試著用產品環境上的兩把“鑰匙”(b-a.consumer.json.2.0和c-a.consumer.json3.0)去開。
如果也都可以打開(測試通過)的話，就證明A的新版本1.1作為Provider端與產品環境的B和C服務也是兼容的。
至此，當驗證了A的新版本1.1無論是作為調用端還是被調用端都與產品環境上的其他服務契約滿足后，我們就認為A1.1與B2.0和C3.0集成是沒有問題的，也就代表A1.1可以被放心地部署到產品環境中，替代現在的1.0版本。
***，敲黑板劃重點
- 微服務架構下的獨立部署(交付)很重要，但往往容易被忽視，沒有被引起足夠重視。
- 為了實現微服務的獨立持續交付，我們要向“后”看，不要向“前”看，即關注當前變更服務與部署環境中其他服務的兼容性而不是關注當前變更服務與其他服務***版本的兼容性。
- 用契約測試來替代E2E測試，降低測試成本，提高測試覆蓋，盡早測試。并通過不斷地完善契約管理，保障微服務架構質量和避免微服務架構腐化僵化。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
