看看有趣的ONOS Ⅲ：系统组成

说明：翻译自ONOS wiki的System Components，自学使用

系统层

ONOS的架构由功能层组成。如下图所示：

ONOS功能层示意图

服务和子系统

服务 service是功能的一个单元，由多个组件组成，这些组件通过软件堆栈在层之间创建垂直切片。我们将组成服务的组件集合称为子系统 subsystem。在本指南中，我们将术语“service”和“subsystem”互换使用。

ONOS定义了几种主要服务：

• Device Subsystem — 管理基础结构设备的清单。
• Link Subsystem — 管理基础结构链接的清单。
• Host Subsystem — 管理终端站主机的清单及其在网络上的位置。
• Topology Subsystem — 管理网络图视图的按时间顺序快照。
• PathService — 使用最新的拓扑图快照计算/查找基础设施设备之间或终端站主机之间的路径。
• FlowRule Subsystem — 管理安装在基础结构设备上的匹配/操作流规则的清单并提供流指标。
• Packet Subsystem — 允许应用程序侦听从网络设备收到的数据包，并通过一个或多个网络设备将数据包发送到网络上。

下图说明了现有和未来部署计划中ONOS的各种子系统：

ONOS子系统示意图

子系统结构

子系统的每个组件都位于三个主要层之一中，并且可以由它们实现的一个或多个Java接口来标识。

下图总结了子系统组件的关系。图中的顶部和底部虚线分别表示由北向和南向API创建的层间边界。

Subsystem组件之间的关系

Provider

Provider是ONOS堆栈的最低层，通过特定于协议的库与网络形成接口，并将ProviderService作为与core层的接口。

协议感知Provider负责使用各种控制和配置协议与网络环境进行交互，并将特定于服务的感觉数据提供给核心。提供者还可以从其他子系统收集数据，将其转换为特定于服务的数据。

一些Provider可能还需要接受来自核心的控制命令，并使用适当的协议特定手段将其应用于网络。这些通过Provider接口馈入Provider。

Provider ID

Provider与ProviderId关联。ProviderId可以提供Provider族的可外部化的身份，即使在其被卸载或Provider被卸载之后，设备和其他模型实体也可以与负责其存在的Provider的身份保持关联。

ProviderId带有URI方案名称，以允许将设备与备用提供商系列的提供商进行松散配对，并且无需访问Provider本身就可以做到这一点。

多Provider

一个subsystem可能与多个Provider相关联。在这种情况下，Provider被指定为primary或ancillary 。Primary provider拥有与其服务关联的实体，而ancillary provider则将其信息作为overlays提供。如果任何overlay导致与underlay信息冲突，则此方法将优先考虑主要provider信息。

Device Subsystem就是这样一种能够支持多个provider的服务。

Manager

Manager是驻留在core的组件，它从provider接收信息并将其提供给应用程序和其他服务。它公开了几个接口：

• Service应用程序或其他核心组件可以通过其北向接口了解网络状态的特定方面的信息
• AdminService用于选取管理命令和将命令应用到网络状态或系统的接口
• ProviderRegistry使provider可以通过其南向接口向管理器注册，以便与之交互
• ProviderService是提供给注册provider的南向接口，通过它可以向Manager发送信息或从Manager接收信息

Manager服务接口的使用者可以通过查询服务同步接收信息，也可以作为事件侦听器异步接收信息（例如，通过使用ListenerService的Service的一部分接口注册事件并实现用于接收事件的EventListener接口）。

Store

同样在core内并且与Manager密切相关，Store还具有索引、持久化和同步Manager收到的信息的任务。这包括通过与其他ONOS实例上的存储直接通信来确保跨多个ONOS实例的信息的一致性和鲁棒性。在Cluster Coordination（集群协调）中可以找到更多有关分布式环境中存储的讨论。

Application

Application通过AdminService和Service接口使用并操作管理器汇总的信息。Application具有很多功能，可以从在Web浏览器中显示网络拓扑到设置网络流量的路径。

Application ID

每个应用程序都与一个唯一的ApplicationId关联。ONOS使用此标识符来跟踪与Application关联的上下文（例如，任务和目标，例如意图和流程规则）。为了获得有效的ID，Application向CoreService进行注册并提供其名称，该名称应遵循反向DNS表示法，例如org.onlab.onos.fwd。

并非所有subsystem都拥有所有这些组件，也不是所有组件都严格遵守这些功能。例如，TopologyProvider仅作用于系统core的设备和链接的协议不可知的表示，并且永远不会直接与基础结构进行交互，CoreService则由CoreManager仅实现服务接口。

Events and Descriptions

ONOS中信息分发的两个基本单位是事件和描述。与服务一样，事件和描述与特定的网络元素和概念相关联。一旦创建，两者都是不可变的。

内容描述

描述用于通过南向API传递有关元素的信息。例如，HostDescription包含有关主机的MAC和IP地址及其在网络中的位置（VLAN ID和设备/端口连接点）的信息。描述通常由一个或多个模型object（各种网络组件的ONOS表示）组成。

Events

Manager使用Event来通知其侦听器有关网络中的更改，Store使用Event来通知其对等对象分布式设置中的Event。Event由事件类型和由模型对象构建的主题组成。例如，可以使用DeviceEvent通知DeviceListeners设备（主题）已检测到（DEVICE_ADDED），丢失（DEVICE_REMOVED）或设备的某些方面已更改（DEVICE_UPDATED）等。

Event dispatch

Event是由Store根据Manager的输入生成的。生成事件后，就会通过StoreDelegate接口将Event分配给感兴趣的侦听器，该接口最终会调用EventDeliveryService。实际上，StoreDelegate将Event移出商店，并且EventDeliveryService确保事件仅到达感兴趣的侦听器。由于它们的交互方式，这两个组件驻留在Manager中，其中Manager的向商店提供StoreDelegate的实现类。

Event Listeners

Event Listener是实现EventListener 接口的任何组件。EventListener子接口Event按其侦听的子类的类型进行分类。典型的实现方式是事件侦听器是管理器或应用程序的内部类，根据接收到的事件从中调用适当的服务。这将子系统外部事件的处理限制在子系统的管理器或应用程序（即应处理它们的逻辑位置）中。

下图详细说明了上图，以显示“Descriptions”，“Events”和此处描述的组件之间的关系。

组件之间的关系

Network representations

模型对象是各种网络元素和属性的ONOS协议无关表示。事件将这些表示作为主题主体。这些表示是根据系统核心在“描述”中找到的信息构建的。

有关网络表示的进一步讨论可以在Representing Networks（表示网络）中找到。