微服务测试的思考与实践

评论

最近几年，微服务架构越来越火爆，逐渐被企业所采用。随着软件架构的变化，对应的软件测试策略需要作何调整呢？本文将介绍微服务架构下的测试策略，并结合分享在业务和架构演变过程中，一个历经九年的项目测试策略的演进。

关于微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体的业务进行构建，并且能够被独立部署到生产环境、预生产环境。

从微服务的概念可以看出它有如下好处：

  • 每个服务可以独立开发
  • 处理的单元粒度更细
  • 单个服务支持独立部署和发布
  • 更有利于业务的扩展

同时，独立开发导致技术上的分离，HTTP通信加上Queue的机制增加了问题诊断的复杂度，对系统的功能、性能和安全方面的质量保障带来了很大的挑战。另外，服务间的复杂依赖关系带来了很多的不确定性，要实现独立部署，对运维也提出了更高的要求。微服务架构的系统要特别关注这几个方面：

  • 服务间的依赖、连通性
  • 服务的容错、可用性
  • 数据的最终一致性
  • 独立部署
  • 不确定性

测试策略的选择

谈到微服务的测试策略，很容易就想到了老马推荐的文章《Microservices Testing》，该文推荐的微服务框架下的测试策略是这样的：

（经典策略模型）

这个策略模型强调测试分层以及每一层的恰当覆盖，整体符合金字塔结构。它是最优的吗？

有人对此提出了质疑…认为策略模型应该是蜂巢形状的（请参考文章）：

（蜂巢模型）

这个模型重点关注服务间的集成测试，两端的单元测试和UI层E2E测试较少。

也有同事提出微服务下的测试结构应该是钻石形状的，服务间的集成依然是重点，单元测试较少，而顶层增加了安全和性能等非功能测试。

（钻石模型）

好像都有道理，到底选择什么样的策略模型好呢？不禁陷入了困境……怎么办？不妨先来听听我们项目的故事吧！

项目的故事

测试策略的演进

还是那个蓝鲸项目，不知不觉进入了第九个年头。在这九年里，随着业务的不断发展，系统架构也进行了多次演进和调整。相应的，测试策略也发生了有意思的演进变化。

（测试策略的演进）

最初单一用户系统、单体架构的时候，严格按照测试金字塔来组织各层的自动化测试。随着功能的扩展，大量mock的单元测试给重构带来了很大的不便。

企业系统开始开发的时候，我们调整了策略，减少单元测试的编写，增加UI层E2E测试的覆盖，测试结构由原来的金字塔演变成上面梯形下面倒三角的形式。

后来，架构调整，开始服务化。此时，大量的E2E测试渐渐暴露出问题：

  • CI上的测试执行时间越来越长，而且定位问题的能力很弱，测试一旦失败需要很长时间修复，测试人员好几天也拿不到可以测试的版本，反馈周期过长；
  • 由于服务化带来的不稳定因素增加，E2E测试没法很好的覆盖到需要的场景，测试人员就算拿到可测的版本也总有各种缺陷发生。

因此，项目引入契约测试，停止编写新的E2E测试，将测试下移，分别用API测试和契约测试取代。

随着功能的不断增加，虽然E2E测试的量并不增加，但是其不稳定性、维护难、定位难的问题有增无减，此时已经很难由自动化测试来保证产品的质量。为了平衡成本和收益，项目考虑去掉大部分E2E测试，只保留少量的Smoke测试，将更多的测试下移。

同时，技术雷达上新的技术“生产环境下的QA”出现，项目也开始关心生产环境，并且在QA测试阶段结合微服务的特点进行对应的探索式测试。

应对微服务的挑战

前文提到过微服务带来的挑战，下面来看项目是如何应对这些挑战的。

服务间的依赖、连通性

微服务架构下，独立开发的服务要整合起来最具挑战，如何保证服务间的依赖关系和连通性非常关键。前面已经讲过E2E集成测试有很大的挑战，并不适合，而消费端驱动的契约测试是个不错的选择。项目正是利用契约测试去保证服务间的连通性，取代一部分E2E集成测试。

服务的容错、可用性

在系统负荷达到一定程度或者某个服务出现故障的时候，微服务架构有两种技术来确保系统的可用性：服务的熔断和降级。服务的熔断是指当某个服务出现故障时，为了保证系统整体的可用性，会关闭掉出现故障的服务；服务的降级则是当系统整体负荷过载的时候，考虑关闭某些外围服务来保证系统的整体可用性。

对应的测试包括：

  1. 熔断：从性能角度，当系统负载达到某个熔断状态的时候，服务是否能正确熔断；同时，从功能角度验证熔断后系统的行为是否跟预期相符；
  2. 降级：从业务的角度，要能区分出核心业务和外围业务，在需要降级的时候不能影响核心业务；当某个服务降级后，从功能角度验证系统行为是否跟预期相符。

数据的最终一致性

（数据一致性）

数据一致性是微服务特别需要关注的。举个例子，电商平台某个订单支付成功以后，需要更新积分和订单状态，当订单服务或者积分服务其中有一个出现故障的时候，就会导致最终的数据不一致性。

测试这种情况，从业务的角度分析哪些服务会导致数据不一致性，制造对应的异常情况去测试数据的最终一致性。

独立部署

微服务的独立部署需要有CI、CD的支持，跟DevOps实践分不开。同时，更为关键的是需要契约测试来验证独立部署后服务行为的正确性。项目在这方面的工作，请参考王健的文章：你的微服务敢独立交付吗？

不确定性

微服务架构使得系统复杂度增加不少，很多的事情发生都是不可预测的，只能在其发生以后找到产生的原因。因此，也就没法在预生产环境通过测试去发现在真实生产环境才会发生的issue，我们需要把目光转移到生产环境，利用生产环境的不确定性、微服务的不可预测性来构建反脆弱的系统。

项目在这方面主要采用的技术是生产环境下的QA，请参考文章：生产环境下的QA

项目测试策略

从前面介绍的演进过程可以看到，项目测试策略在不同阶段结合参考了不同的策略模型：金字塔->近似钻石（除非功能测试外，类似于钻石模型）->蜂巢。后期全面服务化的时候，我们认为蜂巢模型是比较适合的。

当然，光有符合这个策略模型的自动化测试是远远不够的，我们项目还采用了针对微服务特点的探索式测试，保持持续交付节奏，践行DevOps实践，结合生产环境下的QA等技术把关注点右移到生产环境。

现在，项目整体测试策略演变成下图的形式：

（项目测试策略）

  1. 项目采用的是敏捷迭代开发和持续交付的模式，每四周一个发布周期。
  2. 在开发过程中实现的自动化测试是分层实现的：底层少量的单元测试，中间量最多的是API测试（类似于老马策略模型里的组件测试），上面有一部分契约测试和少量的Smoke测试来保证服务间的契约和集成。除此之外，QA有手动的探索式测试，其中包括针对微服务特点进行的一些测试。整个测试结构是类似于蜂巢模型的。
  3. 采用生产环境下的QA技术，利用生产环境，进行error监控、用户行为分析、用户反馈收集，从而来影响和指导预生产环境的开发和测试工作。
  4. 利用DevOps实践，做到高效的部署和监控，跟生产环境下的QA结合，形成良性的环路，保证项目的正常交付。

测试策略再思考

项目上多次测试策略的调整，看似很简单，其实每次调整并不是一个轻松的过程，都是平衡利弊、综合考虑多个因素才做出的决定。

分析整个调整过程，最后突然发现：当我们面对多个策略模型不知道如何选择的时候，其实我们陷入了一个太过于关注测试结构的误区，忘记了最初的目标是什么。

