消費者驅動的契約Consumer drivern Contract

消費者驅動的契約Consumer Driven Contracts (CDC)

A contract between a consuming service and a providing service, stating what the consumer wants from a providing service, in a defined format.

     CDC有那麼些特色：

• 在啓動階段，服務功能的描述必須能在多種場合下被重用：粒度既不能粗到僅在一種特定場合下能被重用，也不能細到要作大量補充工做方可在不一樣場合下被重用。
• 在構建服務時，咱們必須確保提供者與消費者可彼此獨立地進行演化。若是一項服務功能的消費者們必須隨提供者改變而改變，那麼該服務就不是真正鬆耦合的。
• 在運營服務時，咱們須要理解各個服務之間的關係，以便咱們能夠診斷問題、評估服務可用性（availability）發生變化（經常是去除）時將產生的影響、併爲各服務針對新的或變化的業務需求而演化設計計劃。

    消費者驅動的契約，以下圖

      消費者驅動的契約（Consumer-driven contracts）——消費者驅動的契約描述的是服務提供者向其全部當前消費者承諾遵照的約束。一旦各消費者把本身的具體指望告知提供者，消費者驅動的契約就被建立了。在提供者方面建立的約束，肯定了一個消費者驅動的契約。若提供者接受了一個消費者驅動的契約，那麼它只需保證已有約束仍能獲得知足，便可自行改進與修改其服務。

      關於這些外部化的交互與行爲，關鍵之處在於它們表示的是對業務有意義的東西，它們若不發生，業務活動的某部分就沒法繼續或完成。在各方之間發生的業務事件、文檔交換和對話過程當中，服務符合之處就是系統內在價值顯露的地方。消費者驅動的契約反映了一個業務團體、功能或能力爲完成其工做而對另外一個夥伴的指望。

     在一個通過良好構造的服務資產中，真正重要且有用的結果是經過若干對等服務之間的交互實現的，將一個服務與一組分散的業務目標與利益對應起來並不是易事。

      爲了認識到服務所提供的具體利益與結果，咱們須要在其協做上下文之中來理解該服務。這就是消費者驅動的契約發揮做用之處：消費者驅動的契約描述了對服務羣落的協做指望，它經過其更爲直觀的成對關係、有效地把全體參與者間接感知的價值串連了起來。消費者驅動契約試圖在團隊之間定義一些明確的溝通界限。CDC 的整體流程是，消費者定義他們指望 API 消息是什麼樣子。這種指望就稱爲契約。從這些契約能夠生成存根，稍後，消費者團隊能夠在構建過程當中重複使用它們。在生產者一端也須要驗證契約。那就致使，不論是測試生產者一端，仍是測試消費者一端，都須要引入一種快速失敗方法。對於快速失敗，咱們指的是軟件構建失敗以及經過產品調試發現問題.

     Dubbo 是一個 RPC 框架，它和全部的 RPC 同樣，有一個最小運行子集，它須要 Provider、Consumer，以及一個服務註冊發現相關的東西，在 Spring Cloud 裏面是叫服務註冊發現，在 Dubbo 裏面咱們叫它註冊中心

讓咱們看看Dubbo 的整個啓動過程

• Provider 導出一個服務，這個服務就是可被調用的；
• 第二步，往註冊中心註冊這個服務；
• Consumer 這端會來訂閱相關的服務，若是註冊中內心面，Provider 列表有變化的話，它也會獲得通知；
• Consumer 會根據必定的路由規則從註冊中心拿到 Provider 列表，再根據必定的負載均衡策略，精確地調用到某臺 Provider 上去。

 

Spring Cloud 體系

Spring Cloud Contract

思考

     CDC are not a silver bullet. There are a number of things CDC do not cover. To start with, they are not a test of business logic. That should be covered by your service’s unit tests.

關於測試

     端到端測試至關脆弱。有許多和代碼 Bug 無關的緣由能夠致使它們失敗。我不是說端到端測試沒有帶來任何價值——偏偏相反。當複雜度達到必定程度時，必須計算成本和收益。消費者驅動契約能夠解決問題。若是消息違反了契約，那麼執行契約測試能夠提前終止構建。換句話說，若是你的消息中有錯誤，那麼最好在構建的第一分鐘就失敗，而不是在 2 個小時的端到端測試的最後一分鐘。

     更好的作法是：讓負責交付消費者應用與服務的團隊來編寫他們本身的消費者測試，並把這些測試交給服務提供者。各個消費者把本身的一個基於測試的消費者契約交給服務提供者——提供者從各消費者處收到的契約集合便構成了它的消費者驅動的契約。接着，消費者能夠參照它們本身的契約進行開發，並相信提供者也將參照一樣的指望進行開發。這樣作，即可以把契約整合到雙方的開發線之中。

      向後 / 向前兼容性原則依然對版本化服務極爲重要，但消費者驅動的契約有助於根據現有的約束與關係來在大環境中考慮兼容性問題。

The CDC wish list，咱們須要自查，是否知足：

1. A consistent format to describe requests and responses between provider and consumer
2. An easy way to create contracts
3. A way of storing the created contracts
4. A way of testing our services against the contracts, in an automated way, in our CI/CD pipeline
5. A way of running these tests locally

這樣是有效的方式,  模擬提供者

再看 模擬Consumer

           你們不要語言的約束，理解模式本質，從開發到測試是緊密相聯的，基於實際場景使用。

更多參考：

CDC官方

https://martinfowler.com/articles/consumerDrivenContracts.html

---

今天先到這兒，但願對技術領導力， 企業管理，系統架構設計與評估，團隊管理, 項目管理, 產品管理,團隊建設 有參考做用 , 您可能感興趣的文章:
精益IT組織與分享式領導
領導人怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
學習型組織與企業
企業創新文化與等級觀念
組織目標與我的目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網數據庫架構設計思路
IT基礎架構規劃方案一(網絡系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

若有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關注個人微信訂閱號：

做者：Petter Liu
出處：http://www.cnblogs.com/wintersun/ 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。 該文章也同時發佈在個人獨立博客中-Petter Liu Blog。