前言：

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

基礎——OSGi:

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

OSGi體系架構：

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

ONOS設計目標：

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

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

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

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

4.協(xié)議不可知：ONOS本身和它的應用都不應該被綁定到特定的協(xié)議庫或?qū)崿F(xiàn)。

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

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

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

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

ONOS子系統(tǒng)結構：

ONOS中，一個子系統(tǒng)是一系列服務的集合。

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

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

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

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

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

Provider：

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

在Provider中還包含Provider Id，一個Provider必須和一個Id關聯(lián)標識。

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

#p#

Manager：

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

它提供了數(shù)個接口：

一個用于給其他組件讀取網(wǎng)絡狀態(tài)的北向接口;

一個用于執(zhí)行管理命令和應用網(wǎng)絡狀態(tài)的AdminService接口;

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

一個提供給已經(jīng)注冊的Provider用來對manager收發(fā)信息的ProviderService南向接口;

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

Application：

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

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

幾個子系統(tǒng)的簡單介紹：

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

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

Device Subsystem包含以下幾個部分：

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

DeviceProviders，每一個都有自己的網(wǎng)絡協(xié)議庫的支持。

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

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

2.Store的職責例子——集群協(xié)調(diào)

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

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

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

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

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

兩個子系統(tǒng)間的同步示意圖如下：

結語：

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