5. 可部署性

第5章 可部署性

从我们到达地球的那一天起
眨眼，走进阳光
要看的比看得见的要多
要做的比能做的更多

—狮子王

总有一天，软件和我们其他人一样，必须离开家，冒险进入世界，体验现实生活。与我们其他人不同，随着更改和更新的进行，软件通常会多次旅行。本章是关于使这种过渡尽可能有序和有效，最重要的是尽可能快速。这就是持续部署的领域，最受可部署性质量属性的影响。

为什么可部署性在质量属性领域占据了前排？

在“糟糕的过去”，发布并不频繁 - 大量更改被捆绑到版本中并安排。版本将包含新功能和错误修复。每月、每季度甚至每年发布一次是很常见的。许多领域的竞争压力（由电子商务主导）导致需要更短的发布周期。在这些上下文中，发布可以随时发生（每天可能数百个发布），并且每个发布都可以由组织内的不同团队发起。能够频繁发布意味着错误修复尤其不必等到下一个预定版本，而是可以在发现并修复错误后立即进行和发布。这也意味着新功能不需要捆绑到版本中，而是可以随时投入生产。

这在所有领域都是不可取的，甚至是不可能的。如果你的软件存在于具有许多依赖项的复杂生态系统中，则可能无法仅发布其中的一部分，而不将该版本与其他部分协调。此外，许多嵌入式系统、难以访问位置的系统以及未联网的系统都不适合持续部署思维。

本章重点介绍大量且不断增长的系统，在这些系统中，即时功能发布具有显著的竞争优势，而即时错误修复对于安全或安保或连续运行至关重要。通常，这些系统是微服务和基于云的，尽管这里的技术不仅限于这些技术。

5.1 持续部署

部署是一个从编码开始，到真实用户在生产环境中与系统交互结束的过程。如果此过程是完全自动化的（即，如果没有人工干预），则称为“持续部署”。如果流程自动化到将系统（部分）投入生产，并且最后一步需要人工干预（可能是由于法规或政策），则该过程称为持续交付。

为了加快发布速度，我们需要引入部署管道的概念：从将代码签入版本控制系统时开始，到部署应用程序以便用户向其发送请求时结束的工具和活动的序列。在这些点之间，一系列工具集成并自动测试新提交的代码，测试集成代码的功能，并测试应用程序是否存在负载下的性能、安全性和许可证合规性等问题。

部署管道中的每个阶段都发生在为支持阶段隔离并执行适合该阶段的操作而建立的环境中。主要环境如下：

• 代码是在开发环境中为单个模块开发的，在该环境中，它受到独立的单元测试。一旦通过测试并经过适当的审查，代码将提交到在集成环境中触发构建活动的版本控制系统。

• 集成环境构建服务的可执行版本。持续集成服务器编译 ¹ 你的新代码或更改的代码，以及服务其他部分的最新兼容代码版本，并为你的服务构建可执行映像。²集成环境中的测试包括来自各种模块的单元测试（现在针对构建的系统运行），以及专门为整个系统设计的集成测试。通过各种测试后，生成的服务将提升到过渡环境。

• 暂存环境测试整个系统的各种质量。其中包括性能测试、安全测试、许可证一致性检查以及可能的用户测试。对于嵌入式系统，这是物理环境模拟器（向系统馈送合成输入）发挥作用的地方。通过所有暂存环境测试（可能包括现场测试）的应用程序将使用蓝/绿模型或滚动升级部署到生产环境（请参见 第 5.6 节）。在某些情况下，部分部署用于质量控制或测试市场对提议的更改或产品的反应。

• 一旦进入生产环境，服务就会受到密切监控，直到所有各方对其质量有一定程度的信心。在这一点上，它被认为是系统的正常部分，并受到与系统其他部分相同的关注。

在每个环境中执行一组不同的测试，将测试范围从开发环境中单个模块的单元测试扩展到集成环境中构成服务的所有组件的功能测试，最后在过渡环境中进行广泛的质量测试和生产环境中的使用监视。