影响测试策略的因素

跳出误区，回到原点，重新思考测试策略的目标。影响策略的最关键因素是业务价值、质量要求、痛点。

（影响测试策略的因素）

业务价值

带来更大的业务价值、帮企业赢得更多的利润，是软件系统的目标；软件测试是软件系统成功的保障之一，业务价值也是测试策略的终极目标。所有测试活动都要围绕这个目标开展，考虑业务优先级，有效规避业务风险。

质量要求

不同的系统、同一系统的不同利益干系人（参与的不同角色）对于质量的定义和要求都可能是不同的，这毫无疑问是影响测试策略的一个关键因素。

对于仅有内部用户的系统，关注的重心可能是系统的功能；而对外发布的产品，则要求更高，一个按钮位置的不恰当都可能带来大量用户的流失。

痛点

真正的痛点往往也是优先级最高，迫切需要解决的。那些可以通过测试策略的调整来解决的痛点，自然成为了关键的影响因素之一。比如，CI Pipeline出包太慢，为了提高出包的效率，一方面在Pipeline本身想办法，另一方面调整自动化测试的比例、执行频率等也是解决方案之一。

演进式测试策略

处在不同阶段的项目，在业务价值这个大目标下，其他影响因素也是会不一样的，跟技术架构的演进一样，测试策略也应该是演进式的。

从目标出发，综合所处阶段各个方面的影响因素，制定出适合当时的测试策略。随着时间的推移，对策略进行评估和度量，并进一步改进、提高，以更好的满足需求。这就是目标驱动的演进式测试策略。

（演进式测试策略）

总结

微服务架构下多个服务的整合是最具有挑战的，对此最重要的是契约测试。契约测试有效保证服务间的契约关系不被破坏，确保服务的连通性，有助于实现真正的独立部署和独立交付。

微服务架构引入的不确定性并不是坏事，可以利用这些不确定性，采用生产环境下的QA等技术，增强系统的反脆弱性，从中获益。

测试策略的影响因素不是唯一的，技术架构并不是最关键的因素。微服务架构下的测试策略跟其他架构下的并不会有本质的区别。

业务价值始终是我们的终极目标。在这个终极目标的驱动下，测试策略不是制定完了就可以束之高阁的，需要在整个软件系统构建过程中不断的度量和改进，是演进式的。

更多精彩洞见，请关注微信公众号：思特沃克

Share

讨论微服务之前，你知道微服务的 4 个定义吗？

1 条评论

关于“什么是微服务”的问题，其实并没有一个统一的认识。这些年在不同的场合里和不同背景的朋友都在探讨微服务。但聊得越多，越发现大家聊的不是同一回事。和 DevOps 一样，“微服务”也是一个内涵十分广泛的词。本文从“Microservice“这个概念的源头出发，总结了 4 个常用的微服务定义。

James Lewis 原始版的微服务 6 大特征

这个版本起源于2012年，这里首先要注意年份，那时候还没有 Docker，而且 Netflix 的微服务化过程也在这个概念提出之前——2008年就开始了，那时候甚至连 DevOps 还没发明出来。James Lewis 在波兰第 33 次 Degree in Kraków 会议上分享了一个案例，名称是 “Micro Services – Java, the Unix Way”。在这个分享里， James Lewis 分享了在 2011 年中参与的一个项目中所采用的一系列实践，以 UNIX 的哲学重新看待企业级 Java 应用程序，并且把其中的一部分称之为“ Micro-Services ”。

这个时候的微服务所用的单词和我们现在所用的 Microservices 这个单词有所不同。一方面，采用 Micro 作为形容词，是和 Monolithic 相对，而不是和 Macro 相对是源于操作系统这门大学课程。我们知道，现代的操作系统课程都是以 UNIX 作为案例进行讲解的。而这两个单词来自于“微内核”（Micro-Kernel）和“宏内核”（Monolithic kernel）的比较。而非常见的“微观经济学”和“宏观经济学”中的 Micro 和 Macro 两个相对应的单词。

另一方面，服务要以复数形式出现，表示的是一个以上。由于汉语里单复数是同型的，所以我们在翻译的时候会出现问题。因此，“微服务”在作为架构的形式出现的时候，我们会用“微服务架构”称呼。单个的微服务从概念上为了和 SOA 以及其它领域的“服务”有所区分，会以“单个微服务”以示区别。而“微服务”单独拿出来是被看作为一系列技术实践的总称。

在这个分享里，James Lewis将所实践的“微服务架构”总结为 6 大特征：

  1. Small with a single responsibility —— “小到只有单一原则”在这个特征里，关于微服务有多小有两个标准：第一个标准是如果一个类复杂的超过一个开发人员的理解范围，那么它就太大了，需要被继续拆分。第二个标准是：如果它小到可以随时丢弃并重写，而不是继续维护遗留代码，那么它就足够小。这个标准有个很重要的原则就是 Rewrite over Maintain，即“重写胜于维护”。
  2. Containerless and installed as well behaved Unix services —— “去容器化并且作为 Unix Service 安装”在这个特征中，James Lewis 提倡采用 Jetty 这样的工具集成到 Maven 里，可以很方便的调试或者部署，然后打包成一个可执行的 JAR 包并以 UNIX 守护进程的方式在系统启动时执行。特别是在 AWS 这样的公有云环境下，把这样的应用程序和虚拟机实例的初始化脚本结合在一起。使得应用程序的生命周期和虚拟机的生命周期绑定成为一体，由于守护进程在所有 Unix 系统中都是通用的，因此简化整体架构的开发和运维。
  3. Located in different VCS roots ——“分布在不同的版本控制代码库里”在这个特征中，James Lewis 提到了应用程序的分离，他认为一个“微服务”应该完全和另外一个服务实现彻底的隔离，这里当然是指的从开始的代码库就开始隔离了。他同样也要求开发人员看到相似性和抽象，并采用单一的领域来指导开发团队的开发。因此接下来他继续讨论了领域驱动设计领域驱动设计和康威定律的重要性。他认为界限上下文要足够的清晰，但可以有所重合。如果没有办法做到领域之间很清晰，就通过“物理上的手段”——分离不同的团队来做到这一点。这不可避免的带来一些公共代码，但要把这些公共代码作为“库”和“基础设施即代码”来对待，就像你代码中用到的开源软件。并搭建一个 nexus 库来存储那些二进制依赖
  4. Provisioned automatically ——“自动初始化”自动初始化的要点不在于如何自动化，因为不同的应用不同的平台有不同的初始化方式。这里的重点在于管理分布式应用的复杂性。所以对于每个服务，能够采用声明出这些初始化。例如：服务 A，需要一个 负载均衡，并且可以自动扩展。服务 B，也是同样的声明方式。而这些声明可以用基础设施即代码技术很好的管理起来。
  5. Status aware and auto-scaling ——“关注状态和自动扩展”在这里，他认为这些应用应该是能够感知吞吐量的监控指标来自我进行扩展的。对于一个现代的应用而言，这是一个基本的架构性要求，但这需要团队有一定的 DevOps 能力。因为这不光要求开发人员能够让应用无状态化，而且要求基础设施可以及时捕获环境的变化。
  6. They interact via the uniform interface —— “它们通过统一格式的接口进行交互”在这里，James 建议大家采用已经成熟的 HTTP 协议以及标准的媒体类型进行接口交互，而不是采用其它的方式。并且采用HATEOAS（Hypermedia As The Engine Of Application State） 的方式构建 Restful API，使其成为一个超媒体的应用状态引擎。这样就可以将状态和执行过程隔离区分开来，更加容易进行水平扩展。此外，它也构建了一个避免架构孵化的层，可以独立于客户端持续演进。

