通过严格的开发和生产前测试，您的微型服务将能够正常运行。然而，微服务需要根据实际的最终用户活动不断进行测试，以使应用程序适应不断变化的偏好和请求。本文将介绍五种部署策略，帮助开发人员和 DevOps 团队在发布新特性或对基于微服务的应用程序进行更改时进行部署。

总是在生产中进行测试

分阶段环境是构建健壮的微服务基础设施的必要步骤，但这是不够的。虽然是指示性的，但它不能替代不断变化的用户流量和行为。当真实用户在生产过程中与软件进行交互时，服务可能无法有效地执行。

用户是不可预测的。他们可能会在设计通信路径时提出您没有说明的请求。或者您的 microservices 体系结构可能无法维持实际的生产流量。当与真正的最终用户进行测试时，您确信软件的性能，并且可以改进它或添加新的功能。

使用真实用户的缺点是，任何错误都会影响到他们。但是，通过特定的部署策略，您可以识别问题并最小化它们对这些用户的影响。

根据您的目标，您可以在部署阶段实现以下测试策略。它们可以单独执行，也可以组合执行，因为每种方法对部署的贡献不同。

蓝绿色部署

蓝绿色部署使用两个截然不同但完全相同的生产环境。例如，在蓝色环境中部署应用程序的非活动版本。同时，最终用户可用的最新版本在绿色环境中运行。接下来，您将按下代码以向蓝色环境添加新功能。

在这个阶段，您将在蓝色环境中测试服务，以确保它们平稳地运行。您可以通过使用基本的烟雾测试来自动化这个过程。当微服务通过这些测试时，您可以指示负载均衡器将用户流量逐渐重定向到这个新环境。

如果新功能没有问题，路由器会将所有通信从绿色环境移动到蓝色环境，但是如果出现任何错误，路由器可以立即恢复通信。

由于这两个环境的性质相同，并且它们相互依赖，因此很少或根本没有停机时间。最终用户的体验基本上没有受到影响，开发人员可以迅速行动修复任何问题 bug。

旧环境可以作为备份，从而可以在不停机的情况下执行回滚。在发布最新版本之后，您可以决定终止旧实例，但必须在您确信新环境将继续运行而不会出现错误之后。您还可以同时克隆蓝色和绿色环境，以便在将来的其他特性部署中重复该过程。

金丝雀部署

金丝雀的部署类似于蓝绿色测试，因为它可以防止与释放信息相关的风险。

“金丝雀部署”一词源于一种古老的采矿做法，即将笼中鸟放入矿井以探测有害气体的存在。如果存在，这些气体会先杀死金丝雀，然后再影响矿工，从而提供一个早期警告，让他们立即撤离矿井。

金丝雀部署也遵循类似的原则。与创建两个独立的环境不同，金丝雀部署在相同的微服务或基础设施中运行。开发人员推出一个新的服务或应用程序版本，只对一小部分最终用户进行更改。

您可以在使用新服务时快速检测错误或漏洞。这种影响是暂时的，而且是最小的，因为实验只在一部分用户上进行，而且大多数用户都没有受到影响。一旦它们正常工作并通过了验证，您就可以扩大更改的规模。

对于那些运行金丝雀式部署的人来说，最大的挑战是需要运行相同微服务的多个版本，以便一次可以将它们部署到少数用户。实现多个版本还意味着您需要跟踪哪些用户使用哪些版本来运行精确的业务指标和分析。如果在同一个应用程序中部署多个金丝雀，这种监视会变得越来越复杂。

Feature Flags 功能开关

功能标志或功能切换是在条件代码中编写的更改或功能。在应用程序运行和使用过程中，开发人员可以根据自己的测试需求开启或关闭该特性。

代码已经部署完毕，并且有两个代码路径: 一个使用实现该特性的代码，另一个不使用该特性。开发人员只需要在两条路径中选择一条。当开关打开时，代码块作为流程的一部分被执行。当关闭时，该代码将被跳过，功能也不会实现。其余的源代码继续正常运行，与功能标志的条件无关，在最终用户的体验中没有任何干扰。

