从 AWS ALB 转向 Cloudflare Load Balancing 的团队通常会正确配置所有内容，然后遇到他们的心理模型无法解释的行为：客户端在失败后几分钟内不断到达同一源，实例之间的负载分配显得不均匀，并且故障转移所需的时间比运行状况检查建议的时间长。该产品可以工作，但它的工作方式与预期不同——因为它在 DNS 上运行，而不是在传输层或应用程序层上运行。
Cloudflare 负载均衡的实际工作原理
Cloudflare Load Balancing 是一种流量分配服务，可在名称解析时采取操作。当客户端对平衡域进行 DNS 查询时，Cloudflare Authoritative 会评估哪些源运行状况良好，应用配置的转向规则，并返回所选源的 IP。从那时起，客户端直接连接到源，或者连接到 Cloudflare PoP（如果注册是代理的），并且来自该会话的所有请求都会发送到该目的地，直到 TTL 过期并且客户端需要再次解析名称。
这意味着负载分配是通过 DNS 解析而不是通过 HTTP 请求进行的。在同一秒内解析域的两个并发客户端可以分配不同的源。解析一次名称并保持连接打开的单个客户端将无限期地保持在同一源上。如果 ALB 后面运行有 10 个实例，则 ALB 会通过每个新请求在这些实例之间分配请求。对于 Cloudflare LB，粒度是客户，而不是请求。
当源发生故障时，运行状况检查系统会更正路径。 Cloudflare 对每个注册源从多个 PoP（而不是单个点）执行主动运行状况检查。当故障百分比超过配置的阈值时，源将被标记为降级并从解析池中删除。在此标记后解析其名称的新客户端将不再收到有问题的源的 IP。已解析名称并缓存 IP 的客户端将继续尝试连接，直到 TTL 过期。因此，故障转移有两个延迟组成部分：运行状况检查检测和标记故障的时间，以及已解决的客户端的剩余 TTL。
定价模型及其涵盖范围
Cloudflare Load Balancing 基本计划的费用为每月 5 美元，包括两个源池、每个池五个源以及可配置的运行状况检查。每 500,000 个运行状况检查查询 0.50 美元的额外费用适用于检查生成的量 - 间隔为 60 秒并分布在多个 PoP 上，每月的量会快速增长，但对于小型池的主动-被动设置来说仍处于合理范围内。
对于简单的主动-被动设置（具有两个来源的主池和一个后备池），大多数情况下每月的费用低于 10 美元。对于具有多个区域池和每个 PoP 的精细运行状况检查的更复杂的架构，成本会增加，但与管理区域之间的手动故障转移的运营开销相比，仍然具有竞争力。
Geo Steering：按客户的地理来源进行路由
地理转向是将负载均衡器转变为真正的地理路由层的功能。该配置将区域（特定大陆或国家）与源池相关联。巴西客户解析域名并收到源自圣保罗的 IP。欧洲客户收到原产地为法兰克福的IP。 Cloudflare 权威标识发出查询的解析器的地理位置并从相应池返回响应。
当区域池变得不可用时（其中的所有源都标记为降级），Cloudflare 会自动下降到配置的全局后备池。法兰克福矿池位于外部的欧洲客户从圣保罗或任何其他健康的矿池接收 IP，无需人工干预。这种自动回退机制使得地理转向对于地理高可用性非常有用，而不仅仅是延迟优化。
对于同一实例需要跨多个 DNS 解析为同一客户端提供服务的情况，Cookie 会话亲和性补充了地理路由。 Cloudflare 将一个 cookie 注入到标识所选源的 HTTP 响应中，并且负载均衡器使用此 cookie 在后续解析中将客户端返回到同一源，即使 TTL 已过期也是如此。对于无状态应用程序来说，这是无关紧要的；对于在实例内存中存储上下文的会话，它是防止正常 TTL 重新解析期间体验破坏的机制。
改变架构设计的区别
ALB 在第 7 层运行。它接收 TCP 连接、检查 HTTP 标头、应用路径和标头路由规则，并将每个单独的请求分发到后端池的实例。它会看到每个请求。您可以进行基于路径的路由 - 0 转到一组实例，1 转到另一组实例。可以注入或修改标头。如果协议允许，则可以查看请求正文。
Cloudflare LB 看不到单独的请求。它回答 DNS 查询。无法检查路径2，因为该路径甚至不存在于 DNS 层 - 它仅在客户端与源建立 TCP 连接并发送 HTTP GET 后才出现。这并非偶然的限制；这是在该粒度级别上使用错误协议操作的自然结果。
将两者结合起来的模式解决了每一层的不同问题。 Cloudflare LB 负责区域之间的地理路由和故障转移：巴西的客户到达圣保罗，欧洲的客户到达法兰克福，如果圣保罗出现故障，流量会自动迁移。在每个区域内，ALB 或 nginx 在池实例之间分配请求，执行基于路径的路由，并在请求级别管理负载。两者共存并不冲突，因为它们解决堆栈不同层的问题。
运行状况检查对于故障转移 SLA 意味着什么
故障转移的速度取决于三个变量：运行状况检查间隔、将源标记为降级所需的连续失败次数以及 DNS 记录的 TTL。以每 60 秒一次的健康检查一次和连续两次失败为阈值，最坏的检测情况是 120 秒。添加 TTL（代理记录的 TTL 为 60 秒），最大故障转移窗口约为 3 分钟。
减少健康检查间隔可以加快检测速度，但会增加查询量。盈亏平衡点取决于服务可用性 SLA。对于可接受 3 分钟部分故障的系统（检测到死源为零个新客户端提供服务，但具有活动缓存的客户端仍会尝试达到 TTL），默认设置就足够了。对于任何将流量转移到降级源的系统都是不可接受的，低 TTL、短间隔运行状况检查和至少两个并行 PoP 检查的组合在实践中可将窗口缩短至不到 2 分钟。
具有 ALB 背景的团队低估的一点是，当源被标记为降级时，Cloudflare LB 不会删除活动连接。它停止在新的 DNS 解析中返回该 IP。已缓存 IP 的客户端将继续尝试。 TCP 连接超时或应用程序错误是客户端将遇到的情况，直到 TTL 过期并且新的解析返回健康的 IP。实际影响取决于发生故障时拥有新鲜缓存和过期缓存的活动客户端的比例。
另请阅读
- [Cloudflare DNS：远远超出解析名称的网络基础设施3
- [DNS 代理与仅 DNS：有何变化以及每种模式何时有意义4
- [DNSSEC 与 Cloudflare：它保护什么、不保护什么以及如何顺利激活55
- [Cloudflare 电子邮件路由：在您的域上接收电子邮件 - 以及不包括的内容6
- [KV、R2 与 Cache API：何时使用每个 Cloudflare7 存储层
- [Cloudflare KV：当你需要写时，全球分布式意味着什么8