通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 上任务关键工作负载的网络和连接

  • 项目

鉴于建议的全球分布式主动-主动设计方法，网络是任务关键型应用程序的基本领域。

此设计区域探讨应用程序级别的各种网络拓扑主题，同时考虑必要的连接和冗余流量管理。 更具体地说，它重点介绍了用于为任务关键型应用程序设计安全且可缩放的全球网络拓扑的关键注意事项和建议。

重要

本文是 Azure 架构良好的任务关键型工作负荷系列的一部分。 如果不熟悉此系列，我们建议从什么是任务关键型工作负荷开始 ？

全局流量路由

使用多个活动区域部署标记需要全局路由服务将流量分发到每个活动标记。

Azure Front Door、Azure 流量管理器和 Azure 标准负载均衡器提供所需的路由功能来管理跨多区域应用程序的全局流量。

或者，可以考虑第三方全球路由技术。 这些选项几乎可以无缝交换，以替换或扩展使用 Azure 本机全局路由服务。 热门选择包括 CDN 提供程序的路由技术。

本部分探讨 Azure 路由服务的主要区别，用于定义如何使用每个路由服务来优化不同的方案。

设计注意事项

  • 绑定到单个区域的路由服务表示单一故障点，并且存在与区域中断相关的重大风险。

  • 如果应用程序工作负载包含客户端控制，例如移动或桌面客户端应用程序，则可以在客户端路由逻辑中提供服务冗余。

    • 可以并行考虑多种全局路由技术（如 Azure Front Door 和 Azure 流量管理器）以实现冗余，同时将客户端配置为在满足某些故障条件时故障转移到替代技术。 引入多个全局路由服务引入了边缘缓存和Web 应用程序防火墙功能方面的重大复杂性，以及 SSL 卸载的证书管理以及入口路径的应用程序验证。
    • 还可以考虑第三方技术，为所有级别的 Azure 平台故障提供全局路由复原能力。

  • Azure Front Door 和 流量管理员 之间的功能差异意味着，如果两种技术彼此并置以实现冗余，则需要不同的入口路径或设计更改，以确保保持一致且可接受的服务级别。

  • Azure Front Door 和 Azure 流量管理器 是具有内置多区域冗余和可用性的全球分布式服务。

    • 规模足够大的假设故障方案可能威胁到这些可复原路由服务的全局可用性，在级联和相关故障方面，应用程序面临更广泛的风险。
      • 此规模的故障方案只是由共享的基础服务（例如 Azure DNS 或 Microsoft Entra ID）引起的，这些服务几乎充当所有 Azure 服务的全局平台依赖项。 如果应用了冗余的 Azure 技术，则辅助服务也可能遇到不可用或服务降级。
      • 全局路由服务故障方案很可能通过服务间依赖项显著影响用于关键应用程序组件的其他许多服务。 即使使用第三方技术，应用程序也可能会处于不正常状态，因为基础问题的影响更大，这意味着路由到 Azure 上的应用程序终结点仍提供很少的价值。

  • 全局路由服务冗余为极少数假设故障方案提供了缓解措施，其中全局服务中断的影响仅限于路由服务本身。

    若要为全球服务中断方案提供更广泛的冗余，可以考虑多云主动-主动部署方法。 多云主动-主动部署方法引入了重要的操作复杂性，这会带来重大复原风险，可能远远超过全球中断的假设风险。

  • 对于无法进行客户端控制的情况，必须在单个全局路由服务上建立依赖项，以便为所有活动部署区域提供统一的入口点。

    • 在隔离中使用时，它们表示由于全局依赖项而导致服务级别的单一故障点，即使提供了内置的多区域冗余和可用性。
    • 所选全局路由服务提供的 SLA 表示可达到的最大复合 SLA，而不管考虑了多少部署区域。

  • 如果无法控制客户端，则可以考虑操作缓解措施，以定义一个过程，以便在全局服务中断禁用主服务时迁移到辅助全局路由服务。 从一个全局路由服务迁移到另一个路由服务通常是持续几个小时的漫长过程，尤其是在考虑 DNS 传播的情况下。

  • 某些第三方全局路由服务提供 100% SLA。 但是，这些服务提供的历史和可实现的 SLA 通常低于 100%。

    • 虽然这些服务为不可用提供财务赔偿，但当不可用的影响非常重要时，就没有什么意义了，例如，对于人类生活最终处于危险之中的安全关键场景而言。 因此，即使播发的法律 SLA 为 100%，仍应考虑技术冗余或足够的操作缓解措施。

