微服务架构下的质量迷思——混沌工程

从2005年Peter Rodgers博士提出微web服务，到2014年ThoughtWorks首席科学家Martin Fowler与James Lewis共同提出微服务概念至今已多年，这期间也是互联网及互联网+发展的高速期，消费市场变化莫测，消费者也变得越来越挑剔，很多公司和产品由于无法跟上市场的快速变化而纷纷倒下。越来越多的互联网巨头甚至传统行业都开始对自己的遗留系统进行微服务改造，通过把系统拆分为更加灵活、有业务边界上下文、松散耦合、可独立部署的服务来应对快速变化的消费市场。

微服务架构面临的挑战

通常情况下，对于复杂业务或遗留系统，我们可以通过领域驱动设计(DDD:Domain-Driven Design)有效的解决限界上下文划分、服务边界定义以及组织结构调整等问题。除了这些，我们的开发团队还面临着其他的挑战：复杂的分布式系统、数据一致性、容错设计、限流设计、舱壁设计等问题。那么如此复杂的系统如何来保证系统“质量”呢？

长久以来，“测试金字塔”都是敏捷开发团队保证项目交付质量的守则，而“测试金字塔”也确实从不同的维度涵盖了方法调用、业务逻辑、用户行为等方面。为了确保在进行复杂的调用和被调用时，服务之间能有一定程度上的一致性和快速反馈，我们会第一时间想到“契约测试”，“测试金字塔”也演化成了另一个样子。

下图，我们聚焦于微服务架构的业务服务层，在API测试之外在基础服务的调用方和提供方之间增加了契约测试：

在微服务和前后端分离日趋流行的今天，契约测试的确可以在系统频繁演进、重构的情况下保证服务间调用的可用性，而在“聚合服务层”通过API测试，可以暴露服务的组合过程中的问题。“尽早测试”可以让团队在初期发现更多的问题，降低后期修复成本，同时让服务与服务之间具有“感知力”，任何与契约不符的业务变更都能被测试所感知。但是，既然契约测试是保证服务调用方和提供方的一致性，更直接说，是另一种对API的验证，那么契约测试只能覆盖到业务逻辑维度，如果想更好开发或改造微服务系统，就需要相对深入的了解微服务有哪些特性：

我们可以看到，这个简单的图中提到了一些微服务的特性(基于Spring Boot)：客户端负载均衡、微服务容错保护、API服务网关、分布式链路跟踪等，我们不对这些进行解释，但毫无疑问，契约测试无法覆盖和测试到这些特性，同时也无法模拟例如网络延迟、CPU