但并非一切都按计划进行。如果在软件处于生产环境中后发现问题，通常需要在解决缺陷时回滚到以前的版本。

架构选择会影响可部署性。例如，通过使用微服务架构模式（参见 第 5.6 节），负责微服务的每个团队都可以做出自己的技术选择;这消除了以前在集成时发现的不兼容问题（例如，使用哪个版本的库的不兼容选择）。由于微服务是独立的服务，因此此类选择不会引起问题。

同样，持续部署思维方式迫使你在开发过程的早期考虑测试基础结构。这是必要的，因为持续部署的设计需要持续的自动化测试。此外，需要能够回滚或禁用功能会导致有关机制（如功能切换和接口的向后兼容性）的体系结构决策。这些决定最好尽早做出。

虚拟化对不同环境的影响

在虚拟化技术广泛使用之前，我们在这里描述的环境是物理设施。在大多数组织中，开发、集成和暂存环境由不同组采购和操作的硬件和软件组成。开发环境可能包含几台台式计算机，开发团队将其重新用作服务器。集成环境由测试或质量保证团队操作，可能包含一些机架，其中装有来自数据中心的上一代设备。暂存环境由运营团队操作，可能具有与生产中使用的硬件类似的硬件。

我们花费了大量时间试图弄清楚为什么在一个环境中通过的测试在另一个环境中失败。采用虚拟化的环境的一个好处是能够具有“环境奇偶校验”，其中环境的规模可能不同，但在硬件类型或基本结构上却不同。各种预配工具通过允许每个团队轻松构建通用环境并确保此通用环境尽可能模拟生产环境来支持环境奇偶校验。

衡量管道质量的三种重要方法如下：

• 周期时间是管道的进度。许多组织每天将部署到生产环境数次甚至数百次。如果需要人为干预，这种快速部署是不可能的。如果一个团队在将其服务投入生产之前必须与其他团队协调，这也是不可能的。在本章的后面，我们将看到允许团队执行持续部署而无需咨询其他团队的架构技术。

• 可追溯性是恢复导致元素出现问题的所有工件的能力。这包括该元素中包含的所有代码和依赖项。它还包括在该元素上运行的测试用例以及用于生成该元素的工具。部署管道中使用的工具中的错误可能会导致生产中出现问题。通常，可追溯性信息保存在工件数据库中。此数据库将包含代码版本号、系统所依赖的元素（如库）的版本号、测试版本号和工具版本号。

• 重复性在对相同伪影执行相同操作时获得相同的结果。这并不像听起来那么容易。例如，假设生成过程提取库的最新版本。下次执行生成过程时，可能已发布新版本的库。再举一个例子，假设一个测试修改了数据库中的某些值。如果未恢复原始值，则后续测试可能不会产生相同的结果。

运维

DevOps 是“开发”和“运营”的结合体，是一个与持续部署密切相关的概念。它是一种运动（很像敏捷运动），是对一组实践和工具的描述（再次，很像敏捷运动），以及销售这些工具的供应商吹捧的营销公式。DevOps 的目标是缩短上市时间（或发布时间）。与传统的软件开发实践相比，目标是大幅缩短开发人员对现有系统进行更改（实现功能或修复错误）与系统到达最终用户手中之间的时间。

DevOps 的正式定义既捕获了发布频率，也捕获了按需执行错误修复的能力：

DevOps 是一组实践，旨在缩短将更改提交到系统与将更改放入正常生产之间的时间，同时确保高质量。[低音 15]

实施 DevOps 是一项流程改进工作。DevOps 不仅包含任何流程改进工作的文化和组织元素，还包含对工具和架构设计的强烈依赖。当然，所有环境都是不同的，但我们描述的工具和自动化可以在为支持 DevOps 而构建的典型工具链中找到。

我们在此处描述的持续部署策略是 DevOps 的概念核心。反过来，自动化测试是持续部署的一个至关重要的组成部分，而用于此的工具通常是DevOps的最高技术障碍。某些形式的DevOps包括对这些日志的日志记录和部署后监视，以便在“家庭办公室”自动检测错误，甚至监视以了解用户体验。当然，这需要系统中的“电话总部”或日志交付功能，这在某些系统中可能是可能的，也可能是不允许的。

