<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 解读本地 ADC 规则：迁移至 Azure Application Gateway
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
该解决方案阐述了如何将企业本地环境中的**应用交付控制器 (ADC)**，如 F5 (iRules)、Citrix NetScaler (Policy Expressions) 等，迁移至微软云原生服务 **Azure Application Gateway v2**。核心目标是解答客户关于 Azure 原生负载均衡服务能否支持其现有复杂流量管理规则的疑问。该方案并非简单的配置逐行平移，而是倡导一种**“意图导向”**的迁移模式，即分析现有规则的业务目的，并利用 Application Gateway 及其生态系统中的原生功能（如重写、重定向、WAF 规则等）重新实现这些业务逻辑。此方案主要适用于计划向**云原生或混合云架构**转型的企业，旨在利用 Azure 的敏捷性、可扩展性和安全性来现代化其应用交付基础设施。
## 实施步骤
1. **清单盘点与分析 (Inventory & Analyze)**
- 全面梳理现有本地 ADC 中的所有规则，特别是高级脚本（如 iRules, Policy Expressions）。
- 将复杂的、单一的脚本逻辑分解为多个独立的、模块化的功能单元，例如：重定向、头部重写、路径路由等。
2. **模式转换与映射 (Pattern Translation)**
- 采用“意图导向”的翻译方法，理解每个规则片段的**最终目的**，而非逐字翻译代码。
- 可借助 AI 工具（如 Copilot）对常见的 ADC 规则模式进行初步转换，以识别 Azure 中的对等功能。
- 核心是将 ADC 的事件驱动或过程式脚本，映射为 Application Gateway 的声明式配置。
3. **配置实现 (Configuration & Implementation)**
- 在 Azure 中使用相应功能实现已映射的逻辑。配置可通过多种方式进行：
- **Azure Portal UI:** 适用于手动配置和快速验证。
- **Azure CLI / PowerShell:** 适用于脚本化、可重复的部署。
- **ARM / Bicep 模板:** 适用于 **Infrastructure-as-Code (IaC)**，实现自动化和版本控制。
- 例如，实现 HTTP 头部重写，需在 Application Gateway 中创建**重写集 (Rewrite Set)**，定义条件和操作，并将其关联到相应的路由规则。
4. **验证与调优 (Validation & Tuning)**
- 对于迁移的 WAF 规则，首先应在**“检测模式 (Detection Mode)”**下运行，以识别并修正潜在的误报（False Positives），确认无误后再切换至“阻止模式 (Enforcement Mode)”。
- 对所有迁移的规则进行端到端的业务功能验证，确保其行为与原始配置的业务意图一致。
## 方案客户价值
- **简化运维:** 从管理复杂的本地 ADC 设备转向使用 Azure 托管服务，显著降低了硬件维护、软件升级和故障排查的运维负担。
- **提升敏捷性与可扩展性:** 受益于 **Autoscaling**（自动缩放）和 **Zone Redundancy**（区域冗余）特性，应用可根据流量自动调整容量并具备高可用性。通过 IaC 工具链可实现快速、自动化的部署和变更。
- **增强原生安全性:** 与 **Azure WAF**、**Azure DDoS Protection** 和 **Microsoft Defender for Cloud** 等原生安全服务无缝集成，提供从网络层到应用层的全面防护。
## 涉及的相关产品
- **Azure Application Gateway v2:** 核心产品，提供 L7 负载均衡、SSL 卸载、URL 路径路由、头部重写等功能。
- **Azure Web Application Firewall (WAF):** 与 Application Gateway 集成，用于实现 IP 过滤、地理位置封锁及抵御常见的 Web 攻击。
- **Azure Front Door:** 可与 Application Gateway 结合使用，以实现**全局负载均衡 (GSLB)** 和更高级的地理路由功能。
- **网络安全组 (NSGs):** 作为一种备选方案，可用于在网络层实现 IP 过滤。
- **Azure Monitor & Log Analytics:** 用于监控 Application Gateway 的性能指标、收集和分析日志，提供可观测性。
---
## 技术评估
该迁移方案在技术上是可行的，尤其适用于以 HTTP/HTTPS 流量管理为主的现代 Web 应用。
- **优势:**
- **云原生集成:** 与 Azure 生态（监控、安全、IaC）深度融合，提供了统一的管理和自动化体验。
- **托管服务优势:** 免去了底层基础设施的管理复杂性，让团队更专注于业务逻辑。
- **覆盖主流场景:** 对于常见的流量管理需求，如重定向、URL 路由、头部修改等，提供了直接的原生支持，迁移路径清晰。
- **局限性与挑战:**
- **高级脚本能力缺失:** Application Gateway **不支持**本地 ADC 中强大的事件驱动脚本（如 F5 iRules 的 `HTTP_REQUEST` 事件钩子）或完整的编程语言（如 TCL）。对于深度依赖此类脚本实现复杂业务逻辑的场景，无法直接迁移。
- **不支持 TCP 层精细控制:** 无法实现对 TCP 载荷的检查或基于 TCP 表达式的路由，功能范围严格限定于 L7。
- **有限的正则表达式支持:** 在路径匹配等方面的正则表达式能力有限，可能无法满足高度依赖复杂正则匹配的路由策略。
- **迁移复杂度:** 迁移并非“一键式”操作，需要进行架构层面的重新设计和规则的“意图重构”，对实施团队的技术理解能力要求较高。最终仍需手动验证以确保准确性。
| Citrix 特性 | F5 iRule 特性 | App Gateway v2 对等方案 | Azure 支持度 |
| :--- | :--- | :--- | :--- |
| Responder Policies | Redirects (301/302) | 原生重定向规则 | ✅ |
| Rewrite Policies | Header rewrites | 重写集规则 (Rewrite Set) | ✅ |
| GSLB + Responder | Geo-based Routing | 结合 **Azure Front Door** | ✅ |
| Content Switching | URL-based routing | 基于路径的路由规则 | ✅ |
| Responder/ACLs | IP filtering | WAF 自定义规则或 NSG | ✅ |
| Advanced Policy Expressions | Regex-based routing | 有限的正则支持 (通过路径参数) | ➗ |
| AppExpert with TCP expressions | TCP payload inspection | 不支持 | ❌ |
| 不支持 | Event-driven hooks | 不支持 | ❌ |
| 不支持 | Full scripting (TCL) | 不支持 | ❌ |
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 解读本地 ADC 规则：迁移至 Azure Application Gateway
**原始链接:** [https://techcommunity.microsoft.com/blog/azurenetworkingblog/decoding-on-premises-adc-rules-migration-to-azure-application-gateway/4439156](https://techcommunity.microsoft.com/blog/azurenetworkingblog/decoding-on-premises-adc-rules-migration-to-azure-application-gateway/4439156)
**发布时间:** 2025-08-06
**厂商:** AZURE
**类型:** TECH-BLOG
---
Azure 网络博客
# 解读本地 ADC 规则：迁移至 Azure Application Gateway
2025 年 8 月 6 日
### **概述**
随着 Azure Application Gateway 的不断发展，许多组织正在考虑如何将其现有的本地解决方案 (例如 F5、NetScaler 和 Radware) 迁移至 Azure 的原生服务。在向云原生架构 (cloud-native architecture) 转型的过程中，一个常见的问题是：
> **“Application Gateway 能否支持我当前的负载均衡 (load balancing) 配置？”**
简而言之：这取决于您的具体用例。只要方法得当，迁移过程可以做到平滑、可扩展且安全。Azure Application Gateway，特别是与 Web 应用程序防火墙 (WAF)、Azure Front Door 和 Azure Firewall 等 Azure 原生服务结合使用时，可以支持常见的用例。
本指南提供了功能对比，概述了支持的功能，并为成功迁移提供了蓝图。
### **Application Gateway 的核心能力**
[**Azure Application Gateway v2** ](<https://learn.microsoft.com/en-us/azure/application-gateway/overview-v2>) 带来了一系列增强功能，以满足现代云优先组织的需求：
- 自动缩放 (Autoscaling) 和区域冗余 (Zone Redundancy)
- 原生 WAF 与 Azure DDoS 保护
- 对标头重写 (Header Rewrites)、基于 URL 的路由 (URL-based routing) 和 SSL 终止 (SSL termination) 的原生支持
- 与 Azure Monitor、Log Analytics、Defender for Cloud 集成
- Azure 原生部署：ARM/Bicep、CLI、GitOps、Terraform、CI/CD
这些特性使 App Gateway 成为云优先和混合场景的有力选择，客户可以从中受益，实现简化的运维、更高的敏捷性和更强的安全性。
### **什么是 ADC 规则？**
本地的应用交付控制器 (ADC) 通常包含高级流量管理功能，例如 iRules 和 Citrix 策略表达式。这些第 4-7 层设备超越了基本的负载均衡，能够在连接生命周期 (connection lifecycle) 的各个阶段对流量进行操控。ADC 功能强大、灵活，并且通常深度嵌入到企业的流量逻辑中。如果您依赖这些功能，迁移仍然是可行的——Azure Application Gateway 原生支持许多常用功能。
常见的 ADC 场景：
- 重定向和重写
- IP 过滤和地理位置封锁
- 自定义错误处理
- 事件驱动逻辑 (Event-driven logic)，如 `HTTP_REQUEST`、`CLIENT_ACCEPTED`
### **Application Gateway 功能模式**
ADC 的流量管理功能强大而灵活，通常深度嵌入在企业流量流中。Application Gateway 为许多常见场景提供了原生支持。在本指南中，我们将向您展示如何将高级规则转换为典型的配置模式。
> [注意]：迁移 WAF 规则时，请先启用检测模式 (detection mode)，以识别误报 (false positives)，然后再强制执行阻止策略。
| **Citrix 功能** | **iRule 功能** | **App Gateway v2 等效功能** | **App Gateway 是否支持?** |
| --- | --- | --- | --- |
| 响应器策略 (Responder Policies) | 重定向 (301/302) | 原生重定向规则 | ✅ |
| 重写策略 (Rewrite Policies) | 标头重写 | 重写集规则 | ✅ |
| 全局服务器负载均衡 (GSLB) + 响应器策略 | 基于地理位置的路由 | 与 Azure Front Door 结合使用 | ✅ |
| 内容交换策略 (Content Switching Policies) | 基于 URL 的路由 | 基于路径的路由规则 | ✅ |
| 响应器/访问控制列表 (ACL) | IP 过滤 | WAF 自定义规则或 NSG | ✅ |
| GSLB + 策略表达式 | 地理位置封锁 | WAF 规则 | ✅ |
| 内容交换策略 | 基于路径的路由 | URL 路径映射 | ✅ |
| 内容交换/重写策略 | 基于标头的路由 | 通过基于参数的路径选择提供有限支持 | ➗ |
| 高级策略表达式 (支持 Regex) | 基于正则表达式的路由 | 通过路径参数提供有限的正则表达式支持 | ➗ |
| 优先级队列/速率控制 | 实时流量整形 | 通过 Azure Front Door 提供有限支持 | ➗ |
| AppExpert (使用 TCP 表达式) | TCP 负载检查 | 不支持 | ❌ |
| 不支持 | 事件驱动挂钩 (如 HTTP_REQUEST) | 不支持 | ❌ |
| 不支持 | 查询池 (Query Pool) | 不支持 | ❌ |
| 不支持 | 按请求编写脚本 | 不支持 | ❌ |
| 深度包检测 + 策略 (有限) | 基于负载的路由 | 不支持 | ❌ |
| 不支持 | 完整脚本 (TCL) | 不支持 | ❌ |
### **转换高级规则**
迁移 iRules 和 Citrix 策略表达式等 ADC 功能，与其说是逐行翻译，不如说是识别模式。可以将其理解为翻译一门语言——不是逐字逐句，而是意图对意图。
如何开始：
- 工具辅助翻译 (tool-assisted translation)：使用 Copilot 或基于 GPT 的工具来翻译常见的 ADC 规则模式。
- 清点与分析：将复杂的规则分解为模块化的 App Gateway 功能 (重定向、重写)。
- 归档：记录所有原始目标及其翻译后的等效配置。
### **在 Azure 中如何配置**
您可以通过以下方式实现路由和重写逻辑：
- Azure 门户 UI
- Azure CLI / PowerShell (`az network application-gateway`)
- ARM 模板 / Bicep (用于基础设施即代码 (infrastructure-as-code) 部署)
- REST API (用于自动化/CI-CD 流水线)
示例：在门户中配置标头重写
1. 在 [Azure 门户] (<https://portal.azure.com/>) 中打开您的 Application Gateway。
2. 导航到侧边栏的 **重写**。
3. 点击 **+ 添加重写集**，然后将其应用到您的路由规则。
4. 定义您的重写条件和操作。
[注意]：不确定什么是重写？在此处了解有关 [重写 HTTP 标头] (<https://learn.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers-url>) 的更多信息。
1. 重写配置：点击 **+ 添加重写集** 为您的路由规则应用新的重写：
### **资源**
- [Application Gateway v1 到 v2：从 App Gateway v1 迁移到 v2] (<https://learn.microsoft.com/en-us/azure/application-gateway/migrate-v1-v2>)
- 最佳实践：[Azure Application Gateway v2 架构最佳实践 - Microsoft Azure Well-Architected Framework | Microsoft Learn] (<https://learn.microsoft.com/en-us/azure/well-architected/service-guides/azure-application-gateway>)
- 重写：<https://learn.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers-url>
- 基于标头的路由：<https://learn.microsoft.com/en-us/azure/application-gateway/parameter-based-path-selection-portal>
- 优化 WAF 规则：[为 Azure Front Door 优化 Azure Web 应用程序防火墙 | Microsoft Learn] (<https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-tuning?pivots=front-door-standard-premium>)
### **结论**
尽管 AI 驱动的助手 (AI-powered assistants) 可以帮助解释和翻译常见的 ADC 流量管理模式，但为了确保准确性并符合您的特定需求，手动重新创建和验证规则仍然是必要的。尽管如此，迁移到 Application Gateway v2 不仅是可行的，更是向现代化、云原生基础设施迈出的战略性一步。
通过周密的规划和正确的心态，组织可以在保持流量灵活性的同时，获得 Azure 生态系统的敏捷性、可扩展性和运营效率。如果您不确定当前的本地配置是否能在 Azure Application Gateway 中得到支持，请查阅官方 Azure 文档或联系 Microsoft 支持以获取指导。
更新于 2025 年 8 月 6 日
版本 1.0
<!-- AI_TASK_END: AI全文翻译 -->