Azure 登陆区域中的任务关键基线体系结构

此参考体系结构提供有关部署使用集中式共享服务、需要本地连接并与企业的其他工作负荷集成的任务关键型工作负荷的指导。 本指南适用于属于组织中的应用程序团队的工作负荷所有者。

当组织想要在继承公司管理组的 Azure 应用程序登陆区域中 部署工作负荷时，你可能会发现自己处于这种情况。 工作负荷应与由集中式团队管理的 Azure 平台登陆区域中 预先预配的共享资源集成。

在此方法中，最大的可靠性是你和平台团队之间的共同责任。 集中管理的组件需要高度可靠，任务关键型工作负荷才能按预期运行。 必须与平台团队建立受信任的关系，以便集中服务中的不可用问题（影响工作负荷）在平台级别得到缓解。 但是，你的团队负责推动平台团队的要求，以实现目标。

此体系结构基于具有网络控制的任务关键基线体系结构。 建议先熟悉 基线体系结构 ，然后再继续本文。

关键设计策略

将这些策略应用于 任务关键基线之上：

• 关键路径

  并非所有体系结构组件都需要同样可靠。 关键路径包括那些必须保持正常运行的组件，以便工作负荷不会遇到任何停机或性能下降的问题。 保持路径精简将最大程度地减少故障点。

• 组件的生命周期

  考虑关键组件的生命周期，因为它会影响实现近零停机的目标。 组件可以是 临时 资源，也可以是可以根据需要创建和销毁的短期资源;与系统或区域共享生存期 的非 临时或长生存期资源。

• 外部依赖项

  最大程度地减少对组件和进程的外部依赖关系，这可能会导致故障点。 该体系结构的资源由团队外部的各个团队拥有。 这些组件（如果关键）是此体系结构的作用域内。

• 订阅拓扑

  Azure 登陆区域并不意味着单个订阅拓扑。 与平台团队提前规划订阅占用空间，以适应所有环境中的工作负荷可靠性要求。

• 自主可观测性进入关键路径

  拥有专门的监视资源，使团队能够快速查询其数据收集（尤其是关键路径），并采取措施进行修正。

建筑

下载此体系结构的 Visio 文件。

此体系结构的组件与 具有网络控制的任务关键型基线体系结构相同。 说明简短。 如果需要详细信息，请参阅链接的文章。 有关 Azure 服务的产品文档，请参阅 相关资源。

全局资源

这些资源位于应用程序登陆区域订阅中。 全局资源是非临时资源，共享系统的生存期。 Azure 服务及其配置与 基线全局资源保持不变。

区域网络资源

这些资源跨平台登陆区域订阅和应用程序登陆区域订阅（s）生存。 基线体系结构部署你拥有的所有资源。 但是，在此体系结构中，通过 连接订阅 提供网络资源作为平台登陆区域的一部分进行预配。

在本文中，请参阅 “区域中心虚拟网络 ”部分。

区域戳记资源

这些资源位于应用程序登陆区域订阅中。 除了 全局资源之外，这些资源不与其他资源共享任何资源。

大多数 Azure 服务及其配置与 基线标记体系结构相同，但平台团队预先预配的网络资源除外。

在本文中，请参阅 “区域辐射虚拟网络 ”部分。

外部资源

工作负荷与本地资源交互。 其中一些位于工作负荷的关键路径上，例如本地数据库。 这些资源和与其通信将纳入工作负荷的总体复合服务级别协议（SLA）。 所有通信都通过连接订阅。 工作负荷可能会访问其他外部资源，但它们不被视为关键资源。

部署管道资源

必须完全自动化任务关键型应用程序的生成和发布管道，以确保部署已验证标记的一致方式。 这些资源与 基线部署管道保持不变。

区域监视资源

这些资源位于应用程序登陆区域订阅中。 全局资源和区域资源的监视数据单独存储。 Azure 服务及其配置与 基线监视资源保持不变。

在本文中，请参阅 “监视注意事项 ”部分。

管理资源

为了访问专用计算群集和其他资源，此体系结构使用专用生成代理和跳转盒虚拟机实例。 Azure Bastion 提供对跳线框的安全访问。 印章中的资源与 基线管理资源保持不变。

网络注意事项

在此设计中，工作负荷部署在应用程序登陆区域中，需要连接到平台登陆区域中的联合资源。 目的是访问本地资源、控制出口流量等。

网络拓扑

