可编程数据平面虽让运营商受益于精细遥测、厂商受益于软件开发加速，但用户层面的收益仍未被充分挖掘。当前可编程设备仍沿用固定功能设备的转发抽象——匹配 IP 地址、递减 TTL、转发至下一跳，与现代分布式应用期望的服务级抽象存在根本错位。
容器化场景下的地址路由困境：
容器化部署加剧了地址路由的不适配。同一宿主机上的容器可能共享地址，容器迁移会导致地址变更，传统基于地址的路由难以直接支撑。运营商被迫引入标识符定位地址（ILA）等标识符路由方案，必须在转发前插入名称解析步骤，增加了网络栈的复杂度。
中间件与中间盒的性能代价：
负载均衡与消息中间件成为另两大痛点。数据中心依赖 Google Maglev、Facebook Katran 等专用中间盒将 IP 报文映射到服务端点；大数据系统则依托 TIBCO Rendezvous、Apache Kafka、IBM MQ 等消息中间件实现组件解耦。这些中间层虽掩盖了地址通信细节，却将吞吐率限制在服务器级的 Gbps，远低于 ASIC 可达的 Tbps 级别，同时推高运维成本并成为频发故障源。原文未给出具体故障率数据。
可编程数据平面的潜在突破口：
既然可编程设备已存在，核心问题在于能否将服务级抽象直接下沉到数据平面。若可在 ASIC 上原生实现标识符路由、服务发现、负载均衡等逻辑，就能消除中间盒带来的性能损耗与运维负担。但当前可编程数据平面仍停留在传统转发抽象层面，未提供面向应用的高层原语，这正是下一步演进的关键方向。
对网络工程师而言，关键不在于部署更多中间盒，而在于评估可编程交换机是否已具备在数据平面直接表达服务语义的能力——这将决定下一代数据中心网络能否在 Tbps 吞吐下原生支撑容器化、微服务与大数据负载。
原文: APNIC Blog（2021-03-26）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog