我今晚看看

我们以前曾经尝试在项目中试点 cdc（消费者驱动的契约测试），技术用的是 spring cloud contract ，但后面发现用处不大。

主要原因是，实际项目中虽然微服务间通讯很多，但服务间基本都是通过使用 rpc 的方式来调用（例如 dubbo），schema 是以 java 代码（service 定义接口，model 定义具体数据内容）形式定义并把所有抽离成单独的 Jar 包供所有使用方以依赖项形式引入。双方都通过同样的 java 代码相互调用，基本不大会存在契约被破坏的情况。即使是一个 provider 多个 consumer ，由于用的 java 代码一致，也不存在契约字段数量、类型等对不上契约测试关注的问题点。

至于 provider 或者 consumer 单方面调整协议导致另一方无法通讯，只要 provider 在修改时保证向下兼容即可（如 service 和 model 都只做增加），实在无法兼容的，通知对应所有契约使用方更新依赖 jar 包版本也可以解决。

当然，也有一个很大的原因时，我们微服务的总服务数量不多，在 20 个以内，provider 提供的契约最多也就给 2-3 个服务使用，且都是同一个团队或者沟通非常密切的团队。所以契约测试里提到的沟通不顺畅、同步不到位导致部分服务无辜被契约变更受累的问题也基本不怎么会出现。

你说的没错, dubbo 的引用机制可以确保调用参数方法正确, 所以不要在 java 之间想这个事情, 想一下, 每个 UI 其实也是 consumer, 每个 h5 都是 consumer...是不是开朗些了