DevSecOps 是 DevOps 的一种变体，它将安全方法（针对基础架构及其生成的应用程序）整合到整个过程中。DevSecOps 在航空航天和国防应用中越来越受欢迎，但在 DevOps 有用的任何应用领域中也有效，并且安全漏洞的成本特别高。许多 IT 应用程序都属于这一类。

5.2 可部署性

可部署性是指软件的一种属性，指示它可以在可预测和可接受的时间和工作量内部署（即分配给环境执行）。此外，如果新部署不符合其规范，则可以在可预测和可接受的时间和工作量内再次回滚。随着世界越来越多地转向虚拟化和云基础架构，并且随着部署的软件密集型系统的规模不可避免地增加，架构师的职责之一是确保以高效和可预测的方式完成部署，从而最大限度地降低整体系统风险。³

为了实现这些目标，架构师需要考虑如何在主机平台上更新可执行文件，以及随后如何调用、测量、监视和控制可执行文件。由于对带宽的担忧，移动系统在如何更新方面尤其对可部署性提出了挑战。部署软件涉及的一些问题如下：

• 它如何到达其主机（即推送，其中部署的更新未经请求，或拉取，其中用户或管理员必须显式请求更新）？

• 它如何集成到现有系统中？这可以在现有系统执行时完成吗？

• 什么是介质，例如 DVD、USB 驱动器或互联网交付？

• 什么是打包（例如，可执行文件、应用程序、插件）？

• 与现有系统的集成结果是什么？

• 执行流程的效率如何？

• 过程的可控性是什么？

考虑到所有这些问题，架构师必须能够评估相关的风险。架构师主要关注体系结构支持以下部署的程度：

• 颗粒。部署可以是整个系统，也可以是系统内的元素。如果体系结构提供了更精细的部署粒度选项，则可以降低某些风险。

• 可控制的。该体系结构应提供以不同粒度级别进行部署、监视已部署单元的操作以及回滚不成功的部署的功能。

• 高效。 该体系结构应支持快速部署（如果需要，还应支持回滚），并具有合理的工作量。

这些特点将反映在可部署性一般设想的应对措施中。

5.3 可部署性通用场景

表 5.1 列举了表征可部署性的通用场景的要素。

表 5.1 可部署性的通用场景

场景部分	描述	可能的值
来源	部署的触发	最终用户、开发人员、系统管理员、操作人员、组件市场、产品所有者。
触发事件	导致触发的原因	可以部署一个新元素。这通常是用新版本替换软件元素的请求（例如，修复缺陷、应用安全补丁、升级到组件或框架的最新版本、升级到内部生成的元素的最新版本）。新元素被批准合并。需要回滚现有元素/元素集。
工件	要更改的内容	特定组件或模块、系统平台、用户界面、环境或与之互操作的其他系统。因此，工件可能是单个软件元素、多个软件元素或整个系统。
环境	暂存、生产（或两者之一的特定子集）	完整部署。子集部署到用户、虚拟机、容器、服务器、平台的指定部分。
响应	应该发生什么	合并新组件。部署新组件。监视新组件。回滚以前的部署。
响应度量	对部署或一系列部署随时间推移的成本、时间或流程有效性的度量	成本方面： 受影响项目的数量、大小和复杂性 平均/最坏情况的努力 经过的时钟或日历时间 金钱（直接支出或机会成本） 引入的新缺陷

图5.1 说明了一个具体的可部署性方案：“组件市场中提供了新版本的身份验证/授权服务（我们的产品使用），产品所有者决定将此版本合并到版本中。新服务在经过的 40 小时内进行测试并部署到生产环境，工作量不超过 120 人-小时。部署不会引入任何缺陷，也不会违反 SLA。

图 5.1 具体可部署性方案示例

5.4 可部署性策略

新软件或硬件元素的发布促进了部署。如果在可接受的时间、成本和质量约束内部署这些新元素，则部署成功。我们在 图 5.2 中说明了这种关系，从而说明了可部署性策略的目标。

