引子
随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也应运而生——微服务不是被发明出来的，而是从现实世界中总结出来的一种趋势。
微服务的第一步——高内聚低耦合
低耦合：修改一个服务不需要修改另外一个服务。
能够独立修改及部署单个服务而不需要修改系统的其他部分，这是使用微服务最重要的一点。一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息，意味着应该限制两个服务之间不同调用形式的数量，因为除了潜在的性能问题之外，过度的通信可能会导致高耦合。
高内聚：把相关行为聚集在一起，把不相关行为放在别处。
如果我们要改变某个行为的话，最好能够只在一个地方进行修改，然后就可以尽快地发布。如果需要在很多不同的地方做修改，那么可能就需要同时发布多个微服务才能交付这个功能。在多个不同的地方进行修改会降低速度，同时部署多个服务风险也很高，这两者都是我们想要避免的。
所以，找到问题域的边界就可以确保相关的行为放在同一个地方，并且它们会和其他边界以尽量低耦合的形式进行通信。
持续集成
什么是CI? 我们可以引用Jez Humble（《持续交付》的作者，持续交付的书名来源于敏捷宣言的第一条原则：“我们的首要任务是尽早持续交付有价值的软件并让客户满意。”）提出的三个问题用来测试我们是否真正理解CI。
我们是否每天签入代码到主线？
我们应该保证代码能够与已有代码进行集成。如果我们的代码和其他人的代码没被频繁地放在一起，那么将来的集成就会非常困难。即使我们只使用生命周期很短的分支来管理这些修改，也要尽可能频繁地把代码捡入到单个主线分支中。
我们是否有一组测试来验证修改？
如果没有测试，我们只能知道集成后没有语法错误，但无法知道系统的行为是否已经被破坏。没有对代码进行验证的CI不是真正的CI。
当构建失败后，我们是否把修复CI当作第一优先级的事情来做？
绿色的构建意味着，我们的修改已经安全地和已有代码集成在一起。红色的构建意味着，最后一次修改很可能有问题，这时只能提交修复构建的代码。如果我们允许别人在构建失败时提交更多的修改，用于修复构建的时间就会大大增加。
ThoughtWorks武汉办公室
将持续集成映射到微服务，每个微服务都会有自己的代码库和构建流程。
持续集成
契约测试
契约测试最开始的概念由Martin Fowler（ThoughtWorks首席科学家） 提出， 它又被称之为消费者驱动的契约测试（CDC：Consumer Driven Contracts）。这里的契约是指软件系统中各个服务间交互的数据标准格式，更多的指消费端（client）和提供端（server）之间交互的数据接口的格式。
系统工程中存在这样的理论：线性系统（即复杂性随规模线性增长的系统）的可靠性等于组成它的各个组件的可靠性之乘积。这容易理解，因为整个系统正常工作的条件是必须每个组件都同时正常工作。
线性系统的可靠性
如上图表述的由三个组件共同支撑的系统。如果每个组件的可靠性是90%，那么整个系统的可靠性就是 90%×90%×90%=72.9%，我们可以看到系统整体的可靠度是低于任一组件的可靠性的。如果一个系统由100个组件组成，每个组件即使能达到99%的可靠性，那么整个系统的可靠性也会降到36.6%左右。
我们常说复杂性是软件工程的最重要的特性，一个完善的软件系统必然是由很多的子系统、组件共同撑起来的。随着业务的复杂度越来越高，整个系统也变得越来越庞大和错综复杂，在微服务的架构下通常一个消费端会与多个服务端相互交互，可以想象一下如果某一个服务的接口发生变化将会影响整个系统的运行。
在微服务模式下如何保证各个服务端与消费端之间以及服务与服务之间能够可靠的交互呢？在服务端接口发生变化的情况下通过契约测试可以很容易的测试出契约不匹配，在集成测试之前发现问题，尽早解决。（一般契约测试是在单元测试之后，集成测试之前进行的，首先在保证各自功能正确的前提下测试消费者和提供者的契约是否相匹配，然后再进一步的测试功能的完备性和整个业务流的正确性。）
契约测试
所以，契约测试能解决这样的问题：
可以使得消费端和提供端之间测试解耦，不再需要客户端和服务端联调才能发现问题。
完全由消费者驱动的方式，消费者需要什么数据，服务端就提供什么样的数据，数据契约也是由消费者来决定的。
测试前移，越早的发现问题，保证后续测试的完整性。
通过契约测试，团队能以一种离线的方式（不需要消费者、提供者同时在线），通过契约作为中间的标准，验证提供者提供的内容是否满足消费者的期望。
后记
去中心化与微服务——为了最大化微服务能带来的自治性，我们需要持续寻找机会，给拥有服务的团队委派决策和控制权。让团队与组织保持一致，构建面向业务服务的团队，帮助团队的每个成员共同对系统技术愿景的演化负责。
逐步开始的重要性——在有能力大规模使用微服务之前，请花费一定的时间来构建工具和实践，帮助管理微服务。这个过程可以帮助我们了解组织改变的意愿和能力，这将有助于正确地采用微服务。
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
网友评论