Azure Front Door

  • Azure Front Door 使用具有拆分 TCP 的 Anycast 协议提供全局 HTTP/S 负载均衡和优化连接，以利用 Microsoft 全球主干网络。

    • 为每个后端终结点维护许多连接。
    • 传入客户端请求首先在离发起客户端最近的边缘节点终止。
    • 进行任何所需的流量检查后，请求要么使用现有连接通过 Microsoft 主干转发到适当的后端，要么从边缘节点的内部缓存中提供。
    • 这种方法在通过后端连接分散大量流量方面非常有效。

  • 提供一个内置缓存，用于从边缘节点提供静态内容。 在许多用例中，这还可以消除专用内容分发网络（CDN）的需求。

  • Azure Web 应用程序防火墙（WAF）可用于 Azure Front Door，因为它已部署到全球 Azure 网络边缘位置，因此 Front Door 在网络边缘检查的每个传入请求。

  • Azure Front Door 使用 Azure DDoS 防护基本保护应用程序终结点免受 DDoS 攻击。 Azure DDoS 标准版提供了其他和更高级的保护和检测功能，并且可以作为额外的层添加到 Azure Front Door。

  • Azure Front Door 提供完全托管的证书服务。 为终结点启用 TLS 连接安全性，而无需管理证书生命周期。

  • Azure Front Door 高级版支持专用终结点，使流量可以直接从 Internet 流向 Azure 虚拟网络。 这样就无需在 VNet 上使用公共 IP，以便通过 Azure Front Door 高级版访问后端。

  • Azure Front Door 依赖于按间隔调用的运行状况探测和后端运行状况终结点（URL），以返回 HTTP 状态代码，以反映后端是否正常运行，HTTP 200 （OK） 响应反映正常状态。 一旦后端反映不正常的状态，从某个边缘节点的角度来看，该边缘节点将停止在那里发送请求。 因此，从流量循环中透明地删除不正常的后端，而不会有任何延迟。

  • 仅支持 HTTP/S 协议。

  • Azure Front Door WAF 和 应用程序网关 WAF 提供略有不同的功能集，尽管同时支持内置规则和自定义规则，并且可以设置为在检测模式或防护模式下运行。

  • Front Door 后端 IP 空间可能会更改，但 Microsoft 将确保与 Azure IP 范围和服务标记集成。 可以订阅 Azure IP 范围和服务标记来接收有关任何更改或更新的通知。

  • Azure Front Door 支持各种 负载分发配置：

    • 基于延迟：将流量从客户端路由到“最接近”后端的默认设置;基于请求延迟。
    • 基于优先级：适用于主动-被动设置，除非流量不可用，否则流量必须始终发送到主后端。
    • 加权：适用于将特定百分比的流量发送到特定后端的 Canary 部署。 如果多个后端分配了相同的权重，则使用基于延迟的路由。

  • 默认情况下，Azure Front Door 使用基于延迟的路由，这可能会导致某些后端获得比其他流量更多的传入流量的情况，具体取决于客户端的来源。

  • 如果一系列客户端请求必须由同一后端处理， 则可以在前端上配置会话相关性 。 它使用客户端 Cookie 将后续请求发送到与第一个请求相同的后端，前提是后端仍然可用。

Azure 流量管理器

  • Azure 流量管理器是一项 DNS 重定向服务。

    • 不会处理实际的请求有效负载，而是流量管理员根据所选流量路由方法的配置规则返回池中某个后端的 DNS 名称。
    • 然后，后端 DNS 名称解析为客户端随后直接调用的最终 IP 地址。

  • DNS 响应由客户端缓存并重复使用指定的生存时间（TTL），在此期间发出的请求将直接转到后端终结点，而无需流量管理员交互。 消除与 Front Door 相比提供成本优势的额外连接步骤。

  • 由于请求直接从客户端发出到后端服务，因此可以利用后端支持的任何协议。

  • 与 Azure Front Door 类似，Azure 流量管理器还依赖于运行状况探测来了解后端是否正常运行。 如果返回另一个值或未返回任何值，则路由服务将识别正在进行的问题，并停止将请求路由到该特定后端。

    • 但是，与 Azure Front Door 不同，这种不正常的后端删除不是即时的，因为客户端将继续创建与不正常的后端的连接，直到 DNS TTL 过期，并从流量管理员服务请求新的后端终结点。
    • 此外，即使 TTL 过期，也不能保证公共 DNS 服务器将遵循此值，因此 DNS 传播实际上可能需要更长的时间才能发生。 这意味着，在持续一段时间内，流量可能会继续发送到不正常的终结点。

Azure 标准负载均衡器

重要

跨区域标准负载均衡器以预览版提供，但存在技术限制。 对于任务关键型工作负荷，不建议使用此选项。

设计建议

  • 将 Azure Front Door 用作 HTTP/S 方案的主要全局流量路由服务。 Azure Front Door 强烈建议用于 HTTP/S 工作负载，因为它提供优化的流量路由、透明故障转移、专用后端终结点（使用 高级版 SKU）、边缘缓存和与 Web 应用程序防火墙（WAF）的集成。

  • 对于可以进行客户端控制的应用程序场景，应用客户端路由逻辑来考虑主要全局路由技术失败的故障转移场景。 如果单个服务 SLA 不够，则应并行放置两个或多个全局路由技术以增加冗余。 在发生全局服务故障的情况下，需要客户端逻辑路由到冗余技术。

    • 应使用两个不同的 URL，其中一个 URL 应用于每个不同的全局路由服务，以简化故障转移的整体证书管理体验和路由逻辑。
    • 优先使用第三方路由技术作为辅助故障转移服务，因为这将缓解全球故障方案的最大数量，行业领先的 CDN 提供商提供的功能将允许采用一致的设计方法。
    • 还应考虑直接路由到单个区域标记，而不是单独的路由服务。 虽然这将导致服务级别下降，但它表示一种更简单的设计方法。

此图显示了使用 Azure Front Door 作为主要全局负载均衡器的客户端故障转移的冗余全局负载均衡器配置。

任务关键全局负载均衡器配置

重要

为了真正降低 Azure 平台中全局故障的风险，应考虑多云主动-主动部署方法，并采用跨两个或多个云提供商托管的活动部署戳章，以及用于全局路由的冗余第三方路由技术。

