消费者驱动的契约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
出处：
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-petter liu blog。