ONOS的发布直面OpenDaylight进行挑战，直接将SDN领域两大阵营（运营商和设备商）的竞争瞬间升级，之所以ONOS能做到这一点，首先，ONOS的定位就是要为运营商提供敏捷和灵活的大规模部署能力，避开了设备商围绕着OpenDaylight展开的品牌保卫战。另外，ONOS实现了高可用、可扩展的系统设计方案，基于此基础上对系统的层次结构以及网络实体进行高度抽象，这种优秀的设计和高度的抽象保障了系统的演进和能够被优化得更快更有效。这篇文章主要探寻ONOS在HA和Scale-out的设计上的一些蛛丝马迹。

首先回忆一下SDN定义的三个特性：控制平面和数据平面的分离、逻辑上集中控制、开放的编程接口，然后再看ONOS的系统架构，可以看出ONOS的架构与这三个特性清晰的对应。如图1所示，在南向接口层，采用协议插件以实现控制平面与数据平面的分离；在北向接口层，提供一套应用编程接口以实现网络的可编程性的应用接口；在东西向的扩展上，通过分布式集群的方式以实现逻辑上集中控制。

我们在SDN系统中讨论的当网络系统一旦涉及分布式，其复杂性就会急剧上升。一方面，在分布式情况下，系统中数据又呈现不同的状态和特性，比如对数据的一致性、实时性的需求不同，在性能和可用性方面做更多的工作；另一方面，需要考虑系统容错（单点故障）、灾难恢复和系统扩展（节点的增加/删除），因为系统中任何一个节点的状态变化，需要所有其他节点做相应的调整。

一致性主要分为两种类型。一种是强一致性，其要求当一个实例更新网络状态时任何实例随后的读操作都返回最近更新的数值；另一种是最终一致性，当系统保证如果没有新的状态更新时，最终所有的实例都能获得最后的更新保持最终状态一致，中间允许读取操作延后一段时间。两者比较而言，最终一致性是一种特殊的弱一致，而强一致性将导致分布式数据管理的复杂性和延时。

在ONOS系统中，如 表1所示，Distributed Core模块负责状态管理，进行拓扑、意图、链路资源等存储管理，这些数据属性可根据ACID和BASE(Basically Available, Soft-state, Eventual consistency)的性质进行划分。根据这些数据的特性，可以参用不同的协议来满足不同的需求。

强一致性要求数据在某个节点更新后，在这之后其它副本节点上获得该数据最新的更新，这种可以通过分布式事务协议(Paxos)来实现，例如分布式锁。在对Switch-Controller映射关系进行更新时，必须是强一致性的，示意图如图2所示；弱一致性保证数据在一定时间窗口之后可以读到更新的数据，存在“不一致窗口”。最终一致性是弱一致性的一种特例，保证客户端能够读取到某操作对系统特定数据的更新，“不一致性窗口”的大小依赖于系统负载、副本数。最终一致性模型又包括Causal Consistency(因果一致性)、Session Consistency(会话一致性)等模型的划分，像如图3所示的网络状态最终一致性就是一个典型场景，在初期的ONOS版本中主要可以通过Gossip协议实现，使用了基于anti-entropy实现。

ONOS在系统的可用性和可扩展性方面做了大量工作。我们知道，单一节点的处理能力有限，例如计算资源和数据流量等方面会成为瓶颈，而且会形成网络的单点故障。为了提高系统的可用性，避免在系统某一个节点发生故障，导致系统无法正常运行，这时就需要更多的副本(Replica)节点。当系统中存在多个副本时，系统需要保证副本数据的一致性。ONOS根据其数据的不同性质，采取不同的同步和复制策略：全复制（Fully Replicated）、主从复制（Master-Slave Replicated）和分片（Partitioned/Distributed）。如图4所示，Network Toplogy是实时性要求不高的数据，利用gossip协议，采用乐观复制的方式在各个节点进行同步。

实际上ONOS从prototype 1到prototype 2在分布式管理上有了很大变化，比如用Hazelcast取代zookeeper的一些职责，而在onos 1.1.0版本中，使用Raft替代Hazelcast。因此这篇文章只是初步的了解ONOS系统在分布式构建下的一些数据特性，以及如何保证数据一致性所采用的算法、协议。这里我们不禁会提出另外一个问题：为什么不用Zookeeper，而选择了Hazelcast?最后又选择了Raft?

想要和本文作者进行问题交流可以加入交流群：194240432