云基础设施负载均衡交通路由联网DevOps

动态流量路由与固定请求路由

动态流量路由会根据服务器健康状况、延迟和负载实时调整请求路径，而固定请求路由则无论情况如何变化，都会将所有请求发送到预先设定的目标地址。这两种方法在现代云系统的弹性、可扩展性和运维复杂性方面存在显著差异。

亮点

动态路由可在几秒钟内对后端健康状况做出反应，而固定路由则等待手动更新。
固定路由方式要简单得多，但服务器发生故障时无法自动切换。
动态系统能够通过将流量转移到更健康的节点，在负载不均衡的情况下优雅地扩展。
基于地理位置和延迟的路由本质上是动态流量管理所独有的。

动态流量路由是什么？

一种能够根据服务器状况、网络延迟和跨多个后端的流量负载进行实时请求分发的方法。

通过主动和被动探测持续监控后端健康状况，并在几秒钟内将路由从故障节点转移出去。
使用加权轮询、最少连接数和一致性哈希等算法来智能地平衡负载。
通常通过负载均衡器实现，例如 AWS ALB、NGINX Plus、HAProxy 和 Envoy 代理。
支持基于地理位置和延迟的路由，将用户引导至最近或速度最快的可用区域。
可以与 Istio 和 Linkerd 等服务网格平台集成，实现细粒度、策略驱动的流量控制。

固定请求路由是什么？

一种静态请求分发方法，其中每个传入的请求都会被发送到预定义的目的地，而无需运行时调整。

路由可以通过手动配置或 DNS 记录进行配置，DNS 记录一旦设置就很少更改，因此其行为具有高度可预测性。
通常依赖于简单的轮询 DNS 或应用程序配置文件中硬编码的 IP 地址。
需要人工干预才能将不健康的服务器从轮换中移除，通常是通过配置更新来实现。
常见于传统系统、小规模部署以及流量模式稳定、可预测的环境中。
缺乏对实时健康检查的原生支持，因此故障的后端可能仍会接收流量，直到手动移除为止。

比较表

功能	动态流量路由	固定请求路由
路由决策时间	实时，按需	配置时
健康检查支持	内置主动和被动探测功能	手动或无
负荷适应	自动扩容和再平衡	静态分布
故障恢复	秒级自动故障转移	需要人工干预
配置复杂度	较高的初始设置	简单明了
地理意识	延迟和基于地理位置的策略	通常区域固定
典型应用案例	微服务、全球SaaS、电子商务	内部工具、遗留应用程序、小型网站
实施成本	由于工具和监控成本较高	更低，通常免费，使用 DNS 服务。

详细对比

每种方法如何做出路由决策

动态流量路由会根据后端当前的状况评估每个传入请求，并基于响应时间、活跃连接数和 CPU 负载等实时指标选择目标地址。相比之下，固定请求路由则在设置时一次性做出路由决策，并将其统一应用于所有流量。这种根本性的差异决定了从故障处理方式到系统在不可预测的需求下扩展能力等方方面面。

弹性和容错性

在动态路由架构中，当后端服务器宕机时，负载均衡器会通过健康检查检测到故障，并几乎立即停止向该节点发送流量。而固定路由则不具备这种故障感知能力，因此请求可能会持续攻击已宕机的服务器，直到有人发现并更新配置为止。对于关键任务型应用而言，自动故障转移方面的这种差距往往是决定两种方案优劣的关键因素。

可变负载下的可扩展性

当流量高峰在不同区域或服务间分布不均时，动态路由系统优势显著，因为它们可以动态地将负载转移到更健康或负载较低的后端。而固定路由则不考虑服务器的实际负载情况，平均分配流量，这可能导致某些节点过载而其他节点闲置。因此，动态路由更适合全天横向扩展的云原生工作负载。

运营复杂性和成本

设置动态路由需要投资负载均衡软件或托管服务，配置健康检查，并维护可观测性工具来辅助路由决策。固定路由则简单得多，通常只需要一条 DNS A 记录或一个配置文件条目，从而降低了运维开销。但这种简单性是以牺牲灵活性为代价的，一旦发生故障，团队可能需要为此付出代价。

最佳拟合方案

动态流量路由是微服务架构、全球SaaS平台以及任何正常运行时间和性能直接影响收入的系统的标准选择。固定请求路由在流量模式稳定且负载均衡器成本不合理的较小型应用程序、内部工具和传统环境中仍然占有一席之地。许多组织实际上同时运行这两种路由方式，对非关键服务使用固定路由，对面向客户的端点使用动态路由。

优点与缺点

动态流量路由

优点

+ 自动故障转移
+ 实时负载均衡
+ 地理感知路由
+ 随需求变化

继续

− 更高的初始成本
− 更复杂的配置
− 需要监控工具
− 轻微的延迟开销

固定请求路由

优点

+ 配置简单
+ 运营成本低
+ 可预测的行为
+ 无需额外工具

