在 Azure 登陆区中部署基线 Microsoft Foundry 聊天参考架构

Azure OpenAI in Foundry Models、Foundry Tools、Azure App Service、Azure Key Vault、Azure Monitor、Microsoft Foundry

本文是系列文章的一部分，建立在《基线 Microsoft Foundry 聊天参考架构》（Baseline Microsoft Foundry chat reference architecture）之上。在 Azure 工作负载登陆区（workload landing zone）订阅中部署之前，请先审阅该基线架构，以便确定必须做出的调整。

本文描述一种生成式 AI 工作负载架构：它部署基线聊天应用，但使用工作负载团队职责范围之外的资源。平台团队集中管理这些资源，多个工作负载团队共同使用。共享资源包括用于跨本地连接的网络资源、身份访问管理系统以及策略。本指南帮助使用 Azure 登陆区（Azure landing zones）的组织保持一致的治理和成本效率。

Foundry 使用资源和项目来组织 AI 开发与部署。例如，一种登陆区实现可能把 Foundry 资源当作业务组级别的集中资源，把项目当作该业务组中每个工作负载的委派资源。由于资源组织因素和成本分摊限制，我们不推荐这种拓扑，本文也不对其提供指导。相反，本架构把工作负载视为 Foundry 资源的所有者，这是推荐做法。

作为工作负载所有者，你把共享资源管理委派给平台团队，以便专注于工作负载开发。本文从工作负载团队的视角出发，并给出针对平台团队的建议。

重要

什么是 Azure 登陆区？

Azure 登陆区把组织的云足迹分成两个关键区域：

• 每个工作负载有一个工作负载登陆区，其中包含其全部环境，例如开发、测试和生产。每个环境由一个或多个 Azure 订阅组成。工作负载登陆区连接到组织的共享平台资源。该连接为登陆区提供支撑工作负载的基础设施，例如网络、身份访问管理、策略和监控。
• 平台登陆区（platform landing zone）是一组可由多个平台团队管理的订阅。每个订阅有特定职能。例如，连接订阅为平台团队提供集中的域名系统（Domain Name System，DNS）解析、跨本地连接，以及网络虚拟设备（network virtual appliances，NVAs）。

要实施本架构，需要理解 Azure 登陆区、其设计原则和设计领域。

文章布局

架构

[图：工作负载架构图，包括选定的平台订阅资源。]

此架构图包含两个主要部分。上方蓝色部分标为工作负载登陆区订阅。下方黄色部分标为平台登陆区订阅。上方方框同时包含工作负载创建的资源和订阅配给资源。工作负载资源包括 Azure Application Gateway 和 Azure Web Application Firewall、App Service 及其集成子网，以及平台即服务（platform as a service，PaaS）解决方案的专用终结点（private endpoints），例如 Azure Storage、Azure Key Vault、Azure AI Search、Foundry、Azure Cosmos DB 和 Azure Storage。工作负载资源还有一个带 Agent Service 和监控资源的 Foundry 项目。App Service 在不同 Azure 区域（zones）中有三个实例。平台订阅包含中心虚拟网络、Azure Firewall、Azure Bastion，以及灰色显示的 Azure VPN Gateway 和 Azure ExpressRoute。工作负载登陆区中的分支虚拟网络与中心虚拟网络通过虚拟网络对等互连连接。受控出站流量从工作负载登陆区前往平台登陆区中的 Azure Firewall。一条流从 App Service 到 App Service 集成子网，再到专用终结点，然后到这些专用终结点对应的服务。

下载此架构的 Visio 文件。

组件

所有 Azure 登陆区架构都在平台团队和工作负载团队之间划分所有权。这种划分称为订阅民主化（subscription democratization）。应用架构师、数据科学家和 DevOps 团队必须清楚理解这种划分，以判断哪些内容处于其直接影响力或控制之下，哪些不是。

与大多数工作负载登陆区实现一样，工作负载团队主要管理工作负载组件的配置、部署和监督，包括本架构中的 AI 服务。

#### 工作负载团队拥有的资源

下列资源相对基线架构基本保持不变。

• Foundry 资源及其项目是一个 AI 应用平台。在该平台上，工作负载的 AI 开发者和数据科学家评估并部署 AI 模型。他们也使用该平台测试和托管智能体（agents）。每个项目暴露一个终结点，客户端用它与团队的智能体和模型交互。在本架构中，Foundry 资源使工作负载团队能够以模型即服务（models as a service，MaaS）方式托管模型、实施内容安全，并建立使用工作负载特定工具连接的智能体。