平台团队决定整个组织的网络拓扑。 在此体系结构中假定中心辐射型拓扑。 替代方法是 Azure 虚拟 WAN。

区域中心虚拟网络

连接订阅包含一个中心虚拟网络，其中包含由整个组织共享的资源。 这些资源由平台团队拥有和维护。

从任务关键型的角度来看，此网络不是临时的，这些资源位于关键路径上。

Azure 资源	目的
Azure ExpressRoute	提供从本地到 Azure 基础结构的专用连接。
Azure 防火墙	充当检查和限制出口流量的 NVA。
Azure DNS	提供跨界名称解析。
VPN 网关	通过公共 Internet 将远程组织分支连接到 Azure 基础结构。 还可以充当备份连接替代方法，用于添加复原能力。

资源在每个区域中预配，并与辐射虚拟网络对等互连（下一步所述）。 请确保了解并同意对 NVA、防火墙规则、路由规则、ExpressRoute 故障转移到 VPN 网关、DNS 基础结构等的更新。

区域辐射虚拟网络

应用程序登陆区域至少有两个预先预配的 Azure 虚拟网络，每个区域都由区域标记引用。 这些网络是非临时网络。 一个服务生产流量，另一个面向 vNext 部署。 此方法使你能够执行 可靠且安全的部署做法。

作虚拟网络

作流量在单独的虚拟网络中隔离。 此虚拟网络是非临时的，你拥有此网络。 此体系结构使用 网络控件保留与基线体系结构相同的设计。

作网络和辐射网络之间没有对等互连。 所有通信都通过专用链接进行。

共担责任

清楚地了解哪个团队负责体系结构的每个设计元素。 以下是一些关键领域。

IP 地址规划

估计运行工作负荷所需的大小后，请与平台团队协作，以便他们可以适当地预配网络。

平台团队

• 为参与对等互连的虚拟网络提供不同的地址。 重叠的地址（例如本地和工作负荷网络）可能会导致中断。

• 分配足够大的 IP 地址空间，以包含运行时和部署资源、处理故障转移和支持可伸缩性。

预配的虚拟网络和对等互连必须能够支持工作负荷的预期增长。 你必须定期评估平台团队的这种增长。 有关详细信息，请参阅 与 Azure 的连接。

区域辐射网络子网

你负责在区域虚拟网络中分配子网。 子网和资源是临时的。 地址空间应足够大，以适应潜在的增长。

• 专用终结点子网 流量到达虚拟网络后，使用专用终结点限制与网络内的 PaaS 服务通信，就像 使用网络控制的基线体系结构一样。 这些终结点放置在专用子网中。 从该子网向专用终结点分配专用 IP 地址。

• 群集子网 工作负荷的可伸缩性要求会影响应为子网分配多少地址空间。 随着 AKS 节点和 Pod 横向扩展，IP 地址将从此子网分配。

网络分段

保持适当的分段，以便未经授权的访问不会损害工作负荷的可靠性。

此体系结构使用网络安全组（NSG）来限制子网和连接订阅之间的流量。 NSG 将 ServiceTags 用于受支持的服务。

平台团队

• 通过 Azure 网络管理器策略强制使用 NSG。

• 请注意工作负荷设计。 邮票之间没有任何直接流量。 此外，区域间没有流。 如果需要这些路径，流量必须流经连接订阅。

• 防止来自其他工作负荷的不必要的中心流量进入任务关键型工作负荷。

来自区域标记的出口流量

来自每个区域辐射网络的所有传出流量都通过区域中心网络中的集中式 Azure 防火墙进行路由。 它充当检查并允许或拒绝流量的下一跃点。

平台团队

• 为该自定义路由创建 UDR。

• 分配 Azure 策略，该策略将阻止应用程序团队创建没有新路由表的子网。

• 为应用程序团队授予足够的基于角色的访问控制（RBAC）权限，以便他们可以根据工作负荷的要求扩展路由。

多区域冗余

任务关键型工作负荷必须部署在多个区域中，才能承受区域性中断。 与平台团队合作，确保基础结构可靠。

平台团队

• 为每个区域部署集中式网络资源。 任务关键型设计方法需要区域隔离。

• 与应用程序团队协作，发现隐藏的区域依赖关系，以便一个区域中的降级平台资源不会影响另一个区域中的工作负荷。

DNS 解析

连接订阅提供专用 DNS 区域。 但是，这种集中式方法可能不会考虑可能特定于用例的 DNS 需求。 预配自己的 DNS 区域并链接到区域标记。 如果应用程序团队不拥有 DNS，则对全局资源（如 Azure Cosmos DB）的管理将变得具有挑战性。