图 5.2 可部署性策略的目标

可部署性的策略如 图5.3 所示。在许多情况下，这些策略将至少部分由你购买而不是构建的 CI/CD（持续集成/持续部署）基础结构提供。在这种情况下，你作为架构师的工作通常是选择和评估（而不是实施）正确的可部署性策略和正确的策略组合。

图 5.3 可部署性策略

接下来，我们将更详细地描述这六种可部署性策略。第一类可部署性策略侧重于管理部署管道的策略，第二类策略涉及在部署时和部署后管理系统。

管理部署管线

• 缩放卷展栏。扩展部署不是部署到整个用户群，而是逐步将服务的新版本部署到用户群的受控子集，通常不会向这些用户发出明确通知。（其余用户群继续使用以前版本的服务。通过逐步发布，可以监视和衡量新部署的效果，并在必要时回滚。此策略可最大程度地减少部署有缺陷的服务的潜在负面影响。它需要一种体系结构机制（不是正在部署的服务的一部分）来将来自用户的请求路由到新服务或旧服务，具体取决于该用户的标识。

• 回滚。如果发现部署存在缺陷或不符合用户期望，则可以将其“回滚”到其先前状态。由于部署可能涉及多个服务及其数据的多个协调更新，因此回滚机制必须能够跟踪所有这些更新，或者必须能够逆转部署所做的任何更新的后果，最好是以全自动方式。

• 编写部署命令脚本。部署通常很复杂，需要精确执行和编排许多步骤。因此，部署通常是脚本化的。这些部署脚本应被视为代码 - 记录、审查、测试和版本控制。脚本引擎自动执行部署脚本，从而节省时间并最大程度地减少人为错误的机会。

管理已部署的系统

• 管理服务交互。此策略适用于同时部署和执行多个版本的系统服务。来自客户端的多个请求可以按任意顺序定向到任一版本。但是，运行同一服务的多个版本可能会引入版本不兼容。在这种情况下，需要调解服务之间的交互，以便主动避免版本不兼容。这种策略是一种资源管理策略，无需完全复制资源以分别部署旧版本和新版本。

• 包依赖项。此策略将元素及其依赖项打包在一起，以便将它们一起部署，并且当元素从开发转移到生产时，依赖项的版本是一致的。依赖关系可能包括库、操作系统版本和实用程序容器（例如，sidecar、服务网格），我们将在 第9章 中讨论。打包依赖项的三种方法是使用容器、Pod 或虚拟机；这些在 第16章 中有更详细的讨论。

• 功能切换。即使代码经过全面测试，部署新功能后也可能会遇到问题。因此，能够为新功能集成“终止开关”（或功能切换）非常方便。终止开关会在运行时自动禁用系统中的功能，而不会强制你启动新部署。这提供了控制已部署功能的能力，而无需实际重新部署服务的成本和风险。

5.5 基于策略的可部署性问卷

根据 第5.4节 中描述的策略，我们可以创建一组受可部署性策略启发的问题，如 表5.2 所示。为了大致了解为支持可部署性而做出的体系结构选择，分析师会询问每个问题并将答案记录在表中。然后，这些问题的答案可以成为后续活动的重点：文档调查、代码或其他工件分析、代码逆向工程等。

表5.2 基于策略的可部署性调查表

策略组	策略问题	支持与否	风险	设计决策和位置	理由和假设
管理部署管线	你是否扩展推出，逐步推出新版本（与以全有或全无的方式发布相反）？
	如果你确定已部署的服务未以令人满意的方式运行，你是否能够自动回滚这些服务？
	你是否编写部署命令脚本以自动执行复杂的部署指令序列？
管理部署系统	你是否管理服务交互，以便可以同时安全地部署多个版本的服务？
	是否包依赖项以便服务与它们所依赖的所有库、操作系统版本和实用程序容器一起部署？
	如果确定功能有问题，是否使用功能切换自动禁用该功能（而不是回滚新部署的服务）？

5.6 可部署性的模式

