消费者驱动的契约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。