平台团队

• 将 Azure 专用 DNS 区域委托给应用程序团队，以涵盖其用例。

• 对于区域中心网络，请将 DNS 服务器值设置为“默认”（Azure 提供），以支持应用程序团队管理的专用 DNS 区域。

环境设计注意事项

一般做法是将工作负荷放置在单独的环境中，以便进行生产、预生产和发展。 下面是一些关键注意事项。

如何维护隔离？

生产环境 必须 与其他环境隔离。 较低的环境还应保持隔离级别。 避免在环境之间共享应用程序拥有的资源。

应用程序团队拥有的全球、区域和印花资源需要一个生产环境。 需要预生产环境（如过渡和集成）来确保在模拟生产的环境中测试应用程序。 开发环境应是缩减版本的生产环境。

预期的生命周期是什么？

完成验证测试后，可以销毁预生产环境。 建议开发环境共享功能的生存期，并在开发完成后销毁。 这些作由持续集成/持续部署（CI/CD）自动化完成。

利弊是什么？

考虑环境隔离、管理复杂性和成本优化之间的权衡。

工作负荷基础结构的订阅拓扑

平台团队会为你提供订阅。 根据 环境数量，只需为一个工作负荷请求多个订阅。 根据 环境类型，某些环境可能需要专用订阅，而其他环境可能合并到一个订阅中。

不管怎样，请与平台团队协作，设计符合工作负荷整体可靠性目标的拓扑。 在同一订阅中的环境之间共享平台提供的资源有好处，因为它将反映生产环境。

生产订阅

对于你提供的订阅，可能存在资源限制。 如果将所有这些资源并置在一个订阅中，可能会达到这些限制。 根据缩放单位和预期缩放，请考虑使用更分布式的模型。 例如，

• 一个订阅，其中包含 Azure DevOps 生成代理和全局资源。

• 每个区域有一个订阅。 它包含区域资源、邮票资源和区域邮票的跳转框。

下面是此体系结构中使用的示例订阅拓扑。

预生产订阅

至少需要一个订阅。 但它可以运行许多独立环境，但建议在专用订阅中有多个环境。 此订阅还可能受资源限制，如上述生产订阅。

开发订阅

至少需要一个订阅。 如果运行所有独立环境，则此订阅可能受资源限制的约束。 因此，可以请求多个订阅。 建议在其专用订阅中拥有单个环境。

尝试尽可能多地匹配生产拓扑。

部署注意事项

失败的部署或错误版本是应用程序中断的常见原因。 在应用程序生命周期中全面测试应用程序（和新功能）。 在登陆区域中部署工作负荷时，需要将设计与平台提供的资源和治理集成。

请参阅： 架构完善的任务关键型工作负荷：部署和测试。

部署基础结构

部署基础结构（如生成代理及其网络）的可靠性通常与工作负荷的运行时资源一样重要。

此体系结构使用专用生成代理来防止未经授权的访问，这些访问可能会影响应用程序的可用性。

强烈建议在部署资源之间保持隔离。 部署基础结构应绑定到该环境的工作负荷订阅（s）。 如果在预生产订阅中使用多个环境，则通过限制仅对这些单个环境的访问权限来创建进一步分离。 可以考虑每个区域部署资源，使部署基础结构更加可靠。

零停机时间部署

对应用程序的更新可能会导致服务中断。 强制实施一致的部署将提高可靠性。 建议使用以下方法：

• 具有完全自动化的部署管道。
• 在清理标记的预生产环境中部署更新。

有关详细信息，请参阅 任务关键型部署和测试指南。

在 基线体系结构中，这些策略通过取消预配来实现，然后通过每次更新拆解标记。 在此设计中，无法完成取消预配，因为平台团队拥有一些资源。 因此，部署模型已更改。

部署模型

基线体系结构使用 Blue-Green 模型来部署应用程序更新。 包含更改的新标记与现有印花一起部署。 将流量移动到新标记后，将销毁现有标记。

在这种情况下，给定的对等互连虚拟网络是非临时的。 不允许创建虚拟网络或与区域中心的对等互连。 需要在每次部署中重复使用这些资源。

Canary 模型可以通过回滚选项来实现安全部署。 首先，使用代码更改部署新标记。 部署管道引用预配的虚拟网络并分配子网、部署资源、添加专用终结点。 然后，它会将此预配的虚拟网络中的流量转移到这些子网。