可部署性的模式可以分为两类。第一类包含用于构建要部署的服务模式。第二类包含如何部署服务的模式，可以将其解析为两大子类别：全有或全无或部分部署。可部署性的两个主要类别并非完全相互独立，因为某些部署模式依赖于服务的某些结构属性。

构建服务的模式

微服务架构

微服务体系结构模式将系统构建为可独立部署服务的集合，这些服务仅通过服务接口的消息进行通信。不允许其他形式的进程间通信：没有直接链接，没有直接读取另一个团队的数据存储，没有共享内存模型，没有任何后门。服务通常是无状态的，并且（因为它们是由一个相对较小的团队开发的⁴）相对较小，因此称为“微服务*”。服务依赖关系是非循环的。此模式的一个组成部分是发现服务，以便可以适当地路由消息。

好处：

• 缩短了上市时间。由于每个服务都很小且可独立部署，因此无需与拥有其他服务的团队协调即可部署对服务的修改。因此，一旦团队完成了对服务的新版本的工作，并且该版本已经过测试，就可以立即部署。

• 每个团队都可以为其服务做出自己的技术选择，只要技术选择支持消息传递。不需要在库版本或编程语言方面进行协调。这减少了由于集成过程中出现的不兼容而导致的错误，这些错误是集成错误的主要来源。

• 服务比粗粒度应用程序更容易扩展。由于每个服务都是独立的，因此动态添加服务的实例非常简单。这样，服务的供应可以更容易地与需求相匹配。

妥协：

• 与内存中通信相比，开销会增加，因为服务之间的所有通信都通过网络上的消息进行。这可以通过使用服务网格模式（参见 第9章）来缓解，该模式限制将某些服务部署到同一主机以减少网络流量。此外，由于微服务部署的动态性质，发现服务被大量使用，这增加了开销。最终，这些发现服务可能会成为性能瓶颈。

• 微服务不太适合复杂的事务，因为很难跨分布式系统同步活动。

• 每个团队选择自己技术的自由是有代价的——组织必须维护这些技术和所需的经验基础。

• 由于微服务数量众多，对整个系统的智能控制可能很困难。这就引入了对接口目录和数据库的要求，以帮助维持智力控制。此外，正确组合服务以实现预期结果的过程可能是复杂而微妙的。

• 将服务设计为具有适当的职责和适当的粒度级别是一项艰巨的设计任务。

• 若要实现独立部署版本的能力，必须设计服务的体系结构以允许该部署策略。使用 第5.4节 中所述的管理服务交互策略可以帮助实现此目标。

大量采用微服务架构模式的组织包括Google，Netflix，PayPal，Twitter，Facebook和Amazon。许多其他组织也采用了微服务架构模式;书籍和会议侧重于组织如何采用微服务架构模式来满足自己的需求。

完全更换服务的模式

假设服务 A 有 N 个实例，并且你希望将它们替换为新版本服务 A 的 N 个实例，而不保留原始版本的实例。你希望在不降低服务客户端服务质量的情况下执行此操作，因此必须始终运行服务的 N 个实例。

完整的替换策略有两种不同的模式，这两种模式都是规模部署策略的实现。我们将一起介绍它们：

1. 蓝色/绿色。 在蓝/绿部署中，将创建 N 个服务的新实例，每个实例都填充新的服务 A（我们称这些实例为绿色实例）。安装新服务 A 的 N 个实例后，DNS 服务器或发现服务将更改为指向新版本的服务 A。一旦确定新实例工作令人满意，则只有这样，原始服务 A 的 N 个实例才会被删除。在此截止点之前，如果在新版本中发现问题，只需切换回原始版本（蓝色服务），很少或没有中断即可。

2. 滚动升级。 滚动升级将服务A的实例替换为新版本的服务A的实例，一次一个。（实际上，你可以一次替换多个实例，但在任何单个步骤中都只替换一小部分。滚动升级的步骤如下：

   1. 为服务 A 的新实例（例如虚拟机）分配资源。

   2. 安装并注册新版本的服务 A。

   3. 开始将请求定向到新版本的服务 A。

   4. 选择旧服务 A 的实例，允许它完成任何活动处理，然后销毁该实例。

   5. 重复上述步骤，直到替换旧版本的所有实例。

