傳統的交換機操作系統(簡稱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提出的模塊化問題，更重要是配合數據庫架構，由對單進程的升級，變成了對容器的升級，聰明的使用成熟通用的技術解決傳統問題。

總結整個基礎架構發展史如下圖：

經過歷代演進，NOS已經不再是結構復雜，需要像黑客一樣定位問題，產品化周期和芯片差不多的專用操作系統了。現代NOS在架構上進化為使用通用的數據庫，容器虛擬化技術，支持高速迭代，某種意義上設備商是不是也可以稱自己是互聯網公司了。

作者簡介：成偉，蘇州盛科系統工程師經理