2. Route 53核心机制

Route 53 是 AWS 的权威 DNS 服务，也是混合云跨域解析工程中最关键的“解析中枢”。理解它，不能只停留在“能建域名、能加记录”的层面，而要掌握六个彼此咬合的核心机制：托管区域决定“谁负责这个域”，记录类型决定“返回什么”，别名记录决定“如何指向 AWS 资源”，路由策略决定“返回哪一个”，健康检查决定“这个答案还能不能用”，TTL 决定“这个答案能被缓存多久”。这六者共同决定了跨域解析的准确性、切换速度和成本。

托管区域：解析责任的边界

托管区域（Hosted Zone）是一组记录的容器，代表某个域名及其子域的解析责任范围。它分为两类：公有托管区域面向互联网，私有托管区域只关联到指定 VPC，供 VPC 内实例解析。公有区域创建后，Route 53 会分配四个 NS 记录（名称服务器）和一个 SOA 记录，你需要在域名注册商处把域名的 NS 指向这四个地址，解析权才真正交给 Route 53。

私有托管区域的关键在于“关联 VPC”。只有被关联的 VPC 才能解析其中的记录。在混合云场景中，本地 IDC 通常通过 Resolver 入站/出站端点与私有区域交互：出站端点把本地查询转发到 Route 53，入站端点让本地 DNS 能查询私有区域。因此，私有托管区域是跨域解析的“落点”，而不是简单的内网域名表。

记录类型与别名记录

Route 53 支持 A、AAAA、CNAME、MX、TXT、NS、SOA、SRV、CAA、PTR 等标准记录类型。其中 A 记录把域名映射到 IPv4 地址，CNAME 把域名映射到另一个域名。但 CNAME 有两个限制：不能用于区域顶点（如 example.com 本身），也不能与其它记录类型共存。

别名记录（Alias Record）是 Route 53 特有的扩展，它看起来像 A/AAAA 记录，但目标不是 IP，而是 AWS 资源，例如 ALB、CloudFront、S3 静态网站、API Gateway、另一个 Route 53 记录，甚至同区域内的私有资源。别名记录的最大价值是：它可以在区域顶点使用，且对 AWS 资源的 IP 变化自动跟随，不需要你手工维护 IP。对于指向 ELB 或 CloudFront 的场景，别名记录通常不收取查询费用，而普通查询会计费。

路由策略：决定返回哪一个答案

Route 53 提供多种路由策略，它们不是互斥的“开关”，而是按记录集分别选择的：

• 简单路由（Simple）：一条记录一个值，适合单点、无健康检查需求的场景。
• 加权路由（Weighted）：为同一名称配置多条记录并分配权重，按比例分流，常用于灰度发布或蓝绿切换。权重为 0 的记录不参与流量，但可用于“预置”切换目标。
• 延迟路由（Latency）：按用户到各区域的网络延迟选择最优区域，适合多区域部署。
• 故障转移路由（Failover）：配置主记录和备用记录，主记录健康检查失败时自动切到备用。
• 地理位置路由（Geolocation）：按用户所在国家/地区或大陆返回不同答案，常用于合规和本地化。
• 多值回答（Multivalue Answer）：返回多条健康记录，客户端自行选择，起到简易负载均衡作用。

在混合云跨域解析中，最常用的是故障转移和加权：本地 IDC 与 AWS 之间做双活或主备时，用故障转移把主流量指向本地、备用指向 AWS，或者反过来；灰度迁移时用加权逐步把权重从本地切到云上。

健康检查：让 DNS 具备“感知能力”

健康检查是 Route 53 实现自动故障转移的基础。它由 Route 53 的健康检查节点主动发起探测，支持三种类型：HTTP/HTTPS、TCP、以及基于 CloudWatch 告警的健康检查。你可以指定探测路径、端口、协议、间隔（默认 30 秒，可设为 10 秒快速探测）、失败阈值（默认 3 次）和成功阈值。

健康检查可以关联到记录集，也可以关联到另一条健康检查（计算型健康检查），用于表达“多个端点中至少 N 个健康”这类逻辑。在跨域场景中，健康检查通常指向本地 IDC 的入口地址或 AWS 侧的 ALB。需要注意的是：健康检查节点来自公网，如果本地 IDC 入口只允许内网访问，健康检查会失败，此时应改用 CloudWatch 告警健康检查，由本地监控系统把状态推送到 CloudWatch。

TTL设计：切换速度与查询成本的平衡

TTL（Time To Live）决定解析结果在递归解析器中的缓存时长。TTL 越短，故障切换越快，但查询量和成本越高；TTL 越长，缓存命中率高、成本低，但切换延迟大。常见取值参考：

需要特别说明：TTL 只影响递归解析器的缓存，不影响 Route 53 自身的权威应答。切换发生时，已经缓存旧答案的客户端仍会继续使用旧地址直到 TTL 过期。因此，计划内切换应提前把 TTL 调低，切换完成并稳定后再调回。别名记录没有独立 TTL，它继承目标资源的 TTL 行为，这也是别名记录在切换场景中更省心的原因之一。

把六个机制串起来看

假设一个典型混合云场景：主服务在本地 IDC，备用服务在 AWS 的 ALB 后面，域名是 app.example.com。合理的做法是：在公有托管区域中为 app.example.com 创建故障转移记录集，主记录指向本地 IDC 入口（A 记录，TTL 60 秒），备用记录用别名记录指向 ALB（TTL 60 秒），并为主记录关联一个健康检查。当健康检查判定本地入口不可用时，Route 53 自动返回 ALB 的别名答案，客户端在 TTL 过期后切换到 AWS 侧。

如果本地入口不能被公网健康检查节点访问，就改用 CloudWatch 告警健康检查，由本地监控把“入口不可用”推送到 CloudWatch 告警，Route 53 依据告警状态执行切换。这样既避免了暴露本地入口，又保留了自动故障转移能力。

最后要记住一个工程原则：TTL、健康检查间隔和失败阈值共同决定了实际切换时间。切换时间大致等于“健康检查判定失败所需时间 + TTL 缓存过期时间”。例如健康检查间隔 30 秒、失败阈值 3 次，判定失败约需 90 秒；TTL 60 秒，则最坏情况下客户端约 150 秒后完成切换。计划内维护时，提前把 TTL 降到 30 秒，可以把这个窗口压缩到约 120 秒以内。理解这个计算关系，才能在跨域解析工程中把可用性和切换速度调到符合业务预期的水平。