正在阅读：ONOS与OpenDayLight 两个控制器之间的较量ONOS与OpenDayLight 两个控制器之间的较量

　　【PConline 干货铺】上一期我们谈到了在众多控制器中怎么去选择适合自己的控制器，谈到了几种选择的维度。今天这篇文章将聚焦于当前比较流行的两种商用开源控制器ONOS和OpenDayLight（下文简称ODL），进行深入比较。

起源&生态圈

　　ODL诞生之初是为了对抗ONF将网络设备弱化（白牌化）、开放的理念，借助占领控制器这个制高点，通过丰富的南向接口间接保留网络设备本身的价值。ODL主要由众多设备厂商驱动，在一定程度上是为了维护自己阵营的利益产物，目前发展势头比较猛，版本迭代比较快（一般是一个Q一个小版本、一年一个大版本，并且在不断加速），也成为各设备厂商推出各自商用控制器的一个基础平台。目前包含了大量的参与者，包括Cisco、Citrix Systems、Red Hat 、Brocade、Ericsson、ClearPath、HP、NEC、Inte、HW、H3C、Juniper、ZTE、INOCYBE等等（当然锐捷也是采用ODL）。

　　ONOS（Open Network Operating System）顾名思义就是要定义一个开发的网络操作系统，其核心的服务对象是服务提供商（运营商就是其中的大头）。既然服务对象要达到运营商的级别，那么其重点就需要考虑可靠性、性能，并在白盒系统上创建高性能可编程的运营商网络。其诞生之初就是为了对抗ODL，希望能成为控制器的主流。目前主要的参与者包括了，AT&T、CIENA、VERIZON、NTT、爱立信、华为、NEC、INTEL、富士通等等。

优劣势分析对比

2.1.ODL架构

2.2.ONOS架构

2.3.两种架构对比

　　从结构层次上仿佛大同小异，都包含：北向接口、核心层、服务抽象、南向接口协议（虽然在具体各层次的内容描述上或简单或详细）。

　　如上一小节讲到的，ODL和ONOS的起源以及服务的对象不同，也使二者在架构设计细节上有比较大的差异。

　　ODL服务于设备产商，所以必须在整体设计过程体现网络设备本身的价值，这一点更多地表现在以下几个方面：

　　•ODL有丰富的南向接口：OpenFlow、NETCONF、OVSDB、BGP、PCEP……，说白了就是将设备端目前实现的并且能抽象成设备北向接口的协议尽可能多地暴露出来，从外部看ODL支持丰富的南向接口功能强大（也确实强大），但是变相地提升了控制器设计的复杂度，也增加了控制器与不同网络设备对接的难度。换言之，接口协议定义越丰富，也就意味着控制器和网络设备的“种类”就越多，相互之间的兼容性、互通性问题就越复杂，控制器和网络设备之间的捆绑性就越强。

　　•ODL通过MD-SAL（模型驱动的服务抽象层，各位看官可先忽略其具体内容，以后的文章将对该层的工作原理做详细介绍）将南向接口与其核心层互联起来，由于模型本身具有厂商自定义属性（ODL中并没有严格限定，允许各开发者定义自己的YANG模型），不同南向协议之间相同的功能都可以抽象成不同的模型，这也使得在ODL上各个设备产商可以根据当前自有设备的具体实现，将功能抽象成有局部差异的模型，甚至可以抽象出“产商特色”的模型，也就意味着集成一个特定的网络设备功能到ODL上还是非常便利的。

　　而ONOS服务于服务提供商，注重的是可靠性和性能，这两点也体现在其轻量化的设计中（特别还沿用AD-SAL（API驱动的服务抽象层，该模式曾在ODL氢版使用过，后续的ODL版本里被MD-SAL替代）的方式，整体设计比ODL要简单）：

　　•可靠性方面，ONOS采用的集群技术基于Hazelcast开源分布式内存数据库，Hazelcast是一个高度可扩展的数据分发和集群平台，可用于实现分布式数据存储、数据缓存。ONOS提供许多常见的分布式原型，开发人员利用现有服务，很方便就能构建分布式业务。

　　•性能方面的一个对比测试如下（不同的ODL和ONOS版本、不同的测试方法在测试数值上会存在差异性，整体来看的话ONOS略高一些，但并没有显著的优势）：

　　♦测试环境

　　Xeon CPU E5-2630 v2 @ 2.60GHz，RAM：16G，

　　JVM：1.8.0

　　-Xms128M -Xmx2048m(ONOS修订$KARAF_ROOT/bin/karaf脚本)

　　·ODL_Li + CBench

　　单台控制器最大性能（平均值）：106699.80 responses/s

　　·ONOS_1.4 +CBench

　　单台控制器最大性能（平均值）：127508.5 responses/s（略好）

2.4.模块化

　　二者都是基于OSGI标准进行开发，使用Apache Karaf feature组装，在这方面属于半斤八两。

　　ONOS在OSGI和Karaf之上，设计出Application管理子系统，Application与具体的Feature关联，用来实现Application的组件化管理，支持动态添加和移除。

　　ODL也使用Feature打包组件，但引入的Config Subsystem极大复杂化了OSGI模块化机制，对应用管理的粒度过于分散，对于初学者入手来说相当困难。

2.5.文档丰富程度

　　ONOS从第一个发布版本开始，就提供系统的文档支持。ONOS使用清晰的文档目录索引，非常容易检索和使用。

　　ODL的复杂性饱受诟病，尤其是没有系统的文档支持。wiki上文档分散和各个页面，缺乏有效的目录指引，初学者难以下手，学习十分困难。

结语

　　ONOS和ODL虽然一段时间内还是处于竞争的状态，但基于二者的一些优势互补以及共同的组织成员，未来还是存在二者相互融合的可能性。