DNS 负载均衡：方法、优势与局限

DNS 负载均衡通过为主机名返回一个或多个地址来分配请求，有时还会根据位置、健康状况或策略选择不同的应答。它可以把流量分散到多个区域，把用户引向就近的基础设施，并提供简单的一层故障切换。具体行为取决于 DNS 服务商和解析器缓存。标准 DNS 应答并不会针对每个 HTTP 请求重新评估，所以解析器刷新缓存时做出的决定，可能一直沿用到 TTL 过期。这使得 DNS 适合做粗粒度的流量引导，但它与实时评估每个新连接的负载均衡器是两回事。

常见的 DNS 分流策略

轮询（round-robin）可以在一组地址之间轮换返回顺序。基于地理位置或延迟的 DNS 可以根据递归解析器的表面位置返回区域端点。加权路由可以让某个端点比另一个获得更多流量，适用于受控的灰度发布或容量分配。故障切换配置可以在健康检查发现问题后，不再返回某个端点。每项功能都有服务商特有的细节：健康检查间隔、失败阈值、解析器位置推断和 TTL 行为，都会影响最终用户看到的结果。在依赖这些行为之前，请先阅读服务商的实现指南，并从具有代表性的网络进行测试。

解析器的位置是一个重要的细节。支持地理感知的 DNS 服务通常看到的是递归解析器的地址，而不是用户设备的地址。部分系统中，EDNS Client Subnet 可能提供更多位置上下文，但它并非普遍发送，还涉及隐私方面的考量。因此，一个公共解析器可能代表众多用户，并代他们接收同一个区域的应答。在某些部署中，从不同位置观察到不同的 DNS 应答是预期之内的，但这并不能证明某位具体访问者被路由到了最近的物理服务器。

DNS 的决策会被缓存

DNS TTL 规定了解析器在刷新之前可以缓存应答多长时间。较低的 TTL 可以让计划内的变更在缓存过期后更快可见，但会增加查询量，也不能保证立即传播。解析器可以一直使用已缓存的应答，直到剩余有效期结束，应用程序还可能有自己的缓存或持久连接。因此，端点发生故障时，基于 DNS 的故障切换可能比在感知连接的负载均衡器内部移除该端点要慢。在决定把 DNS 作为唯一的故障切换机制之前，请同时考虑关键的恢复时间和预期会经过的缓存层。

• 明确什么才算端点健康，并测试完整的应用路径。
• 确认服务商如何评估解析器的地理位置和健康状态。
• 根据运维需求设置 TTL，而不要认为越低越好。
• 需要快速、感知健康状态的连接决策时，使用应用或网络负载均衡器。
• 从多个区域监测用户，以发现路由差异。

规划并验证流量变更

在转移流量之前，先确认每个目标都已准备好提供相同的主机名、证书和应用行为。在服务商支持加权的情况下，逐步做出变更，检查日志和错误率，只有在结果健康时才增加流量。为了便于回滚，要了解缓存最长会保留之前的应答多久，并在这段时间内保持旧环境可用。不要依赖单次 DNS 查询来确认到达各个后端的真实用户占比；应当使用服务遥测数据、服务商的分析功能，或与实际客户端路径一致的受控探测。

只要了解 DNS 的优势和延迟，它就是一个有效的全局控制平面。它是对负载均衡器和应用健康检查的补充，而不是替代。关于最简单的地址池模型，请阅读 DNS 轮询详解；关于缓存行为，请阅读 DNS TTL 详解。公共的 DNS 查询可以显示某个解析器在某一时刻能获取到的内容；运维团队在评估流量是否到达了健康的基础设施时，应将这份证据与实际的连接监控和应用监控结合起来。

在应用层衡量用户体验

DNS 策略只有在改善了用户实际获得的服务时才算成功。请在每个区域的应用端点上跟踪延迟、错误率和可用性，并把这些指标与服务商返回的 DNS 应答进行对照。最近的解析器不一定对应最近的用户，最近的服务器也不一定负载最低或最健康。既要纳入来自具有代表性网络的合成监测，也要查看真实流量遥测数据中的异常值。如果某条路由策略把用户送往了不健康的区域，应当调整健康信号或回退方案，而不是只改 TTL。一次具备完善监测的发布，能让运维人员依据真实的缓存条件，了解加权和区域选择究竟是如何运作的。