每个子系统的所有组件分布于ONOS系统三个主要层级中，并且可以通过它们实现的一个或多个Java接口识别。  如上图描述了子系统组件之间的关系。图中顶端和底端的虚点线分别代表由北向和南向APIs创建的层级间边界。下面讨论ONOS的子系统结构。 ### 提供者 提供者(Provider)位于ONOS堆栈中最底层部分。Provider向下通过特定协议(protocol-specific)的库建立与底层网络的连接，向上通过ProviderService接口建立与ONOS core的联系。协议相关的（protocol-aware）provider使用多种控制和配置协议与网络环境互动，同时想core实时提供特定服务(service-specific)的感知（sensory）数据。有时Provider也会收集来自其他子系统的数据，转换为相应的服务数据。 某些providers也可能需要从core接收控制命令，并使用特定协议将它们应用到底层网络中。 #### 提供者标识（Provider ID） 每个Provider必须和一个ProviderId关联。ProviderId的主要目的是为了提供providers家族的外部标识，允许设备和其他模型实体关联到provider标识，并在provider被卸载后保持它们的存在。 ProviderId提供基于URI方案设计，允许松散地配对不同provider家族的设备，而无须访问Provider本身。 #### 多Providers 子系统可能会包含多个Provider，那么可以指定Provider是主(primary)Provider还是从属的(ancillary)Provider。主Provider拥有其服务的相关实体。这种机制为主要的provider信息提供了优先权。ONOS的Device子系统就是能够支持多Provider的一个例子。 ### 管理者 管理者(Manager)是位于ONOS core中的组件，Manager负责接收来自Provider的信息，并为上层应用和服务提供服务等工作。它提供了多种接口： * 一个用于应用程序或其它core组件读取网络状态的北向服务(Service)接口； * `AdminService`接口，用于执行管理命令并将命令应用于底层网络状态或系统； * `ProviderRegistry`南向接口，底层Provider用于向Manager注册，实现彼此的交互； * `ProviderService`南向接口，提供给已经注册的Provider，用来从manager收发信息； Manager服务接口的接收者（consumers）可以既可以通过同步地询问服务接收信息，也可以以异步的方式作为事件监听者接收信息（例如，使用每个服务（Service）接口中包含的`ListenerService`接口，注册监听哪些事件，并实现`EventListener`接口接收事件。 ### 库（Store） 在core中有一个Store组件，与Manager紧密结合，它主要负责索引、持久化和同步由Manager接收的消息。通过直接与其它ONOS实例的store通信，多个ONOS实例之间确保信息的一致性和鲁棒性。关于分布式设置下的stores的深入讨论见于集群协同章节。 ### 应用程序 应用程序（Application）通过`AdminService`和其他服务接口使用和操作由manager聚合的消息。应用程序的功能多种多样，比如在web浏览器中显示网络拓扑，为网络流量设置路径等。 `Application`和`Provider`一样要和一个Id关联，这里称之为`Application Id`。它被ONOS用来跟踪应用程序的上下文（例如，诸如意图（intent）和流表项）。每个应用程序若想得到一个合法ID，它必须提供它的名字，使用`CoreService`注册。应用程序名字遵循反向DNS服务，如，`org.onlab.onos.fwd`。 ### 小结 总之，对于子系统，并不是所有的子系统都拥有上述所有组件，也不是所有组件严格地遵守这些功能。例如，`TopologyProvider`纯粹地依靠设备和链路的协议无关抽象，不直接与基础设施交互，且`CoreService`由`CoreManager`实现，一个`manager`只实现一个服务接口。