如果组织的 AI 卓越中心（AI Center of Excellence）限制对 AI 模型部署的访问，工作负载团队可能不会在自己的 Foundry 资源中托管模型。相反，他们可能需要使用集中式 AI 资源，例如 AI 中心（AI hub）。在这种场景中，所有模型消费通常流经 AI 平台团队提供的 AI 网关（AI gateway）。

本文假设此场景中的生成式 AI 模型是工作负载拥有并托管的资源。如果不是，模型宿主或 AI 网关就成为工作负载依赖项。平台团队必须维护从你的虚拟网络到他们虚拟网络的可靠网络连接，或者必须建立专用终结点。

• Agent Service 是云原生运行时环境，使智能体能够安全、自主地运行。在本架构中，Agent Service 为聊天交互提供编排层。它托管并管理处理用户请求的提示词智能体，与基线架构一致。无论你部署提示词智能体还是容器化托管智能体，本文中的登陆区网络和治理设计都适用。

在本架构中使用标准智能体设置。把智能体连接到分支虚拟网络中的专用子网，并经由连接订阅路由出站流量。如基线架构所述，单租户数据代理在该专用子网中运行，并发起智能体的出站流量。

工作负载团队为智能体状态、聊天历史和文件存储提供专用 Azure 资源。这些资源是 Azure Cosmos DB for NoSQL、Azure Storage 和 Azure AI Search。你的 Agent Service 实例独占管理这些资源及其数据。工作负载中的其他应用组件，或组织中的其他工作负载，不应使用它们。

• 如果托管专用 MCP 服务器，工作负载团队部署并运营 MCP 服务器及其宿主环境。平台团队为专用 MCP 子网分配足够的分支地址空间，并支持集中式 DNS 和防火墙要求。对于公共 MCP 服务器，工作负载团队向平台团队提供智能体流量必须经由中心防火墙到达的已批准终结点 FQDN。

• Azure App Service 使开发者能够构建 Web 和移动应用，并用 API 应用自动化业务流程。在本架构中，它托管包含聊天用户界面（user interface，UI）的 Web 应用，并交付面向用户的组件，跨区域部署多个实例以实现可用性。

一个 Azure Storage 帐户以 ZIP 文件形式托管 Web 应用代码，该文件挂载在 App Service 内。

• AI Search 是可扩展的搜索基础设施，为异构内容建立索引，并通过 API、应用和 AI 智能体实现数据检索。在本架构中，由 AI Search 驱动的 Foundry IQ 充当检索增强生成（Retrieval Augmented Generation）模式的工作负载知识库。该模式从提示词中提取合适的查询，查询 AI Search，并把结果用作生成式 AI 基础模型的依据数据。

• Azure Application Gateway 是 Web 流量负载均衡器和应用交付控制器。在本架构中，它作为反向代理，把用户请求路由到托管在 App Service 中的聊天 UI。它托管 Azure Web 应用防火墙，以帮助保护前端应用免受潜在恶意流量影响。

• Azure Key Vault 是用于安全存储和访问机密、密钥和证书的云服务。在本架构中，它存储应用网关的传输层安全（Transport Layer Security，TLS）证书。

• Azure Monitor、Azure Monitor Logs 和 Application Insights 收集、存储并可视化可观测性数据。在本架构中，它们为全部工作负载组件提供监控、诊断和运营洞察。

• Azure Policy 应用工作负载特定策略，以帮助大规模治理、保护和施加控制。在本架构中，它对工作负载团队管理的资源强制执行治理和合规规则。

工作负载团队还维护以下资源：

• 分支虚拟网络子网和网络安全组（network security groups，NSGs）维持分段，并控制子网之间的流量。在本架构中，它们在工作负载组件之间强制网络边界和安全。
• 专用终结点保护到平台即服务（PaaS）解决方案的连接。在本架构中，它们确保敏感服务只能在专用网络内访问，从而减少对公共互联网的暴露。其他依赖项，例如其他团队拥有的状态存储，可以作为专用终结点暴露给你的工作负载，避免经由连接订阅的传递路由。

#### 平台团队拥有的资源

平台团队拥有并维护下列集中资源。本架构假设这些资源已预先预配，并把它们视为依赖项。

• Azure Firewall 是托管的、基于云的网络安全服务。在本架构中，中心网络里的 Azure Firewall 路由、检查并限制源自工作负载的出站流量，包括智能体流量。工作负载出站流量前往互联网、跨本地目的地，或其他工作负载登陆区。

相对基线的变化：在基线架构中，工作负载团队拥有此组件。在本架构中，平台团队在连接订阅下管理它。

