第2篇：SONiC 的前世今生
微软为解决网络系统升级困难、功能迭代慢等问题，开发了开源网络操作系统SONiC。2015年推出SAI作为芯片抽象层，2016年开源SONiC，2022年加入Linux基金会实现中立治理。SONiC采用容器化设计，每年发布两个主版本，由多个工作组共同维护。其成功得益于微软Azure的实际应用、开放的架构设计以及健康的社区生态。目前已有100+平台和500+贡献者参与，成为云服务商和企业广泛采用的网络
深入理解 SONiC 系列 · 第2篇
📖 预计阅读时间：5分钟
解决方案开始出现瓶颈：
- 每次系统升级需要整机重启，影响业务
- 想加一个小功能？等厂商排期，6-12个月起步
- 不同厂商设备混合部署，运维复杂度爆炸
微软的网络团队意识到：在这个规模下，必须自己掌控网络操作系统。
从 FBOSS 到 SONiC
微软并不是第一个这么想的。Facebook（现 Meta）在 2013 年就开始开发自己的网络操作系统 FBOSS。但 FBOSS 与 Facebook 的基础设施深度耦合，难以被其他公司直接使用。
微软的方案从一开始就有不同的设计目标：
SAI 先行：2015 年
SONiC 不是凭空出现的。2015年7月，微软先向 OCP 贡献了 SAI（Switch Abstraction Interface）——一套标准化的交换机芯片 API。
SAI 解决了一个核心问题：不同芯片厂商（Broadcom、Mellanox、Marvell）各有各的 SDK，写一套网络软件要适配 N 套芯片接口。SAI 在中间加了一层抽象，让上层软件只需要对接一套 API。
这为 SONiC 的诞生铺平了道路。
关键里程碑
2016：SONiC 开源
2016年3月，微软在 OCP 美国峰会上宣布开源 SONiC。
微软对 SONiC 的定位很清晰：它是构建网络设备所需的软件组件集合。配合 SAI，云运营商可以在开源框架上开发交换机应用，并支持多种硬件平台。
首日即有 Arista、Broadcom、Dell、Mellanox 参与贡献。这说明 SONiC 从一开始就不是微软一家的项目，而是多厂商协作。
2022：加入 Linux Foundation
2022年4月14日，SONiC 正式加入 Linux Foundation，实现中立治理。
微软 Azure 网络部门的 Technical Fellow Dave Maltz 在公告中说：
"SONiC already runs on millions of ports in the networks of cloud scalers, enterprises, and fintechs."
阿里云网络基础设施负责人 Dennis Cai 表示：
"Alibaba Cloud has widely deployed SONiC-based whitebox switches in our data centers, edge computing cloud, P4-based network gateways, and will extend the deployment to Wide Area Networks."
Linux Foundation 正式托管 SONiC，成立 SONiC Foundation。成员包括：Alibaba · Broadcom · Dell · Google · Intel · Microsoft · NVIDIA + 50多个合作伙伴。
SONiC 的版本发布节奏
SONiC 采用 YYYYMM 命名规则，每年发布约 2 个主版本：
| 版本 | 日期 | SAI | 亮点 |
|---|---|---|---|
| 202205 | 2022.05 | 1.10.2 | FRR 8.2, Active-Active ToRs |
| 202211 | 2022.11 | 1.11.0 | gNMI 配置, SRv6 uSID, Secure Boot |
| 202305 | 2023.05 | 1.12.0 | Docker Bullseye 迁移, PINS |
| 202311 | 2023.11 | 1.13.3 | DASH ACL, Auto FEC, FRR 8.5.1 |
| 202405 | 2024.05 | 1.14.0 | 升级到 Debian 12 (Bookworm) |
| 202411 | 2024.11 | 1.15.1 | FRR 10.0.1, Port Access Control |
| 202505 | 2025.05 | — | SmartSwitch DPU, Stream Telemetry |
SONiC 的治理结构
SONiC 社区由多个工作组（Working Group）构成，每个工作组负责特定领域：
| 工作组 | 职责 |
|---|---|
| Routing WG | BGP、OSPF、MPLS 等路由协议 |
| PINS WG | P4 Integrated Network Stack |
| DASH WG | Disaggregated API for Switch Hardware（SmartNIC） |
| Platform WG | 硬件平台适配、驱动 |
| Security WG | 安全特性、漏洞管理 |
| Testing WG | 测试框架（sonic-mgmt） |
为什么 SONiC 能成功？
不是每个开源项目都能走到今天。SONiC 成功的关键因素：
- 生产背书：微软 Azure 自己在用，不是玩具项目
- 架构开放：SAI 让芯片厂商有参与动力，不威胁他们的核心竞争力
- 务实设计：容器化让部署运维门槛低，Linux 基础让运维熟悉
- 社区健康：平衡了企业利益和社区开放性
- 时机正确：白盒交换机硬件已成熟，市场需要开源 NOS
本篇小结
| 要点 | 内容 |
|---|---|
| 起源 | 微软 Azure 内部需求驱动 |
|
SAI 时间 |
2015年被 OCP 接受 |
|
开源时间 |
2016年 OCP 峰会 |
| 基金会 | 2022年加入 Linux Foundation |
| 发布节奏 | 每年 2 个主版本，YYYYMM 命名 |
| 治理方式 | 工作组制度，企业+社区共建 |
| 当前规模 | 100+ 平台，500+ 贡献者 |
下一篇预告
第3篇：SONiC 整体架构鸟瞰 — 容器化设计的全貌，每个 Docker 容器的职责，以及它们如何通过 Redis 协同工作。这是理解 SONiC 一切细节的基础。
💡 这是「深入理解 SONiC」系列的第2篇。如果你从第1篇开始看，可以回顾：为什么需要sonic
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
3
0- 0
已为社区贡献2条内容
所有评论(0)