继续

− 无自动故障转移
− 忽略服务器健康状况
− 在不均匀负载下性能较差
− 需要手动缩放

常见误解

神话

固定路由总是更便宜，因为它不需要负载均衡器。

现实

虽然固定路由可以避免负载均衡器的费用，但后端故障导致的停机成本往往会远远超过这些节省。对于一个中型电商网站来说，仅仅一小时的停机就可能造成数千美元的损失，因此动态路由的故障转移功能绝对值得投资。

神话

动态路由会增加过多的延迟，因此不适用于对性能要求很高的应用。

现实

现代负载均衡器会增加几微秒的开销，但这与将用户路由到最近或最稳定的后端所节省的延迟相比可以忽略不计。在大多数情况下，动态路由实际上可以缩短端到端响应时间。

神话

对于全球应用来说，基于 DNS 的固定路由与动态路由一样好。

现实

DNS 路由存在 TTL 延迟，可能需要几分钟甚至几小时才能传播，而且客户端通常会积极缓存 DNS 查询结果。动态路由决策则在请求时做出，从而能够更准确、更即时地控制流量分配。

神话

动态路由设置完成后，就无需再进行任何更改。

现实

动态路由系统需要随着流量模式的演变，不断调整健康检查阈值、权重算法和路由策略。它们可以减少人工干预，但并不能完全消除运维人员的关注。

神话

固定路由已经过时，没人再用了。

现实

在流量可预测且负载均衡器成本不合理的内部工具、小型企业网站和传统企业系统中，固定路由仍然很常见。它并非过时，只是更适合特定的应用场景。

常见问题解答

动态请求路由和固定请求路由的主要区别是什么？

核心区别在于路由决策的做出时间。动态路由会在每个请求时评估后端状况并实时调整路径，而固定路由则在配置时一次性做出决策并应用于所有流量。这会影响到从故障转移速度到各自处理流量高峰的能力等方方面面。

哪种路由方式更适合微服务？

动态流量路由显然是微服务架构的最佳选择，因为它能够根据服务健康状况、实例负载甚至请求头进行路由。Istio 和 Linkerd 等服务网格工具正是围绕动态路由概念构建的，因此对于管理数十甚至数百个独立服务至关重要。

能否在同一个系统中结合动态路由和固定路由？

是的，许多组织采用混合方法，其中固定路由处理非关键的内部流量，而动态路由管理面向客户的端点。您还可以在区域级别使用固定 DNS 路由，并在每个区域内进行动态负载均衡，以实现分层控制。

动态路由对服务器故障的反应速度如何？

大多数现代负载均衡器通过主动健康检查在 2 到 10 秒内检测到故障，然后立即停止向不健康的后端发送流量。被动健康检查通过实时监控实际请求错误率，反应速度更快。

云环境中是否仍然使用固定路由？

固定路由在云环境中仍然存在，尤其适用于简单的工作负载、内部 API 和尚未现代化改造的遗留应用程序。然而，大多数云原生架构默认使用动态路由，例如通过 AWS ALB、Azure 负载均衡器或 GCP 负载均衡器等服务实现的路由。

动态路由器使用哪些算法来分配流量？

常用算法包括轮询、加权轮询、最少连接数、最短响应时间、IP哈希和一致性哈希。更高级的系统使用机器学习模型来预测负载并据此进行路由，尽管这些模型在生产环境中仍然相对少见。

动态路由是否适用于容器编排平台？

当然。例如，Kubernetes 使用 Service、Ingress 控制器和服务网格进行动态路由，从而在各个 Pod 之间分配流量。当 Pod 进行扩容或缩减时，路由层会自动更新，无需手动配置。

动态路由与固定路由相比成本是多少？

托管负载均衡服务通常按小时计费，外加每GB处理数据量的费用，对于高流量应用来说，这笔费用可能相当可观。像NGINX或HAProxy这样的自托管解决方案虽然免费，但需要投入工程时间来设置和维护。使用DNS的固定路由除了标准的DNS托管费用外，基本上是免费的。

动态路由能否帮助实现蓝绿部署？

是的，动态路由非常适合蓝绿部署和金丝雀部署，因为您可以使用加权路由规则在不同版本之间逐步切换流量。这样，您可以在全面发布之前，先用一小部分用户测试新版本，从而降低部署失败的风险。

如果动态路由器本身发生故障会发生什么？

这确实是一个值得关注的问题，因此生产环境部署通常会在多个可用区中以高可用性对的形式运行负载均衡器。云服务提供商会自动处理这种情况，而自托管环境则需要冗余实例和故障转移机制，以避免出现单点故障。

裁决

当正常运行时间、性能和自动故障转移至关重要时，请选择动态流量路由，尤其适用于流量波动较大的面向客户的应用。对于流量较低、结构简单的内部系统，如果简单性和最低基础设施成本比实时适应性带来的优势更为重要，则应坚持使用固定请求路由。