• Azure Bastion 是托管 PaaS 服务，用于通过专用 IP 地址连接到虚拟机。在本架构中，中心网络中的 Azure Bastion 提供对工作负载组件的安全运营访问，并允许访问 Foundry 组件。它确保管理员和支持人员可以安全连接到虚拟机，而无需把 RDP/SSH 端口暴露到公共互联网。

相对基线的变化：在基线架构中，工作负载团队拥有此组件。

• 分支虚拟网络是部署工作负载的位置。

相对基线的变化：在基线架构中，工作负载团队拥有此网络。

• 用户定义路由（user-defined routes，UDRs）强制隧道到中心网络的防火墙。

相对基线的变化：在基线架构中，工作负载团队拥有此路由。

• 基于 Azure Policy 的治理约束和 DeployIfNotExists（DINE）策略应用于工作负载订阅。你可以在平台团队拥有的管理组级别应用这些策略，或直接应用到工作负载的订阅。

相对基线的变化：这些策略在本架构中是新增的。平台团队应用约束你的工作负载的策略。某些策略可能重复已有的工作负载约束，或引入新约束。

• Azure 专用 DNS 区域托管专用终结点的 A 记录，以便工作负载组件能够安全解析工作负载内使用的 PaaS 服务的 FQDN。更多信息请参阅《大规模 Azure Private Link 与 DNS 集成》（Azure Private Link and DNS integration at scale）。

相对基线的变化：在基线架构中，工作负载团队拥有此网络。在本架构中，平台团队在连接订阅下管理此组件。

• DNS 解析服务支持分支虚拟网络和跨本地工作站。此服务通常使用 Azure Firewall 作为 DNS 代理，或使用 Azure DNS Private Resolver。在本架构中，该服务为来自分支的全部 DNS 请求解析专用终结点 DNS 记录。为满足 Agent Service 的解析要求，平台团队应使用 DNS Private Resolver 和链接的规则集，或确保虚拟网络的 DNS 配置为基于中心的解析。

• Azure DDoS Protection 帮助保护公共 IP 地址免受分布式攻击。在本架构中，DDoS Protection 帮助保护与 Application Gateway 关联的公共 IP 地址。

相对基线的变化：在基线架构中，工作负载团队购买 DDoS Protection。

重要

Azure 登陆区把上述部分资源作为平台登陆区订阅的一部分提供。你的工作负载订阅提供其他资源。这些资源中有许多位于连接订阅中，该订阅还包括 Azure ExpressRoute、Azure VPN Gateway 和 DNS Private Resolver。这些资源提供跨本地访问和名称解析。这些资源的管理不在本文范围内。

订阅设置

工作负载团队必须把特定登陆区要求告知平台团队，以实施本架构。平台团队也必须把其要求传达给工作负载团队。

例如，工作负载团队必须提供所需网络空间的详细信息。平台团队使用这些信息分配必要资源。工作负载团队定义要求，平台团队在虚拟网络内分配适当的 IP 地址。

平台团队根据工作负载的业务关键性和技术需求分配管理组。例如，如果工作负载像本架构一样暴露到互联网，平台团队会选择适当的管理组。为建立治理，平台团队还配置并实施管理组。工作负载团队必须在此治理约束内设计并运营工作负载。关于典型管理组区分的更多信息，请参阅《定制 Azure 登陆区架构》（Tailor the Azure landing zone architecture）。

平台团队为本架构设置订阅。以下各节提供关于初始订阅设置的指导。

工作负载要求与落实

工作负载团队和平台团队必须就管理组分配、Azure Policy 治理和网络设置等细节协作。准备一份要求清单，以便与平台团队启动讨论和协商。下列清单作为一个示例。

重要

平台团队应遵循订阅配给流程，使用一组结构化问题从工作负载团队收集信息。这些问题可能因组织而异，但目标是收集有效实施订阅所需的输入。更多信息请参阅《订阅配给》（Subscription vending）。

计算

编排层和聊天 UI 托管与基线架构保持相同。

网络

在基线架构中，工作负载预配在单个虚拟网络中。

相对基线的变化：本架构把工作负载划分到两个虚拟网络上。一个网络托管工作负载组件。另一个网络管理互联网和混合连接。平台团队决定工作负载的虚拟网络如何与组织更大的网络架构集成，该架构通常遵循中心-分支拓扑。

[图：主要关注网络入站流的架构图。]