图5.4显示了由Netflix的Asgard工具在亚马逊EC2云平台上实施的滚动升级过程。

图 5.4 由 Netflix 的 Asgard 工具实现的滚动升级模式的流程图

好处：

• 这些模式的好处是能够完全替换已部署的服务版本，而无需使系统停止服务，从而提高系统的可用性。

妥协：

• 蓝/绿方法的峰值资源利用率为 2N 个实例，而滚动升级的峰值资源利用率为 N + 1 个实例。无论哪种情况，都必须采购用于托管这些实例的资源。在云计算广泛采用之前，采购意味着购买：组织必须购买物理计算机才能执行升级。大多数时候没有正在进行的升级，因此这些额外的计算机基本上处于闲置状态。这使得财务权衡变得清晰，滚动升级是标准方法。现在，计算资源可以按需租用，而不是购买，财务权衡不那么引人注目，但仍然存在。

• 假设你在部署新服务 A 时检测到错误。尽管在开发、集成和暂存环境中进行了所有测试，但在将服务部署到生产环境时，仍可能存在潜在错误。如果你使用的是蓝/绿部署，则当你在新服务 A 中发现错误时，所有原始实例可能都已删除，回滚到旧版本可能需要相当长的时间。相反，滚动升级可能允许你在旧版本的实例仍然可用时发现新版本服务中的错误。

• 从客户端的角度来看，如果你使用的是蓝/绿部署模型，则在任何时候，新版本或旧版本都处于活动状态，但不能同时处于活动状态。如果使用滚动升级模式，则两个版本同时处于活动状态。这引入了两种类型问题的可能性：时间不一致和接口不匹配。

  • 时间不一致。在客户端 C 对服务 A 的一系列请求中，有些可能由旧版本的服务提供服务，有些可能由新版本提供服务。如果版本的行为不同，这可能会导致客户端 C 产生错误或至少不一致的结果。（这可以通过使用管理服务交互策略来防止。

  • 接口不匹配。如果新版本服务 A 的接口与旧版服务 A 的接口不同，则服务 A 的客户端调用尚未更新以反映新接口将产生不可预知的结果。可以通过扩展接口但不修改现有接口，并使用调解器模式（参见 第7章）从扩展接口转换为产生正确行为的内部接口来防止这种情况。有关更全面的讨论，请参见第15章。

部分替换服务的模式

有时，更改服务的所有实例是不可取的。部分部署模式旨在为不同的用户组同时提供多个版本的服务;它们用于质量控制（金丝雀测试）和营销测试（A / B测试）等目的。

Canary Testing 金丝雀测试

在推出新版本之前，谨慎的做法是在生产环境中对其进行测试，但用户集有限。金丝雀测试是beta测试的持续部署模拟。⁵金丝雀测试指定将测试新版本的一小部分用户。有时，这些测试人员是来自组织外部的所谓高级用户或预览流用户，他们更有可能执行典型用户可能不太频繁使用的代码路径和边缘情况。用户可能知道也可能不知道他们被用作豚鼠——呃，也就是金丝雀。另一种方法是使用开发软件的组织内的测试人员。例如，Google 员工几乎从不使用外部用户将使用的版本，而是充当即将发布的版本的测试人员。当测试的重点是确定新功能的接受程度时，将使用一种称为暗启动的金丝雀测试变体。

在这两种情况下，用户都被指定为金丝雀，并通过 DNS 设置或发现服务配置路由到服务的相应版本。测试完成后，用户将全部定向到新版本或旧版本，并销毁已弃用版本的实例。滚动升级或蓝/绿部署可用于部署新版本。

好处：

• 金丝雀测试允许真实用户以模拟测试无法做到的方式“敲打”软件。这允许部署服务的组织收集“使用中”数据并以相对较低的风险执行受控实验。

• 金丝雀测试产生的额外开发成本最小，因为无论如何，正在测试的系统都在生产道路上。

