准备

  • 5 分钟

你将向现有架构中添加自己的增强功能，以满足组织的较高可靠性要求。 在此处，我们将讨论使练习获得成功所需的背景上下文。

问题上下文

Contoso Shoes 需要为下次高调的产品发布做好准备，预计这会显著增加流量。 在过去两年中发生了一些事件，导致网站离线长达半天。 系统未在开发/测试环境中进行完整测试，某些 bug 进入了生产环境。 故障排除和修正花费了很长时间，因为操作员无法快速识别根本原因。

当某些组件不可用时，出现了一些挑战。 Azure Key Vault 配置错误时，对计算的横向扩展操作受到了影响。 此外，未针对区域中断实施任何策略。 在最近的一个事件中，整个西欧区域出现停机。 由于工作负载仅在该区域中运行，因此在备份该区域之前，公司必须承受财务损失。

当前体系结构

若要完成此挑战，需要充分了解 Contoso Shoe 的当前体系结构。 让我们重点看看其 API 层。

Web 应用程序的基本体系结构图。

组件

此体系结构的所有组件都部署到单个区域。

  • Azure 应用服务计划的标准 S2 SKU 提供托管应用的计算平台。 自动缩放处于启用状态。 开发环境使用基本 B1 SKU。

  • Azure 应用服务提供在容器中运行 API 代码的应用程序平台。 应用服务身份验证功能处于启用状态以便进行授权。

  • 借助部署槽位可分阶段完成部署，然后将该部署交换为生产部署。 它们仅用于生产。

  • Azure 容器注册表存储容器化 API 代码，通过由工作负载团队创建和管理的持续集成/持续交付 (CI/CD) 管道进行推送。 生产环境和开发/测试环境都会使用容器注册表。

  • 具有 SQL API 的 Azure Cosmos DB 存储与工作负载相关的所有状态。 Cosmos DB 数据库帐户具有单一数据库，其中包含共享吞吐量模型中的几个容器。 Azure Cosmos 帐户使用无服务器容量模式。 有一个实例用于生产，另一个实例用于开发/测试。

  • Azure Key Vault 存储 API 向外部第三方 API 进行 HTTP POST 调用所需的机密（作为一个请求流的一部分）。 应用程序通过 Azure 应用服务应用配置中的 Key Vault 引用访问机密。 有一个 Key Vault 用于生产，另一个 Key Vault 用于开发/测试。

  • Azure Log Analytics 用作统一接收器，以便为解决方案中使用的所有组件的所有 Azure 诊断设置存储日志和指标。 有一个工作区用于生产，另一个工作区用于开发/测试。

  • Azure Application Insights 用于从 API 捕获遥测和日志。 Application Insights 使用独立模式，而不是写入专用 Log Analytics 工作区。 生产和开发/测试不共享通用实例。

  • Azure Pipelines 用于在预生产环境和生产环境中构建、测试和部署工作负载的 CI/CD。 工作负载团队负责管理管道，该团队还管理其解决方案中的所有基础结构。 Bicep 是适用于基础结构即代码 (IaC) 的技术选择。

设计选项

在组件列表中，部署戳包含参与处理请求的服务。 这些服务包括应用程序服务、API 代码和 Cosmos DB。 该戳还包括非功能组件：Key Vault 和容器注册表。 应用程序对性能和复原能力框架具有第三方依赖项。 系统托管标识在缩放单元的组件之间使用。

在缩放单元中，应用服务配置为基于负载自动缩放。

不同的环境用于生产和开发/测试。 生产环境使用应用服务计划的标准 SKU。 公司进行此选择是为了在将应用程序部署到生产环境之前，能够将其预热到槽。 开发/测试环境使用基本 SKU 来实现成本优化。 两种环境都有自己的服务实例。 环境仅共享容器注册表。

容器化 API 代码在单个容器映像（在应用服务中运行）中交付。 API 具有多个 HTTP 终结点，供各种前端用于读取和写入。 前端超出了本模块的范围，但从此情形的关键任务状态的全局来看，它们是在范围之内的。 代码使用 Application Insights 进行检测，以捕获一些基本遥测。 开发此代码的团队还管理 API 容器映像的 CI/CD 管道。

权衡

但是，与所有事物一样，当前体系结构也有弱点。 业务要求使成本优化优先于可靠性和操作。 为了保持在成本限制范围内，体系结构未进行发展。 当利用平台提供的可靠性功能时，组件会出现不足。 例如，选择 SKU 进行计算会阻止工作负载使用可用性区域。 对于遥测，使用的是未与 Log Analytics 集成的较旧版本 Application Insights。

此外，对工作负载的访问过于普遍。 例如，如果没有任何虚拟网络集成，所有 Azure 服务都可以通过公共 Internet 直接访问。

开发了解决方案后，应用开发团队使用单一 Azure 订阅，将开发/测试和生产置于相同订阅中，以便 DevOps 团队能够轻松使用工具。 但是，生产资源和开发/测试资源未完全隔离。 某些资源在两个环境之间共享，尽管它们确实获得了与 Contoso Shoes 解决方案的其余部分隔离的订阅。

此外，开发/测试环境是在开发和 QA 团队的所有成员之间共享的单一环境。 考虑到团队的规模以及他们之间的协调不需要较高程度的隔离，该选择是合理的。 随着团队和解决方案的发展，由于工作流生命周期发生冲突，单一开发/测试环境导致了越来越多的集成复杂性。 改动及其对可靠性的影响代价高昂。

项目规范

公司希望向其解决方案体系结构添加功能，以便能够处理预期的负载增加。 下面是业务要求：

  • 通过将体系结构扩展到多个区域来构建承受区域故障的能力
  • 在地理位置更靠近客户的区域中更快地为客户提供服务，从而改善客户体验
  • 与 Azure 路线图保持一致，并利用 Azure 服务提供的最新可靠性功能
  • 通过构建整体运行状况模型，及早捕获问题并检测其在系统中的级联影响

这些要求只是其改进计划的优先列表。 应用程序团队知道，必须考虑所有设计领域才能使此解决方案的可靠性达到任务关键型标准。 请放心，在你帮助他们完成即将进行的练习中涉及的各个方面后，他们不会停止改进其解决方案和运营。

欢迎加入团队！ Contoso Shoes 期待听取你的建议。

安装

在此挑战项目中，你将担任架构师的角色，并将从以上部分的优先项目开始，帮助 Contoso Shoes 实现其可靠性成果。

  • 建议使用体系结构绘图工具直观显示体系结构。
  • 如果你对服务及其功能感到满意，则无需 Azure 订阅即可完成此挑战。