一个白牌厂商视角：极简交换机NOS演进史

传统的交换机操作系统(简称NOS)对大众是一个相对封闭的领域。随着白牌交换机的高速增长，NOS纷纷开源，NOS的开发者也从只有设备商工程师，扩大到互联网，运营商以及云计算的从业者。

NOS的作用是按照管理者的意志将网络中的业务在交换机上运转起来。所以NOS首先需要提供对管理者或者控制器的接口;然后需要运行协议运算，和网络中的其他交换机进行协议面的交互;第三是需要硬件接口来适配交换芯片，风扇电源等板载硬件。如下图，我们可以将NOS拆分为三个核心功能模块，以及基础架构模块。

管理接口，包括传统的CLI, SNMP, WEB功能。SDN引入的Openflow, NET-CONF, OPEN Config，Restful API功能等;

协议应用模块，包括二层的协议模块STP, LLDP, M-LAG，三层的协议模块OSPF, BGP, VRRP等，以及DHCP, NTP等应用模块，SDN时代的Openflow Agent，包括OVS，;

硬件接口上包括对接交换芯片，电源，风扇的管理接口;

具备了以上三个核心功能就算是一个合适的NOS了，但给看一个NOS牛不牛，更要看“基础架构”，它是NOS骨骼和肌肉，NOS的健壮性，延展性都由它决定，NOS演进其实是这个基础架构的的演进历史。

我们将过程分割为两个阶段，第一段是思科，Juniper，Arista的巨头厂商竞争时期，这个时期核心技术集中在设备商手中，是一个技术积累的阶段;第二段是OPS, Sonic和OPX这些开源新势力的时代，喜欢玩颠覆的互联网厂商带着SDN的新需求参与了进来。

巨头之争

原始架构

《Inside Cisco IOS Software Architecture》介绍的IOS架构如上图，框架里还包括软件转发的模块，可见属于非常早期版本。通过蓝色方框去剖析Cisco IOS，可以看到IOS满足了NOS的三个要素，管理接口，协议应用模块，硬件接口。但是在基础架构上还相对原始，没有将管理接口和协议应用模块分开。这个架构更多的是解决有无问题，当时的精力更多的还是在业务模块上。

模块化架构

《JunOS OS for Dummies》中介绍的JunOS的架构如上图，包含管理接口，协议应用模块，硬件接口的同时提出了模块化架构的理念。

The modular architecture of Junos OS allows individual control plane processes to run in their own module (also sometimes called a daemon). Each module has specified processing resources and runs in its own protected memory space, avoiding the processing conflicts that can occur in other platforms.

同样是比较早期的架构，但是通过这个架构可以清晰的看到管理接口和其他模块是分离的，已经有一些控制和转发的分离的意思在里面，但这次演进不是革命性的，更像是从温饱到小康的进步。

数据库架构

Arista的EOS的架构图如上图，EOS最牛的地方就是他的数据库架构，SysDB是一个Key-Value的内存数据库，Arista的核心亮点是能够原生的解决进程级别故障，流程如下：

可以看到进程故障时候，交换芯片继续保持转发，进程恢复后从SysDB重新获取状态继续运行，该功能不但可以保障业务的稳定运行，还可以实现单进程升级功能。记得当时Arista一个典型的DEMO是将正在运行的STP KILL掉进行单进程升级，因为STP的状态都是存在SysDB里的，所以STP进行恢复工作后，业务层面可以做到不感知。

数据库架构的演进是一个重大的变革，颠覆了传统的定义数据结构，然后进程间消息通信的传统的架构。开发者可以使用类似开发通用软件的思路进行开发，而且NOS的数据可视化了，大大降低定位问题，解决问题的难度。

思科在NX-OS上同样通过Key-Value的内存数据库来实现了HA，如下图：

思科的NX-OS清晰的完成了管理和协议应用分离(排名不分先后)，实现了轻量级的Key-Value内存数据库完成了HA Infrastructure，思科在庞大的协议栈包袱下始终不断演进，同样令人钦佩。

新势力

SDN高速发展，白牌产业催生了一批开源开放的NOS，这些新兴的NOS站在巨人的肩膀上，都基于数据库架构，OPS选择了OVSDB，Sonic和OPX选择了Redis，OVSDB和Redis都属于Key-Value的In-memory数据库。

但这并没有让新势力满足，SDN要的是更快，更灵活，更大规模，更好扩展。巨头时期的NOS开发周期还是过长，升级还是有点不方便，用惯了动态语言的互联网开发者表示无法接受。数据中心的互联网用户对NOS最痛点的需求是如何流量无感知的完成版本迭代，以及如何更方便，更高效的进行版本升级。

数据库架构 + 容器架构

做公有云的微软自然的想到通过虚拟化重构NOS，将容器技术应用到了NOS。容器技术可以简单理解为：对Linux操作系统来看是容器是一个进程，容器看自己内部是一个轻量级虚拟机。Sonic将各种进程，比如BGP运行在容器中，原生的解决了JunOS提出的模块化问题，更重要是配合数据库架构，由对单进程的升级，变成了对容器的升级，聪明的使用成熟通用的技术解决传统问题。

总结整个基础架构发展史如下图：