​​​​​​​​​​​​​​​​​​​​​​​​​​​摘要：本期和大家簡單聊聊在服務互動場景下使用服務契約的重要性，以及契約管理的必要性，最後簡單介紹了下契約測試。​

1、服務互動帶來的問題

我們簡單畫下一個系統應用的內部服務的呼叫關係：交付一個大的系統可能涉及到多家ISV進行整合，每家ISV自己又存在前端、閘道器、後端等多個微服務，且各自ISV或者服務均存在自己的SE、開發和測試人員，都有自己相對獨立的版本演進，服務之間存在呼叫關係。

思考一下，這會帶來哪些問題呢？

透過介面文件或者表格管理介面內容，服務互動雙方、多方頻繁對接互動呼叫的介面資訊，頻繁重新整理，剪不斷、理還亂，讓人崩潰；服務依賴導致必須等待底層服務先開發完成才能聯調對接和整合測試，效率低下；此時如果發現被呼叫服務介面不滿足要求、介面缺失、介面無法聯調等問題時，需要重新等待版本聯調，造成資源和時間上的浪費；服務都在不停的向前演進，呼叫服務與被呼叫服務的版本會隨著外部需求增加、Bug修改、程式碼重構等等因素而導致介面發生變更，介面呼叫服務往往無法及時獲取介面變化而導致整體業務受損。2、服務契約——服務互動問題的一種解決方案

如何解決服務間紛紛複雜的聯調問題呢？本章節我們來聊一聊契約與契約測試。

顧明思義，契約就是一份由雙方或多方共同訂立的、具有強制遵從性的信用文書。契約測試全稱消費者驅動契約測試(Consumer Driven Contracts Testing)，最早見於2011年。“消費者驅動契約測試”名稱中清楚描述了“契約”、“誰提供契約”的問題。

一般來說，是消費者(Consumer)把自己對輸入和輸出的資料結構、效能已經併發性等期望以約定的格式告訴服務提供者(Provider)，服務提供者簽署同意，這就形成了一份服務契約，服務提供者對所有消費者的契約取並集進行服務能力開發，形成自己服務的對外承諾或者schema。

模型如下：消費端服務 A、B、C 呼叫訪問服務提供端服務A，消費端服務 A、C服務提供端服務B。服務提供端會根據消費端期望分別生成1份契約檔案，以滿足消費端的訴求。

服務之間透過契約互動會帶來哪些好處呢？

1）、使用契約，介面呼叫雙方的對接、問題定界等都有“法律依據”，問題不會扯不清、道不明、來回甩鍋。

2）、使用契約，就確定了交付雙方的介面形式和入口與出口期望，消費端和服務提供端可以並行開發服務，並且在開發過程中就利用契約進行預整合測試，不需要等待聯調再來整合測試，大幅降低聯調溝通成本。

3）、因為契約的存在，可以整體看到服務消費端的原有介面使用情況，讓介面的變動有跡可循，即使變動也可以確保變動的安全性和準確性。

4）、消費端也能透過契約的變化獲知服務端的API變化情況。

3、契約互動的問題

在第二章節我們看到契約的基本流程。在正常的契約測試流程中，契約由消費者提供，服務者遵從，根據消費者的提供的契約完成服務測試。但是，大家思考下這種模式存在什麼樣的問題？我們思考下一下的問題：

雙方的契約有了，但是口頭協議空口無憑，契約如何儲存，以及如何才能防篡改？郵件互動、會議紀要難以維護？在敏感市場，消費者提供的契約是否符合正常訴求與合規？在多ISV服務商、多部門協作的應用系統，消費者頻繁重新整理契約要求怎麼辦？正常需要重新整理契約怎麼處理、契約怎麼會退或者回溯？消費端驅動，會不會造成消費端權力過大，話語權過重，倒逼服務提供端，最終也會導致整個系統不倫不類？

從上面的幾個問題可以看出，由於契約很重要，那麼設計和管控契約也就顯得更加重要。

4、契約設計與契約管理的必要性

互動的問題並不像想象的那邊簡單，為了解決契約設計和管控的問題，我們新增一個設計管控和契約管理的環節。

設計管控環節類似於議會這種機溝通和決策機構，用於調停和審視契約的合理性、合規性和更改的必要性，且對於多消費者的契約做合併處理。

契約管理環節，解決契約儲存、訪問認證和不可篡改性、可追溯性和可回退等問題。這樣就避免了前面所說的問題，當然犧牲了一定了靈活性，但是在大型系統中，這樣行為是值得的。

我們看下，消費者的契約的生成和下載過程就變成如下流程：

同時，如果服務端要主動變更契約，也要得到消費端和審視委員會的透過，稽核透過合入後，消費者和服務提供者從契約管理平臺下載契約使用。流程變得如下：

5、契約測試

前面的章節，我們花了較多篇幅介紹了契約的生成和契約在服務互動過程中的作用以及重要性，那麼對契約的測試也很重要。下面我們簡單聊聊如何對契約進行測試。

契約測試不是元件測試，契約測試和核心也是透過API來進行。每個消費者只會關注自己的期望是否得到滿足，所以只需要根據自己提供的、已稽核透過的契約檔案進行測試。而服務提供端則需要滿足所有消費者的訴求，需要拿所有消費者的契約做測試，所有契約需要測試透過。如下所示：

由於實際開發中，契約簽訂之後，Consumer和Provider是同步開發，所以Consumer和Provider也是分別測試。一般的契約測試過程如下：

Consumer服務的測試環境，需要使用契約進行Mock Provider服務進行構建：

Provider服務的測試環境，則需要根據和Consumer簽署的契約檔案生成的契約測試用例進行測試，透過測試契約用例驗證自己提供的介面是否滿足消費者需要，介面是否有變更。一旦介面發生變更，契約測試用例會執行失敗。

前面所述，契約是消費者(Consumer)把自己對輸入和輸出的資料結構、效能已經併發性等期望以約定的格式告訴服務提供者(Provider)，服務提供者簽署同意後形成的，那邊契約測試的主要內容也便是這幾個方面：

支援契約測試的工具有Pact、Pacto、Janus、CloudTest，Swagger也能滿足部分要求。一般來說，業界使用Pact工具的較多，簡單說下Pact工具的過程，具體Pact用法請參照官網：

Consumer測試：

Provider測試：

我們也補充下Pact工具的優缺點

6、微服務下的服務契約樣例

契約一般是一個yaml檔案或者json檔案的格式，我們以CSE微服務的契約為展示樣例：