Azure 可以有效地与其他云平台集成。 但是，强烈建议不要应用多云方法，因为它引入了显著的操作复杂性，不同云平台中的操作运行状况定义和表示形式不同。 这种复杂性反过来在应用程序的正常操作中引入了许多复原风险，这远远超过了全球平台中断的假设风险。

  • 尽管不建议这样做，但对于使用 Azure 流量管理器 到 Azure Front Door 进行全局路由冗余的 HTTP（s） 工作负荷，请考虑将 Web 应用程序防火墙 （WAF） 卸载到 应用程序网关，以便允许流经 Azure Front Door 的流量。
    • 这将引入标准入口路径的额外故障点、用于管理和缩放的其他关键路径组件，还会产生额外的成本，以确保全球高可用性。 但是，它通过在 Azure Front Door 和 Azure 流量管理器 之间提供可接受的和不可接受的入口路径之间的一致性来大大简化故障方案，无论是 WAF 执行还是专用应用程序终结点。
    • 故障方案中边缘缓存的丢失会影响整体性能，这必须与可接受的服务级别或缓解设计方法保持一致。 为了确保一致的服务级别，请考虑将边缘缓存卸载到这两个路径的第三方 CDN 提供程序。

建议考虑使用第三方全局路由服务来代替两个 Azure 全局路由服务。 这提供了最高级别的故障缓解和更简单的设计方法，因为大多数行业领先的 CDN 提供商提供的边缘功能与 Azure Front Door 提供的功能基本一致。

Azure Front Door

  • 使用 Azure Front Door 托管证书服务启用 TLS 连接，并不再需要管理证书生命周期。

  • 使用 Azure Front Door Web 应用程序防火墙（WAF）在边缘提供保护，防止常见的 Web 攻击和漏洞，例如 SQL 注入。

  • 使用 Azure Front Door 内置缓存从边缘节点提供静态内容。

    • 在大多数情况下，这也消除了专用内容分发网络（CDN）的需求。

  • 配置应用程序平台入口点，以使用 X-Azure-FDID 通过基于标头的筛选来验证传入的请求，以确保所有流量都流经配置的 Front Door 实例。 另请考虑使用 Front Door 服务标记配置 IP ACLing，以验证来自 Azure Front Door 后端 IP 地址空间和 Azure 基础结构服务的流量。 这将确保流量在服务级别通过 Azure Front Door 流动，但仍然需要基于标头的筛选来确保使用配置的 Front Door 实例。

  • 定义自定义 TCP 运行状况终结点，以验证区域部署戳中的关键下游依赖项，包括数据平台副本 (replica)（例如基础参考实现提供的示例中的 Azure Cosmos DB）。 如果一个或多个依赖项变得不正常，运行状况探测应在返回的响应中反映这一点，以便整个区域标记可以从流通中取出。

  • 确保记录运行状况探测响应，并将 Azure Front Door 公开的所有操作数据引入全局 Log Analytics 工作区，以便在整个应用程序中实现统一的数据接收器和单个操作视图。

  • 除非工作负荷极其延迟敏感，否则将流量均匀分散到所有已考虑的区域标记中，以最有效地使用已部署的资源。

    • 为此，请将 “延迟敏感度（附加延迟）” 参数设置为足够高的值，以满足后端不同区域之间的延迟差异。 确保应用程序工作负荷可以接受的容差，涉及整个客户端请求延迟。

  • 除非应用程序需要会话关联，否则不要启用会话相关性，因为它可能会对流量分布的平衡产生负面影响。 使用完全无状态的应用程序时，如果遵循建议的任务关键型应用程序设计方法，则任何请求都可以由任何区域部署处理。

Azure 流量管理器

  • 将 流量管理员 用于非 HTTP/S 方案，作为 Azure Front Door 的替代。 功能差异将推动缓存和 WAF 功能以及 TLS 证书管理的不同设计决策。

  • 应在每个区域中考虑使用 Azure 应用程序网关 流量管理员入口路径的 WAF 功能。

  • 配置适当较低的 TTL 值，以优化在后端变得不正常时从循环中删除不正常的后端终结点所需的时间。

  • 与 Azure Front Door 类似，应定义自定义 TCP 运行状况终结点，以验证区域部署戳中的关键下游依赖项，这应该反映在运行状况终结点提供的响应中。

    但是，对于流量管理员应向服务级别区域故障转移提供额外的考虑。 例如“狗腿”，为了缓解因依赖项故障而删除不正常的后端的潜在延迟，尤其是在无法为 DNS 记录设置低 TTL 时。

  • 应考虑第三方 CDN 提供程序，以便在将Azure 流量管理器用作主要全局路由服务时实现边缘缓存。 如果第三方服务也提供边缘 WAF 功能，则应考虑简化入口路径，并可能消除对应用程序网关的需求。

应用程序分发服务

任务关键型应用程序的网络入口路径还必须考虑应用程序传递服务，以确保安全、可靠且可缩放的入口流量。

本部分基于全局路由建议，探索关键应用程序交付功能，考虑 Azure 标准负载均衡器、Azure 应用程序网关 和 Azure API 管理等相关服务。