在总结的时候，它特意提到了 UNIX 哲学。这引用自Doug McIlroy 的一篇采访：

Everybody started putting forth the UNIX philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.” Those ideas which add up to the tool approach, were there in some unformed way before pipes, but they really came together afterwards. Pipes became the catalyst for this UNIX philosophy. “The tool thing has turned out to be actually successful. With pipes, many programs could work together, and they could work together at a distance.”

从这段话里，我们看到了“微服务架构”和 UNIX 哲学之间的关联：

  1. 职责独立：让多个程序（注意是 Programs 不是 Program）做好一件事。
  2. 统一接口：文本流是统一的接口，每个程序都可以通过统一的接口进行消费。
  3. 公共通信：采用管道（pipe）的方式可以说，微服务架构本身是对 UNIX 哲学在企业级 Java 应用系统中的另一个案例。

可以说，虽然应用场景变了，但 UNIX 分解复杂度的方式和保持简单的理念并未改变。

最后，James Lewis 把上述六点特征变成了一个六边形的业务能力：

Hexagonal Business capabilities composed of: Micro Services that you can Rewrite rather than maintain and which form A Distributed Bounded Context. Deployed as containerless OS services With standardised application protocols and message semantics Which are auto-scaling and designed for failure

翻译过来就是：

微服务可以通过重写而非维护一个分布式的界限上下文，且作为一个无应用容器的操作系统服务部署。并以标准化的应用协议和消息语义，为失败设计且可自动扩展。

Martin Fowler & James Lewis 合作版的微服务 9 大特征

由于在 James Lewis 之后，有很多不同的项目也采用“微服务”作为它们的实践名称。然而，不同项目之间还是存在一些差异的，且每个人都按照自己的方式在实践“微服务”。因此，基于“求同存异”的原则，Jame Lewis 的同事 —— 大名鼎鼎的 Martin Fowler 采用一种归纳的方式来解决这个问题：他认为“定义”是一些“共有的特征”(Common characteristics)。Martin Fowler 继续采用了 James Lewis 对这一系列实践的命名，并且做了修改，使之成为一个单独的名词 —— Microservices。

所以，他将微服务总结为以下9大特征：

  1. 通过服务组件化
  2. 围绕业务能力组织
  3. 是产品不是项目
  4. 智能端点和哑管道
  5. 去中心化治理
  6. 去中心化数据管理
  7. 基础设施自动化
  8. 为失效设计
  9. 演进式设计

这 9 大特征的中文版具体内容请参考这里，限于篇幅原因，本文不展开讨论。

我们可以从中看出，Martin Fowler 试图将 James Lewis 的微服务定义进行一般化推广，使其不光可以在不同的语言架构和技术栈上使用。又可以兼顾敏捷、DevOps 等其它技术，成为一个架构的“最佳实践”集合。但这样一组实践本质上并没有太多的创新，只是把我们本身知道的很多架构和设计的原则结合在当前的技术栈上进行了一次整体的组合和应用。

恰逢一系列互联网公司的成功事迹带来的新实践（持续交付、DevOps）和新技术（Docker）在经历了早期实践者（Early Adopter）实践积累后的结果井喷后。这样的最佳实践的集中反应固然得到了技术人员的掌声。然而，这种定义对于妄图采用“微服务架构“的人来说是一个很高的门槛。如果这样的 9 个特征的总结是对”微服务架构“的定义。那么，为了要满足以上的 9 个定义，则需要花费很大的精力来进行改造，而且已经超出了技术升级和企业 IT 部门的职责范围。此外，即便我们知道其中每个特征所带来的收益，但却很难拿出案例和数据去佐证满足这 9 个特征的改造收益。

避开这 9 个特征的概念正交性不谈，即便这 9 个特征可以从既有的结果来回答”什么（What）是微服务“，但却没有给出“为什么（Why）要满足这些特征”和”如何（How）同时满足这些特征”。

如果自己挖的坑填不了，就教给别人来填吧：

Sam Newman 版微服务的两大特征和 7 个原则

同样作为 Martin Fowler 的同事，Sam Newman 在其著作 “Building Microservice”（中文译名为“微服务设计”）的第一章就重新回答了”什么是微服务架构“并回答了”为什么要采用微服务架构“的问题。

Sam Newman 在书中是这么定义微服务的（《微服务设计》的翻译）：

微服务就是一些协同工作的小而自治的服务。

Sam Newman 自述的微服务的定义更加简单，包含了两个特征：“小” 和 “自治”。

除了继承 James Lewis 关于微服务应该有多小的描述以外（当然，大小都是基于个人的主观判断），还创造性的用康威定律来约束微服务的大小，即“能否和团队结构相匹配”：如果你的团队维护单个服务很吃力，需要保持团队大小不变的情况下还对维护工作游刃有余，那么这个服务就需要继续被拆分。

而“自治” 则很谨慎的把 Martin Fowler 微服务定义的 9 大特征中的“去中心化”、“独立” 、”松散耦合“等字眼进行了统一。并进一步解释到“一个微服务就是一个独立的实体”。并且从外部，也就是黑盒的角度来看每个符合”自治”的单个微服务所具有的特征，即：

  1. 可以独立部署。
  2. 通过网络通信。
  3. 对消费方的透明。
  4. 尽可能降低耦合，使其自治。

此外，他还采用了更简单的“黄金法则”来判断期”自治性”。即能否修改一个服务并对其部署，且不影响其他任何服务。如果答案是否定的，说明你的微服务还不够”自治“。

从 Sam Newman 的定义中，我们可以推导出“微服务”的几个基本事实：

  1. 微服务架构是一个分布式系统架构。
  2. 微服务是微服务架构的基本单元。
  3. 网络隔离是“必要的”解耦手段。
  4. 微服务的业务功能从概念上是完整的，并符合用户角度的“独立”认知。

简而言之，以上的两个特征的表述主要是将微服务从逻辑架构上和部署架构上都看作是一个正交的原子功能单元。而要做到这一点，则需要而要把整个应用系统正确的建模到这个层次，则需要参考很多的内部外部因素。

此外，为了达到“小”和“自治”的目的，Sam Newman 还总结了 7 条原则用来在实施的时候和具体实践结合，分别是：

  1. 围绕业务概念建模
  2. 接受自动化文化
  3. 隐藏内部实现细节
  4. 让一切都去中心化
  5. 可独立部署
  6. 隔离失败
  7. 高度可观察

可以看出，Sam Newman 把 Martin Fowler 的 9 大特征用更加具体的术语来重新描述，并且从逻辑上处理了 Martin Fowler 微服务 9 大特征中概念重复和不明确的部分，使其更简单和明确并且更加可操作。例如把“去中心化的数据管理” 和 “去中心化治理”合并为“让一切都去中心化”等。

更重要的是，Sam Newman 提出了采用微服务技术的主要好处，告诉了我们“为什么要用微服务”：

  1. 技术异构性：采用更合适的技术栈灵活的处理局部问题。
  2. 弹性：这里的“弹性”是弹性工程学的概念，指的是局部失败会被隔离，使得整体不会失败。
  3. 扩展：可以根据系统的部分组件按需扩展。
  4. 简化部署：这里简化部署不是指的是部署的拓扑结构，而是通过持续的小批量、小范围的部署来降低整体失败的风险。
  5. 与组织结构相匹配：微服务架构可以让组织的团队转化为合适的大小，并采用透明的制度来进行规范和复制。避免团队的人数增长而带来更多的管理层，使组织熵的上涨。
  6. 可组合性：由于各个微服务间不存在依赖关系，所以可以根据用户界面的情况进行灵活的调整和复用，避免对单体应用进行整体的大规模调整。
  7. 对可替代性的优化：由于风险和领域更加独立和隔离。因此，抛弃一个微服务并重写的成本并就变的十分低廉。