此架构图有一个标为工作负载登陆区订阅的上方蓝色部分，其中包含分支虚拟网络。该虚拟网络包含六个子网。子网标为 snet-appGateway、snet-buildAgents、snet-jumpBoxes、snet-appServicePlan、snet-agentsEgress 和 snet-privateEndpoints。snet-privateEndpoints 子网具有 App Service、Azure Storage、Key Vault、Foundry、知识库、Azure AI Search、Azure Cosmos DB 和另一个 Azure Storage 实例的专用终结点。最后三个专用终结点标为 Agent Service 依赖项。每个子网有一个 NSG，除 snet-appGateway 子网外，所有子网都有一条通往中心的 UDR。来自本地和本地之外用户的入站流量指向应用网关。数据科学家用户连接到底部标为连接订阅的部分中的 VPN 网关或 ExpressRoute。连接订阅包含 Private Link 的专用 DNS 区域、DNS Private Resolver 和 DDoS Protection。连接订阅中的中心虚拟网络通过对等互连连接到分支虚拟网络。中心向分支虚拟网络提供 DNS。

下载此架构的 Visio 文件。

• 中心虚拟网络：此虚拟网络作为区域中心，包含与同一区域中工作负载资源通信的集中式、且常常共享的服务。中心位于连接订阅中。平台团队拥有此网络中的资源。
• 分支虚拟网络：在本架构中，基线架构中的单个虚拟网络实质上成为分支虚拟网络。平台团队把此分支网络对等到中心网络。他们拥有并管理分支网络，包括其对等互连和 DNS 配置。工作负载团队拥有此网络中的资源，包括其子网。此网络包含许多工作负载资源。

由于这种管理和所有权划分，工作负载团队必须把工作负载要求清楚地传达给平台团队。

重要

给平台团队：不要把分支网络直接对等到另一个分支网络，除非工作负载明确要求。这种做法保护工作负载的分段目标。你的团队必须促成全部传递虚拟网络连接。但是，如果工作负载登陆区团队使用自管理的专用终结点直接连接其网络，你的团队不管理这些连接。

理解哪些工作负载资源由外部团队管理。例如，理解聊天智能体与另一个团队管理的依据上下文向量数据库之间的网络连接。

虚拟网络子网

在分支虚拟网络中，你根据工作负载要求创建并分配子网。为提供分段，施加限制进出子网流量的控制。本架构不在基线架构的子网之外增加子网。登陆区网络架构不再需要 AzureBastionSubnet 或 AzureFirewallSubnet 子网，因为平台团队很可能在平台订阅中托管这些能力。

在 Azure 登陆区中部署工作负载时，你仍需实施本地网络控制。你的组织可能施加进一步的网络限制，以防范数据外泄，并确保中央安全运营中心和 IT 网络团队的可见性。

入站流量

入站流量流与基线架构保持相同。

你管理与进入工作负载的公共互联网入站相关的资源。例如，在本架构中，Application Gateway 及其公共 IP 地址位于分支网络而非中心网络。一些组织使用集中边界网络（也称为 DMZ、非军事区和屏蔽子网）实现，把面向入站的资源放在连接订阅中。与该特定拓扑的集成不在本文范围内。

#### 检查传入流量的替代方法

本架构不使用 Azure Firewall 检查传入流量，但有时组织治理要求这样做。在这些情况下，平台团队支持该实现，为工作负载团队提供额外的入侵检测和防护层。该层帮助阻断不需要的入站流量。为支持此拓扑，本架构需要更多 UDR 配置。更多信息请参阅《使用 Azure Firewall 和 Application Gateway 的 Web 应用零信任网络》（Zero Trust network for web applications with Azure Firewall and Application Gateway）。

DNS 配置

在基线架构中，所有组件直接使用 Azure DNS 进行 DNS 解析。

相对基线的变化：在本架构中，通常由中心里的一台或多台 DNS 服务器处理 DNS 解析。创建虚拟网络时，虚拟网络上的 DNS 属性应已相应设置。工作负载团队不需要理解 DNS 服务的实现细节。

本架构按下列方式为工作负载组件配置 DNS。

本架构不为不发起出站通信的组件配置 DNS 设置。这些组件不需要 DNS 解析。

本架构中的许多组件依赖托管在中心 DNS 服务器中的 DNS 记录，以解析此工作负载的专用终结点。更多信息请参阅 Azure 专用 DNS 区域。

当无法进行基于中心的 DNS 解析时，这些组件面临下列限制：

• 平台团队无法记录 DNS 请求，这可能违反组织安全团队的要求。
• 解析登陆区中或其他工作负载登陆区中通过 Private Link 暴露的服务可能无法实现。

建议你熟悉平台团队如何管理 DNS。更多信息请参阅《大规模 Private Link 与 DNS 集成》（Private Link and DNS integration at scale）。当你添加直接依赖 Azure DNS 的组件功能时，可能给平台提供的 DNS 拓扑带来复杂性。你可以重新设计组件或协商例外，以尽量降低复杂性。

