此参考体系结构为部署使用集中式共享服务、需要本地连接并与企业的其他工作负载集成的任务关键型工作负载提供了指导。 本指南适用于属于组织中应用程序团队的工作负载所有者。
当组织想要在继承公司管理组的 Azure 应用程序登陆区域中部署工作负载时，你可能会发现自己处于这种情况。 工作负载应与 Azure 平台登陆区域中预先预配的共享资源集成，这些资源由集中式团队管理。
重要
什么是 Azure 登陆区域？ 应用程序登陆区域是在其中运行工作负载的 Azure 订阅。 它已连接到组织的共享资源。 通过该连接，它可以访问运行工作负载所需的基本基础结构，例如网络、标识访问管理、策略和监视。 平台登陆区域是各种订阅的集合，每个订阅都有特定的功能。 例如，连接订阅提供集中式 DNS 解析、本地连接和可供应用程序团队使用的网络虚拟设备 (NVA)。
作为工作负载所有者，你可以通过将共享资源的管理卸载到中心团队并专注于工作负载开发工作而受益。 组织通过跨多个工作负载应用一致的治理和摊销成本而受益。
强烈建议了解 Azure 登陆区域的概念。
在这种方法中，最大可靠性是你和平台团队的共担责任。 集中管理的组件需要高度可靠，以便任务关键型工作负载按预期运行。 必须与平台团队建立信任关系，以便在平台级别缓解影响工作负载的集中式服务中的不可用性问题。 但是，你的团队负责与平台团队一起推动需求，以实现你的目标。
此体系结构基于具有网络控制的任务关键型基线体系结构。 建议先熟悉基线体系结构，然后再继续阅读本文。
注意
该指南由生产级示例实现提供支持，该实现展示了 Azure 上的任务关键型应用程序开发。 在生产的第一步中，此实现是进一步进行解决方案开发的基础。
关键设计策略
在任务关键型基线之上应用这些策略：
关键路径
并非所有体系结构组件都需要同样可靠。 关键路径包括那些必须保持正常运行的组件，以便工作负载不会遇到任何停机时间或性能下降。 保持该路径精简将最大程度地减少故障点。
组件的生命周期
考虑关键组件的生命周期，因为它会影响实现接近零停机时间的目标。 组件可以是临时或短期资源，可以根据需要创建和销毁；非临时或与系统或区域共享生存期的长期资源。
外部依赖关系
最大程度地减少对组件和进程的外部依赖，这可能会导致故障点。 该体系结构具有团队外部各个团队拥有的资源。 这些组件（如果关键）在此体系结构的范围内。
订阅拓扑
Azure 登陆区域并不意味着单个订阅拓扑。 与平台团队一起提前规划订阅占用空间，以满足所有环境中的工作负载可靠性要求。
关键路径的自主可观测性
拥有专用的监视资源，使团队能够快速查询其数据收集（尤其是关键路径）并采取补救措施。
体系结构
下载此体系结构的 Visio 文件。
此体系结构的组件与具有网络控制的任务关键型基线体系结构相同。 为简洁起见，这些说明很短。 如果需要详细信息，请参阅链接的文章。 有关 Azure 服务的产品文档，请参阅相关资源。
全局资源
这些资源位于应用程序登陆区域订阅中。 全局资源是非临时的，并共享系统的生存期。 Azure 服务及其配置与基线全局资源相同。
区域网络资源
这些资源跨平台登陆区域订阅和应用程序登陆区域订阅。 基线体系结构部署你拥有的所有资源。 但在此体系结构中，网络资源通过连接订阅预配为平台登陆区域的一部分提供。
在本文中，请参阅区域中心虚拟网络部分。
区域标记资源
这些资源位于应用程序登陆区域订阅中。 这些资源不与其他资源共享，但全局资源除外。
大多数 Azure 服务及其配置与基线标记体系结构相同，但网络资源除外，这些资源由平台团队预先预配。
在本文中，请参阅区域辐射型虚拟网络部分。
外部资源
工作负载与本地资源交互。 其中一些位于工作负载的关键路径上，例如本地数据库。 这些资源及其通信已纳入在工作负载的整体复合服务级别协议 (SLA) 中。 所有通信都通过连接订阅进行。 工作负载可能会访问其他外部资源，但它们不被视为关键资源。
部署管道资源
任务关键型应用程序的生成和发布管道必须完全自动化，从而保证以一致的方式部署经过验证的标记。 这些资源与基线部署管道相同。
区域监视资源
这些资源位于应用程序登陆区域订阅中。 全局资源和区域资源的监视数据独立存储。 Azure 服务及其配置与基线监视资源相同。
在本文中，请参阅监视注意事项部分。
管理资源
为了访问专用计算群集和其他资源，此体系结构使用专用生成代理和跳转盒虚拟机实例。 Azure Bastion 提供对跳转盒的安全访问。 标记中的资源与基线管理资源相同。
网络注意事项
在此设计中，工作负载部署在应用程序登陆区域中，需要连接到平台登陆区域中的联合资源。 目的可能是访问本地资源、控制出口流量等。
网络拓扑
平台团队决定整个组织的网络拓扑。 在此体系结构中假定中心辐射型拓扑。 另一种方法是 Azure 虚拟 WAN。
区域中心虚拟网络
连接订阅包含一个中心虚拟网络，其中包含由整个组织共享的资源。 这些资源由平台团队拥有和维护。
从任务关键的角度来看，此网络是非临时的，这些资源位于关键路径上。
| Azure 资源 | 用途 |
|---|---|
| Azure ExpressRoute | 提供从本地到 Azure 基础结构的专用连接。 |
| Azure 防火墙 | 充当检查和限制出口流量的 NVA。 |
| Azure DNS | 提供跨界名称解析。 |
| VPN 网关 | 通过公共 Internet 将远程组织分支连接到 Azure 基础结构。 还充当备份连接替代项，用于增加复原能力。 |
资源在每个区域中预配，并与辐射型虚拟网络对等互连（如下所述）。 请确保了解并同意对 NVA、防火墙规则、路由规则、ExpressRoute 故障转移到 VPN 网关、DNS 基础结构等的更新。
注意
使用联合中心的主要好处是，工作负载可以通过遍历组织管理的网络中心与 Azure 中的其他工作负载或跨界集成。 此更改还会降低运营成本，因为部分责任已转移到平台团队。
区域辐射型虚拟网络
应用程序登陆区域的每个区域至少有两个预先预配的 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 生成代理和全局资源的订阅。
每个区域一个订阅。 它包含区域资源、标记资源和区域标记的跳转框。
下面是此体系结构中使用的订阅拓扑示例。
预生产订阅
至少需要一个订阅。 它可以运行许多独立的环境，但是，建议在专用订阅中包含多个环境。 此订阅还可能受资源限制（如生产订阅）的约束，如上所述。
开发订阅
至少需要一个订阅。 如果运行所有独立环境，则此订阅可能受资源限制的约束。 因此，可以请求多个订阅。 建议在其专用订阅中包含单个环境。
尽量匹配生产拓扑。
部署注意事项
部署失败或发布错误是应用程序中断的常见原因。 在应用程序生命周期中全面测试应用程序（和新功能）。 在登陆区域中部署工作负载时，需要将设计与平台提供的资源和治理集成。
请参阅：架构良好的任务关键型工作负载：部署和测试。
部署基础结构
部署基础结构（例如生成代理及其网络）的可靠性通常与工作负载的运行时资源一样重要。
此体系结构使用专用生成代理来防止可能影响应用程序可用性的未经授权的访问。
强烈建议在部署资源之间保持隔离。 部署基础结构应绑定到该环境的工作负载订阅。 如果在预生产订阅中使用多个环境，则通过限制对这些单个环境的访问来创建进一步的分离。 可以考虑按区域部署资源，以使部署基础结构更可靠。
零停机部署
对应用程序的更新可能会导致中断。 实施一致的部署将提高可靠性。 建议使用以下方法：
- 创建完全自动化的部署管道。
- 在预生产环境中以干净标记部署更新。
有关详细信息，请参阅任务关键型部署和测试指南。
在基线体系结构中，可通过取消预配然后在每次更新时拆除标记来实现这些策略。 在此设计中，无法完全取消预配，因为平台团队拥有一些资源。 因此，部署模型发生了变化。
部署模型
基线体系结构使用蓝绿模型来部署应用程序更新。 具有更改的新标记与现有标记一起部署。 将流量移动到新标记后，现有标记将被销毁。
在这种情况下，给定的对等互连虚拟网络是非临时的。 不允许该标记创建虚拟网络或与区域中心建立对等互连。 需要在每个部署中重复使用这些资源。
Canary 模型可以通过回退选项实现安全部署。 首先，使用代码更改部署新的标记。 部署管道引用预先预配的虚拟网络并分配子网、部署资源、添加专用终结点。 然后，它将流量转移到此预先预配的虚拟网络中的这些子网。
不再需要现有标记时，管道将删除所有标记资源，但平台拥有的资源除外。 将保留虚拟网络、诊断设置、对等互连、IP 地址空间、DNS 配置和基于角色的访问控制 (RBAC)。 此时，标记处于干净状态，并已准备好进行下一个新部署。
DINE (deploy-if-not-exist) Azure 策略
Azure 应用程序登陆区域可能具有 DINE (deploy-if-not-exists) Azure 策略。 这些检查可确保部署的资源符合应用程序登陆区域中的公司标准，即使这些资源归应用程序团队所有。 部署与最终资源配置之间可能不匹配。
了解将应用于资源的所有 DINE 策略的影响。 如果资源配置发生更改，请在工作负载开发周期的早期将策略的意图合并到声明性部署中。 否则，可能会出现导致所需状态和部署状态之间的增量偏移。
部署订阅访问管理
将订阅边界视为安全边界，以限制爆炸半径。 威胁可能会影响工作负载的可靠性。
平台团队
- 向应用程序团队授予权限范围为应用程序登陆区域订阅的操作授权。
如果在单个订阅中运行多个部署，则违规将影响这两个部署。 建议在专用订阅中运行部署。 为每个环境创建服务主体，以保持逻辑分离。
服务主体应提供对工作负载资源的自主性。 此外，它应该有限制，以防止过度操作订阅中的平台资源。
监视注意事项
Azure 登陆区域平台在管理订阅中提供共享的可观测性资源。 集中式运营团队鼓励应用程序团队使用联合模型。 但对于任务关键型工作负载，不建议使用单个集中式可观测性存储，因为它可能是单一故障点。 任务关键型工作负载还会生成可能不适用于集中式运营团队或不可操作的遥测数据。
因此，强烈建议使用自主监视方法。 工作负载操作员最终负责监视，并且必须有权访问表示整体运行状况的所有数据。
基线体系结构遵循该方法，并在此参考体系结构中继续使用。 Azure Log Analytics 和 Azure Application Insights 按区域和全球部署，以监视这些范围内的资源。 聚合日志、创建仪表板和警报属于团队的范围。 利用将指标和日志发送到各种接收器的 Azure 诊断功能，以支持日志和指标收集的平台要求。
运行状况模型
任务关键型设计方法需要系统运行状况模型。 定义总体运行状况分数时，请包括应用程序所依赖的范围内平台登陆区域流。 生成日志、运行状况和警报查询以执行跨工作区监视。
平台团队
为任务关键型应用程序的关键路径中使用的相关平台资源授予基于角色的访问控制 (RBAC) 查询和读取日志接收器。
通过向应用程序团队提供足够的操作权限，支持组织对任务关键型工作负载的可靠性目标。
在此体系结构中，运行状况模型包括来自连接订阅中预配的资源的日志和指标。 如果将此设计扩展到本地资源（如数据库），则运行状况模型必须包括与该资源的网络连接，包括 Azure 中和本地的网络虚拟设备等安全边界。 此信息对于快速确定根本原因并修正可靠性影响非常重要。 例如，是尝试路由到数据库时发生故障，还是数据库有问题？
与平台提供的策略和规则集成
应用程序登陆区域订阅从其管理组继承 Azure 策略、Azure 网络管理器规则和其他控制。 平台团队提供这些防护措施。
对于部署，不要完全依赖平台提供的策略，因为：
- 它们的设计不能满足单个工作负载的需求。
- 策略和规则可能会在团队外部更新或删除，因此可能会影响可靠性。
强烈建议在部署中创建和分配 Azure 策略。 考虑到对系统可靠性的潜在影响，这项工作可能会导致一些重复，但这是可以接受的。 如果平台策略发生更改，工作负载策略仍将在本地生效。
平台团队
- 随着策略的发展，让应用程序团队参与策略的变更管理过程。
- 请注意应用程序团队使用的策略。 评估是否应将其添加到管理组。
部署此体系结构
此体系结构的网络方面是在任务关键型连接实现中实现的。
注意
连接实现旨在说明依赖组织资源、与其他工作负载集成并使用共享服务的任务关键型工作负载。 此实现假定连接订阅已存在。
后续步骤
查看 Azure 架构良好的框架中的网络和连接设计领域。
相关资源
除基线体系结构中使用的 Azure 服务之外，这些服务对于此体系结构也很重要。