Chris Richardson 的“微服务架构模式”

2017 年，Chris Richardson 使用 Microservices.io 域名开始推广自己的微服务理念。他是这样定义微服务的：

Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.

中文翻译过来，大意如下：

微服务，也就是微服务架构。是一种用于把一个应用程序结构化为一个实现业务功能的松散耦合的服务集合的架构风格。 微服务架构使得在大型、复杂的应用程序中实现持续交付和持续部署成为可能。它使得组织可以演进自己的技术栈。

在 Chris Richardson 采用了较为简单的架构定义和准确的目标定义相结合的方式来定义”微服务架构“：它一方面简单的把微服务架构定义成一个实现业务功能的松散耦合的服务集合，另一方面又以十分具体的目标和结果（持续交付/持续集成）来约束这样一个松散耦合系统的效果：组织可以演进自己的技术栈。

Chris Richardson 将“单体架构”和“微服务架构”看做两种架构模式。并且在同样的上下文中对二者各自的优劣进行了比较。更加重要的是，Chris Richardson 采用 AFK 扩展立方来拆分微服务从而回答了“如何做微服务”的问题。

值得注意的是，Chris Richardson 所采用的例子虽然在同样的上下文中，但由于特征不同并不具备可比较性。因此，他采用了在“单体架构模式”（Pattern: Monolithic Architecture）的基础上描述其局限性的方法引出了“微服务架构模式”（Pattern: Microservice Architecture）。严格的说，Chris Richardson 的“单体架构模式”是一种对现状的和举例，并没有给出其特征和方法的描述，因此不能称之为模式。而“微服务架构模式”则又是一系列模式的总和，如下图所示：

从这个角度看，Chris Richardson 的这些模式并没有突破 Sam Newman 在《微服务设计》中总结出的实践。但相较于我们所知道的微服务的优点。Chris Richardson 也列出了微服务的缺点：

  1. 开发者的 IDE 对分布式系统的在线开发和调试相对于单体应用架构来说并不友好。
  2. 测试更加困难。
  3. 开发者必须实现跨服务的通信机制。
  4. 不采用分布式事务来跨服务构建业务是十分困难的。
  5. 需要进行跨团队的协调工作。
  6. 部署更加复杂。
  7. 更多的内存消费，对于 Java 应用来说，独立的部署意味着无法共享 JVM 的内存管理。

相较于之前的微服务定义而言， Chris Richardson 的微服务体系比较完整，而不仅仅是总结和列举实践。Chris Richardson 的”微服务架构模式”不光回答了“什么是（What）微服务”，也回答了“为什么（Why）要用微服务”，“什么时候（When）用微服务”，“什么场景（Where）下”以及“如何（How）实现微服务”的问题。

Chris Richardson 还编写了一套微服务的指南，可以在这里查看。

比“什么是微服务”更重要的事

本文总结了微服务常见的 4 个定义。但比这些定义更重要的是你为什么要用微服务？你想从微服务中获得什么益处？你是否了解为了追求这些益处所带来的代价？如果不先明确这些问题，在不理解微服务架构或者技术所带来的的风险和成本。盲目的采用所谓的微服务，可能带来的结果并不理想。

不过，在讨论这些问题之前，坐下来统一一下对微服务的理解，会提升我们讨论和实践微服务的效率。

更多精彩洞见，请关注微信公众号：思特沃克

Share

识别领域事件

1 条评论

随着微服务架构的兴起，微服务设计与拆分的的最佳实践DDD已然成为大家讨论与实践的热点，整个行业都在探索如何用DDD建模来实现微服务设计。事件风暴作为最接地气的实践，在不同的项目中野蛮生长，不断演进，今天已经渐渐成熟。作为事件风暴的灵魂——领域事件，值得我们投入更多的精力去设计与打磨。

领域事件是用特定方式(已发生的时态)表达发生在问题域中的重要事情，是领域通用语言(UL)的一部分。为了方便理解这个概念，这里举一个宠物的例子：如果做为宠物主人，你的问题域是如何养好一只猫，那么是不是已经打了疫苗，给宠物饲喂食物等将成为你关注的事情，领域事件会有：疫苗已注射，猫粮已饲喂等。如果你是宠物医生，问题域是如何治好宠物的病，关注的事情是宠物的身体构成，准确的诊断宠物病情，对症下药，领域事件会有：病情已确诊，药方已开治。虽说二者关注的都是宠物，在不同的问题域下领域事件是不同的。

DDD的提出者和圈内的大师先后提到领域事件在领域建模中的价值，前沿实践者们已经开始应用领域事件来表达业务全景。在DDD建模过程中，以领域事件为线索逐步得到领域模型已经成为了主流的实践，即：事件风暴。

事件风暴是以更专注的方式发现与提取领域事件，并将以领域事件为中心的概念模型逐渐演化成以聚合为中心的领域模型，以快速可落地的方式实现了DDD建模。

对于高质量的事件风暴，首先要解决识别领域事件的问题，理想的情况下领域专家和研发团队一起参加事件风暴，从业务的视角去分析涉众关心的领域事件，短时间内高度可视化交流，集中思考，快速发散收敛形成所有参与者一致认可的领域事件集合。我在多个项目上实现事件风暴后，总结了一些坑和应对办法，供大家参考：

1. 组织没有领域专家

对问题域有深刻见解的主题专家称为领域专家，在大多数组织中没有这个角色，当DDD建模需要领域专家支持时，组织往往找业务部门的业务人员，BA，产品经理或在这个领域有多年开发经验的DEV来充当。

这些一线业务人员和开发团队都清楚有什么功能，但往往不清楚为什么有这些功能。举个例子：如果我们的问题是打开一瓶红酒，你去调研每天都会打开酒瓶的waiter, 给你的答案是：开瓶器。但换做领域专家的视角来看，会回归问题的本质，如果我们希望打开酒瓶，需要把瓶塞移除，移除瓶塞的方式有多种，包括推，撬与拉拽，对于拉拽可能基于吸力或螺旋拉拽，下面右图的开瓶器只不过是螺旋拉拽的一种解决方案。领域专家应该对问题域及其中的各种可行方案有更深入的理解。

在辅导团队的过程中，为了弥补这部分视角的缺失，往往会在事件风暴之前，组织业务愿景和场景分析，与被指派的业务干系人对齐业务愿景，一起分析业务场景背后的问题域，找到问题域的本质后再展开事件风暴。

2. 面向复杂业务系统的事件风暴

高效事件风暴的规模推荐5-8人，超过8人的事件风暴就会出现讨论时间过长，部分成员参与度不高，业务之间的相关度弱等问题。在一个以支付中台为主题的事件风暴中，对于电商商城的支付与理财产品的支付相关性就很弱，各自关心的是自己的业务，让这两组人在一起讨论，在得到同样产出的情况下，会花费双倍的时间。

在处理复杂问题时，一个有效又好用的方法就是分而治之，对于复杂系统的事件风暴也是同样如此。在业务干系人达到一定规模后，将业务干系人分成多组，组织多轮事件风暴，迭代演进领域模型也是一种不错的选择。

分组的基本原则应以业务线为线索，如果目标系统的业务干系人在同一个业务主线上，每一组人代表业务主线上的一个环节 (如下图)，这种情况按照业务结点进行分组即可。对于业务相对简单的结点，可以将其与相临结点合并组织事件风暴。

