消費者驅動的契約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，我們需要自查，是否滿足：
- A consistent format to describe requests and responses between provider and consumer
- An easy way to create contracts
- A way of storing the created contracts
- A way of testing our services against the contracts, in an automated way, in our CI/CD pipeline
- A way of running these tests locally
這樣是有效的方式, 模擬提供者
再看 模擬Consumer
大家不要語言的約束，理解模式本質，從開發到測驗是緊密相聯的，基于實際場景使用，
更多參考：
CDC官方
https://martinfowler.com/articles/consumerDrivenContracts.html
今天先到這兒，希望對技術領導力， 企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管理,團隊建設 有參考作用 , 您可能感興趣的文章:
精益IT組織與分享式領導
領匯入怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下訊息佇列架構
互聯網高效研發團隊管理演進之一
訊息系統架構設計演進
互聯網電商搜索架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商云平臺實踐
互聯網資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之采購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變
如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱號：
![MegadotnetMicroMsg_thumb1_thumb1_thu[2]](https://img.uj5u.com/2020/09/15/69464150417047.jpg "MegadotnetMicroMsg_thumb1_thumb1_thu[2]")
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，
該文章也同時發布在我的獨立博客中-Petter Liu Blog，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/42051.html
標籤：架構設計
上一篇：23.網市場云建站系統部署
下一篇：CDN原理加速決議