设计注意事项

  • TLS 加密对于确保到任务关键型应用程序的入站用户流量的完整性至关重要， TLS 卸载 仅在标记的入口点应用，以解密传入流量。 TLS 卸载需要 TLS 证书的私钥来解密流量。

  • Web 应用程序防火墙提供针对常见 Web 攻击和漏洞（例如 SQL 注入或跨站点脚本）的保护，并且对于实现任务关键型应用程序的最大可靠性愿望至关重要。

  • Azure WAF 使用托管规则集针对前 10 个 OWASP 漏洞提供现成的保护。

    • 还可以添加自定义规则以扩展托管规则集。
    • 可以在 Azure Front Door、Azure 应用程序网关或Azure 内容分发网络（目前为公共预览版）中启用 Azure WAF。
      • 每个服务上提供的功能略有不同。 例如，Azure Front Door WAF 提供速率限制、地理筛选和机器人保护，这些保护尚未在 应用程序网关 WAF 中提供。 但是，它们都支持内置规则和自定义规则，并且可以设置为在检测模式或预防模式下运行。
      • Azure WAF 的路线图可确保在所有服务集成中提供一致的 WAF 功能集。

  • 还可以考虑 Kubernetes 中的第三方 WAF 技术（如 NVA 和高级入口控制器）提供必要的漏洞保护。

  • 无论使用哪种技术，最佳 WAF 配置通常需要微调。

    Azure Front Door

  • Azure Front Door 仅接受 HTTP 和 HTTPS 流量，并且仅处理具有已知 Host 标头的请求。 此协议阻止有助于缓解跨协议和端口传播的批量攻击，以及 DNS 放大和 TCP 中毒攻击。

  • Azure Front Door 是一种全局 Azure 资源，因此将配置全局部署到所有 边缘位置。

    • 资源配置可以大规模分发，以每秒处理数十万个请求。
    • 汇报配置（包括路由和后端池）是无缝的，不会在部署期间造成任何停机。

  • Azure Front Door 为面向客户端的 SSL 证书提供完全托管的证书服务和自带证书方法。 完全托管的证书服务提供了一种简化的操作方法，有助于通过在解决方案的单个区域中执行证书管理来降低整体设计的复杂性。

  • Azure Front Door 在证书过期前至少 60 天自动轮换“托管”证书，以防止证书风险过期。 如果使用自管理证书，更新的证书应在现有证书过期前 24 小时部署，否则客户端可能会收到过期的证书错误。

  • 仅当 Azure Front Door 在“托管”和“使用自己的证书”之间切换时，证书更新才会造成停机。

  • Azure Front Door 受 Azure DDoS 防护基本保护，默认情况下集成到 Front Door 中。 这提供始终开启的流量监视、实时缓解，并针对常见的第 7 层 DNS 查询洪水或第 3/4 层批量攻击进行防御。

    • 即使遇到 DDoS 攻击，这些保护也有助于维护 Azure Front Door 可用性。 分布式拒绝服务（DDoS）攻击可能会使目标资源变得不可用，因为它具有非法流量。

  • Azure Front Door 还在全局流量级别提供 WAF 功能，同时必须在每个区域部署标记内提供 应用程序网关 WAF。 功能包括防范常见攻击的防火墙规则集、地区筛选、地址阻止、速率限制和签名匹配。

    Azure 负载均衡器

  • Azure Basic 负载均衡器 SKU 不受 SLA 支持，并且与标准 SKU 相比具有多种功能约束。

设计建议

  • 在尽可能少的地方执行 TLS 卸载，以保持安全性，同时简化证书管理生命周期。

  • 使用加密连接（例如 HTTPS），从 TLS 卸载发生到实际应用程序后端的点。 应用程序终结点对最终用户不可见，因此 Azure 托管域（例如 azurewebsites.net 或 cloudapp.net）可用于托管证书。

  • 对于 HTTP（S） 流量，请确保 WAF 功能在所有公开的终结点的入口路径内应用。

  • 在单个服务位置（使用 Azure Front Door 全局启用 WAF 功能）或使用 Azure 应用程序网关 进行区域功能，因为这简化了配置微调并优化了性能和成本。

    在防护模式下配置 WAF 以直接阻止攻击。 仅当防护模式的性能损失过高时，才在检测模式下使用 WAF（即仅记录但不阻止可疑请求）。 必须充分理解隐含的额外风险，并与工作负载场景的特定需求保持一致。

  • 优先使用 Azure Front Door WAF，因为它提供最丰富的 Azure 本机功能集并在全局边缘应用保护，从而简化整体设计并进一步提高效率。

  • 仅当向外部客户端或其他应用程序团队公开大量 API 时，才使用 Azure API 管理。

  • 将 Azure 标准负载均衡器 SKU 用于微服务工作负载中的任何内部流量分发方案。

    • 在跨可用性区域部署时，提供 99.99% 的 SLA。
    • 提供诊断或出站规则等关键功能。

  • 使用 Azure DDoS 网络保护来帮助保护每个应用程序虚拟网络中托管的公共终结点。

缓存和静态内容传送

对静态内容（如图像、JavaScript、CSS 和其他文件）的特殊处理可能会对整体用户体验以及解决方案的总体成本产生重大影响。 在边缘缓存静态内容可以加快客户端加载时间，从而提供更好的用户体验，还可以降低涉及后端服务的流量、读取操作和计算能力的成本。