当目标系统是多条业务线上的某几个公共结点，一般业务中台会出现这种情况，如支付中台要为不同的业务部门(保险，商城，还信用卡等)提供支付服务，如下图中的虚线部分。这类业务往往结点之间的边界并没有那么清楚，系统做什么与不做什么只有在梳理完整条业务线才能确认下来，这种情况按每条业务线分组展开事件风暴，然后针对多组产出结果进行统一业务概念抽象，建立系统边界内的统一事件流。

3. 业务代表或领域专家用自己的语言表达业务

事件风暴的第一个环节是让参与者头脑风暴，各自找出业务干系人关注的领域事件，对于业务干系人来讲，往往不适应把自己理解的业务按领域事件的方式表达出来，他们看到一串领域事件，也不觉得这种表达方式比传统方式直观，在这种情况下，我们就需要考虑如何引导业务共同输出领域事件。留心领域专家在表达需求过程中的一些模式：

1. 当…
2. 如果发生…
3. 当…的时候请通知我
4. 发生…时

通过模式中的关键字转换成领域事件，按时间顺序排序后，基于商业模式与价值定位与领域专家讨论领域事件，以统一的语言与统一的业务视角修正并验证领域事件。高质量的领域事件定义自然是清楚的，是可以找到问题域中的某个actor是关注它的，通过讲述领域事件是可以体现商业价值的。

4. 事件风暴可能识别不出来所有领域事件

通过事件风暴可以快速把整个问题域主线梳理出来，这样的产出是相当的高效和有价值，但对于正在尝试用事件风暴成果代替传统交付物的组织，往往会质疑事件风暴是否可以发现所有领域事件。

试考虑一个投资者，为一座摩天大楼的建造提供资金，投资者未必对建造过程的细节感兴趣，材料的选择及各种工程细节会议对于建造者来说是很重要的活动，对于投资者来讲，感兴趣的是良好的投资回报，保护投资免受风险，较为务实的投资者会设立明确的里程碑，每个里程碑通过后再做下一次注资。例如，在项目开始时，提供适量资金进行建筑设计工作。当建造事宜被批准时，再为项目提供较多的资金以进行设计工作。在设计通过评审通过后，才拔给更大量的资金，以便建造者破土动工。梳理得到事件如下：

系统建模同理，我们不关注所有事件，仅关注对干系人解决特定问题有价值的事件，并且这个特定问题应该已经在项目初期，业务愿景梳理的过程中在组织内达成了共识，就像上述投资者关注的问题一样清楚，在业务场景梳理与事件风暴的过程中，不断还原具体过程，以确保识别出的活动或事件真正可以解决业务问题。所以在事件风暴的过程中，并不需要担心是不是找出所有领域事件，只要真正解决了业务问题就好了。

另外，当开始采用新的方法论时，实践过程与角度都有差别，旧有体系的交付物不适用是常有的情况，重点关注的新的方法会不会以更简洁的方式解决实际问题。在存疑的风险处，活学活用新方法的交付物能够让组织更顺利的落地，当然必要的开发过程与交付物改进也是需要的，即可以更高效的完成设计工作，也能够让团队更专注在问题上。

总结

有人说微服务的设计与拆分是一门艺术，经验性的成份占了很大比重。当我们准备基于经验来做微服务的设计决策时，结合业务愿景，找出问题域内所有业务干系人真正关心的领域事件，展开完整的事件风暴，循序渐进的让场景变得更加具体，让经验与艺术在生动的问题域之中得到最大的发挥。

另一方面，有效地识别领域事件，既统一了语言，又助力在模型中体现出业务价值部分，为设计关注业务价值的领域模型打下了坚实的基础。

更多精彩洞见，请关注微信公众号：思特沃克

Share

Serverless的微服务持续交付案例

1 条评论

本文是GitChat《Serverless 微服务的持续交付》部分内容已做修改。文章聊天实录请见：“顾宇：Serverless 微服务的持续交付解析”

“Serverless 风格微服务的持续交付（上）：架构案例”中，我们介绍了一个无服务器风格的微服务的架构案例。这个案例中混合了各种风格的微服务。

架构图如下：

在这个架构中，我们采用了前后端分离的技术。我们把 HTML，JS， CSS 等静态内容部署在 S3 上，并通过 CloudFront 作为 CDN 构成了整个架构的前端部分。我们把 Amazon API Gateway 作为后端的整体接口连接后端的各种风格的微服务，无论是运行在 Lambda 上的函数，还是运行在 EC2 上的 Java 微服务，他们整体构成了这个应用的后端部分。

从这个架构图上我们可以明显的看到 前端（Frontend）和后端（Backend）的区分。

持续部署流水线的设计和实现

任何 DevOps 部署流水线都可以分为三个阶段：待测试，待发布，已发布。

由于我们的架构是前后端分离的，因此我们为前端和后端分别构造了两条流水线，使得前后端开发可以独立。如下图所示：

(整体流水线)

在这种情况下，前端团队和后端团队是两个不同的团队，可以独立开发和部署，但在发布的时候则有些不同。由于用户是最后感知功能变化的。因此，为了避免界面报错找不到接口，在新增功能的场景下，后端先发布，前端后发布。在删除功能的场景下，前端先发布，后端后发布。

我们采用 Jenkins 构建我们的流水线，Jenkins 中已经含有足够的 AWS 插件可以帮助我们完成整个端到端的持续交付流水线。

前端流水线

前端持续交付流水线如下所示：

前端流水线的各步骤过程如下：

  1. 我们采用 BDD/ATDD 的方式进行前端开发。用 NightWatch.JS 框架做 端到端的测试，mocha 和 chai 用于做某些逻辑的验证。
  2. 我们采用单代码库主干（develop 分支）进行开发，用 master 分支作为生产环境的部署。生产环境的发布则是通过 Pull Request 合并的。在合并前，我们会合并提交。
  3. 前端采用 Webpack 进行构建，形成前端的交付产物。在构建之前，先进行一次全局测试。
  4. 由于 S3 不光可以作为对象存储服务，也可以作为一个高可用、高性能而且成本低廉的静态 Web 服务器。所以我们的前端静态内容存储在 S3 上。每一次部署都会在 S3 上以 build 号形成一个新的目录，然后把 Webpack 构建出来的文件存储进去。
  5. 我们采用 Cloudfront 作为 CDN，这样可以和 S3 相互集成。只需要把 S3 作为 CDN 的源，在发布时修改对应发布的目录就可以了。

由于我们做到了前后端分离。因此前端的数据和业务请求会通过 Ajax 的方式请求后端的 Rest API，而这个 Rest API 是由 Amazon API Gateway 通过 Swagger 配置生成的。前端只需要知道 这个 API Gateway，而无需知道API Gateway 的对应实现。

后端流水线

后端持续交付流水线如下所示：

