1. 多径路由选择到底在解决什么问题第一次接触“多径路由选择”这个概念是在一个跨区域数据同步的项目里。当时业务方要求把一批文件从三个边缘节点汇总到一个中心节点同时还要保证任意一条链路中断时整体传输不能停。最开始我用的是最朴素的做法配一条主链路再配一条备份链路主链路断了才切到备份。结果实测下来主链路一抖动切换就要花好几秒业务侧直接报超时。后来把思路换成“同时走多条路谁快用谁”问题才真正缓解。这就是多径路由选择要解决的核心场景。说白了多径路由选择指的是在源节点和目的节点之间同时维护两条或两条以上的可用路径并根据实时状态决定流量怎么分配、走哪条、走多少。它和传统的单路径路由最大的区别在于单路径是“选一条最好的”多径是“同时用几条动态调配”。这个思路听起来简单但真正落地时会牵扯到路径发现、路径质量评估、流量分配算法、乱序重组、故障切换等一连串问题。它适合谁来参考我的判断是三类人一是做分布式系统或存储同步的工程师需要跨机房、跨区域传数据二是做实时音视频或直播的开发者对延迟和抖动极其敏感三是做网络架构或运维的同学手里有多条出口链路想榨干带宽又不想手动切来切去。哪怕你只是普通后端开发理解多径路由的思路对设计高可用服务也有直接帮助。我写这篇东西的出发点是把我在几个项目里踩过的坑、试过的方案、算过的参数尽量完整地摊开讲。不会只讲概念而是把“为什么这么选”“参数怎么定”“出问题怎么查”都写清楚。你可以把它当成一份实操笔记遇到类似场景直接抄作业。2. 核心思路与方案选型拆解2.1 为什么不是“主备”而是“多活”主备模式最大的问题是资源浪费和切换延迟。备份链路平时闲着带宽白白浪费主链路一挂切换需要检测、决策、收敛这段时间业务就是不可用的。多径路由选择的核心思路是让多条路径同时处于“活跃”状态流量按某种策略分摊到各条路径上。这样即使某条路径质量下降其他路径仍在承载流量整体不会出现断崖式中断。从实现角度看多径路由选择通常包含四个环节路径发现、路径质量评估、流量分配、故障处理。路径发现负责找出所有可用的下一跳或端到端路径质量评估负责给每条路径打分指标包括延迟、丢包率、带宽、抖动、成本等流量分配根据打分结果决定每条路径分多少流量故障处理负责在路径失效时快速剔除并重新分配。我试过把质量评估做成静态权重也试过做成动态探测。静态权重的优点是简单、稳定缺点是应对突发拥塞能力差动态探测的优点是灵敏缺点是探测本身会带来额外开销而且容易震荡。实测下来比较稳的做法是“慢速动态调整”每隔一个较长周期比如5到10秒更新一次权重避免频繁抖动。2.2 路径质量评估的指标怎么选指标选择直接决定多径路由的效果。我一般会看这几个维度延迟端到端往返时间最直观的指标。适合对实时性敏感的业务。丢包率单位时间内丢失包的比例。丢包高说明链路不稳定。带宽可用吞吐量。适合大文件传输场景。抖动延迟的变化幅度。音视频场景必须关注。成本有些链路按流量计费成本也要纳入权重。不同业务对指标的敏感度完全不同。文件同步更看重带宽和成本实时通话更看重延迟和抖动。所以我在做方案时不会用一个固定公式套所有场景而是给每个指标配一个权重系数业务方可以根据自己的需求调。这里有个容易忽略的点指标采集本身会消耗资源。如果每条路径都高频发探测包探测流量可能占到总流量的百分之几。我的经验是探测频率和业务流量成反比业务流量大时探测可以稀疏一些因为业务流量本身就能反映链路质量业务流量小时探测可以密一些保证及时发现链路变化。2.3 流量分配算法的取舍流量分配算法大致分三类轮询、加权轮询、基于质量的自适应分配。轮询最简单每条路径轮流发一个包。优点是绝对公平缺点是完全不考虑路径质量慢路径会拖累整体。加权轮询给每条路径配一个权重按权重比例分配。比轮询好但权重是静态的链路质量变化时反应慢。自适应分配根据实时质量动态调整权重效果最好但实现复杂度最高。我在一个跨区域同步项目里用的是“加权轮询加动态修正”基础权重按带宽比例设定然后每隔一段时间根据丢包率和延迟做一次修正。修正幅度设了上限比如单次调整不超过原权重的百分之二十防止震荡。这个方案实测下来比纯轮询吞吐提升明显比纯自适应稳定得多。提示流量分配算法没有绝对最优只有最适合当前业务。选型时先问自己三个问题业务对延迟敏感还是对带宽敏感链路质量变化快不快实现复杂度能接受到什么程度2.4 乱序与重组为什么绕不开多径路由有一个天然副作用同一个数据流的不同包走了不同路径到达目的端时顺序可能乱了。如果业务对顺序敏感比如TCP流就必须在目的端做重组。重组需要缓冲区缓冲区大小取决于路径之间的延迟差。延迟差越大需要的缓冲区越大内存开销和重组延迟也越大。我踩过的一个坑是两条路径延迟差达到80毫秒结果重组缓冲区设小了大量包被丢弃重传吞吐反而下降。后来把缓冲区按“最大延迟差乘以带宽”来估算才稳定下来。具体公式是缓冲区字节数等于最大延迟差秒乘以总带宽字节每秒再乘一个安全系数一般取1.5到2。如果业务本身能容忍乱序比如某些UDP应用可以不做重组直接交给上层处理。但大多数场景还是需要重组的所以设计时一定要把这块算进去。3. 核心细节解析与实操要点3.1 路径发现怎么知道有几条路可走路径发现是多径路由的第一步。在传统网络里路径发现靠路由协议在应用层做多径路径发现更多靠配置和探测。我一般分两步走先静态配置候选路径再通过探测确认哪些路径真正可用。静态配置的好处是可控。比如你有三条出口链路就在配置里写三条每条对应一个本地接口或下一跳地址。然后写一个探测任务定期向每条路径发探测包收到回应就标记为可用连续多次收不到就标记为不可用。探测包的设计也有讲究。我通常用ICMP或UDP探测包大小设小一点比如64字节避免探测本身占用太多带宽。探测间隔根据业务敏感度定实时业务可以1秒一次文件同步可以5到10秒一次。超时时间一般设为探测间隔的三倍避免误判。注意探测目标不要只探下一跳最好探到目的端的完整路径。因为下一跳通不代表整条路通中间某段断了下一跳可能还是通的。3.2 质量评估数据怎么采集、怎么平滑质量评估的数据来源有两个主动探测和被动统计。主动探测就是前面说的发探测包被动统计是从实际业务流量里提取延迟、丢包等信息。两者结合最准。主动探测的优点是可控想测什么就测什么缺点是有额外开销而且探测包和业务包的优先级可能不同测出来的结果不一定代表业务体验。被动统计的优点是零开销反映真实业务体验缺点是业务流量小的时候样本不足统计不准。我的做法是业务流量大时以被动统计为主主动探测为辅业务流量小时以主动探测为主。两者数据做加权平均权重根据样本量动态调整。数据平滑也很关键。原始采集的延迟、丢包数据抖动很大直接用来算权重会导致路径频繁切换。我一般用指数加权移动平均来平滑公式是新值等于平滑系数乘以当前采样值加上一减平滑系数乘以旧值。平滑系数取0.2到0.3比较合适太小反应慢太大震荡。3.3 流量分配权重怎么算、怎么调权重计算是流量分配的核心。我一般用加权求和的方式给每个指标配一个权重系数把各指标归一化后加权求和得到一个综合得分再按得分比例分配流量。举个例子假设有两条路径A和B指标包括延迟和丢包率。延迟权重0.6丢包权重0.4。路径A延迟20毫秒丢包率1%路径B延迟40毫秒丢包率0.5%。归一化后路径A延迟得分0.520除以40丢包得分0.331除以3路径B延迟得分1.0丢包得分1.0。加权求和路径A得分0.5乘0.6加0.33乘0.4等于0.432路径B得分1.0乘0.6加1.0乘0.4等于1.0。按得分比例分配路径A分到约30%流量路径B分到约70%。这个例子说明一个反直觉的结论延迟低的路径不一定分到更多流量因为丢包率可能拖后腿。所以指标权重一定要根据业务调不能拍脑袋。权重调整要有阻尼。我一般设一个调整周期比如每5秒调一次每次调整幅度不超过当前权重的20%。这样既能跟上链路变化又不会因为瞬时抖动导致流量剧烈波动。3.4 故障处理怎么快速发现、怎么平滑切换故障处理分两步发现和切换。发现靠探测和被动统计连续多次探测失败或丢包率超过阈值就判定路径故障。切换就是把故障路径的流量重新分配到其他路径上。这里有个细节故障判定不能太灵敏。网络偶尔抖动很正常如果一抖动就判故障会导致路径频繁上下线反而影响稳定。我一般设一个连续失败次数阈值比如连续3次探测失败才判故障恢复也要连续3次成功才判恢复。切换时要注意流量平滑。如果故障路径原本承载50%流量突然全部转移到其他路径其他路径可能瞬间拥塞。我的做法是分步转移比如每次转移10%间隔几百毫秒给其他路径一个缓冲时间。提示故障恢复后不要立刻把流量全部切回来先给一个较小的权重观察一段时间再逐步增加。这样可以避免“刚恢复又挂”的循环。4. 实操过程与核心环节实现4.1 环境准备与基础配置假设我们要在两个节点之间做多径路由节点A和节点B之间有两条可用链路链路1和链路2。节点A有两个出口接口分别对应两条链路。基础配置包括给每个接口配IP、配路由、确认两条链路都能通。在Linux环境下可以用ip route命令配置多路径路由。比如ip route add default scope global nexthop via 192.168.1.1 dev eth0 weight 1 nexthop via 192.168.2.1 dev eth1 weight 1这条命令的意思是默认路由有两个下一跳分别走eth0和eth1权重都是1也就是各承担50%流量。这是最基础的多径配置内核会自动做轮询分配。但内核自带的多径是静态权重不会根据链路质量动态调整。要动态调整需要自己写控制逻辑定期更新路由权重。更新命令类似ip route replace default scope global nexthop via 192.168.1.1 dev eth0 weight 3 nexthop via 192.168.2.1 dev eth1 weight 1这条命令把权重改成3比1也就是eth0承担75%eth1承担25%。4.2 探测脚本怎么写探测脚本的核心是定期向每条路径发探测包记录延迟和丢包。我用Python写过一个简易版思路是对每条路径用ping命令发探测包解析输出提取延迟和丢包率写入一个共享数据结构。import subprocess import re import time def probe(path_ip, count3): result subprocess.run( [ping, -c, str(count), -W, 1, path_ip], capture_outputTrue, textTrue ) output result.stdout loss_match re.search(r(\d)% packet loss, output) rtt_match re.search(rrtt min/avg/max/mdev ([\d.])/([\d.])/([\d.])/([\d.]), output) loss int(loss_match.group(1)) if loss_match else 100 avg_rtt float(rtt_match.group(2)) if rtt_match else 999 return {loss: loss, rtt: avg_rtt} paths { path1: 192.168.1.1, path2: 192.168.2.1 } while True: for name, ip in paths.items(): stats probe(ip) print(f{name}: loss{stats[loss]}%, rtt{stats[rtt]}ms) time.sleep(5)这个脚本每5秒探测一次每次发3个包。实际生产环境里我会把结果写入Redis或共享内存供权重计算模块读取。4.3 权重计算与路由更新权重计算模块定期读取探测数据按前面说的加权求和法算出每条路径的得分再换算成权重最后调用ip route命令更新。def compute_weights(stats): # stats: {path1: {loss: 1, rtt: 20}, path2: {loss: 0.5, rtt: 40}} scores {} for name, s in stats.items(): # 归一化延迟和丢包都是越小越好 rtt_score 1.0 / (s[rtt] 1) loss_score 1.0 / (s[loss] 1) scores[name] 0.6 * rtt_score 0.4 * loss_score total sum(scores.values()) weights {name: max(1, int(score / total * 10)) for name, score in scores.items()} return weights这个函数把得分换算成1到10之间的整数权重避免权重太小导致内核忽略。实际使用时权重范围可以更大比如1到100精度更高。更新路由的命令拼接def update_route(weights): nexthops .join([fnexthop via {paths[name]} dev {devs[name]} weight {w} for name, w in weights.items()]) cmd fip route replace default scope global {nexthops} subprocess.run(cmd, shellTrue)4.4 乱序重组的实现要点如果业务需要保序目的端要做重组。重组的基本思路是给每个包编一个序列号收到包后按序列号排序按序交付给上层。缓冲区用优先队列实现序列号小的先出。import heapq class ReorderBuffer: def __init__(self, max_size10000): self.buffer [] self.next_seq 0 self.max_size max_size def add(self, seq, data): if seq self.next_seq: return None # 重复包丢弃 heapq.heappush(self.buffer, (seq, data)) if len(self.buffer) self.max_size: # 缓冲区满强制推进 _, data heapq.heappop(self.buffer) self.next_seq seq 1 return data return self._drain() def _drain(self): result [] while self.buffer and self.buffer[0][0] self.next_seq: _, data heapq.heappop(self.buffer) result.append(data) self.next_seq 1 return result这个实现比较简单实际生产环境还要考虑超时机制如果某个序列号长时间没到不能一直等要跳过它继续交付否则整个流会被一个丢包卡死。超时时间一般设为最大延迟差的两倍。5. 常见问题与排查技巧实录5.1 路径频繁切换导致性能下降这是最常见的问题。表现是流量在两条路径之间来回跳吞吐忽高忽低。原因通常是质量评估太灵敏或者权重调整幅度太大。排查思路先看探测数据如果延迟和丢包在阈值附近波动说明阈值设得太紧。解决办法是加平滑、加阻尼、加滞回。滞回的意思是判定路径变差和判定路径变好使用不同的阈值比如丢包超过5%判差低于2%才判好中间区域保持原状。我踩过的一个坑是两条路径延迟差只有几毫秒但探测数据抖动有十几毫秒结果权重一直在变。后来把探测次数从3次增加到10次取平均值抖动就小多了。5.2 重组缓冲区溢出表现是吞吐上不去抓包发现大量重传。原因通常是缓冲区太小或者路径延迟差太大。排查思路先测两条路径的实际延迟差然后按公式算所需缓冲区大小。如果延迟差是80毫秒总带宽是10兆字节每秒那缓冲区至少要80毫秒乘10兆字节每秒等于800千字节再乘安全系数1.5就是1.2兆字节。如果实际缓冲区小于这个值就会溢出。解决办法要么加大缓冲区要么减小延迟差比如选延迟更接近的路径要么降低对保序的要求。5.3 某条路径“假活”表现是探测显示路径可用但实际业务流量走这条路径时大量丢包。原因是探测包和业务包的优先级或路径不同。比如探测包走的是管理通道业务包走的是数据通道管理通道通不代表数据通道通。排查思路对比探测数据和业务统计数据。如果探测正常但业务丢包高基本可以确定是“假活”。解决办法是让探测包尽量模拟业务包的特征比如用相同的端口、相同的包大小、相同的优先级。5.4 权重更新不生效表现是改了权重但流量分配没变化。原因可能是内核缓存了路由或者更新命令写错了。排查思路先用ip route show确认路由表里的权重是否真的变了。如果变了但流量没变可能是连接跟踪导致的已有连接仍然走原路径。解决办法是清一下连接跟踪表或者等旧连接自然老化。提示做多径路由时尽量用无状态协议或短连接避免长连接把流量钉死在一条路径上。5.5 常见问题速查表问题现象可能原因排查方法解决办法路径频繁切换评估太灵敏、调整幅度大看探测数据波动加平滑、加阻尼、加滞回吞吐上不去重组缓冲区小、延迟差大测延迟差、算缓冲区加大缓冲区或减小延迟差探测正常但业务丢包探测包与业务包路径不同对比探测与业务统计让探测模拟业务特征权重更新不生效路由缓存、连接跟踪查路由表、查连接跟踪清缓存或等连接老化故障恢复后再次故障恢复太激进看恢复后的质量数据逐步恢复权重观察后再加5.6 几个我踩过的坑第一个坑是探测频率太高。有一次我把探测间隔设成200毫秒结果探测流量占了总带宽的15%业务反而受影响。后来改成2秒一次探测开销降到1%以下效果没差多少。第二个坑是权重粒度太粗。内核支持的权重是整数如果只有两条路径权重只能是1比1、2比1这种调整精度不够。解决办法是增加路径数量或者用应用层负载均衡代替内核多径。第三个坑是忽略上行下行差异。有些链路下行带宽大但上行小如果按下行带宽分配权重上行会拥塞。后来我把上行下行分开评估取较小值作为权重依据问题才解决。第四个坑是没考虑成本。有一次用了按流量计费的链路权重设得高结果月底账单爆了。后来把成本纳入权重计算高成本链路权重压低才控制住。6. 多径路由选择的扩展思路多径路由选择不只能用在网络层应用层同样可以做。比如在微服务架构里一个服务有多个实例客户端可以同时向多个实例发请求谁先返回用谁的结果这就是应用层的多径。再比如CDN场景一个文件有多个源站下载时可以同时从多个源站拉取不同分片最后拼起来这也是多径的思路。我在一个文件同步项目里试过应用层多径把一个大文件切成多个块同时通过三条链路传输每条链路传不同的块目的端收齐后按块号拼接。这个方案比网络层多径更灵活因为可以按块粒度调度不受内核路由限制。缺点是应用层要自己处理块调度、断点续传、完整性校验实现复杂度高一些。另一个扩展方向是多径加多播。如果一份数据要发给多个目的端可以结合多播和多径让不同目的端走不同路径进一步分散压力。这个思路在内容分发场景很有用但实现起来更复杂需要协调多个目的端的路径选择。最后分享一个小技巧做多径路由时先别急着上动态调整先用静态权重跑一段时间观察各路径的实际表现。很多时候静态权重就能满足需求动态调整反而引入不稳定。等静态方案确实不够用了再逐步加动态逻辑这样风险可控也更容易定位问题。我个人在实际操作中的体会是多径路由选择的核心不是算法多复杂而是对业务需求的理解有多深。延迟敏感的业务和带宽敏感的业务方案完全不同链路稳定的场景和链路抖动的场景策略也完全不同。先把业务需求拆清楚再选指标、定权重、调参数比一上来就套公式有效得多。
1. 多径路由选择到底在解决什么问题第一次接触“多径路由选择”这个概念是在一个跨区域数据同步的项目里。当时业务方要求把一批文件从三个边缘节点汇总到一个中心节点同时还要保证任意一条链路中断时整体传输不能停。最开始我用的是最朴素的做法配一条主链路再配一条备份链路主链路断了才切到备份。结果实测下来主链路一抖动切换就要花好几秒业务侧直接报超时。后来把思路换成“同时走多条路谁快用谁”问题才真正缓解。这就是多径路由选择要解决的核心场景。说白了多径路由选择指的是在源节点和目的节点之间同时维护两条或两条以上的可用路径并根据实时状态决定流量怎么分配、走哪条、走多少。它和传统的单路径路由最大的区别在于单路径是“选一条最好的”多径是“同时用几条动态调配”。这个思路听起来简单但真正落地时会牵扯到路径发现、路径质量评估、流量分配算法、乱序重组、故障切换等一连串问题。它适合谁来参考我的判断是三类人一是做分布式系统或存储同步的工程师需要跨机房、跨区域传数据二是做实时音视频或直播的开发者对延迟和抖动极其敏感三是做网络架构或运维的同学手里有多条出口链路想榨干带宽又不想手动切来切去。哪怕你只是普通后端开发理解多径路由的思路对设计高可用服务也有直接帮助。我写这篇东西的出发点是把我在几个项目里踩过的坑、试过的方案、算过的参数尽量完整地摊开讲。不会只讲概念而是把“为什么这么选”“参数怎么定”“出问题怎么查”都写清楚。你可以把它当成一份实操笔记遇到类似场景直接抄作业。2. 核心思路与方案选型拆解2.1 为什么不是“主备”而是“多活”主备模式最大的问题是资源浪费和切换延迟。备份链路平时闲着带宽白白浪费主链路一挂切换需要检测、决策、收敛这段时间业务就是不可用的。多径路由选择的核心思路是让多条路径同时处于“活跃”状态流量按某种策略分摊到各条路径上。这样即使某条路径质量下降其他路径仍在承载流量整体不会出现断崖式中断。从实现角度看多径路由选择通常包含四个环节路径发现、路径质量评估、流量分配、故障处理。路径发现负责找出所有可用的下一跳或端到端路径质量评估负责给每条路径打分指标包括延迟、丢包率、带宽、抖动、成本等流量分配根据打分结果决定每条路径分多少流量故障处理负责在路径失效时快速剔除并重新分配。我试过把质量评估做成静态权重也试过做成动态探测。静态权重的优点是简单、稳定缺点是应对突发拥塞能力差动态探测的优点是灵敏缺点是探测本身会带来额外开销而且容易震荡。实测下来比较稳的做法是“慢速动态调整”每隔一个较长周期比如5到10秒更新一次权重避免频繁抖动。2.2 路径质量评估的指标怎么选指标选择直接决定多径路由的效果。我一般会看这几个维度延迟端到端往返时间最直观的指标。适合对实时性敏感的业务。丢包率单位时间内丢失包的比例。丢包高说明链路不稳定。带宽可用吞吐量。适合大文件传输场景。抖动延迟的变化幅度。音视频场景必须关注。成本有些链路按流量计费成本也要纳入权重。不同业务对指标的敏感度完全不同。文件同步更看重带宽和成本实时通话更看重延迟和抖动。所以我在做方案时不会用一个固定公式套所有场景而是给每个指标配一个权重系数业务方可以根据自己的需求调。这里有个容易忽略的点指标采集本身会消耗资源。如果每条路径都高频发探测包探测流量可能占到总流量的百分之几。我的经验是探测频率和业务流量成反比业务流量大时探测可以稀疏一些因为业务流量本身就能反映链路质量业务流量小时探测可以密一些保证及时发现链路变化。2.3 流量分配算法的取舍流量分配算法大致分三类轮询、加权轮询、基于质量的自适应分配。轮询最简单每条路径轮流发一个包。优点是绝对公平缺点是完全不考虑路径质量慢路径会拖累整体。加权轮询给每条路径配一个权重按权重比例分配。比轮询好但权重是静态的链路质量变化时反应慢。自适应分配根据实时质量动态调整权重效果最好但实现复杂度最高。我在一个跨区域同步项目里用的是“加权轮询加动态修正”基础权重按带宽比例设定然后每隔一段时间根据丢包率和延迟做一次修正。修正幅度设了上限比如单次调整不超过原权重的百分之二十防止震荡。这个方案实测下来比纯轮询吞吐提升明显比纯自适应稳定得多。提示流量分配算法没有绝对最优只有最适合当前业务。选型时先问自己三个问题业务对延迟敏感还是对带宽敏感链路质量变化快不快实现复杂度能接受到什么程度2.4 乱序与重组为什么绕不开多径路由有一个天然副作用同一个数据流的不同包走了不同路径到达目的端时顺序可能乱了。如果业务对顺序敏感比如TCP流就必须在目的端做重组。重组需要缓冲区缓冲区大小取决于路径之间的延迟差。延迟差越大需要的缓冲区越大内存开销和重组延迟也越大。我踩过的一个坑是两条路径延迟差达到80毫秒结果重组缓冲区设小了大量包被丢弃重传吞吐反而下降。后来把缓冲区按“最大延迟差乘以带宽”来估算才稳定下来。具体公式是缓冲区字节数等于最大延迟差秒乘以总带宽字节每秒再乘一个安全系数一般取1.5到2。如果业务本身能容忍乱序比如某些UDP应用可以不做重组直接交给上层处理。但大多数场景还是需要重组的所以设计时一定要把这块算进去。3. 核心细节解析与实操要点3.1 路径发现怎么知道有几条路可走路径发现是多径路由的第一步。在传统网络里路径发现靠路由协议在应用层做多径路径发现更多靠配置和探测。我一般分两步走先静态配置候选路径再通过探测确认哪些路径真正可用。静态配置的好处是可控。比如你有三条出口链路就在配置里写三条每条对应一个本地接口或下一跳地址。然后写一个探测任务定期向每条路径发探测包收到回应就标记为可用连续多次收不到就标记为不可用。探测包的设计也有讲究。我通常用ICMP或UDP探测包大小设小一点比如64字节避免探测本身占用太多带宽。探测间隔根据业务敏感度定实时业务可以1秒一次文件同步可以5到10秒一次。超时时间一般设为探测间隔的三倍避免误判。注意探测目标不要只探下一跳最好探到目的端的完整路径。因为下一跳通不代表整条路通中间某段断了下一跳可能还是通的。3.2 质量评估数据怎么采集、怎么平滑质量评估的数据来源有两个主动探测和被动统计。主动探测就是前面说的发探测包被动统计是从实际业务流量里提取延迟、丢包等信息。两者结合最准。主动探测的优点是可控想测什么就测什么缺点是有额外开销而且探测包和业务包的优先级可能不同测出来的结果不一定代表业务体验。被动统计的优点是零开销反映真实业务体验缺点是业务流量小的时候样本不足统计不准。我的做法是业务流量大时以被动统计为主主动探测为辅业务流量小时以主动探测为主。两者数据做加权平均权重根据样本量动态调整。数据平滑也很关键。原始采集的延迟、丢包数据抖动很大直接用来算权重会导致路径频繁切换。我一般用指数加权移动平均来平滑公式是新值等于平滑系数乘以当前采样值加上一减平滑系数乘以旧值。平滑系数取0.2到0.3比较合适太小反应慢太大震荡。3.3 流量分配权重怎么算、怎么调权重计算是流量分配的核心。我一般用加权求和的方式给每个指标配一个权重系数把各指标归一化后加权求和得到一个综合得分再按得分比例分配流量。举个例子假设有两条路径A和B指标包括延迟和丢包率。延迟权重0.6丢包权重0.4。路径A延迟20毫秒丢包率1%路径B延迟40毫秒丢包率0.5%。归一化后路径A延迟得分0.520除以40丢包得分0.331除以3路径B延迟得分1.0丢包得分1.0。加权求和路径A得分0.5乘0.6加0.33乘0.4等于0.432路径B得分1.0乘0.6加1.0乘0.4等于1.0。按得分比例分配路径A分到约30%流量路径B分到约70%。这个例子说明一个反直觉的结论延迟低的路径不一定分到更多流量因为丢包率可能拖后腿。所以指标权重一定要根据业务调不能拍脑袋。权重调整要有阻尼。我一般设一个调整周期比如每5秒调一次每次调整幅度不超过当前权重的20%。这样既能跟上链路变化又不会因为瞬时抖动导致流量剧烈波动。3.4 故障处理怎么快速发现、怎么平滑切换故障处理分两步发现和切换。发现靠探测和被动统计连续多次探测失败或丢包率超过阈值就判定路径故障。切换就是把故障路径的流量重新分配到其他路径上。这里有个细节故障判定不能太灵敏。网络偶尔抖动很正常如果一抖动就判故障会导致路径频繁上下线反而影响稳定。我一般设一个连续失败次数阈值比如连续3次探测失败才判故障恢复也要连续3次成功才判恢复。切换时要注意流量平滑。如果故障路径原本承载50%流量突然全部转移到其他路径其他路径可能瞬间拥塞。我的做法是分步转移比如每次转移10%间隔几百毫秒给其他路径一个缓冲时间。提示故障恢复后不要立刻把流量全部切回来先给一个较小的权重观察一段时间再逐步增加。这样可以避免“刚恢复又挂”的循环。4. 实操过程与核心环节实现4.1 环境准备与基础配置假设我们要在两个节点之间做多径路由节点A和节点B之间有两条可用链路链路1和链路2。节点A有两个出口接口分别对应两条链路。基础配置包括给每个接口配IP、配路由、确认两条链路都能通。在Linux环境下可以用ip route命令配置多路径路由。比如ip route add default scope global nexthop via 192.168.1.1 dev eth0 weight 1 nexthop via 192.168.2.1 dev eth1 weight 1这条命令的意思是默认路由有两个下一跳分别走eth0和eth1权重都是1也就是各承担50%流量。这是最基础的多径配置内核会自动做轮询分配。但内核自带的多径是静态权重不会根据链路质量动态调整。要动态调整需要自己写控制逻辑定期更新路由权重。更新命令类似ip route replace default scope global nexthop via 192.168.1.1 dev eth0 weight 3 nexthop via 192.168.2.1 dev eth1 weight 1这条命令把权重改成3比1也就是eth0承担75%eth1承担25%。4.2 探测脚本怎么写探测脚本的核心是定期向每条路径发探测包记录延迟和丢包。我用Python写过一个简易版思路是对每条路径用ping命令发探测包解析输出提取延迟和丢包率写入一个共享数据结构。import subprocess import re import time def probe(path_ip, count3): result subprocess.run( [ping, -c, str(count), -W, 1, path_ip], capture_outputTrue, textTrue ) output result.stdout loss_match re.search(r(\d)% packet loss, output) rtt_match re.search(rrtt min/avg/max/mdev ([\d.])/([\d.])/([\d.])/([\d.]), output) loss int(loss_match.group(1)) if loss_match else 100 avg_rtt float(rtt_match.group(2)) if rtt_match else 999 return {loss: loss, rtt: avg_rtt} paths { path1: 192.168.1.1, path2: 192.168.2.1 } while True: for name, ip in paths.items(): stats probe(ip) print(f{name}: loss{stats[loss]}%, rtt{stats[rtt]}ms) time.sleep(5)这个脚本每5秒探测一次每次发3个包。实际生产环境里我会把结果写入Redis或共享内存供权重计算模块读取。4.3 权重计算与路由更新权重计算模块定期读取探测数据按前面说的加权求和法算出每条路径的得分再换算成权重最后调用ip route命令更新。def compute_weights(stats): # stats: {path1: {loss: 1, rtt: 20}, path2: {loss: 0.5, rtt: 40}} scores {} for name, s in stats.items(): # 归一化延迟和丢包都是越小越好 rtt_score 1.0 / (s[rtt] 1) loss_score 1.0 / (s[loss] 1) scores[name] 0.6 * rtt_score 0.4 * loss_score total sum(scores.values()) weights {name: max(1, int(score / total * 10)) for name, score in scores.items()} return weights这个函数把得分换算成1到10之间的整数权重避免权重太小导致内核忽略。实际使用时权重范围可以更大比如1到100精度更高。更新路由的命令拼接def update_route(weights): nexthops .join([fnexthop via {paths[name]} dev {devs[name]} weight {w} for name, w in weights.items()]) cmd fip route replace default scope global {nexthops} subprocess.run(cmd, shellTrue)4.4 乱序重组的实现要点如果业务需要保序目的端要做重组。重组的基本思路是给每个包编一个序列号收到包后按序列号排序按序交付给上层。缓冲区用优先队列实现序列号小的先出。import heapq class ReorderBuffer: def __init__(self, max_size10000): self.buffer [] self.next_seq 0 self.max_size max_size def add(self, seq, data): if seq self.next_seq: return None # 重复包丢弃 heapq.heappush(self.buffer, (seq, data)) if len(self.buffer) self.max_size: # 缓冲区满强制推进 _, data heapq.heappop(self.buffer) self.next_seq seq 1 return data return self._drain() def _drain(self): result [] while self.buffer and self.buffer[0][0] self.next_seq: _, data heapq.heappop(self.buffer) result.append(data) self.next_seq 1 return result这个实现比较简单实际生产环境还要考虑超时机制如果某个序列号长时间没到不能一直等要跳过它继续交付否则整个流会被一个丢包卡死。超时时间一般设为最大延迟差的两倍。5. 常见问题与排查技巧实录5.1 路径频繁切换导致性能下降这是最常见的问题。表现是流量在两条路径之间来回跳吞吐忽高忽低。原因通常是质量评估太灵敏或者权重调整幅度太大。排查思路先看探测数据如果延迟和丢包在阈值附近波动说明阈值设得太紧。解决办法是加平滑、加阻尼、加滞回。滞回的意思是判定路径变差和判定路径变好使用不同的阈值比如丢包超过5%判差低于2%才判好中间区域保持原状。我踩过的一个坑是两条路径延迟差只有几毫秒但探测数据抖动有十几毫秒结果权重一直在变。后来把探测次数从3次增加到10次取平均值抖动就小多了。5.2 重组缓冲区溢出表现是吞吐上不去抓包发现大量重传。原因通常是缓冲区太小或者路径延迟差太大。排查思路先测两条路径的实际延迟差然后按公式算所需缓冲区大小。如果延迟差是80毫秒总带宽是10兆字节每秒那缓冲区至少要80毫秒乘10兆字节每秒等于800千字节再乘安全系数1.5就是1.2兆字节。如果实际缓冲区小于这个值就会溢出。解决办法要么加大缓冲区要么减小延迟差比如选延迟更接近的路径要么降低对保序的要求。5.3 某条路径“假活”表现是探测显示路径可用但实际业务流量走这条路径时大量丢包。原因是探测包和业务包的优先级或路径不同。比如探测包走的是管理通道业务包走的是数据通道管理通道通不代表数据通道通。排查思路对比探测数据和业务统计数据。如果探测正常但业务丢包高基本可以确定是“假活”。解决办法是让探测包尽量模拟业务包的特征比如用相同的端口、相同的包大小、相同的优先级。5.4 权重更新不生效表现是改了权重但流量分配没变化。原因可能是内核缓存了路由或者更新命令写错了。排查思路先用ip route show确认路由表里的权重是否真的变了。如果变了但流量没变可能是连接跟踪导致的已有连接仍然走原路径。解决办法是清一下连接跟踪表或者等旧连接自然老化。提示做多径路由时尽量用无状态协议或短连接避免长连接把流量钉死在一条路径上。5.5 常见问题速查表问题现象可能原因排查方法解决办法路径频繁切换评估太灵敏、调整幅度大看探测数据波动加平滑、加阻尼、加滞回吞吐上不去重组缓冲区小、延迟差大测延迟差、算缓冲区加大缓冲区或减小延迟差探测正常但业务丢包探测包与业务包路径不同对比探测与业务统计让探测模拟业务特征权重更新不生效路由缓存、连接跟踪查路由表、查连接跟踪清缓存或等连接老化故障恢复后再次故障恢复太激进看恢复后的质量数据逐步恢复权重观察后再加5.6 几个我踩过的坑第一个坑是探测频率太高。有一次我把探测间隔设成200毫秒结果探测流量占了总带宽的15%业务反而受影响。后来改成2秒一次探测开销降到1%以下效果没差多少。第二个坑是权重粒度太粗。内核支持的权重是整数如果只有两条路径权重只能是1比1、2比1这种调整精度不够。解决办法是增加路径数量或者用应用层负载均衡代替内核多径。第三个坑是忽略上行下行差异。有些链路下行带宽大但上行小如果按下行带宽分配权重上行会拥塞。后来我把上行下行分开评估取较小值作为权重依据问题才解决。第四个坑是没考虑成本。有一次用了按流量计费的链路权重设得高结果月底账单爆了。后来把成本纳入权重计算高成本链路权重压低才控制住。6. 多径路由选择的扩展思路多径路由选择不只能用在网络层应用层同样可以做。比如在微服务架构里一个服务有多个实例客户端可以同时向多个实例发请求谁先返回用谁的结果这就是应用层的多径。再比如CDN场景一个文件有多个源站下载时可以同时从多个源站拉取不同分片最后拼起来这也是多径的思路。我在一个文件同步项目里试过应用层多径把一个大文件切成多个块同时通过三条链路传输每条链路传不同的块目的端收齐后按块号拼接。这个方案比网络层多径更灵活因为可以按块粒度调度不受内核路由限制。缺点是应用层要自己处理块调度、断点续传、完整性校验实现复杂度高一些。另一个扩展方向是多径加多播。如果一份数据要发给多个目的端可以结合多播和多径让不同目的端走不同路径进一步分散压力。这个思路在内容分发场景很有用但实现起来更复杂需要协调多个目的端的路径选择。最后分享一个小技巧做多径路由时先别急着上动态调整先用静态权重跑一段时间观察各路径的实际表现。很多时候静态权重就能满足需求动态调整反而引入不稳定。等静态方案确实不够用了再逐步加动态逻辑这样风险可控也更容易定位问题。我个人在实际操作中的体会是多径路由选择的核心不是算法多复杂而是对业务需求的理解有多深。延迟敏感的业务和带宽敏感的业务方案完全不同链路稳定的场景和链路抖动的场景策略也完全不同。先把业务需求拆清楚再选指标、定权重、调参数比一上来就套公式有效得多。