• 金丝雀测试最大限度地减少了在新系统中可能面临严重缺陷的用户数量。

妥协：

• 金丝雀测试需要额外的前期规划和资源，并且需要制定评估测试结果的策略。

• 如果金丝雀测试针对高级用户，则必须识别这些用户并将新版本路由到他们。

A/B 测试

营销人员使用 A/B 测试对真实用户进行实验，以确定几种备选方案中哪一种会产生最佳业务结果。少数但有意义的用户获得的待遇与其他用户不同。差异可能很小，例如字体大小或表单布局的更改，也可能更显著。例如，HomeAway（现在的Vrbo）使用A / B测试来改变其全球网站的格式，内容和外观，跟踪哪些版本产生了最多的租金。“赢家”将被保留，“输家”将被丢弃，另一个竞争者将被设计和部署。另一个例子是一家银行提供不同的促销活动来开设新账户。一个经常重复的故事是，谷歌测试了41种不同的蓝色阴影，以决定使用哪种阴影来报告搜索结果。

与金丝雀测试一样，DNS 服务器和发现服务配置设置为将客户端请求发送到不同的版本。在 A/B 测试中，监控不同的版本，以查看哪个版本从业务角度提供最佳响应。

好处：

• A / B测试允许营销和产品开发团队对真实用户进行实验并从真实用户收集数据。

• A / B测试可以允许根据任意特征集定位用户。

妥协：

• A / B测试需要实施替代方案，其中一个将被丢弃。

• 需要预先确定不同类别的用户及其特征。

5.7 扩展阅读

本章的大部分材料改编自 Len Bass 和 John Klein 的 [Bass 19] 和 [Kazman 20b]。

有关 DevOps 上下文中可部署性和体系结构的一般讨论，请参见 [Bass 15]。

可部署性的策略很大程度上归功于Martin Fowler及其同事的工作，可以在[Fowler 10]，[Lewis 14]和[Sato 14]中找到。

部署管道在 [Humble 10] 中有更详细的描述。

微服务和迁移到微服务的过程在 [Newman 15] 中进行了描述。

5.8 问题讨论

1. 使用通用场景中的每个可能响应编写一组具体的可部署性场景。

2. 为汽车（如特斯拉）的软件编写具体的可部署性场景。

3. 为智能手机应用编写具体的可部署性场景。现在，为与此应用通信的服务器端基础结构编写一个。

4. 如果你需要显示搜索操作的结果，你会执行A / B测试还是仅使用Google选择的颜色？为什么？

5. 参考 第 1 章 中描述的结构，实现包依赖策略将涉及哪些结构？你会使用使用结构吗？为什么或为什么不呢？你是否需要考虑其他结构？

6. 参考 第 1 章 中描述的结构，实现管理服务交互策略将涉及哪些结构？你会使用使用结构吗？为什么或为什么不呢？你是否需要考虑其他结构？

7. 在什么情况下，你希望前滚到新版本的服务，而不是回滚到以前的版本？什么时候前滚是一个糟糕的选择？

---

---

---

1. 如果你正在使用解释性语言（如 Python 或 JavaScript）开发软件，则没有编译步骤。 ↩︎

2. 在本章中，我们使用术语“服务”来表示任何可独立部署的单元。 ↩︎

3. 可测试性的质量属性（参见第12章）在持续部署中肯定起着关键作用，架构师可以通过确保系统可测试的方式为持续部署提供关键支持。但是，我们在这里关注的是与可测试性之外的持续部署直接相关的质量属性：可部署性。< ↩︎

4. 在亚马逊，服务团队的规模受到“两个披萨规则”的限制：团队的规模不得超过两个披萨所能喂饱的比萨饼。 ↩︎

5. 金丝雀测试以 19 世纪将金丝雀带入煤矿的做法命名。煤矿开采释放出爆炸性和有毒的气体。由于金丝雀对这些气体比人类更敏感，煤矿工人将金丝雀带入矿井，观察它们对气体的反应迹象。金丝雀充当矿工的早期预警设备，表明环境不安全。 ↩︎