后端流水线的各步骤过程如下：

  1. 我们采用“消费者驱动的契约测试”进行开发，先根据前端的 API 调用构建出相应的 Swagger API 规范文件和示例数据。然后，把这个规范上传至 AWS API Gateway，AWS API Gateway 会根据这个文件生成对应的 REST API。前端的小伙伴就可以依据这个进行开发了。
  2. 之后我们再根据数据的规范和要求编写后端的 Lambda 函数。我们采用 NodeJS 作为 Lambda 函数的开发语言。并采用 Jest 作为 Lambda 的 TDD 测试框架。
  3. 和前端一样，对于后端我们也采用单代码库主干（develop 分支）进行开发，用 master 分支作为生产环境的部署。
  4. 由于 AWS Lambda 函数需要打包到 S3 上才能进行部署，所以我们先把对应的构建产物存储在 S3 上，然后再部署 Lambda 函数。
  5. 我们采用版本化 Lambda 部署，部署后 Lambda 函数不会覆盖已有的函数，而是生成新版本的函数。然后通过别名（Alias）区分不同前端所对应的函数版本。默认的 $LATEST，表示最新部署的函数。此外我们还创建了 Prod，PreProd, uat 三个别名，用于区分不同的环境。这三个别名分别指向函数某一个发布版本。例如：函数 func 我部署了4次，那么 func 就有 4个版本（从1开始）。然后，函数 func 的 $LATEST 别名指向 4 版本。别名 PreProd 和 UAT 指向 3 版本，别名 Prod 在 2 版本。
  6. 技术而 API 的部署则是修改 API Gateway 的配置，使其绑定到对应版本的函数上去。由于 API Gateway 支持多阶段（Stage）的配置，我们可以采用和别名匹配的阶段绑定不同的函数。
  7. 完成了 API Gateway 和 Lamdba 的绑定之后，还需要进行一轮端到端的测试以保证 API 输入输出正确。
  8. 测试完毕后，再修改 API Gateway 的生产环境配置就可以了。

部署的效果如下所示：

(API Gateway + Lambda 配置)

无服务器微服务的持续交付新挑战

在实现以上的持续交付流水线的时候，我们踩了很多坑。但经过我们的反思，我们发现是云计算颠覆了我们很多的认识，当云计算把某些成本降低到趋近于 0 时。我们发现了以下几个新的挑战：

  1. 如果你要 Stub，有可能你走错了路。
  2. 测试金字塔的倒置。
  3. 你不再需要多个运行环境，你需要一个多阶段的生产环境 (Multi-Stage Production)。
  4. 函数的管理和 Nanoservice 反模式。

Stub ？别逗了

很多开发者最初都想在本地建立一套开发环境。由于 AWS 多半是通过 API 或者 CloudFormation 操作，因此开发者在本地开发的时候对于AWS 的外部依赖进行打桩（Stub） 进行测试，例如集成 DynamoDB（一种 NoSQL 数据库），当然你也可以运行本地版的 DynamoDB，但组织自动化测试的额外代价极高。然而随着微服务和函数规模的增加，这种管理打桩和构造打桩的虚拟云资源的代价会越来越大，但收效却没有提升。另一方面，往往需要修改几行代码立即生效的事情，却要执行很长时间的测试和部署流程，这个性价比并不是很高。

这时我们意识到一件事：如果某一个环节代价过大而价值不大，你就需要思考一下这个环节存在的必要性。

由于 AWS 提供了很好的配置隔离机制，于是为了得到更快速的反馈，我们放弃了 Stub 或构建本地 DynamoDB，而是直接部署在 AWS 上进行集成测试。只在本地执行单元测试，由于单元测试是 NodeJS 的函数，所以非常好测试。

另外一方面，我们发现了一个有趣的事实，那就是：

测试金字塔的倒置

由于我们采用 ATDD 进行开发，然后不断向下进行分解。在统计最后的测试代码和测试工作量的的时候，我们有了很有趣的发现：

  • End-2-End （UI）的测试代码占30%左右，占用了开发人员 30% 的时间（以小时作为单位）开发和测试。
  • 集成测试（函数、服务和 API Gateway 的集成）代码占 45%左右，占用了开发人员60% 的时间（以小时作为单位）开发和测试。
  • 单元测试的测试代码占 25%左右，占用了10%左右的时间开发和测试。

一开始我们以为我们走入了“蛋筒冰激凌反模式”或者“纸杯蛋糕反模式”但实际上：

  1. 我们并没有太多的手动测试，绝大部分自动化。除了验证手机端的部署以外，几乎没有手工测试工作量。
  2. 我们的自动化测试都是必要的，且没有重复。
  3. 我们的单元测试足够，且不需要增加单元测试。

但为什么会造成这样的结果呢，经过我们分析。是由于 AWS 供了很多功能组件，而这些组件你无需在单元测试中验证（减少了很多 Stub 或者 Mock），只有通过集成测试的方式才能进行验证。因此，Serverless 基础设施大大降低了单元测试的投入，但把这些不同的组件组合起来则劳时费力 。如果你有多套不一致的环境，那你的持续交付流水线配置则是很困难的。因此我们意识到：

你不再需要多个运行环境，你只需要一个多阶段的生产环境 (Multi-Stage Production)

通常情况下，我们会有多个运行环境，分别面对不同的人群：

  1. 面向开发者的本地开发环境
  2. 面向测试者的集成环境或测试环境（Test，QA 或 SIT）
  3. 面向业务部门的测试环境（UAT 环境）
  4. 面向最终用户的生产环境（Production 环境）

然而多个环境带来的最大问题是环境基础配置的不一致性。加之应用部署的不一致性。带来了很多不可重现问题。在 DevOps 运动，特别是基础设施即代码实践的推广下，这一问题得到了暂时的缓解。然而无服务器架构则把基础设施即代码推向了极致：只要能做到配置隔离和部署权限隔离，资源也可以做到同样的隔离效果。

我们通过 DNS 配置指向了同一个的 API Gateway，这个 API Gateway 有着不同的 Stage：我们只有开发（Dev）和生产（Prod）两套配置，只需修改配置以及对应 API 所指向的函数版本就可完成部署和发布。

然而，多个函数的多版本管理增加了操作复杂性和配置性，使得整个持续交付流水线多了很多认为操作导致持续交付并不高效。于是我们在思考：

对函数的管理和“ Nanoservices 反模式 ”

根据微服务的定义，AWS API Gateway 和 Lambda 的组合确实满足 微服务的特征，这看起来很美好。就像下图一样：

但当Lambda 函数多了，管理众多的函数的发布就成为了很高的一件事。而且， 可能会变成“Nanoservice 反模式”：

Nanoservice is an antipattern where a service is too fine-grained. A nanoservice is a service whose overhead (communications, maintenance, and so on) outweighs its utility.

如何把握微服务的粒度和函数的数量，就变成了一个新的问题。而 Serverless Framework ，就是解决这样的问题的。它认为微服务是由一个多个函数和相关的资源所组成。因此，才满足了微服务可独立部署可独立服务的属性。它把微服务当做一个用于管理 Lambda 的单元。所有的 Lambda 要按照微服务的要求来组织。Serverless Framework 包含了三个部分：

  1. 一个 CLI 工具，用于创建和部署微服务。
  2. 一个配置文件，用于管理和配置 AWS 微服务所需要的所有资源。
  3. 一套函数模板，用于让你快速启动微服务的开发。

此外，这个工具由 AWS 自身推广，所以兼容性很好。但是，我们得到了 Serverless 的众多好处，却难以摆脱对 AWS 的依赖。因为 AWS 的这一套架构是和别的云平台不兼容的。

所以，这就又是一个“自由的代价”的问题。

CloudNative 的持续交付

在实施 Serverless 的微服务期间，发生了一件我认为十分有意义的事情。我们客户想增加一个很小的需求。我和两个客户方的开发人员，客户的开发经理，以及客户业务部门的两个人要实现一个需求。当时我们 6 个人在会议室里面讨论了两个小时。讨论两个小时之后我们不光和业务部门定下来了需求（这点多么不容易），与此同时我们的前后端代码已经写完了，而且发布到了生产环境并通过了业务部门的测试。由于客户内部流程的关系，我们仅需要一个生产环境发布的批准，就可以完成新需求的对外发布！

