微服务架构的开发原则

微服务的开发还会面临依赖滞后的问题。例如：A要做一个身份证号码校验，依赖服务提供者B。由于B把身份证号码校验服务的开发优先级排得比较低，无法满足A的交付时间点。A会面临要么等待，要么自己实现一个身份证号码校验功能。

以前使用单体架构的时候，大家需要什么，往往自己就写什么，这其实是没有太严重的依赖问题。但是到了微服务时代，微服务是一个团队或者一个小组提供的，这个时候一定没有办法在某一个时刻同时把所有的服务都提供出来，“需求实现滞后”是必然存在的。

一个好的实践策略就是接口先行，语言中立，服务提供者和消费者解耦，并行开发，提升产能。无论有多少个服务，首先需要把接口识别和定义出来，然后双方基于接口进行契约驱动开发，利用Mock服务提供者和消费者，互相解耦，并行开发，实现依赖解耦。

采用契约驱动开发，如果需求不稳定或者经常变化，就会面临一个接口契约频繁变更的问题。对于服务提供者，不能因为担心接口变更而迟迟不对外提供接口；对于消费者，要拥抱变更，而不是抱怨和抵触。要解决这个问题，一种比较好的实践就是管理+技术双管齐下：

（1）允许接口变更，但是对变更的频度要做严格管控。(www.xing528.com)

（2）提供全在线的API文档服务（如Swagger UI），将离线的API文档转成全在线、互动式的API文档服务。

（3）API变更的主动通知机制，要让所有消费该API的消费者能够及时感知到API的变更。

（4）契约驱动测试，用于对兼容性做回归测试。