传统的应用结构通常是单体应用。有统一的数据库、UI层、控制层和逻辑层，虽然有分模块，但是在代码层面都是聚集在一起的。如果是一个简单应用，这不是什么问题，但是随着业务越来越复杂，应用也变得越来越复杂、逐渐变成一头大“怪兽”，维护和后续开发变得越来越困难，牵一发则动全身。交付周期越来越长，交付风险越来越高，应用本身也变得越来越难理解，新人对它的学习周期也会非常长。
在这个背景下， 微服务架构应用而生。如同我在前一篇学习笔记中记录的：微服务不是被发明出来的，而是从现实世界中总结出来的一种趋势。
微服务架构就是把整个应用按照业务拆分成独立的应用。它具备如下特征：
每个应用可独立开发、部署和扩容，甚至有独立的数据库；
每个应用的职责单一、松耦合，和其他应用通过远程接口调用，没有代码依赖；
每个应用的开发、查错和变更速度快（基于以上原因），它能更快地响应业务需求，提高敏捷性；
由于采取去中心化架构，每个应用可以采取完全不同的技术栈以及不同的开发语言，在技术选型上自由度大。
这个世界上是没有“银弹”的。微服务架构降低了每个微服务应用的复杂性，却增加了整个架构的复杂性。其实只要业务是复杂的，系统的整体复杂度就不会降低，只是体现在不同的层面上而已。微服务架构大大增加了集成测试、部署、监控等方面的复杂性。所幸诸如契约测试、容器和Spring Cloud框架等技术的出现大大降低了解决这些问题的难度。
所谓的契约测试是基于消费者驱动契约测试的理念的、API之间的集成测试，涉及彼此独立的不同系统和依赖，相当复杂和昂贵，会大大拖慢交付进度。API存在提供者和消费者两个角色。提供API的一方称为提供者，调用API的一方称为消费者。在开发时，双方根据消费者的验收条件拟定一份契约，契约放在一个双方都可以访问的公共区域，双方通过运行这份契约来测试彼此是否满足要求。这个手段可以使双方的开发过程解耦，解除测试的依赖关系，而且实现像单元测试那样得快速和稳定。目前有Pact和Spring Cloud Contrac两个框架支持契约测试。在微服务架构下，应用之间都是通过Restful API互相调用，契约测试解决了微服务集成测试难的问题。
