契约测试有生成者驱动的契约测试，也有消费者驱动的契约测试；二者之间的异同？消费者端的集成测试需要做到什么程度？微服务测试不仅仅是契约测试，比如端到端的测试等
微服务测试之契约测试
微服务概述
本章目标
* 理解微服务的概念
* 理解微服务与传统开发模式的区别
什么是微服务
微服务的前身，Peter Rounder 在云端计算博览会首次提出 Micro Web Service 这是最早的概念，但还不是微服务；直到 2014年，一个叫做 Martin Flow 的人和 James Lilies 共同提出微服务的概念；Martin Flow也是敏捷开发的创始人，在设计架构，软件开发，重构，面向对象分析等都是一个开创者的角色；国内在 2016年时，开始像这个方向迈进
微服务可以从两方面理解，微和服务
微狭义的讲，就是微小；亚马逊老板贝索斯曾经提出量披萨团队，单个服务的设计，所有人参与只需要两个披萨就可以；因为规模小，服务就简单
服务区别于系统，服务是一组相对较小，并且独立的功能单元，这是用户可以感知到的最小功能集
1.微服务的具体定义
○ 从本质上来讲微服务是一种架构模式
○ 它是面向服务架构SOA的一种变体。（SOA面向服务型架构）
■ 本质上还是SOA，但是微服务不像SOA那样要求绑定具体的技术。微服务鼓励用恰当的
技术去实现合适的服务，这样系统的扩展性会变得很强。
提倡将单一应用程序划分为一组小服务，服务和服务之间相互协调配合，（比如食堂打饭，每个窗口是一个服务，窗口之间有相互联系）为用户提供最终的价值，本质上是SOA架构，但和SOA并不同
微服务架构下，不绑定特殊技术，每个服务都可以使用自己独立的技术栈，比如有些服务用java实现，另外的服务用python，服务之间不受影响，服务之间通过 Rest Full API 进行访问
○ 每个服务运行在自己独立的进程中，服务与服务之间利用Rest API来进行沟通，把不同的服
务有机的整合成一个统一的系统
这一点和SOA是不同的，SOA要求技术架构是一样的
○ 每个服务都围绕着自己的业务来构建，并且可以独立的部署到类生产环境中。
每个服务运行在自己独立的进程中，服务之间通过Rest API沟通，本质上就是 http 协议通过 Rest API 沟通，连接成整体，每个服务都围绕具体的业务构建，并且每个服务都能够独立部署到环境中
注意尽量避免统一的集中式的管理机制，对具体的业务应该选择合适的工具和技术
2.为什么需要微服务
LAMP(Linux+Apache+MySQL+PHP)
MVC(Spring+MyBatis/Hibernate+Tomcat)
单体式架构(Monolithic Architecture)
早些年，各大公司的项目主流技术，大概分为两派，一个是 LAMP Linux+阿帕奇+MySQL+PHP
另外一个主流技术是 MVC Hibernate 数据持久化
基本上就是这两大阵容，一个是 PHP 一个是 java，他们过去都是单一的应用架构设计
这种设计方式优点是学习成本低，开发速度块，测试部署运维都比较方便，有些项目甚至一个人就可以完成；
比如 MVC 架构，通常是打一个包，丢到 Tomcat 中
早起 项目规模不大时，利用这种单一的应用架构模式，团队的开发和运维成本基本是可控的
随着各个行业的业务拓展，服务越来越复杂，软件功能越来越多，这种方式就对企业的技术进行了限定，早期系统的对接和未来新系统和技术的变化，都产生了一定困难
项目的切换时间和成本都比较高，系统稳定性问题的解决时间也比较多
这种早期的传统的开发模式就是单体式架构
微服务就是用来解决这些不方便的，新技术雨后春笋般的飞快发展，要让企业和技术跟上时代进步，项目开发需要变的更加容易，更具扩展性；这些就是微服务诞生的基础
微服务与传统开发方式的区别
■ 单体式架构
○ 优点
■ 团队组织结构简单，便于集中管理
■ 开发进度一致，统一管理，能够避免重复开发的问题。
■ 所有的功能都在本地，没有远程调用的开销和网络损耗
○ 缺点
■ 效率低
■ 维护困难
■ 不够灵活
■ 稳定性不好
■ 扩展性不够
所有功能打包在一起，项目没有对外的依赖，唯一的依赖大概就是数据库；业务逻辑，前端显示等等都是整合在一起的
这种架构的好处就是开发团队的组织架构简单，可以集中管理，开发流程也是统一的，同时也可以避免重复开发，所有功能都在一台运行机器上，访问都是本地操作，基本上没有网络延时，远程调用的损耗。
但是，也有明显的缺点，现在软件应用越来越复杂，功能越来越多，对于项目的更新迭代速度越来越高，就像 Intel 总裁说的，如今市场不是大鱼吃小鱼，而是快鱼吃慢鱼，要求企业对产品和项目有快速更新迭代的能力，这样单体式架构就会力不从心，等待和修改冲突，对于开发来说是一个很高的成本，而且代码都在一个项目下，所以代码的内部耦合比较大，新接手项目的同事通常不知道bug位置在哪里，修复后，也需要对整个项目进行更新
单体式项目的稳定性也是比较差，整个项目在 tomcat 中，任何地方出现问题就会导致整个项目挂掉
■ 微服务架构
○ 优点
■ 解决上面单体式架构项目的所有缺点
■ 部署、回滚变得更加快捷
■ 每个服务都可以独立的扩容
■ 每个服务都可以采用适合自己业务需求的技术栈来实现
■ 可以运用插件的形式来更新系统，不必有一点扩充就要重新部署整个项目
■ 对于业务的数据可以采用数据接口的方式来方便未来业务发展后的数据管理与数据迁移
○ 缺点
■ 每个子系统都有独立的团队，这个会增加整个系统内部的通信需求，也会增加不同团队的交流成本
■ 对于这种分布式架构的系统进行测试时，复杂度大大提高了
■ 分布式系统的部署对于团队DevOps能力要求很高
■ 当系统的服务增加时，管理的复杂度也会呈指数级增加。
所以，微服务架构应运而生，解决单体式架构中的问题，核心理念是按业务功能，业务边界，把单体式项目拆分成一个个的子系统，每个子系统由单独的开发团队开发，他们之间保持合作，而不是整合的关系，只需要把子系统的边界，也就是接口定义好，这样每个团队就可以独立工作了，每个子系统的内部产生沟通成本，每个子系统是一个高内聚的系统，系统和系统之间的耦合关系就变弱了，仅仅只是一个请求，这样系统和系统之间的成本就变低了
图中，每个服务都变的简洁，服务和用户通过简单的 http 协议沟通和访问，微服务不仅能够解决单体式服务所面临的问题，微服务还有一些独特的优点，比如可以更快部署，每个子系统可以单独部署，独立运行，更新服务时，只需要更新子系统即可
每个服务自己可以独立扩容，服务本身在开发时，还可以在技术上有所改变，只要定义的接口不变，用什么技术实现是没有要求的，每个子系统可以使用适合自己业务逻辑的技术实现
整个项目的技术就不会被限制于某种特定的技术，比如 C 适合于快速，运算量大的计算，对于控制硬件比较优秀，java适合web的动态服务，Python脚本解释型语言比较快捷
微服务架构就是一个分布式系统，测试的复杂度大大提高，这是微服务的缺点，微服务的测试，除了考虑业务逻辑，还要考虑中间的通信成本，不同团队的沟通成本，都对测试提出了挑战
DevOps （开发运维）的要求，自动化部署的要求也相应提高，因为不止有一个包，每个项目都要有自己的环境。服务数量的增加会带来可怕的复杂度的增长，这就是微服务的缺点。