为什么微服务从未被技术雷达“采纳”？

评论

如今，微服务在许多组织中发挥着重要作用。自从James Lewis和Martin Fowler发表了那篇开创性的文章后，微服务也随之声名鹊起。此后，Sam Newman也撰写了相关著作并举办了许多讲座，ThoughtWorks、Netflix和Google的人，还有许多其他组织和个人也纷纷发表文章，进一步推动了微服务的发展势头。微服务很快就进入了ThoughtWorks技术雷达的Trial（试验）环，但一直以来，微服务都未进入Adopt（采纳）环。这篇文章便是想探讨一下，为什么微服务一直没有为技术雷达所“采纳”。

Adopt环有意把标准设置得很高

首先，一起回想一下雷达上“试验”环和“采纳”环的定义。“试验”意味着相应技术已经可以供企业在自己的系统中进行尝试。表示我们在已经或多或少地将该技术投入生产，而且相信该技术是稳定的，知道如何以及在何处使用该技术。而进入雷达“采纳”环意味着，我们认为在适用的情况下这种技术是首选解决方案。例如，对于数据库，Neo4J就是一种进入了“采纳”环的图形数据库。这并不意味着所有数据都应该放入图形数据库中，而是意味着当你想使用图形数据库，Neo4J就是理想之选。

考虑到上述定义，我们为何不将微服务或微服务架构放入“采纳”环？毕竟，微服务经常作为各种会议和文章热议的话题，也有越来越多的组织正在转向采用这种架构风格，ThoughtWorks团队已经成功地将微服务用于许多项目。

我们未将微服务放入Adopt环，有多种原因。一部分原因在于“采纳”环的定义，另一部分原因则在于微服务本身。我们先从技术雷达的特定问题谈起。

将某种技术放入“采纳”环是一种非常强烈的表态。我们不希望在考虑做出这种建议时，存在太多让我们举棋不定的因素。将某种技术放入“采纳”环意味着，我们确信对于一些显而易见的情况来说，采用这种技术是正确的选择。在考虑微服务时，虽然它有一些明显的优点，但同时存在成本问题。对成本与效益的权衡因组织而异；组织的成熟度、领域和其他因素可能会影响可用的开发资源。从这个方面来讲，我们不能做出采用微服务的建议，技术雷达对于“采纳”的定义不应当模棱两可。

更重要的是，另一方面，将某种技术放入“采纳”环就要求，这项技术应该可以在各种成熟度范围内的客户和一般企业之中普遍采用。例如，如果某种技术适用于初创企业，但不适用于大型企业，就不应该放入“采纳”环，一个突出的例子是技术公司广泛应用的分布式版本控制系统。我们没有将这种系统纳入到“采纳”环，因为当时许多企业仍在努力采用基本的源控制。我们认为从一无所有到分布式版本控制的飞跃太大了，不能做出采用该系统的强烈建议。我们最终还是将Github放入了Adopt环中，但那是几年之后了。

并非所有组织都适合采用微服务

最后，正如Martin Fowler在一篇关于微服务的文章中所指出的，在考虑采用微服务之前，需要在持续交付和基础设施自动化实践等方面达到一定的成熟度（也许不需要太高）。然而，对于许多组织而言，要达到这种成熟度仍然力所难及。微服务会增加操作负担，因为有更多东西需要监控和生成警报，还有更多东西需要部署。在这方面，全面的自动化和持续交付实践至关重要。

此外，微服务架构还具有一些在单体式应用程序中完全不可能出现的错误模式。微服务系统本质上是分布式的，业务流程通常通过多项微服务的交互来完成。在单体式应用程序中，这些业务流程通常在同一流程边界内执行，从而可以执行传统事务并能确保全部执行或全部不执行。虽然我们可以为所有这些问题提供解决方案，但不可忽视的是，微服务方法确实会引入这些问题并需要处理。因此，需要在微服务方法增加的灵活性和单体式方法的简单性之间进行权衡（这种权衡很常见），尤其是在单体式应用程序结构完善的情况下，从灵活性中获益不多的应用程序不适宜采用微服务架构。

微服务架构的关键设计决策是在服务之间设置边界。虽然有界上下文肯定能为设置适当边界位置提供有效指导，但是仍然存在选择，而选择错误会使系统变得更复杂。对于某个新领域而言，边界的设定会比较模糊，因此在未进一步明确领域和适当上下文之前，有理由暂不开始采用微服务架构。

微服务对企业来说仍然非常重要！

现在，你可能想知道我们为什么推荐微服务架构，或者我们是否仍然推荐此架构。灵活性、独立的可扩展性、不断演进的特性、强大的封装仍然是微服务不可不说的优点。这些优点已经在其他文章中进行了详尽的阐述。我们仍然坚定使用微服务架构，以扩展我们对这种架构的理解，并继续探索解决本文所提到问题的工具和方法。实际上，来自ThoughtWorks的Zhamak Dehghani最近发表了一篇关于将单体式应用程序分解为微服务的文章。但是，该方法的成本和缺点以及执行该方法所需达到的组织成熟度水平正是微服务很可能永远无法进入“采纳”环的原因。

本文翻译自ThoughtWorks全球首席技术官Rebecca Pasrsons的《Microservices in Adopt?》一文。Rebecca将在3月15日来到技术雷达十周年峰会现场，与众位国际软件巨匠一同讲述技术领域的十年趋势变革。现在购买可享受限时七折票！

 

Share

微服务测试的思考与实践

评论

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

关于微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级通信机制互相沟通（通常是基于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