做网络架构这些年，我收到最多的求助消息不是“设备宕机了”，而是“视频会议卡成幻灯片”“ERP登录转圈”“总部复制个文件像在拨号”。排查下来往往发现一个共性现象：带宽本身并没有跑满，甚至还有一大半闲置，但关键业务就是被普通流量挤得没法走。问题出在哪里？传输架构没有把需求分级、资源规划和路由策略放在一张图里设计，各做各的，自然一到高峰就互相打架。
这篇内容适合正在被多分支互联、混合办公、业务上云搞得焦头烂额的网络运维人员和架构师。解决的核心问题是：在不多花钱买带宽的前提下，怎么通过一套一体化的传输架构，让关键业务优先走、让每条链路物尽其用、让扩容决策有数据支撑。下面我就按自己的实操经验，把这个架构从设计到落地完整拆一遍。
1. 整体设计思路：为什么非要“一体化”不可
1.1 先看痛点：单点优化为什么总是翻车
我见过不少企业，花大价钱上了很贵的核心路由器，也配了QoS，但效果依然很差。原因很典型：只在出口设备上做了队列调度，但没人回答“哪些流量需要进高优先级队列”；或者做了队列，但链路资源规划不合理，高优先级流量保障带宽加起来超过物理带宽，调度时照样互相挤压；再或者需求分级和路由策略完全脱节，知道视频会议重要，可流量还是走了又远又堵的备份链路。
传输架构一旦被拆成独立的“带宽规划”“QoS配置”“路由策略”三个项目，必然出现各自为政。网络团队按链路利用率扩容，安全团队按端口开策略，业务团队只在意好不好用，最后的结果就是钱花了，问题原封不动。
1.2 三个模块的职责划分
一体化架构不是把三个名词拼在一起，而是让它们各司其职、相互约束。先把边界划清楚：
| 模块 | 核心问题 | 关键动作 | 典型载体 |
|---|---|---|---|
| 需求分级 | 谁的流量重要 | 识别业务、打标记、分队列 | DSCP、ACL、类映射 |
| 资源规划 | 每条链路能给多少 | 带宽测算、容量预留、余量设计 | 带宽清单、监控数据、保护带宽 |
| 路由策略 | 流量该走哪条路 | 路径选择、引流、负载分担 | PBR、路由协议策略、等价路由 |
需求分级是上层建筑，回答“优先级怎么定义”；资源规划是中层预算，回答“每条链路能承诺多少”；路由策略是执行层，回答“对应流量走哪条物理路径”。三者必须形成单向依赖关系：分级结果决定资源承诺，资源承诺约束路由选择。这样整个传输架构才能从“尽力而为”变成“按需供给”。
1.3 为什么不能只靠“加带宽”解决问题
很多人第一反应是：带宽不够就加钱升专线。但这样做有三个问题。第一，成本不可控，尤其是跨地域、跨运营商的链路，带宽价格指数级上升；第二，带宽再大也有拥塞点，出口设备、防火墙、无线控制器往往先于链路形成瓶颈；第三，纯扩容解决不了“多链路利用率不均”，两条100M电路有一条常年闲置、有一条拥塞掉包，这是负载分担策略的问题，不是容量问题。
我做过的项目里，最成功的一次改造是在带宽不变的前提下，通过需求分级加策略路由，把备份流量从慢速但昂贵的专线挪到便宜的互联网链路，同时给视频会议让出专线保障带宽。结果是用户感知的网络质量大幅提升，月度线路费用还降了。带宽是兜底，控制面才是传输架构的灵魂。
2. 需求分级：一体化架构的地基
2.1 业务分级模型怎么建
需求分级的第一步不是配设备，而是把企业业务盘一遍。我通常分成四级五类模型，适配绝大多数中小型企业和集团型公司：
| 优先级 | 级别名称 | 典型业务 | 流量特征 | 丢失容忍度 |
|---|---|---|---|---|
| P0 | 实时交互 | 视频会议、语音、远程桌面 | 低带宽、低时延、低抖动 | 极低，掉包超1%体验崩 |
| P1 | 核心生产 | ERP、数据库、OA审批、API调用 | 中小包、时延敏感 | 低，超时会造成业务中断 |
| P2 | 普通办公 | 网页浏览、邮件、文件共享 | 突发性强、平均带宽较大 | 中等，可容忍短暂变慢 |
| P3 | 批量传输 | 备份同步、大数据上传、下载更新 | 大流量、持续时间长 | 高，慢一点没影响 |
| P4 | 可损娱乐 | 视频点播、个人网盘、非工作应用 | 大流量、无规律 | 极高，可直接丢弃 |
这个模型和业务部门的认知对齐非常重要。我建议分级表确定后，发邮件给各业务负责人确认，尤其是P0和P1这两级。因为在后续的设计里，P0会占用严格优先队列，P1会拿到带宽保障承诺，这些都会直接影响资源分配。
2.2 DSCP标记与队列设计：从业务到设备的翻译过程
业务分完级，接下来是把级别翻译成网络设备能识别的语言。这里我统一采用DSCP标记，因为主流厂商的设备都支持，且三层网络上可跨设备传递。
以常见的企业级设备CLI为例，标记和队列的对应关系可以这样配：
# 1. 定义类，匹配业务流量 class-map match-any VIDEO match ip dscp ef class-map match-any CORE_ERP match access-group name ERP_SERVICES # 2. 定义策略，绑定队列和带宽参数 policy-map TRANSPORT_POLICY class VIDEO priority percent 20 # 严格优先队列，预留20%带宽 set dscp ef class CORE_ERP bandwidth remaining percent 30 random-detect dscp-based # 启用WRED，AF41比AF43更不易丢包 set dscp af41 class BULK bandwidth remaining percent 10 set dscp af11 class class-default fair-queue需要特别解释两个关键选择：为什么视频会议用priority而ERP只用bandwidth？因为priority是严格优先队列，只要链路有带宽，就先满足它，这符合实时业务对“绝对优先”的需求。但严格优先队列不能给太大比例，否则会饿死其他业务，所以我把P0整体限制在20%以内。为什么ERP要用WRED（加权随机早丢弃）？因为TCP业务在发生拥塞时，丢包触发TCP重传反而能起到退避作用，而AF41、AF43这些子级别可以让重要的数据包比次要的数据包丢得少，这是生产业务在拥塞下保持连接不断的关键。
2.3 分级落地的配套动作：信任边界和重标记
一开始做分级最容易踩的坑是“全链路都信任终端设备的标记”。Windows或Linux主机上的应用是可以自己设置DSCP的，如果无条件信任，业务方随手改个注册表就能把自己流量标成EF，直接把队列打爆。所以必须明确信任边界。
我的做法是：接入交换机连接PC的端口上，把所有入方向DSCP清零，统一在汇聚交换机或者核心设备上按业务网段和应用端口重新标记；只有IP电话、视频会议终端这类受控设备，才保留自身的标记。这个思路写在配置上就两行，但能避免后面90%的“优先级泛滥”问题。
配套工作还包括：在链路的双向上都要做队列调度，因为视频会议的丢包可能发生在回程方向；如果中间有MPLS或者SD-WAN隧道，要确认隧道封装后DSCP是否被复制到外层IP头，否则公网运营商不认你的标记，优先级跨段就失效了。
3. 资源规划：把带宽预算算到每一类流量头上
3.1 带宽测算：平均数和峰值都不能信
资源规划的前提是“你到底需要多少带宽”。直接看线路平均利用率去扩容是外行做法，因为平均值掩盖了所有瞬时拥塞问题。我自己的测算方法是分业务、分时段取值，把每一项需求加总，再乘一个突发系数。
拿一个1000人规模的企业总部举例，按典型业务拆：
| 业务类型 | 并发规模 | 单流带宽 | 合计需求 |
|---|---|---|---|
| 视频会议 | 40路并发 | 2Mbps/路 | 80Mbps |
| ERP/数据库 | 300用户 | 0.2Mbps/人 | 60Mbps |
| Web/邮件办公 | 600用户 | 0.5Mbps/人 | 300Mbps |
| 分支文件同步 | 8个分支 | 5Mbps/分支 | 40Mbps |
| 夜间备份（错峰） | 1条 | 50Mbps | 50Mbps（不计入白天） |
白天业务合计480Mbps，考虑到办公流量的突发特性，我通常再留20%到30%的余量，也就是说互联网出口或者运营商专线至少要按600Mbps来规划。这里有一个经验值：并发用户数和总员工数是两个概念，办公类流量并发系数取0.5到0.7比较合理。
3.2 多链路场景下的容量预留与保护带宽
多条链路并存时，资源规划的逻辑要变成“每条链路分别算账”。比如总部有两条运营商线路，一条专线（低时延、贵）跑生产，一条普通宽带（便宜）跑办公和备份。这时要算的是：专线的带宽保障能不能覆盖所有P0和P1业务？如果不能，要么降低P1的承诺，要么给备份业务设计另一个通道。
我常用的设计原则是：把队列调度里各类业务保障带宽的总和，控制在物理链路带宽的80%以内。为什么不是100%？因为队列调度、TCP重传、广播突发都会消耗实际带宽，留出20%作为系统冗余，否则一旦出现白噪声突发，所有队列都会因为超额排队而集体延迟。一个具体测算例子是，100M专线承载视频会议+ERP，保障带宽设为priority 20M + bandwidth 40M = 60M，剩余40M留给办公和未知流量，线路负载即使到80%，生产业务依然有充足资源。
3.3 突发与缓冲：带宽规划管不住的那部分
需求分级和资源规划能解决“持续拥塞”，但解决不了“瞬时突发”。比如早上九点所有人同时登录OA，或者市场部群发一个200MB的附件，瞬间流量可能是平均带宽的十倍。这时带宽预算再准也没用，必须靠设备队列的缓冲能力吸收突发。
所以资源规划要带上缓冲设计。对关键业务队列，我建议把queue-limit也就是队列深度调大一点，同时在P1队列上启用WRED而不是简单的尾部丢弃，让TCP流量在队列快满时主动降速，而不是一次性把队列塞爆。这里有个监控指标非常好用，接口的discard计数。如果丢包全部集中在P3和P4队列，说明规划是健康的；如果P1队列也丢包，说明要么带宽保障超标，要么突发缓冲不足，需要针对性地调。
4. 路由策略：让流量按照“约定”走向既定链路
4.1 先把概念捋清楚：路由策略和策略路由是两码事
很多刚接触的人会把“路由策略”和“策略路由(PBR)”混为一谈，但它们作用的对象完全不同。我用最直白的话解释一遍：
| 对比项 | 路由策略（Route-Policy / Route-Map） | 策略路由（Policy-Based Routing） |
|---|---|---|
| 作用对象 | 路由表条目 | 数据报文 |
| 生效时机 | 路由学习、发布、重分发时 | 报文转发前，先于路由表查询 |
| 典型动作 | 过滤路由、修改metric、设置community | 强制指定下一跳、指定出接口、打标记 |
| 类比 | 决定“地图上要不要画这条路” | 决定“这辆车必须走这条路” |
举一个实际场景：公司有两条互联网线路，一条电信、一条联通。路由策略可以做的是，从电信学来的路由设置高优先级，让默认流量优先走电信；PBR可以做的则是，无论路由表怎么写，只要检测到源地址是视频会议网段，一律从联通那条低延迟链路出去。两者互补，不能互相替代。
4.2 PBR策略路由的配置实战
下面这套配置是我在总部核心设备上真实用过的简化版。需求背景：总部两条出口，GE0/0/1接低时延专线，GE0/0/2接普通互联网。业务要求：视频会议走专线，备份流量不要走专线，主动改走普通互联网。
# 1. 定义需要识别的流量 ip access-list extended MATCH_VIDEO permit ip any any dscp ef ip access-list extended MATCH_BULK permit tcp any any eq 873 # rsync备份端口 permit tcp any any eq 445 # 文件共享大流量 # 2. 定义策略路由 route-map PBR_TRANSIT permit 10 match ip address MATCH_VIDEO set ip next-hop 192.168.1.254 # 专线网关 set ip precedence urgent route-map PBR_TRANSIT permit 20 match ip address MATCH_BULK set ip next-hop 192.168.2.254 # 互联网网关 route-map PBR_TRANSIT permit 30 set ip next-hop 192.168.2.254 # 其余默认走互联网 # 3. 应用到入接口方向 interface GigabitEthernet0/0/0 ip policy route-map PBR_TRANSIT这里有三个关键经验。第一，PBR一定要应用在流量的入接口方向，也就是内网核心交换机连上来的那个口，方向配反了策略完全不生效。第二，set ip next-hop比set interface更可靠，因为接口可能会down，而下一跳地址只要有路由就能继续转发，但要注意下一跳地址必须和路由器直连。第三，route-map里的permit 30是兜底，否则没有match的流量不走任何策略，会直接走正常路由表，可能又绕回专线，那前面两条规则就白做了。建议给PBR也加上一个no-match动作的兜底条目，避免漏网流量破坏整体设计。
4.3 路由协议侧的协同：静态优先级与BGP属性
纯PBR解决的是“单点引流”，但一旦链路断了怎么办？这时必须让动态路由协议来兜底。我的设计是：专线链路在路由协议里宣告的metric更优，正常时所有流量天然倾向走专线；PBR再按业务需求把特定流量“拉”到其他链路。当专线链路故障时，动态路由自动收敛，把默认路由切到互联网线路，PBR里指向专线下一跳的条目因为下一跳不可达而失效，流量自然回到路由表正常转发。
用BGP场景举个例子：分支和总部建立BGP，我们想引导总部的下行业务不要走某一条质量差的路径，可以通过community标记：
route-policy SET_LOCAL_PREF permit node 10 if community matches-any 65001:100 then apply local-preference 200 endif这样BGP会根据local-preference选择更优路径，实现比静态路由更灵活的流量调度。不过在大多数企业内网场景，静态路由加PBR的组合已经够用，BGP属性控制更多用于多分支、多云互联的复杂场景，不建议一开始就上。
5. 三层联动：需求分级、资源规划、路由策略如何拧成一股绳
5.1 建立一张全局映射表：从业务到路径的完整链条
一体化架构最后一定要落到一张映射表上。我每次做设计都会画一张表格，把业务、DSCP、队列行为、带宽承诺、优选路径全部对应起来：
| 业务 | DSCP | 队列行为 | 带宽保障 | 首选路径 | 备选路径 |
|---|---|---|---|---|---|
| 视频会议 | EF | 严格优先 | 专线20% | 低时延专线 | 互联网（受限） |
| ERP/数据库 | AF41 | 带宽保障+WRED | 专线40% | 低时延专线 | 互联网 |
| 普通办公 | AF21 | 公平调度 | 互联网60% | 负载均衡 | 互联网 |
| 备份传输 | AF11 | 尽力而为 | 互联网30% | 互联网 | 专线（夜间） |
这张表的价值在于，它可以作为网络变更评审的统一口径。业务方问“我的系统为什么变卡了”，查这张表看它的业务落在哪一级、走了哪条路径，就能快速定位是队列问题、路径问题还是容量问题，而不需要每次从头排障。
5.2 上线后怎么验证：队列统计、抓包和端到端指标
配置写完不等于生效。我每次做传输架构改造，验证一定是分三层做的。第一层看队列和接口统计：在核心设备上用命令查接口队列的packet/bit计数，确认EF队列有流量进去且没有被丢弃，确认P1队列的bandwidth利用率没有持续顶满。第二层抓包验证DSCP标记：在核心设备上镜像端口，抓取不同业务的报文，确认视频流量带着EF标记，备份流量带着AF11标记，标记错了后面所有策略都是空谈。第三层做端到端业务验证：视频会议拨测、ERP事务耗时、大文件传输速率，分别在上线前后各测一轮，用数据说话。
5.3 常见问题与排查技巧实录
| 现象 | 排查思路 | 解决方案 |
|---|---|---|
| 标记配了但抓包看不到 | 信任边界未生效，终端重写了DSCP | 接入交换机入口清标记，汇聚按业务网段重标记 |
| 视频会议依然卡顿 | PBR没有命中或下一跳失效 | 查看route-map匹配计数；确认下一跳路由可达；检查PBR接口方向 |
| 普通办公变慢 | 保障带宽总和超过80%链路容量 | 重新测算，压缩P3/P4比例，保证总承诺≤80% |
| 备份流量仍占满专线 | 策略路由没覆盖备份源网段 | 完善ACL匹配条件，确认备份服务器地址段和端口 |
| 队列配置后无任何区分效果 | 出接口和入接口方向混了 | 标记在入方向做，队列调度在出方向做，两端都要有 |
5.4 一个容易被忽视的细节：PBR和QoS的生效顺序
在实际转发流程里，PBR的执行优先于QoS队列调度。也就是说，报文到达路由器后，先查有没有匹配的PBR条目，有就按策略指定的路径转发；没有才进入正常路由表查询，然后再进入出接口的队列调度。这个顺序决定了设计上的一件事：PBR负责“把对流量送到对的链路”，QoS负责“在链路上给对流量分配对的资源”。两者是接力关系，不是替代关系。如果只做PBR不做QoS，备份流量被引到互联网链路后照样能和办公流量抢带宽；如果只做QoS不做PBR，视频会议和备份都挤在专线上，队列调度只能保障视频在专线内部优先，但专线容量有限，整体效果依然打折。
6. 最后再分享一点我的实际体会
做传输架构改造最忌讳一上来就铺开所有功能。我踩过几次坑之后，总结出一套稳妥的落地顺序：先上需求分级和监控，让所有业务流量带着DSCP标记跑两周，期间只观察不干预；然后逐步开启队列调度，边开边看队列统计，确认没有业务被饿死；最后才是PBR精细引流，每一步都有数据兜底。
如果让我给一个最实用的建议，那就是把DSCP标记和抓包验证做成常态化手段，而不要只在项目上线时做一次。传输架构的衰变是缓慢的，新业务不断上线、老业务不断变化，今天合理的分级表三个月后可能已经完全走样。定期对照流量分布和业务重要性做一次校准，比任何花哨的自动化工具都管用。架构是设计出来的，更是养出来的。
