通过

从 Amazon Web Services (AWS) 应用程序负载均衡器迁移到 Azure 应用程序网关

如果当前使用 AWS 应用程序负载均衡器 (ALB) 并计划将工作负载迁移到 Azure，本指南可帮助你了解迁移过程、功能映射和最佳做法。 在 Azure 上，Azure 应用程序网关提供应用程序负载均衡功能，使你能够管理发到 Web 应用程序的流量。

您将学习如何执行以下操作：

  • 评估当前环境
  • 规划和准备迁移
  • 在维护应用程序可用性和性能的同时执行转换

你要完成的操作

按照本指南操作，你需要：

  • 将 AWS ALB 功能映射到应用程序网关功能
  • 为成功迁移准备环境
  • 在最短的停机时间内规划和执行迁移
  • 验证迁移的工作负荷是否符合性能和可靠性要求
  • 学习如何对体系结构进行迭代以实现未来的增强功能

本文使用方案演示常见模式，例如基于路径的路由、多区域分发和适用于许多工作负荷的混合计算环境。

示例方案：微服务体系结构迁移

在此示例中，金融服务公司使用 AWS 应用程序负载均衡器 (ALB) 运营微服务工作负荷，以在多个后端之间路由流量。 工作负荷的体系结构包括 EC2 实例上运行的用户身份验证服务，以及部署在 AWS Fargate 容器上的事务处理服务。 ALB 执行基于路径的路由，将 /auth/* 请求定向到身份验证服务并将 /transactions/* 请求定向到容器化交易处理服务。 此业务关键型设置支持其核心业务功能，可跨多个可用性区域处理具有高可用性的安全财务交易。

体系结构概述

此体系结构示例展示了 AWS 和 Azure 中的常见应用程序负载均衡功能，包括基于路径的路由、跨各种后端服务器的流量分布以及多区域部署模式。 目标是将此体系结构从 AWS ALB 迁移到应用程序网关，同时保持等效的功能，并满足对性能、可靠性、安全性和其他方面的工作负荷期望。 在我们的体系结构关系图中，/service-a/* 表示 /auth/* 路径，/service-b/* 表示 /transactions/*。

下面是 AWS 中工作负荷的体系结构：

显示两个可用性区域中跨 EC2 和 Fargate 的 AWS 应用程序负载均衡器路由服务的关系图。

这是迁移到 Azure 的同一工作负荷的体系结构：

应用程序网关在运行于 Azure 虚拟机 (VM) 的服务与运行于 Azure 容器应用 (ACA) 的服务之间进行流量均衡的关系图。

这两种体系结构都提供等效的功能，包括：

  • 高可用性部署：资源分布在多个可用性区域以实现容错

  • 网络隔离：具有用于负载均衡器、应用程序层和数据服务的专用子网的虚拟网络

  • 基于路径的路由：基于 URL 路径的请求路由到不同的后端服务（/auth/*、/transactions/*）

  • 多目标灵活性：跨不同计算平台和可用性区域分布的后端服务

  • 混合计算支持：虚拟机和容器化工作负荷的组合

  • 高级请求路由：基于具有可配置运行状况监视的 URL 模式的复杂路由规则

  • 集成安全性：具有安全规则集的 Web 应用程序防火墙保护

  • 网络安全控制：控制网络层之间的流量流的安全组/规则

  • 安全套接字层 (SSL) 或传输层安全性 (TLS) 终止：集中式证书管理和 HTTPS 终结点处理

  • 自动缩放功能：基于流量需求和资源利用率的自动缩放

  • 全面的监视：详细的指标、访问日志和运行状况监视，用于故障排除和优化

生产环境注意事项

此次迁移被设计为直接转换迁移。 使用此方法，可以与现有的 AWS 设置并行生成 Azure 基础结构。 这样可最大程度地减少批量移动用户的复杂性，并在出现问题时实现快速回滚。 在 DNS 直接转换期间，可能会遇到短暂的停机时间;此过程旨在最大程度地减少用户中断。

预期停机时间：

  • DNS 传播时间：300 秒 TTL 的情况下为 5-15 分钟
  • 会话中断：在直接转换期间，现有用户会话可能会中断
  • 服务可用性：在迁移期间，各个服务仍可用

建议的维护时段：

  • 持续时间：低流量期间为 1-2 小时
  • 缓冲时间：额外增加 30 分钟，以应对不可预见的问题
  • 回滚时间：15-30 分钟（视需要而异）

注释

在直接转换前将 DNS TTL 值重置为 300 秒（5 分钟），有助于确保顺利转换，同时缩短停机时间。 这可实现快速的 DNS 传播，并减少切换过程中过期 DNS 缓存记录可能引发的问题范围。 在某些情况下，可以将 TTL 进一步减少到 60 秒（1 分钟），以确保 DNS 更改快速传播。 然而，这可能并非适用于所有情况。

步骤 1：评估

在从 AWS 应用程序负载均衡器迁移到应用程序网关之前，请评估现有体系结构并确定要映射或替换的功能。 此评估有助于确保顺利迁移并维护应用程序的功能。

直接功能映射

微服务体系结构功能从 AWS ALB 映射到应用程序网关，如下所示：

AWS ALB 功能 应用程序网关等效项 迁移方法
AWS ALB 目标组 应用程序网关后端池 为每个服务创建后端池。 后端池可以包含 NIC、虚拟机规模集、公共/内部 IP 地址、FQDN 和多租户后端，例如 Azure 应用服务。 为规模集配置自动实例注册。
基于 AWS ALB 路径的路由 应用程序网关基于 URL 路径的路由规则 使用基于 URL 路径的条件配置请求路由规则。 使用应用程序网关的路由规则及基于优先级的处理，将 /auth/* 和 /transactions/* 路由到各自的后端池。
AWS ALB 运行状况检查 应用程序网关运行状况探测 配置与 AWS 运行状况检查设置匹配的自定义运行状况探测。 设置探测间隔、超时、不正常阈值和响应条件以匹配 AWS ALB 配置。 应用程序网关支持带有可配置 HTTP 状态代码和响应正文子字符串匹配功能的默认探测器和自定义探测器。 注意：应用程序网关默认探测间隔为 30 秒，默认超时为 30 秒，默认不正常阈值为 3;自定义响应正文匹配是子字符串匹配（而不是正则表达式），记录的最大响应正文匹配长度为 4,090 个字符。
AWS ALB SSL/TLS 终止 使用 Key Vault 的应用程序网关 TLS 终止 使用 Azure Key Vault 配置 TLS 终止，以便进行证书管理。 使用 Key Vault 集成时，应用程序网关 v2 支持自动证书轮换。 如果计划重复使用 AWS 证书管理器（ACM）中的证书，在尝试迁移之前验证 ACM 证书是否可导出：并非所有 ACM 证书都是可导出的。 当证书可导出时，请使用其私钥导出证书，并转换为 PFX 进行 Key Vault 导入。 对于基于 Key Vault 的轮换，请引用 Key Vault 的机密（而不是版本化机密），这样应用程序网关会自动从 Key Vault 获取更新并自动轮换证书。应用程序网关大约每四小时轮询一次 Key Vault。
AWS ALB 多 AZ 分布 应用程序网关区域冗余 在多个可用性区域中部署具有区域冗余的应用程序网关 v2。 区域冗余部署使用自动故障转移功能自动跨区域分配网关实例。 支持可用性区域 (zone) 的区域 (region)。
AWS ALB 自动缩放集成 Azure 虚拟机规模集 + 应用程序网关 AWS ALB 会自动将自动缩放组中的实例注册或取消注册为目标。 Azure 等效项：使用自动实例注册和基于运行状况的缩放将虚拟机规模集配置为应用程序网关后端池。 对于容器化工作负荷，将 Azure Kubernetes 服务 (AKS) 与应用程序网关入口控制器 (AGIC) 和水平 Pod 自动缩放程序配合使用。 实施基于 Azure Monitor 的缩放规则和自定义指标，以进行自动缩放决策。
AWS ALB WAF 集成 应用程序网关 WAF v2 集成 在应用程序网关上启用 Web 应用程序防火墙 (WAF) v2 策略。 WAF 使用最新的 OWASP 核心规则集 (CRS)，可防御 SQL 注入、跨站脚本以及其他 OWASP 前十漏洞攻击。 配置自定义规则、托管规则集和地区筛选以匹配 AWS WAF 功能。
AWS ALB CloudWatch 日志 使用 Azure Monitor 的应用程序网关诊断日志 配置诊断设置以将应用程序网关日志发送到 Log Analytics 工作区。 启用访问日志、性能日志和防火墙日志。 与用于自定义仪表板和警报的 Azure Monitor 工作簿集成。
AWS ALB EC2 目标组 应用程序网关 VM 后端池 将虚拟机添加为后端池成员。 应用程序网关可以通过不同的子网、虚拟网络（借助对等互连）或本地服务器（借助 ExpressRoute/VPN）与 VM 通信。 为 VM 运行状况监视配置运行状况探测。
AWS ALB ECS/Fargate 目标 应用程序网关容器后端池 将 Azure 容器应用 (ACA) 或 AKS 配置为后端目标。 对于 AKS，请使用应用程序网关入口控制器 (AGIC) 进行本机 Kubernetes 集成和自动目标注册。
AWS ALB 公共 IP 应用程序网关的公共 IP 地址 将静态标准 SKU 公共 IP 地址分配给应用程序网关以供外部访问。 应用程序网关 v2 支持 IPv4 和 IPv6 公共 IP 地址（预览版）。 配置工作负载 DNS 记录以指向应用程序网关公共 IP。
AWS ALB 会话粘性 基于应用程序网关 Cookie 的相关性 在应用程序网关中启用基于 Cookie 的相关性，以维护用户的会话持久性。 配置相关性设置以匹配 AWS ALB 粘性行为，确保迁移后提供一致的用户体验。

功能不匹配和策略

如果工作负荷使用 ALB 功能或应用程序网关无法解决的其他功能，请考虑以下策略，以便仍能取得可比的结果。

  • 使用其他 Azure 服务直接进行功能替换：将 AWS ALB 功能替换为应用程序网关等效项，同时维护核心功能。 这种方法优先考虑将干扰降至最低，并利用原生的 Azure 集成来实现安全、监控和证书管理。 例如，自动缩放集成支持所提供的功能在 Azure 中的处理方式有所不同。

  • 体系结构增强方法：将迁移视为一个契机，借此超越 AWS ALB 的功能实现现代化，方法是将 AKS 与应用网关入站控制器相结合，利用 Azure API 管理器进行高级路由，并使用 Azure Front Door 实现全球分发。

  • 接受功能差异：某些 AWS ALB 功能没有对应的应用网关功能等效功能，因此在迁移架构时需要接受不同的处理方式。 你需要评估这些差异对工作负荷的影响，并确定是否需要做出相应的调整以加以弥补。

自动缩放集成

AWS ALB 功能：AWS ALB 提供与自动缩放组的集成，其中：

  • 启动或终止时，系统会自动将实例注册/取消注册为目标

  • ALB 运行状况检查可以触发自动缩放操作来替换运行不正常的实例

  • 自动缩放可以使用 ALB 指标（每个目标的请求计数）根据流量需求缩放容量

应用程序网关方法：应用网关本身并不具备直接的自动扩展组功能，但通过以下方式提供了类似的功能：

  • 虚拟机规模集：使用自动实例注册和基于运行状况的缩放将规模集配置为应用程序网关后端池

  • AKS：将应用程序网关入口控制器 (AGIC) 与 Horizontal Pod Autoscaler 配合使用，实现基于容器的工作负荷

  • Azure Monitor 集成：基于应用程序网关指标和后端池运行状况实现自定义缩放规则

注意：应用程序网关 v2（Standard_v2/WAF_v2）支持自动缩放和区域冗余部署;但是，自动缩放在网关级别（缩放网关实例）进行管理，与后端实例的 AWS 自动缩放组行为不同。 如果需要自动目标注册和 Pod/实例级别缩放，请使用虚拟机规模集进行后端实例缩放和 AGIC/AKS 或规模集运行状况集成。

重要

自动缩放组展示了功能严重不匹配的一个例子。 还有一些功能在应用网关中并不存在一对一的对应项。 比如说：

  • 负载均衡算法： AWS ALB 支持多种算法（例如：round_robin、least_outstanding_requests、weighted_random）。 应用程序网关使用轮循机制来分发请求，并支持基于 Cookie 的会话相关性，以确保会话持久性。 应用程序网关不提供 ALB 样式的算法（如least_outstanding_requests或weighted_random），也不会公开 IP 哈希选项。 如果应用程序依赖于特定于 ALB 的算法、计划补偿策略（例如，调整后端容量、使用分阶段部署或使用其他流量分发组件）。

  • 慢速启动模式： AWS ALB 的缓慢启动模式在应用程序网关中不可用，无法逐步将流量提升到新目标。 若要缓解此问题，请使用部署策略，例如金丝雀部署、分阶段部署、预热终结点或预热实例，以避免流量高峰流向新的后端。

  • 高级路由功能：某些 AWS ALB 的路由功能可能需要采用不同的方法或接受不同的操作方式。 在评估阶段评估这些差异，并确定是否需要调整架构以进行补偿。

注释

测量性能和可靠性，以确保迁移的工作负载符合原始 AWS ALB 标准。 监视响应时间、吞吐量和错误率，以便应用程序网关按预期执行。

在迁移之前从 AWS ALB 建立基线指标。 使用这些基线来比较迁移后的应用程序网关性能，并确认它满足或超出预期。 包括响应时间、吞吐量和错误率。

步骤 2：准备

通过详细评估，可以发现对源端资源进行调整的机会，从而简化迁移过程，并提升迁移后的运营效率。 此步骤旨在对 AWS 的 ALB 配置及相关服务进行有针对性的调整，以确保其在 Azure 上的兼容性和性能。

源服务配置

成功迁移需要现有 AWS ALB 配置和依赖服务的详细文档，以确保顺利转换到应用程序网关。

基于路径的路由规则文档

  • 记录现有的 AWS ALB 侦听器规则，以确保应用程序网关采用等效的路由规则。 使用 负载均衡器的 AWS CLI 命令收集详细的配置信息。

  • 使用 AWS ALB 侦听器规则文档导出所有路由配置、运行状况检查设置和 SSL/TLS 终止配置。

  • 务必确保所有配置信息都被记录下来，以避免在迁移过程中出现功能缺失的情况，因为应用网关需要明确的路由规则配置。

SSL/TLS 证书准备

  • 从 AWS 证书管理器导出 SSL/TLS 证书以用于 Azure Key Vault 导入。

  • 使用私钥将证书转换为 PFX 格式，因为应用程序网关需要此格式进行证书管理。 按照 Azure Key Vault 证书集成指南进行操作。

    注释

    验证你计划导出的 ACM 证书是否允许 ACM 导出。 某些 ACM 托管证书（例如，某些服务完全由 AWS 管理的证书）无法导出;在迁移过程中依赖证书导出之前，请检查 ACM 文档。

    注释

    此方法假定你在外部 DNS 直接转换中使用相同的域名和现有证书。 如果迁移使用不同的域名，则需要获取新证书。

运行状况检查配置映射

使用应用程序网关运行状况探测配置指南将 AWS ALB 运行状况检查配置映射到应用程序网关运行状况探测等效项。 这可确保后端服务运行状况监视在迁移后继续正常运行。

依赖项变更

通过更新依赖服务和配置来准备迁移，以确保与应用程序网关的兼容性。

后端服务更改

这些更改可确保应用程序使用应用程序网关的请求处理和监视功能正常运作。

DNS 配置更改

  • 将 DNS 记录上的 DNS TTL 值减少到 300 秒，以提高直接转换速度。

  • 如果计划使用 Azure DNS，请使用 Azure DNS TTL 配置指南创建指向应用程序网关公共 IP 地址的 A 记录。 此更改可在迁移直接转换期间实现快速 DNS 传播。

后端池更新

环境更改

通过部署必要的基础结构来准备 Azure 环境。 配置安全和监视组件以支持迁移的工作负荷。 此准备有助于确保平稳过渡，并充分减少迁移过程中的潜在问题。

Azure 资源预配

  • 按照应用程序网关部署指南，在切换之前使用基础结构即代码部署应用程序网关、虚拟机和容器应用。

  • 通过提前部署，在生产切换之前实现全面的测试和验证。

网络安全组

  • 设置与 AWS 安全组规则匹配的网络安全组。
  • 在迁移之前、期间和迁移后保持安全状况。

监视配置

更改顺序和依赖项

以下列表概述了在迁移过程中要实现的一系列逻辑更改。 此顺序可确保在配置开始之前提供所有依赖服务，从而在整个迁移过程中保留系统功能。 将其视为迁移当天的预检清单。

更改的一般流程是基础结构部署、后端服务迁移，然后配置路由规则、运行状况探测和监视。 此顺序可确保在配置开始之前提供所有依赖服务，从而在整个迁移过程中保留系统功能。

虽然具体步骤可能因体系结构而异，但常规顺序如下：

  1. Azure 基础结构部署 - 首先部署应用网关和后端资源，因为这对于后续的配置步骤必不可少。

  2. 后端服务迁移 - 将应用程序迁移到 Azure VM 和容器应用。 这可以与 Azure 基础结构部署并行完成，以节省时间。

  3. SSL/TLS 证书迁移 - 使用 Key Vault 证书集成指南将证书导入 Azure Key Vault。 此步骤可确保在应用路由规则之前正确配置 SSL/TLS 终止。

  4. 运行状况探测配置 - 使用应用程序网关运行状况探测指南配置与 AWS 运行状况检查行为匹配的运行状况探测。 这可确保后端服务运行状况监视在迁移后继续正常运行。

  5. 路由规则配置 - 实现基于路径的路由规则。 此步骤对于确保根据 URL 路径正确路由到适当的后端服务至关重要。

  6. 后端池优化 - 配置多区域分发。 此步骤可确保高可用性。

  7. 监视设置 - 使用 Azure Monitor 配置指南配置 Azure Monitor 仪表板和警报。

    此步骤可确保你能够了解应用程序网关和后端服务的性能和运行状况。

  8. DNS 准备 - 减少当前 DNS 环境中的 TTL 值，并为 DNS 记录更新做好准备。 只要在迁移日之前 DNS 记录尚未更新为指向应用网关的地址，就可以在此过程中与其他步骤同时进行。 此步骤对于确保顺利直接转换至关重要，且故障时间最短。

一般来说，迁移过程首先会部署并迁移资源，然后配置路由规则、运行状况检查以及进行监控。 此顺序可确保生成应用程序网关，并在配置环境其余部分之前迁移后端服务。

步骤 3：评估

对既定成功标准的验证需要结合自动化测试与人工测试，以确保所有功能和性能指标均得到满足。 测试关键领域，包括路由准确性、SSL/TLS 终止、后端运行状况、响应时间和针对原始 AWS ALB 配置的会话处理。 自动测试最适合验证流量分布、吞吐量和运行状况检查性能等可重复方面。 应使用手动测试来确认更复杂的行为，例如自定义错误页显示、配置一致性和 SLA 一致性。 通过组合这些方法，可以自信地验证 Azure 环境是否符合所需的标准，并反映 AWS 的预期行为。

验证条件

在准备过程中，定义衡量迁移成功的验证条件。 这些条件有助于确保所有功能在迁移后按预期运行。

成功条件定义

根据评估部分确定的原始 AWS ALB 功能建立验证条件：

功能条件

  • 基于路径的路由准确性：根据 URL 路径将请求路由到正确的后端池

  • SSL/TLS 功能：HTTPS 连接使用 Azure Key Vault 证书终止并重新加密

  • 后端服务运行状况：所有后端服务均会报告跨可用性区域的运行状况

  • 多区域分布：使用自动故障转移正确分配流量

  • 错误处理：错误页面能够正确显示，并具备适当的故障转移功能。 如果在 AWS ALB 中配置了自定义错误页面，请确保这些页面也在应用网关中进行了同步设置。

  • HTTP 超时处理：确保 AWS 和 Azure 之间的 HTTP 超时值保持一致。 超时值应按现状迁移，以确保预期的运行效果，尤其是在上传/下载场景中。

性能条件

  • 响应时间基线：平均响应时间在 AWS ALB 基线的 10% 以内

  • 吞吐量容量：处理每秒等效请求的数量与 AWS ALB 相同

  • 并发连接：支持相同数量的并发用户

  • 运行状况探测效率：执行运行状况检查不会影响性能

可靠性条件

  • 会话处理：维护已配置的会话亲和性

  • 配置偏移： 监视环境之间的配置偏差，以防止迁移后出现可靠性问题

  • 合规性和 SLA 对齐方式：验证迁移后的解决方案是否符合所需的合规标准以及 Azure 关于系统运行时间和可靠性的 SLA

监视验证

验证监控能力是否匹配 AWS CloudWatch 功能：

  • 响应时间趋势：是否与预期模式相符
  • 请求量图表：是否能够准确反映流量分布
  • 错误率监控：是否包含合理的告警触发机制
  • 后端健康状态：是否能真实反映服务运行状况

验证方法

定义验证上一节中建立的成功标准的方法。 其中包括自动化和手动测试方法，以确保全面覆盖所有功能。

请记住，你的环境可能有独特的要求，因此请相应地调整验证条件和方法。 一般情况下，应尽可能使用自动测试来涵盖大多数功能和性能条件，而手动测试则应作为用于验证这些标准的备用手段。

自动测试

手动验证清单

  • 跨所有服务测试用户旅程
  • 验证文件上传/下载功能
  • 测试身份验证流和会话管理
  • 验证用户体验
  • 测试所有服务的 API 功能
  • 验证错误方案和错误页面显示

步骤 4：流程

在你的迁移计划已经制定完成，且准备工作也已全部结束之后，你就能够继续推进了。 按照以下详细步骤在迁移当天顺利执行迁移。

迁移执行

迁移执行涉及一系列步骤，以确保从 AWS ALB 顺利转换到应用程序网关。 此流程包括最终验证、并行测试、DNS 直接转换、直接转换后验证和 AWS 资源停用。

最终验证和测试

使用自动化和手动测试来验证定义的成功条件，以确保满足所有功能和性能基准。 根据您的评估标准，以下是需要验证的关键功能：

  • 使用有效证书测试 HTTPS 终结点
  • 验证所有服务的基于路径的路由
  • 确认多区域后端池分发和故障转移
  • 使用测试域验证 SSL 证书配置和路由规则
  • 通过应用程序网关执行服务功能测试
  • 跨多个区域验证微服务功能
  • 测试高可用性和故障转移方案
  • 比较性能与 AWS ALB 基线指标

DNS 直接转换执行

执行从 AWS ALB 到应用程序网关的 DNS 直接转换。 更新 DNS 记录以指向应用程序网关公共 IP 地址，并使用标准 DNS 工具监视 DNS 传播。

直接转换后验证

在直接转换后步骤中，需通过确认所有服务均正常运行且性能符合预期来验证迁移是否成功。

功能验证：

  • 验证所有服务路由功能运行正常
  • 验证 TLS/SSL 证书功能
  • 测试错误页和故障转移行为
  • 验证运行状况探测行为和后端运行状况

性能验证：

  • 监控响应时间，并与 AWS ALB 进行对比
  • 验证吞吐量容量是否满足要求

AWS 资源停用

验证成功后，停用 AWS 资源：

  • 监视应用程序网关 24-48 小时
  • 验证未将流量路由到 AWS ALB
  • 备份 AWS ALB 配置以实现回滚功能
  • 终止 AWS ALB 和关联的资源

一般来说，当在为期 7 天的监测期内所有成功标准都能持续达成，且与 AWS ALB 的性能相比没有出现任何性能降低的情况下，此次迁移则被视为成功完成。 根据特定的工作负荷，可能需要调整时间段，以确保所有服务都正常运行，并且性能符合预期。

迭代优化

迁移后，请专注于优化应用程序网关配置并验证路由准确性、性能和高可用性。 此迭代改进过程可确保迁移后的工作负载能够满足评估阶段依据 Azure 架构良好的框架提供的 Application Gateway 服务指南所制定的全部成功标准。

迭代改进过程

迁移过程是迭代的，应根据反馈和测试结果进行调整，直到满足成功条件：

性能优化循环

  1. 基线度量：将应用程序网关指标与 AWS ALB 基线进行比较

  2. 瓶颈标识：确定路由、SSL 终止或后端通信中的性能差距

  3. 配置优化：调整应用程序网关设置、后端探测间隔或连接限制

  4. 验证测试：重新测试性能并衡量改进情况

  5. 监视调整：更新监视阈值和警报规则

路由准确性优化

  1. 流量模式分析：监测实际请求的路由模式与预期模式的差异情况

  2. 规则优化：优化基于路径的路由规则以处理边缘情况

  3. 错误率分析：识别并修复导致错误的路由规则

  4. 用户体验验证：确保用户在不同服务中的使用流程能够实现无缝衔接

高可用性验证

  1. 流量分配验证：确认流量能够正确地分配到各个可用性区域中

  2. 故障转移过程测试：验证区域之间的自动故障转移

  3. 恢复功能：测试区域故障的快速恢复

  4. 运行状况检查准确性：确保运行状况检查正确识别服务问题

关键结论

将使用 AWS 应用负载均衡器的工作负载迁移到 Azure 时，需要进行精心的规划和系统的执行，以获得相同的功能或采用其他可行的方案。 关键成功因素包括：

评估和规划：在流程初期就将 AWS ALB 功能与应用网关的功能进行对应匹配。 特别要注意基于路径的路由、运行状况探测以及证书管理方面的差异。

使用 Azure 集成。 利用 Azure 密钥保管库进行证书管理，使用 Azure Monitor 来实现可观测性，以及采用虚拟机规模集来进行自动扩展。

在直接转换之前进行全面测试。 对临时域使用并行测试来验证所有功能。 在 AWS 环境中建立基线指标，并确保应用程序网关满足或超出性能预期。

规划最短故障时间。 提前降低 DNS 的 TTL 值，并同时做好所有基础设施的准备工作。 实际的直接转换只涉及 DNS 更改，从而最大程度地减少了服务中断的情况。

监测并优化迁移后的状况。 使用迭代改进流程微调性能、路由准确性和高可用性。 应用程序网关提供众多监视功能，可随时间推移优化配置。