前言：

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

基礎(chǔ)——OSGi:

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

OSGi體系架構(gòu)：

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

ONOS設(shè)計(jì)目標(biāo)：

ONOS的設(shè)計(jì)目標(biāo)包含以下幾點(diǎn)：

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

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

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

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

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

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

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

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

ONOS子系統(tǒng)結(jié)構(gòu)：

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

ONOS定義了幾個(gè)主要的subsystem，如：

Device Subsystem：管理基礎(chǔ)設(shè)備的詳細(xì)清單;

Link Subsystem：管理基礎(chǔ)鏈接的詳細(xì)清單;

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

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

Provider：

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

在Provider中還包含Provider Id，一個(gè)Provider必須和一個(gè)Id關(guān)聯(lián)標(biāo)識。

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

#p#

Manager：

Manager是一個(gè)駐留在core中的組件，Manager負(fù)責(zé)接受來自Provider的信息、為上層應(yīng)用和服務(wù)提供服務(wù)等工作。

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

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

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

一個(gè)被Provider用于注冊的ProviderRegistry南向接口;

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

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

Application：

應(yīng)用程序通過AdminService和其他服務(wù)接口聚合消息，被Manager使用和操作。應(yīng)用程序的功能多種多樣，比如顯示網(wǎng)絡(luò)拓?fù)洹⒐?jié)點(diǎn)等。

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

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

1. Provider的職責(zé)例子——Device Subsystem

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

Device Subsystem包含以下幾個(gè)部分：

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

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

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

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

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

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

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

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

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

目前除了拓?fù)涔芾磉@部分，其他所有服務(wù)都要訪問分布式儲存。

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

結(jié)語：

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