不再需要现有标记时，管道会删除所有标记资源，但平台拥有的资源除外。 将保留虚拟网络、诊断设置、对等互连、IP 地址空间、DNS 配置和基于角色的访问控制（RBAC）。 此时，标记处于干净状态，并已准备好进行下一个新部署。

DINE （deploy-if-not-exists） Azure 策略

Azure 应用程序登陆区域可能具有 DINE （deploy-if-not-exists） Azure 策略。 这些检查可确保部署的资源符合应用程序登陆区域中的公司标准，即使它们归应用程序团队所有。 部署与最终资源配置之间可能存在不匹配的情况。

了解将应用于资源的所有 DINE 策略的影响。 如果对资源配置进行了更改，请在工作负载开发周期的早期将策略意图纳入声明性部署。 否则，可能会导致所需状态与已部署状态之间的增量。

部署订阅访问管理

将订阅边界视为安全边界，以限制爆炸半径。 威胁可能会影响工作负荷的可靠性。

平台团队

• 为应用程序团队授予对作用域为应用程序登陆区域订阅的权限的作授权。

如果在单个订阅中运行多个部署，则违规会影响这两个部署。 建议在专用订阅中运行部署。 为每个环境创建服务主体以维护逻辑分离。

服务主体应提供对工作负荷资源的自主性。 此外，它应存在限制，以防止过度作订阅中的平台资源。

监视注意事项

Azure 登陆区域平台在管理订阅中提供共享可观测性资源。 集中式运营团队 鼓励应用程序团队使用联合模型。 但对于任务关键型工作负荷，不建议使用单个集中式可观测性存储，因为它可能是单个故障点。 任务关键型工作负荷还会生成可能不适用于集中式运营团队或可作的遥测数据。

因此，强烈建议使用自治方法来监视。 工作负荷作员最终负责监视，并且必须有权访问表示整体运行状况的所有数据。

基线体系结构遵循该方法，并将继续在此参考体系结构中。 Azure Log Analytics 和 Azure Application Insights 在区域和全球部署，用于监视这些范围内的资源。 聚合日志、创建仪表板和警报适用于你的团队。 利用将指标和日志发送到各种接收器的 Azure 诊断功能，以支持日志和指标收集的平台要求。

运行状况模型

任务关键型设计方法需要系统 运行状况模型。 定义总体运行状况分数时，请包括应用程序依赖的范围内平台登陆区域流。 生成日志、运行状况和警报查询以执行跨工作区监视。

平台团队

• 为任务关键型应用程序的关键路径中使用的相关平台资源授予基于角色的访问控制（RBAC）查询和读取日志接收器。

• 通过向应用程序团队提供足够的权限来执行其作，支持实现对任务关键型工作负荷的可靠性的组织目标。

在此体系结构中，运行状况模型包括连接订阅中预配的资源的日志和指标。 如果扩展此设计以访问本地资源（例如数据库），则运行状况模型必须包括与该资源的网络连接，包括安全边界，例如 Azure 中的网络虚拟设备 以及 本地。 此信息对于快速确定根本原因并修正可靠性影响非常重要。 例如，尝试路由到数据库时是否发生故障，或者数据库出现问题？

请参阅： 架构完善的任务关键型工作负荷：运行状况建模。

与平台提供的策略和规则集成

应用程序登陆区域订阅从其管理组继承 Azure 策略、Azure 网络管理器规则和其他控制措施。 平台团队提供这些护栏。

对于部署，不完全依赖于平台提供的策略，因为：

• 它们未设计为满足单个工作负荷的需求。
• 策略和规则可能会在团队外部更新或删除，因此可能会影响可靠性。

强烈建议在部署中创建和分配 Azure 策略。 这项工作可能会导致一些重复，但考虑到系统可靠性的潜在影响，这是可以接受的。 如果平台策略发生更改，工作负荷策略仍将在本地生效。

平台团队

• 让应用程序团队在策略的更改管理过程中随着策略的发展而参与其中。
• 请注意应用程序团队使用的策略。 评估是否应将其添加到管理组。

部署此体系结构

此体系结构的网络方面在任务关键型连接实现中实现。

后续步骤

查看 Azure 精心构建的框架中的网络和连接设计区域。

相关资源

除了 基线体系结构中使用的 Azure 服务外，这些服务对于此体系结构非常重要。

• Azure 管理组
• Azure Policy
• Azure 网络管理器
• Azure Monitor
• 虚拟网络
• 路由表