在这个过程中，由于我们没有太多的环境要准备，并且和业务部门共同制定了验收标准并完成了自动化测试的编写。这全得益于 Serverless 相关技术带来的便利性。

我相信在未来的环境，如果这个架构，如果在线 IDE 技术成熟的话（由于 Lambda 控制了代码的规模，因此在线 IDE 足够），那我们可以大量缩短我们需求确定之后到我功能上线的整体时间。

通过以上的经历，我发现了 CloudNative 持续交付的几个重点：

  1. 优先采用 SaaS 化的服务而不是自己搭建持续交付流水线。
  2. 开发是离不开基础设施配置工作的。
  3. 状态和过程分离，把状态通过版本化的方式保存到配置管理工具中。

而在这种环境下，Ops工作就只剩下三件事：

  1. 设计整体的架构，除了基础设施的架构以外，还要关注应用架构。以及优先采用的 SaaS 服务解决问题。
  2. 严格管理配置和权限并构建一个快速交付的持续交付流程。
  3. 监控生产环境。

剩下的事情，就全部交给云平台去做。

更多精彩洞见，请关注微信公众号：思特沃克

Share

你的微服务敢独立交付么？

1 条评论

最近经常在项目或是社区里听到大家谈论微服务架构，但谈论的焦点更多集中在微服务拆分，分布式架构，微服务门槛，DevOps配套设施等话题上。

但是在我眼里，真正能称之为微服务架构的少之又少。原因也很简单，我所见到的很多所谓的微服务架构项目，大多都没有做到微服务架构的一个基本要求：服务的独立部署（交付）。

这里的独立部署和自动化部署还不是一个概念，服务的自动化部署相对简单，已有大量的工具可以帮助我们做到。但是这里所谈的独立部署，我认为关键和难点并不在于“部署”，而在于“独立”。

如果失去了服务独立部署（交付）的能力，一个微服务架构的威力将大打折扣，我们的系统虽然在物理上被拆分成了多个小的服务，但是如果从最终交付的角度来看，仍然是以一个整体存在的，就像单体应用一样，存在诸多的问题。

为什么服务的独立交付并不简单？

那为什么不能让每一个服务都独立部署到产品环境呢？问题的答案是：不是不能，而是不敢！

为了表达清楚，让我们来看个例子吧。

像下图一样，我现在就是那个程序员帅哥（本色出演），突然有一天心血来潮，动手开发了一个网上商城。代码Push到Github并通过CI构建持续交付流水线，最终自动化部署到云端产品环境，供用户访问使用。

随着用户和访问量的增加，需求和功能也越来越多，系统也变得越发复杂。

从网上了解到最近有个叫微服务的架构非常火爆，我也赶了回时髦，当然也觉得这种架构确实可以帮助我解决现在的一些问题。

经过对系统的分析，我将商城的后台部分拆分出了3个服务，为了简单我们就称之为ABC三个服务。

我们假设一个比较极端的情况，三个服务相互调用（先不考虑这样是否合理），每个服务通过自己的持续交付流水线独立部署到产品环境。当前产品环境的各个服务的版本是：A：1.0、B：2.0、C：3.0

一切都非常完美是不是？看！我们已经做到了服务的独立部署！So easy~

当然，事情肯定不会那么简单。

问题出现在当我对A服务做了一次新的提交之后，A服务的最新版本升级到了1.1。不幸的是，这个新的版本意外的破坏了A与B之间的契约，错误的调用了B的接口，导致出现了错误。

虽然我的A服务和B服务都有比较完备的UT（单元测试），但因为UT无法发现服务之间的集成是否被破坏，所以只有UT作为质量保障的A服务持续交付流水线也自然没有能力发现AB服务集成被破坏的这个问题。最终导致存在问题的A1.1版本被部署到了产品环境，产品环境出现了严重的Bug。

请问在座的同学，碰到这样的情况，你会如何处理？

“加集成测试啊！”

这位同学说的极是，我这么聪明自然也想到了这一点，不就是要测集成吗？UT干不了就加集成测试不就成了。

为了统一语言，毕竟对于各种测试的叫法太容易引起混淆，参考Martin Fowler在《微服务测试策略》中的定义，我们在本文中将这种测试多服务集成的测试统一称作端到端测试（End-to-End tests，简称E2E测试）。

添加了E2E测试之后，我的交付流水线就变成了下面这个样子。

因为有了E2E测试的存在，问题迎刃而解，当A服务的新版本破坏了与B服务的集成时，E2E测试就会及时诊断出来，并阻止A服务的最新版本向产品环境流动，保证产品环境不被破坏。

这样看似没有什么问题，通过添加E2E测试，解决了服务间集成的验证问题，但在不知不觉中，我们也失去了微服务架构的那个重要的特性：“服务的独立交付”。

怎么讲？别急，我们再往下看。

假设A服务的修复过程中，B和C服务也提交了新的代码，我们假设这两个提交是没有问题的，但因为A服务的1.1版本导致E2E测试挂掉的问题还没有被修复，所以B和C的新版本也被E2E测试拦了下来，此时的E2E测试就像是一个亮起红灯的路口，阻塞了所有服务通往产品环境的通道。

所以说，随着集中E2E测试的添加，质量被保障的同时，我们的“微服务架构”也已悄然失去了服务独立交付的能力，杀敌一千自损八百，损失惨重！

这并不是我假想的场景，在我自己经历的几个真实项目中，这个问题都在一直困扰着我们。带来了各种各样的衍生问题，例如E2E测试长时间失败，无人修复，修复难度大，服务交付堵塞，为了保持交付通路畅通还不得不引入同样存在很大副作用的CodeFrezze机制和提交Token机制等。

可以看到，虽然我们能够在代码库，在部署结构上，甚至在组织上进行服务化拆分，但就因为这最后一个交付的十里路口，最后这一个红绿灯，让所有的服务又纠缠在了一起，所有的服务化拆分形同虚设，最终我们得到的也只是一个看起来像微服务架构的单体应用而已。

拆除红绿灯，各行其道，收复失地！

那，如何才能将这个“红绿灯”拆除，让服务可以在有质量保障的前提下还可以做到独立交付呢？这就是本文要解决的问题，让我们继续往下看。

我的解决方法其实也很简单：Inline E2E tests。

即并不添加新的集中的Pipeline做E2E测试，而是为每一个服务的Pipeline都添加一个相同的E2E测试的Stage，就相当于将E2E测试Inline到每个服务各自的部署流水线中，如下图所示。

其实Inline E2E测试还不是最关键的，最关键的变化点就是假设A服务有了新的提交，运行到A服务自己Pipeline的E2E测试的时候，此时的E2E测试并不是像之前一样获取B和C服务的最新代码库版本做集成验证，而获取当前产品环境上的B和C服务的已部署当前版本做集成验证。

例如，如图所示A服务的版本从1.0升级到了1.1，当前产品环境的B和C的版本是2.0和3.0。在执行A服务Pipeline上的E2E测试时，验证出A1.1和B2.0集成存在问题，测试变红，Pipeline挂掉，从而阻断了A服务的1.1版本部署到产品环境，保证了产品环境不会被A的1.1版本破坏。

同样，假设A还没有被修复之前，B也有了新的提交，产生了一个新的版本B2.1，这时在B服务Pipeline上的E2E测试并不获取当前A服务的代码库最新版本1.1做集成测试，而是获取产品环境上的当前版本A1.0版本做集成测试。我们假设B2.1和A1.0之间的集成没有问题，测试通过，所以B的2.1版本就被成功的交付到了产品环境，而此时产品环境的A服务的版本仍是1.0。

