4. SDK与开放生态概览
Broadcom交换芯片本身只是硅片，真正让芯片变成可交付产品的，是它上面那一层层的软件接口与生态。理解 OpenNSL、SAI、SONiC、OpenSwitch 这些名字，关键不是记住缩写，而是搞清楚它们各自处在软件栈的哪一层、解决什么问题、又不解决什么问题。选型时最常见的错误，是把不同层次的东西放在一起比较，比如拿 SAI 和 SONiC 比“谁更开放”，这就像拿插座标准去比整栋楼的供电系统。
先建立分层视角：从芯片到业务
从下往上看，最贴近芯片的是 SDK（Software Development Kit），Broadcom 的 SDK 提供对表项、计数器、端口、调度器等硬件资源的直接操作。再往上是抽象接口层，OpenNSL 和 SAI 都属于这一层，但定位不同：OpenNSL 更接近“把 SDK 能力以 C API 形式暴露出来”，SAI 则是“用统一的交换机抽象接口屏蔽不同芯片厂商差异”。再往上是网络操作系统，SONiC 和 OpenSwitch 属于这一层，它们消费 SAI 这类接口，向上提供路由、ACL、VLAN、Telemetry 等网络功能。最上面才是用户看到的 CLI、REST、gNMI 等管理面。
OpenNSL：把 SDK 能力“薄薄地”包一层
OpenNSL 的定位是让不直接使用 Broadcom 私有 SDK 的开发者，也能通过一套公开的 C API 操作交换芯片。它保留了相当多的硬件细节，比如可以指定具体的表、索引、端口位图。这意味着它的能力边界很宽，几乎能触达 SDK 的大部分功能，但代价是抽象度低、可移植性差——换一颗芯片，代码往往要改。它适合的场景是：需要精细控制硬件行为、又不想直接依赖私有 SDK 的定制化设备开发。产品化时要特别注意，OpenNSL 的版本与 SDK 版本强绑定，升级路径需要提前规划。
SAI：交换机抽象接口，生态的“插座标准”
SAI（Switch Abstraction Interface）定义了一组与厂商无关的 API，用统一的对象模型描述端口、VLAN、路由、ACL、下一跳、隧道等。它的核心价值在于“一次编写，多芯片运行”。SONiC 之所以能同时支持多家芯片，正是因为它只依赖 SAI。SAI 的能力边界在于：它定义的是“标准能力集”，厂商可以扩展私有属性，但标准之外的特性不具备可移植性。选型时要评估目标芯片的 SAI 实现成熟度，尤其是路由规模、ACL 表深度、Telemetry 支持这些关键项。
SONiC 与 OpenSwitch：两种 NOS 路线
SONiC 是微软开源并已进入 Linux 基金会的网络操作系统，采用容器化架构，各功能模块以 Docker 容器运行，通过 Redis 数据库解耦。它的优势是社区活跃、生态广、与 SAI 配合成熟，适合大规模数据中心场景。OpenSwitch（现多指 OPX，OpenSwitch Platform）则更强调开放平台与可编程性，提供更完整的平台抽象，适合需要深度定制 NOS 行为的场景。两者都不是“芯片 SDK”，而是消费接口层的上层系统。
产品化选型评估：一张可填写的决策表
选型不能只看“是否开源”，而要从芯片支持、功能覆盖、团队能力、长期维护四个维度打分。下面给出一个可直接使用的评估表，权重可根据项目调整，示例中假设权重之和为 100%。
| 评估维度 | 关键问题 | 权重 | OpenNSL | SAI | SONiC | OpenSwitch |
|---|---|---|---|---|---|---|
| 芯片支持 | 目标芯片是否有成熟实现 | 25% | 强（Broadcom 原生） | 取决于厂商 | 依赖 SAI | 依赖 SAI/平台层 |
| 功能覆盖 | 路由/ACL/Telemetry 是否满足 | 25% | 可精细控制 | 标准集+扩展 | 数据中心功能全 | 可编程性强 |
| 团队能力 | 是否需要自研 NOS | 25% | 需较强底层能力 | 需理解对象模型 | 可复用社区 | 需平台开发能力 |
| 长期维护 | 升级与社区活跃度 | 25% | 随 SDK 升级 | 社区+厂商 | 社区活跃 | 社区相对小 |
最后要强调，开放生态的价值不在于“免费”，而在于可替换性与可演进性。SAI 让芯片可替换，SONiC 让 NOS 可复用，OpenNSL 让硬件能力可编程。产品化选型的本质，是在控制力、开发成本、交付速度和长期维护之间找到与团队和业务匹配的平衡点。