出站流量

在基线架构中，全部出站流量经由 Azure Firewall 路由到互联网。

相对基线的变化：在本架构中，平台提供一条指向其托管的 Azure Firewall 实例的 UDR。把此 UDR 应用到与基线架构相同的子网。

离开分支虚拟网络的全部流量，包括由数据代理发起的智能体出站流量，从智能体集成子网经由出站防火墙，通过已对等的中心网络路由。

[图：主要关注网络出站流的架构图。]

此架构图的上方蓝色部分标为工作负载登陆区订阅，并包含分支虚拟网络。分支虚拟网络包含六个子网：snet-appGateway、snet-buildAgents、snet-jumpBoxes、snet-appServicePlan、snet-agentsEgress 和 snet-privateEndpoints。snet-privateEndpoints 子网具有 App Service、Azure Storage、Key Vault、Foundry、知识库、AI Search、Azure Cosmos DB 和另一个 Azure Storage 实例的专用终结点。最后三个专用终结点标为 Agent Service 依赖项。除 snet-appGateway 外，所有子网都有一条虚线指向 Azure Firewall，该防火墙位于下方部分。下方部分标为连接订阅。Azure Firewall 有一条虚线指向表示为云的互联网。上方部分写着：在可能的情况下，由于 0.0.0.0/0 UDR，全部由工作负载发起、发往互联网的流量都流经中心。下方部分的中心虚拟网络与上方部分的分支虚拟网络通过虚拟网络对等互连连接。

下载此架构的 Visio 文件。

到 Key Vault、Foundry 和其他服务的专用终结点的东西向客户端通信与基线架构保持相同。上图不包含该路径。

#### 把互联网流量路由到防火墙

分支网络中的全部子网都包含一条路由，把全部发往互联网的流量，即 0.0.0.0/0 流量，导向中心的 Azure Firewall 实例。

本架构不为不发起出站通信的组件配置强制隧道。

对于不能把出站流量路由经过中心的组件或功能，工作负载团队必须与组织要求对齐。为满足这些要求，使用补偿控制、重新设计工作负载以排除不受支持的功能，或请求正式例外。你负责缓解数据外泄和滥用。

把平台提供的互联网路由应用到全部子网，即使你不预期该子网有出站流量。这种方法确保该子网中的意外部署经过常规出站过滤。对于包含专用终结点的子网，启用网络策略以支持完整路由和 NSG 控制。

此路由配置确保来自 App Service、Foundry 及其项目，以及源自工作负载虚拟网络的任何其他服务的全部出站连接都受到检查和控制。

Azure 专用 DNS 区域

对东西向流量使用专用终结点的工作负载，需要在已配置的 DNS 提供程序中有 DNS 区域记录。为支持 Private Link，本架构依赖许多服务的 DNS 区域记录，例如 Key Vault、Foundry 和 Azure Storage。

相对基线的变化：在基线架构中，工作负载团队直接管理专用 DNS 区域。在本架构中，平台团队通常维护专用 DNS 区域。工作负载团队必须清楚理解平台团队对专用 DNS 区域记录管理的要求和期望。平台团队可以使用专用 DNS 区域记录以外的其他技术。

在本架构中，平台团队必须为下列 Foundry FQDN API 终结点设置 DNS：

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

平台团队还必须为下列 FQDN 设置 DNS，它们是 Agent Service 依赖项：

• privatelink.search.windows.net
• privatelink.blob.core.windows.net
• privatelink.documents.azure.com

重要

在部署 Agent Service 的能力宿主之前以及 Agent Service 运行期间，DNS 解析必须从分支虚拟网络内部正确工作。Agent Service 能力不使用你的分支虚拟网络的 DNS 配置。因此，建议平台团队在 DNS Private Resolver 中为工作负载的专用 DNS 区域配置规则集，并把这些规则链接到工作负载登陆区分支。

在部署 Foundry 及其智能体能力之前，你必须等待，直到从分支网络内部能够把 Agent Service 依赖项完整解析到其专用终结点。如果由 DINE 策略处理对 DNS 专用区域的更新，此要求尤其重要。如果你在专用 DNS 记录可从子网内解析之前尝试部署 Agent Service 能力，部署会失败。

平台团队还必须为本架构中的其他工作负载依赖项托管专用 DNS 区域：

• privatelink.vaultcore.azure.net
• privatelink.azurewebsites.net

PRIMARY_SOURCE: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/baseline-microsoft-foundry-landing-zone