消費者驅動的契約Consumer Driven Contracts (CDC)A contract between a consuming service and a providing service, stating what the consumer wants from a providin... ...
消費者驅動的契約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 體系
思考
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,企業信息化, 團隊管理 資訊,請關註我的微信訂閱號:
作者:Petter Liu
出處:http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。
該文章也同時發佈在我的獨立博客中-Petter Liu Blog。