一旦集成，一个功能标志允许您为一组选定的用户打开一个功能。与随机选择的金丝雀部署不同，特性切换通常用于特定情况。例如，开发人员不会创建两个独立的应用程序来实现免费和付费订阅层。相反，通过操作一个功能标志，您可以使特定的功能只对订阅用户开放。

特性标志在测试期间特别有吸引力，因为开发人员可以使用它们在整个应用程序中运行小型实验，而不用放弃控制。能够远程翻转开关也使回滚更加容易。这种风险可以忽略不计，因为应用程序是自给自足的，可以在没有特性的情况下继续运行。

特性标志通过排列和组合生成复杂的用户到服务的路径。对于特定的用户，很难确定他们在使用服务时的确切路径。功能标志使得这个问题更加复杂，因为它允许每个用户有不同的体验，最终使得应用程序难以调试。这些开关很容易在风险最小的情况下启动，但是它们的维护很快就会变得复杂起来。最好只在需要时使用它们，并与其他部署策略一起使用。

Traffic Shadowing 交通影像

通过流量跟踪或镜像，路由器将传入的流量复制到一个已经发布的服务，并将复制到另一个服务。用户和现有服务之间的请求和响应机制保持不变。另一方面，具有流量副本的第二个服务包含需要测试的新特性。因此，它不会干扰现有的流程。相反，复制用于测试其功能。

它最显著的优点是，它允许新版本接收与它所要替换的服务目前接收的流量相同的流量。不需要创建测试数据或担心复制规模。这种准确性带来的风险很小，因为对现有服务没有实际影响。开发人员可以在这个生产环境中运行所有相关的测试，例如错误测试和性能度量。新版本的响应不会发送给用户，也可以与生产服务的响应进行比较。两个版本都独立运行，具有不同的最终目标。这可以实时发生，也可以保存副本并重放以备将来测试之用。

流量阴影可以与其他部署技术(如蓝绿色或金丝雀部署)一起使用。在成功地隐藏生产环境之后，可以使用金丝雀部署逐步推出更改，以便在完全发布之前获得最大信心。

但是，隐藏可能会产生意外的后果，因此在使用具有第三方依赖性的服务部署此策略时应当谨慎。

A/B Testing A/b 测试

与蓝绿色和金丝雀式部署不同，a/b 测试侧重于用户对新特性的感知和体验。它测量最终用户是否以及如何与这些功能进行交互，它们是否易于注意和使用，以及测量应用程序的总体功能。它为开发团队提供了业务级别的洞察力，以改进他们的应用程序，因为这些特性最终是使用代码实现的。

A/b 测试将用户划分为访问不同特性的组。例如，组 a 看到的用户界面与组织 b 不同，尽管两个组中的成员对访问应用程序发出相同的请求。流量被路由到单独的构建或公共构建上的不同配置。这是通过考虑用户的操作系统和用户代理等方面来实现的。它必须在代表最终用户的示例上运行。测试还需要显示有统计学意义的有效结果。

这个测试可以与蓝绿色或淡黄色部署结合，因为它们处理这个策略测试的实际特性部署。在将显示的版本与组进行比较之后，可以将性能更好的版本推送给所有用户。

制定部署策略

概述的每个策略可以单独使用，也可以组合使用，最适合您的目标、工作流程和微型服务需求。它们允许您识别并减少任何只会在软件发布的最后阶段才出现的漏洞的影响。实现它们可能是一个有点复杂的过程，特别是对于较大的体系结构和依赖项。但是，通过实现这些策略中的任何一个，您的团队将发布应用程序的最佳版本。

使用无须实名的阿里云国际版，添加微信：ksuyun 备注：快速云！

本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请发送邮件至 cloud@ksuyun.com 举报，一经查实，本站将立刻删除。
如若转载，请注明出处：https://www.hanjifoods.com/16404.html

服务器部署测试用例设计(服务器部署测试用例设计方案)