前言：

為了方便靈活性，ONOS采取的是一種模塊化結構，一方面能靈活地組織各種模塊，容易讓開發者擴展出新的模塊，同時通過隔離令系統的模塊各司其職而不會互相干擾。實際上ONOS是由多個子系統組成，本文將對ONOS中幾個比較有代表性的子系統進行介紹。

基礎——OSGi:

ONOS由多個模塊組合而成，實際上ONOS是基于OSGi bundles實現的。OSGi是一個基于插件式的軟件架構，包含OSGi框架和插件。這種插件被稱之為Bundle，Bundle可以被動態地加載和卸載，動態升級也就可以被實現了(有點像Erlang的OTP提供的熱代碼替換，不過OTP和Erlang結合更緊密)，通過使用OSGi，Java應用就可以實現良好的模塊化。OSGi框架規范提供了一個通用的安全的Java框架，Bundle服務應用的部署、擴展全都依賴于該框架。

OSGi體系架構：

JVM運行在硬件上，JVM上包含Execution Environment、Modules、Life Cycle、Services、Security等內容。事實上，OSGi是一個非常強大，同樣非常復雜的框架。ONOS使用了它，能大大提升靈活性。

ONOS設計目標：

ONOS的設計目標包含以下幾點：

1.代碼的模塊化：擴展其他組件更容易。

2.可配置性：靈活的配置能實現靈活的架構，同時也能提高可定制性。

3.問題的分離：每個模塊負責自身所屬的工作內容。如果子系統間有明確的界限，就可以充分利用模塊化的好處。

4.協議不可知：ONOS本身和它的應用都不應該被綁定到特定的協議庫或實現。

在ONOS中，每個子系統都有自己的源碼樹，ONOS吸收了Maven的分層POM組織方式，因而每個子項目擁有自己的pom.xml文件。

至于配置方面，因為ONOS使用了Karaf作為其OSGi框架，這使得動態模塊載入成為可能，同時Karaf提供了諸如允許使用標準JAX-RS API去開發REST API使其更安全、運行時方便日志級別的設置和容易擴展的CLI等特性。

在ONOS中，Protocol-aware network-facing模塊被用于與網絡的交互，Protocol-agnostic system core用于跟蹤和服務與網絡狀態的信息等，應用程序與core通過北向API通訊，而network-facing模塊使用南向API與core通訊，通過層層分離，實現模塊化。

如果我們要使用一種新的協議，我們必須能夠構建出一個相應的network-facing模塊，作為一個插件在運行時加載至ONOS。

ONOS子系統結構：

ONOS中，一個子系統是一系列服務的集合。

ONOS定義了幾個主要的subsystem，如：

Device Subsystem：管理基礎設備的詳細清單;

Link Subsystem：管理基礎鏈接的詳細清單;

Host Subsystem：管理終端主機和它們在網絡中的位置;

還有一些諸如Topology Subsystem、FlowRule Subsystem等子系統。在ONOS中，一個子系統的組件駐留在三個主要層,并且可以由一個或多個Java接口實現，如圖所示：

Provider：

這是ONOS堆棧中***層的部分。Provider接口通過特定協議的庫通向網絡，通過ProviderService接口調用core。protocol-aware provider負責使用多種控制和配置協議與網絡互動，同時提供特定服務的感知(sensory)數據給core。有時Provider也會收集來自其他子系統的數據，轉換為特定服務的數據。

在Provider中還包含Provider Id，一個Provider必須和一個Id關聯標識。

一個子系統可能會包含多個Provider，可以指定Provider是主Provider還是從屬的Provider。在ONOS的Device Subsystem中能支持多個Provider。

#p#

Manager：

Manager是一個駐留在core中的組件，Manager負責接受來自Provider的信息、為上層應用和服務提供服務等工作。

它提供了數個接口：

一個用于給其他組件讀取網絡狀態的北向接口;

一個用于執行管理命令和應用網絡狀態的AdminService接口;

一個被Provider用于注冊的ProviderRegistry南向接口;

一個提供給已經注冊的Provider用來對manager收發信息的ProviderService南向接口;

在core中有一個Store的組件，與Manager緊密結合，它主要負責索引、持久化和同步來自Manager的消息。

Application：

應用程序通過AdminService和其他服務接口聚合消息，被Manager使用和操作。應用程序的功能多種多樣，比如顯示網絡拓撲、節點等。

Application和Provider一樣要和一個Id關聯，這里稱之為ApplicationId。被ONOS用來跟蹤應用程序的上下文。一個應用程序若想得到一個合法ID，它必須提供它的名字，使用CoreService注冊。

幾個子系統的簡單介紹：

1. Provider的職責例子——Device Subsystem

這個子系統負責發現和跟蹤組成網絡的設備，同時允許操作者和應用程序控制它們。大多數的ONOS核心子系統都依賴于這個子系統所創建和管理的Device和Port對象模型或其provider被用于與網絡交互。

Device Subsystem包含以下幾個部分：

一個DeviceManager，通過DeviceProviderService接口與多個Provider關聯，通過DeviceService接口與多個監聽者(listener)關聯。

DeviceProviders，每一個都有自己的網絡協議庫的支持。

一個DeviceStore，跟蹤Device模型對象和生成DeviceEvents。

下圖是OpenFlow Subsystem的示意圖，可以清楚地看到其南向接口和OF控制器的交互過程：

2.Store的職責例子——集群協調

如果我們部署一套多實例ONOS，實際上它是由多個擁有一個唯一的NodeId的實例或節點組成的集群。每一個節點都可以感知網絡的一部分狀態。本地的狀態分段由節點管理，在集群中以事件傳播。事件被Store生成，它們通過分布式儲存與集群中的所有節點共享。

根據具體服務的需求，儲存的內容可以有不同的特征，如強一致性或最終一致性，這使得每個服務的儲存根據需求采用合適的分布機制。

目前ONOS主控部分采用Hazelcast以達到強一致性，而Device、Link等部分的管理使用樂觀的復制技術輔以gossip協議以確保最終一致性。

如果兩個不同節點上的子系統是相同的，子系統將會直接通過Store與另一個進行同步。但是同步的只是一部分的狀態，如，對于DeviceStore，它只知道設備的狀態而不了解其他的，如怎樣跟蹤鏈接狀態的信息。

目前除了拓撲管理這部分，其他所有服務都要訪問分布式儲存。

兩個子系統間的同步示意圖如下：

結語：

本文介紹了ONOS的模塊化架構及子系統的結構，并通過具體的兩個例子介紹子系統中一些概念的運用情況。希望本文能對各位研究ONOS的研究者有所幫助。