toni_liao的专栏

首先，服务提供者利用contract的目的抛开给消费者提供确定的接口规格桩外，对于服务提供者自身，是形成一个测试发起者的模拟（mock），向协议脚本中定义的服务URL（REST API如此，消息队列是另外的参数，不在本文中深究）提交预期定好的请求，服务提供者此时的服务实现应该已经完成开发并能响应，contract将会在测试方法中对响应进行比对验证，所有要素的符合预期的话，则达到了验证服务有效性、正确性的目的。

笔者的经验认为，微服务的出现，是为了应对传统SOA架构在多服务背景下的疲软，本质上是SOA的进一步衍生，是一种治理服务的手段。而微服务解决得了传统SOA、单块大单体程序的问题，依赖于微服务自身的健壮性、灵活性、可扩展性和持续敏捷，这些特性是通过持续集成、持续交付来落实的。而持续集成、持续交付的逻辑前提是：应对变化（主动也罢、被动也罢）时所开展的持续修改、完善需要尽量的顺滑，避免各种各样的问题导致卡停。这些问题主要来源于软件开发的老短板，比如修改和扩展后代码的有效性、可信度。新的功能需要快速被验证。

持续集成的原因和价值