看！服务之间的阻塞被神奇的解决了，服务再也不会被堵在一个统一的十字路口，而是各行其道，A的车道出了事故，是A的问题，应该由A来承担后果和解决问题，不应该影响到其他服务，其他服务依然可以持续的交付到产品环境。

向前看是持续集成，向后看是持续交付！

看到这里可能有些小伙伴会感到有些失望。咋呼半天，不就是将E2E测试整到每个服务的Pipeline里，再把获取版本从最新代码改成产品环境么？有啥厉害的。

但是，在我看来，这个看似简单的变化，意义却是重大的：它揭示了“持续集成”和“持续交付”的一个主要区别。

“持续集成”和”持续交付”，这两个概念相信大家一定都不陌生，在软件领域也被提了不少年头了，不算什么新概念新技术。但对于这两个概念，我们经常一起提及，也经常混淆，搞不清楚两者的区别到底是什么，可能认为持续交付只不过是持续集成的演进版，新瓶装旧酒而已。

但其实它们却有着本质的区别。

“持续集成”关注的是各个集成单元之前最新版本的集成问题，即是不是某个集成单元的最新版本破坏了系统整体的集成，我管这种视角叫：向“前”看。

而“持续交付”关注的应该不是集成单元最新版本之间的集成问题，而是某个集成单元的最新版本是否可以（能和敢）部署到产品环境。换句话说就是维持产品环境的其他服务不变，只将当前集成单元的最新版本部署到产品环境，产品是否依然可用，不被破坏。所以在“持续交付”的视角下，应该关注的是当前集成单元与产品环境上的其他服务的版本是否兼容，我管这种视角叫：向“后”看。

向前看是持续集成，向后看才是持续交付，如果前后都不看那就是在裸奔。

但是肯定早有同学在心里疑惑，将E2E测试下放到每一个服务自己的Pipeline中，靠谱么？是不是太重了？根据测试金字塔，E2E测试应该是属于靠近金字塔顶端的测试种类，无论从数量和覆盖范围应该也都不会太多，怎么能靠它来保障服务之间的所有集成点和契约呢？

主角登场-契约测试

细心的同学肯定已经发现上面最后一张图中，我已经悄悄的把E2E测试变为了CT，即Contract Test，契约测试。

契约测试也是这两年伴随微服务架构的兴起，经常被提及的一种比较新的测试类型。在测试金字塔中，他的位置介于E2E和Component Tests（可以理解成单个服务的API测试）之间。

简单的理解，契约测试就是一种可以用类似于单元测试的技术验证两两服务之间集成的测试技术。它相比于更低层次的单元测试的优势是可以测集成（两两服务之间），相比于更高层次的E2E测试的优势是实现方式上又类似于单元测试，更轻量，跑的更快，覆盖的范围也自然可以更广更细。

使用契约测试替换掉E2E测试之后，整个架构也会变得更复杂一些，目前契约测试的框架也有很多，如大家常常提到的Pact或是SpringContracts等等。这里我先以Pact为例予以说明，其他框架实现上可能有些差别，但是思路是一致的。

A服务调用B服务的一个API，我们就称为A和B之间存在了一个契约，即B应该按照这个契约提供一个满足契约要求的API，而A也应该按照这个契约约定的方式来调用B的这个API。在这个过程中A作为调用方，我们称之为Consumer端。B作为被调用方，我们称之为Provider端。

如果A和B都履行契约，按照契约定义的约定调用和被调用，我们就可以认为集成不会有问题。但无论是B擅自修改了API破坏了契约，还是A擅自修改了调用API的方式破坏了契约，都会导致契约被破坏，反应到测试上就是契约测试会失败，反应到产品上就是功能被破坏，出现Bug。

每个契约，例如A->B，都会有Consumer端和Provider端生成的两个产出物：分别是a-b.consumer.json.1.1(由Consumer端生成的契约文件，所以版本也是Consumer端A的版本号)和a-b.provider.jar.2.0（由Provider端生成的契约验证测试包，他由Provider端生成，所以版本是B的版本）。这个jar包其实就是一组测试，他的输入是a-b.consumer.json，产出则是测试的结果，也就是契约的验证结果：成功或是失败。

可以把A服务产出的契约文件a-b.consumer.json.1.1想象成一把钥匙，把B服务产出的Provider端的测试a-b.provider.jar.2.0想象成一把锁。那契约测试的执行过程就像是用这把钥匙试着去打开这把锁：如果可以打开，我们认为这A1.1->B2.0的契约是满足的，反之契约就是被破坏了。

值得注意的一点就是，契约测试不像E2E测试，它是有方向的，所以我们看到a-b和b-a是两个不同的契约。

所以，只有当A1.1->B2.0和B2.0->A1.1双向的契约都被验证通过后，我们才能认为A1.1版本和B2.0版本的集成是没有问题的。

用契约测试替换E2E测试

回到前面的例子上，假设我们已经构建了ABC三个服务两两之间的契约测试。此时，A服务有了新的提交升级到了1.1版本，那我们如何才能通过契约测试来验证A1.1版本能否交付到产品环境呢？

答案就是只要通过A的1.1版本的最新代码，生成所有A作为Consumer端的契约文件（a-b.consumer.json.1.1和a-c.consumer.json.1.1），用这两把“钥匙”去试着开（作为输入执行Provider端测试）产品环境对应的两把“锁”（a-b.provider.jar.2.0和a-c.provider.jar.3.0）。

如果都可以打开（测试通过）的话，就证明A的新版本1.1作为Consumer端与产品环境的B和C服务是兼容的。

等等，别着急，还没完……

因为我们还需要考虑A作为Provider的情况，做法还是通过A的1.1版本的最新代码生成A版本作为Provider端的契约测试（b-a.provider.jar.1.1和c-a.provider.jar.1.1），拿着这两把“新锁”，然后试着用产品环境上的两把“钥匙”（b-a.consumer.json.2.0和c-a.consumer.json3.0）去开。

如果也都可以打开（测试通过）的话，就证明A的新版本1.1作为Provider端与产品环境的B和C服务也是兼容的。

至此，当验证了A的新版本1.1无论是作为调用端还是被调用端都与产品环境上的其他服务契约满足后，我们就认为A1.1与B2.0和C3.0集成是没有问题的，也就代表A1.1可以被放心地部署到产品环境中，替代现在的1.0版本。

这块稍微有些复杂，用文字也很难讲的特别清楚，如果大家对我上边讲的内容感兴趣，但又没有完全理解。请大家移步去看一下我2017年9月份在北京CDConf（持续交付大会）上针对这个主题做的一次分享，讲的应该比写的更清楚一些。在那个分享的最后，也详细介绍了一些我们在这个方案实施过程中碰到的一些问题：例如对于契约变更，并发提交，多环境支持的解决方案，感兴趣的也可以拖到最后看一下。

《契约测试-微服务持续交付的金钥匙》（CDConf 北京 2017）

最后，敲黑板划重点

  • 微服务架构下的独立部署（交付）很重要，但往往容易被忽视，没有被引起足够重视。
  • 为了实现微服务的独立持续交付，我们要向“后”看，不要向“前”看，即关注当前变更服务与部署环境中其他服务的兼容性而不是关注当前变更服务与其他服务最新版本的兼容性。
  • 用契约测试来替代E2E测试，降低测试成本，提高测试覆盖，尽早测试。并通过不断地完善契约管理，保障微服务架构质量和避免微服务架构腐化僵化。

更多精彩洞见，请关注微信公众号：思特沃克

Share