设计注意事项

  • 并非解决方案通过 Internet 提供的所有内容都是动态生成的。 应用程序同时提供静态资产（图像、JavaScript、CSS、本地化文件等）和动态内容。
  • 具有经常访问的静态内容的工作负荷从缓存中获益很大，因为它减少了后端服务上的负载，并减少了最终用户的内容访问延迟。
  • 可以使用 Azure Front Door 或 Azure 内容分发网络 （CDN） 在 Azure 中本机实现缓存。
    • Azure Front Door 提供 Azure 本机边缘缓存功能和路由功能，用于划分静态和动态内容。
      • 通过在 Azure Front Door 中创建适当的路由规则， /static/* 流量可以透明地重定向到静态内容。
    • 可以使用Azure 内容分发网络服务实现更复杂的缓存方案，为重要的静态内容卷建立完整的内容分发网络。
      • Azure 内容分发网络服务可能更具成本效益，但不提供相同的高级路由和Web 应用程序防火墙（WAF）功能，这是为应用程序设计的其他领域推荐的。 但是，它确实提供了进一步的灵活性，以便与来自第三方解决方案（如 Akamai 和 Verizon）的类似服务集成。
    • 比较 Azure Front Door 和Azure 内容分发网络服务时，应探讨以下决策因素：
      • 可以使用规则引擎完成所需的缓存规则。
      • 存储内容和关联的成本的大小。
      • 执行规则引擎的每月价格（按 Azure Front Door 上的请求收费）。
      • 出站流量要求（价格因目标而异）。

设计建议

  • 生成的静态内容（如图像文件的大小副本），这些文件永远不会或很少更改也受益于缓存。 可以根据 URL 参数和具有不同缓存持续时间来配置缓存。
  • 将静态内容和动态内容分别交付给用户，并从缓存中传递相关内容，以减少后端服务上的负载，从而优化最终用户的性能。
  • 鉴于强建议（网络和连接设计区域）使用 Azure Front Door 进行全局路由和Web 应用程序防火墙（WAF）目的，建议优先使用 Azure Front Door 缓存功能，除非存在差距。

虚拟网络集成

任务关键型应用程序通常包含与其他应用程序或依赖系统的集成要求，这些应用程序可以托管在 Azure、另一个公有云或本地数据中心上。 可以通过网络级集成使用面向公众的终结点和 Internet 或专用网络来实现此应用程序集成。 最终，实现应用程序集成的方法将对解决方案的安全性、性能和可靠性产生重大影响，并严重影响其他设计领域的设计决策。

任务关键型应用程序可以在三个总体网络配置之一内部署，这决定了应用程序集成如何在网络级别进行。

  1. 没有公司网络连接的公共应用程序。
  2. 具有企业网络连接的公共应用程序。
  3. 具有企业网络连接的专用应用程序。

注意

在 Azure 登陆区域中部署时，配置 1。 应在联机登陆区域中部署，而 2） 和 3） 应部署在公司内，连接登陆区域，以促进网络级集成。

本部分探讨这些网络集成方案，在适当使用 Azure 虚拟网络 和周围的 Azure 网络服务时进行分层，以确保最佳满足集成要求。

设计注意事项

无虚拟网络

  • 最简单的设计方法是不在虚拟网络中部署应用程序。

    • 所有已考虑的 Azure 服务之间的连接性完全通过公共终结点和 Microsoft Azure 主干提供。 Azure 上托管的公共终结点之间的连接性只会遍历 Microsoft 主干，不会通过公共 Internet。
    • Azure 外部的任何外部系统连接由公共 Internet 提供。

  • 此设计方法采用“标识为安全外围”，在各种服务组件和依赖解决方案之间提供访问控制。 对于对安全性不太敏感的方案，这可能是可接受的解决方案。 可通过公共终结点访问所有应用程序服务和依赖项，使其容易受到围绕获得未经授权的访问而面向的其他攻击途径的攻击途径。

  • 此设计方法也不适用于所有 Azure 服务，因为许多服务（如 AKS）对基础虚拟网络具有硬性要求。

独立虚拟网络

  • 为了缓解与不必要的公共终结点关联的风险，可以在未连接到其他网络的独立网络中部署应用程序。

  • 传入客户端请求仍要求向 Internet 公开公共终结点，但是，所有后续通信都可以在虚拟网络中使用专用终结点。 使用 Azure Front Door 高级版时，可以直接从边缘节点路由到专用应用程序终结点。

  • 虽然应用程序组件之间的专用连接将通过虚拟网络进行，但与外部依赖项的所有连接仍依赖于公共终结点。

    • 如果支持，可以使用专用终结点建立对 Azure 平台服务的连接性。 如果 Azure 上存在其他外部依赖项（例如另一个下游应用程序），将通过公共终结点和 Microsoft Azure 主干提供连接。
    • Azure 外部的任何外部系统连接由公共 Internet 提供。

  • 对于外部依赖项没有网络集成要求的方案，在隔离的网络环境中部署解决方案可提供最大的设计灵活性。 没有与更广泛的网络集成关联的寻址和路由约束。

  • Azure Bastion 是一种完全平台托管的 PaaS 服务，可在虚拟网络上部署，并提供与 Azure VM 的安全 RDP/SSH 连接。 通过 Azure Bastion 进行连接时，虚拟机不需要公共 IP 地址。

  • 应用程序虚拟网络的使用在 CI/CD 管道中引入了重要的部署复杂性，因为需要数据平面和控制平面访问专用网络上托管的资源，以便于应用程序部署。

    • 必须建立安全专用网络路径，以允许 CI/CD 工具执行必要的操作。
    • 可以在应用程序虚拟网络中部署专用生成代理，以代理访问受虚拟网络保护的资源。

连接的虚拟网络

  • 对于具有外部网络集成要求的方案，应用程序虚拟网络可以使用各种连接选项连接到 Azure 中的其他虚拟网络、另一个云提供商或本地网络。 例如，某些应用程序方案可能会考虑应用程序级与在本地企业网络中专用托管的其他业务线应用程序集成。

  • 应用程序网络设计必须与更广泛的网络体系结构保持一致，尤其是涉及寻址和路由等主题。

  • 在考虑网络集成时，跨 Azure 区域或本地网络重叠的 IP 地址空间将产生重大争用。

    • 但是，当对等互连网络的虚拟网络地址空间更改 对等互连链接上的同步时，可以更新虚拟网络资源以考虑其他地址空间，这会暂时禁用对等互连。
    • Azure 在每个子网中保留五个 IP 地址，在确定应用程序虚拟网络和包含的子网的适当大小时，应考虑该地址。
    • 某些 Azure 服务需要专用子网，例如 Azure Bastion、Azure 防火墙 或 Azure 虚拟网络 网关。 这些服务子网的大小非常重要，因为它们应该足够大，足以支持服务的所有当前实例，考虑到未来的规模要求，但不会像不必要的浪费地址那样大。

  • 当需要本地或跨云网络集成时，Azure 提供了两种不同的解决方案来建立安全连接。

    • 可以调整 ExpressRoute 线路的大小，以提供高达 100 Gbps 的带宽。
    • 虚拟专用网络（VPN）可以调整大小，以提供中心辐射网络中高达 10 Gbps 的聚合带宽，在 Azure 虚拟 WAN中提供高达 20 Gbps 的带宽。

注意

在 Azure 登陆区域中部署时，请注意，登陆区域实现应提供与本地网络的任何所需连接。 该设计可以使用 虚拟 WAN 或中心辐射型网络设计在 Azure 中的 ExpressRoute 和其他虚拟网络。

  • 包含其他网络路径和资源会为应用程序带来额外的可靠性和操作注意事项，以确保保持运行状况。

设计建议

  • 建议尽可能在 Azure 虚拟网络中部署任务关键型解决方案，以删除不必要的公共终结点，从而限制应用程序攻击面，最大程度地提高安全性和可靠性。

    • 使用专用终结点连接到 Azure 平台服务。 对于不支持专用链接的服务，可以考虑服务终结点，前提是数据外泄风险是可接受的，也可以通过替代控制来缓解。

  • 对于不需要企业网络连接的应用程序场景，请将所有虚拟网络视为临时资源，在执行新的区域部署时替换这些资源。

  • 连接到其他 Azure 或本地网络时，不应将应用程序虚拟网络视为临时网络，因为它会产生重大复杂问题，即虚拟网络对等互连和虚拟网络网关资源受到关注。 虚拟网络中的所有相关应用程序资源应继续是临时的，并行子网用于促进更新的区域部署标记的蓝绿部署。

  • 在需要企业网络连接以促进专用网络上的应用程序集成的场景中，确保用于区域应用程序虚拟网络的 IPv4 地址空间不与其他连接的网络重叠，并适当调整大小以实现所需的缩放，而无需更新虚拟网络资源并导致停机。

    • 强烈建议仅使用专用 Internet 地址分配中的 IP 地址（RFC 1918）。
      • 对于专用 IP 地址可用性有限的环境（RFC 1918），请考虑使用 IPv6。
      • 如果需要使用公共 IP 地址，请确保仅使用拥有的地址块。
    • 与 Azure 中 IP 寻址的组织计划保持一致，确保应用程序网络 IP 地址空间不会与本地位置或 Azure 区域中的其他网络重叠。
    • 不要创建不必要的大型应用程序虚拟网络，以确保不会浪费 IP 地址空间。

  • 优先使用 Azure CNI 进行 AKS 网络集成，因为它 支持更丰富的功能集。

    • 对于具有有限可用 IP 地址的场景，请考虑 Kubenet，使其适合受约束的地址空间中的应用程序。

    • 优先使用 Azure CNI 网络插件进行 AKS 网络集成，并考虑将 Kubenet 用于有限范围的可用 IP 地址的方案。 有关更多详细信息，请参阅 微分段和 kubernetes 网络策略 。

  • 对于需要本地网络集成的方案，优先使用 Express Route 来确保安全且可缩放的连接。

    • 确保应用于 Express Route 或 VPN 的可靠性级别完全满足应用程序要求。
    • 如果需要，应考虑使用多个网络路径来提供额外的冗余，例如交叉连接的 ExpressRoute 线路或使用 VPN 作为故障转移连接机制。

  • 确保关键网络路径上的所有组件都符合关联的用户流的可靠性和可用性要求，无论中心 IT 团队的应用程序团队是否提供对这些路径和关联组件的管理。

    注意

    在 Azure 登陆区域中部署并与更广泛的组织网络拓扑集成时，请考虑 网络指南 以确保基础网络与 Microsoft 最佳做法保持一致。

  • 使用 Azure Bastion 或代理的专用连接访问 Azure 资源的数据平面或执行管理操作。

Internet 入口

Internet 出口是任务关键型应用程序在以下情况下促进外部通信的基础网络要求：

  1. 直接应用程序用户交互。
  2. 应用程序与 Azure 外部依赖项的集成。
  3. 访问应用程序使用的 Azure 服务所需的外部依赖项。

本部分探讨如何在确保维护安全性、可靠性和可持续性能的同时实现 Internet 出口，并突出在任务关键型上下文中推荐的服务的关键出口要求。

设计注意事项

  • 许多 Azure 服务需要访问公共终结点，以便按预期方式运行各种管理和控制平面功能。

  • Azure 为虚拟网络上的虚拟机或计算实例提供不同的直接 Internet 出站连接方法，例如 Azure NAT 网关或Azure 负载均衡器。

  • 当来自虚拟网络内部的流量传出 Internet 时，必须进行网络地址转换（NAT）。 这是在网络堆栈中发生的计算操作，因此可能会影响系统性能。

  • 当 NAT 在小规模发生时，性能影响应微不足道，但是，如果可能会出现大量出站请求网络问题。 这些问题通常以“源 NAT（或 SNAT）端口耗尽”的形式出现。

  • 在多租户环境中（例如Azure App 服务），每个实例可用的出站端口数量有限。 如果这些端口耗尽，则无法启动新的出站连接。 可以通过减少专用/公共边缘遍历的数量或使用更可缩放的 NAT 解决方案（例如 Azure NAT 网关）来缓解此问题。

  • 除了 NAT 限制外，出站流量也可能受到必要的安全检查。

    • Azure 防火墙提供适当的安全功能来保护网络出口。

    • Azure 防火墙（或等效的 NVA）可用于通过对出站流量流提供精细控制来保护 Kubernetes 出口要求。

  • 大量的 Internet 出口将产生 数据传输费用。

Azure NAT 网关

  • Azure NAT 网关支持每个分配的出站 IP 地址 64,000 个 TCP 和 UDP 连接。

    • 最多可以将 16 个 IP 地址分配给单个 NAT 网关。
    • 默认 TCP 空闲超时为 4 分钟。 如果空闲超时更改为更高的值，则流将保留更长时间，这会增加 SNAT 端口清单的压力。

  • NAT 网关无法提供现装的区域性隔离。 若要获取区域冗余，包含区域资源的子网必须与相应的区域 NAT 网关保持一致。

设计建议

  • 最大程度地减少传出 Internet 连接数，因为这将影响 NAT 性能。

    • 如果需要大量的 Internet 绑定连接，请考虑使用 Azure NAT 网关 来抽象出站流量流。

  • 使用Azure 防火墙控制并检查出站 Internet 流量的要求。

    • 确保Azure 防火墙不用于检查 Azure 服务之间的流量。

注意

在 Azure 登陆区域中部署时，请考虑使用基础平台Azure 防火墙资源（或等效的 NVA）。 如果将依赖项用于 Internet 出口的中央平台资源上，则该资源和关联的网络路径的可靠性级别应与应用程序要求密切相关。 还应向应用程序提供来自资源的操作数据，以便在故障方案中通知潜在的操作操作。

如果存在与出站流量相关的大规模要求，则应考虑任务关键型应用程序的专用Azure 防火墙资源，以缓解与使用集中共享资源（例如干扰邻居方案）相关的风险。

  • 在虚拟 WAN环境中部署时，应考虑防火墙管理器，以集中管理专用应用程序Azure 防火墙实例，以确保通过全局防火墙策略观察组织安全状况。
  • 确保增量防火墙策略通过基于角色的访问控制委派给应用程序安全团队，以允许应用程序策略自治。

区域间和区域间连接性

虽然应用程序设计强烈建议使用独立的区域部署标记，但许多应用程序场景可能仍需要相关应用程序组件（在不同区域或 Azure 区域中部署）之间的网络集成，即使仅在服务降级的情况下也是如此。 实现区域间和区域间通信的方法对整体性能和可靠性具有重大影响，这将通过本节中的注意事项和建议进行探讨。

设计注意事项

  • 任务关键型应用程序的应用程序设计方法支持使用独立区域部署，并在单个区域中的所有组件级别应用区域冗余。

  • 可用性区域（AZ）是 Azure 区域中物理上独立的数据中心位置，提供高达单个数据中心级别的物理和逻辑故障隔离。

    保证进行区域间通信的往返延迟小于 2 毫秒。 根据区域之间的不同距离和光纤路径，区域将具有较小的延迟差异。

  • 可用性区域连接取决于区域特征，因此可能需要在区域之间路由通过边缘位置进入区域的流量才能到达其目标。 这将在区域间路由和“光速”约束的情况下添加大约 1ms-2 毫秒的延迟，但这应该只对超敏感工作负荷产生影响。

  • 可用性区域被视为单个订阅上下文中的逻辑实体，因此不同的订阅可能具有相同区域的区域性映射。 例如，订阅 A 中的区域 1 可能与订阅 B 中的区域 2 相同。

  • 应用程序方案在应用程序组件之间非常闲聊，跨区域分散应用程序层可能会带来显著的延迟和成本增加。 可以通过将部署标记限制为单个区域，并跨不同区域部署多个图章，从而缓解设计中的此问题。

  • 不同 Azure 区域之间的通信按 GB 带宽产生更大的 数据传输费用 。

    • 适用的数据传输速率取决于已考虑的 Azure 区域的大洲。
    • 数据遍历大陆的收费速率要高得多。

  • Express Route 和 VPN 连接方法还可用于针对特定方案甚至不同的云平台直接连接不同的 Azure 区域。

  • 对于服务到服务通信专用链接可以使用专用终结点进行直接通信。

  • 流量可以通过用于本地连接的 Express Route 线路进行发型固定，以便促进 Azure 区域内的虚拟网络和同一地理位置内不同 Azure 区域的路由。

    • 通过 Express Route 的发型固定流量将绕过与虚拟网络对等互连相关的数据传输成本，因此可用作优化成本的方法。
    • 此方法需要额外的网络跃点来实现 Azure 中的应用程序集成，从而带来延迟和可靠性风险。 从 Azure/本地扩展 Express Route 和关联的网关组件的角色，以包含 Azure/Azure 连接。

  • 当服务之间需要子百万级延迟时， 当使用的服务支持时，可以使用邻近放置组 。

设计建议

  • 使用虚拟网络对等互连，连接区域内和跨不同区域的网络。 强烈建议避免在快速路由中进行 hair-pinning。

  • 使用专用链接直接在同一区域或跨区域（区域 A 中的服务与区域 B 中的服务通信）之间建立通信。

  • 对于组件之间通信异常频繁的应用程序工作负载，可以考虑将部署标记限制在单个区域，并跨不同的区域部署多个标记。 这可确保在封装的部署标记级别而不是单个应用程序组件级别上维护区域冗余。

  • 如果可能，请将每个部署标记视为独立且与其他标记断开连接。

    • 使用数据平台技术跨区域同步状态，而不是使用直接网络路径在应用程序级别实现一致性。
    • 除非有必要，否则避免在不同区域之间的“狗腿”流量，即使在故障场景中也是如此。 使用全局路由服务和端到端运行状况探测，在单个关键组件层发生故障时，不会将流量路由到另一个区域，以消除流通。

  • 对于超延迟敏感应用程序方案，请优先使用具有区域网络网关的区域来优化入口路径的网络延迟。

微分段和 Kubernetes 网络策略

微分段是一种网络安全设计模式，用于隔离和保护各应用程序工作负载，同时应用相关策略来限制工作负载之间的网络流量（基于零信任模型）。 它通常用于减少网络攻击面、改进漏洞遏制，并通过策略驱动的应用程序级网络控制加强安全性。

任务关键型应用程序可以在子网或网络接口级别、服务访问控制列表（ACL）和使用Azure Kubernetes 服务（AKS）时使用网络安全组（NSG）强制实施应用程序级网络安全。

本部分探讨充分利用这些功能，提供实现应用程序级微分段的关键注意事项和建议。

设计注意事项

  • AKS 可以部署在两个不同的 网络模型中：

    • Kubenet 网络： AKS 节点集成到现有虚拟网络中，但 Pod 存在于每个节点上的虚拟覆盖网络中。 不同节点上的 Pod 之间的流量通过 kube-proxy 路由。
    • Azure 容器网络接口（CNI）网络： AKS 群集集成到现有虚拟网络及其节点、Pod 和服务从群集节点附加到的同一虚拟网络接收的 IP 地址。 这与需要从 Pod 和 Pod 建立直接连接的各种网络方案相关。 可以将不同的节点池部署到 不同的子网中。

    注意

    与 Kubenet 相比，Azure CNI 需要更多的 IP 地址空间。 需要适当的前期规划和调整网络大小。 有关详细信息，请参阅 Azure CNI 文档。

  • 默认情况下，Pod 是非隔离的，接受来自任何源的流量，并且可以将流量发送到任何目标;Pod 可以与给定 Kubernetes 群集中的其他每个 Pod 通信;Kubernetes 不确保任何网络级别隔离，也不会在群集级别隔离命名空间。

  • Pod 和命名空间之间的通信可以使用网络策略进行隔离。 网络策略是一种 Kubernetes 规范，其中针对 Pod 之间的通信定义了访问策略。 使用网络策略，可以定义有序的规则集来控制流量的发送/接收方式，并应用于与一个或多个标签选择器匹配的 Pod 集合。

    • AKS 支持两个实现网络策略、 Azure 和 Calico 的插件。 这两个插件都使用 Linux IPTable 强制实施指定的策略。 有关更多详细信息，请参阅 Azure 和 Calico 策略之间的差异及其功能 。
    • 网络策略不会冲突，因为它们是累加性的。
    • 若要允许两个 Pod 之间的网络流，源 Pod 上的出口策略和目标 Pod 上的入口策略都需要允许流量。
    • 只能在群集实例化时启用网络策略功能。 无法在现有 AKS 群集上启用网络策略。
    • 无论使用 Azure 还是 Calico，网络策略的交付都是一致的。
    • Calico 提供更 丰富的功能集，包括对 Windows 节点的支持，并支持 Azure CNI 以及 Kubenet。

  • AKS 支持创建不同的节点池，以使用具有不同硬件和软件特征的节点（例如具有和不使用 GPU 功能的节点）分隔不同的工作负荷。

    • 使用节点池不提供任何网络级隔离。
    • 节点池可以使用 同一虚拟网络中的不同子网。 可以在子网级别应用 NSG，以在节点池之间实现微分段。

设计建议

  • 在所有已考虑的子网上配置 NSG，以提供 IP ACL 来保护入口路径，并根据零信任模型隔离应用程序组件。

    • 在包含 Azure Front Door 中定义的应用程序后端的所有子网上使用 Front Door 服务标记，因为这将验证来自合法 Azure Front Door 后端 IP 地址空间的流量。 这将确保流量在服务级别通过 Azure Front Door 流动，但基于标头的筛选仍需要确保使用特定的 Front Door 实例并缓解“IP 欺骗”安全风险。

    • 应在所有适用 NSG 的 RDP 和 SSH 端口上禁用公共 Internet 流量。

    • 优先使用 Azure CNI 网络插件，并考虑将 Kubenet 用于可用 IP 地址范围有限的场景，以使应用程序适应有限的地址空间。

      • AKS 支持使用 Azure CNI 和 Kubenet。 此网络选择是在部署时选择的。
      • Azure CNI 网络插件是一个更可靠且可缩放的网络插件，建议在大多数情况下使用。
      • Kubenet 是一个更轻型的网络插件，建议用于具有有限范围的可用 IP 地址的方案。
      • 有关更多详细信息，请参阅 Azure CNI 。

  • Kubernetes 中的网络策略功能应该用于定义群集中 Pod 之间的入口和出口流量规则。 定义精细网络策略以限制跨 Pod 通信。

    • 在部署时为Azure Kubernetes 服务启用网络策略。
    • 优先使用 Calico ，因为它为更广泛的社区采用和支持提供了更丰富的功能集。

下一步

查看量化和观察应用程序运行状况的注意事项。

运行状况建模和可观测性