帶你讀《ONAP技術詳解與應用實踐》之三：ONAP架構設計

點選檢視第一章 點選檢視第二章

第3章

ONAP架構設計

本章首先介紹ONAP架構在設計之初的目标與理念，包括要解決什麼問題、需要具備哪些核心能力、相應的架構設計理念和設計原則是什麼等。對于模型驅動等重要設計原則，還輔以具體示例，包括ONAP的實作流程與模型定義示例。了解這些設計理念與原則後，再一步步介紹ONAP的架構、ONAP的各元件與項目歸類。最後介紹ONAP是如何構築安全與可信的代碼品質的，包含思路與落地方法等。

本章會涉及軟體開發與過程管理的常見術語，但會盡量以通俗易懂的方式進行介紹，具有一定的開發經驗的人了解本章内容會更容易些。

3.1　ONAP架構理念

相對以往OSS架構，ONAP架構理念有如下創新點：

• 借鑒了網際網路軟體設計的先進理念，提出設計态與運作态的概念。
• 基于模型驅動的設計架構，在ONAP各項目中落地資料驅動能力，同時提供一個政策驅動的營運管理平台，支援根據資源占用與故障情況，動态實作閉環自動化。
• 考慮到部分營運商可能面臨的複雜場景（覆寫服務、網絡、雲傳遞等全生命周期），ONAP設計了分層的自動化架構，分别提供跨域、無狀态的“編排器”項目，以及面向單領域，有狀态進行編排控制的、更高效的“控制器”項目，所有子產品都是服務化設計，友善按需定制與部署。

在上述基礎上，還借鑒了軟體領域的優秀架構設計理念與原則，最終的ONAP架構藍圖是所有這些有機結合的産物。社群專門成立了ONAP架構委員會，負責管理架構理念和原則。本節将介紹如下重要設計理念：業務無關的平台（Vendor & Service Agnostic廠商與業務無關）、開放性、閉環自動化及DevOps的理念。

3.1.1　業務無關的平台

ONAP定位為自動化使能平台，要能讓不同營運商根據自身需要靈活定制，而不受具體廠商、業務、場景的限制。社群UseCase的目标主要是展示ONAP作為平台的能力，并不追求開發面向特定場景的完整功能實作。也就是說，ONAP不像Linux或OpenStack那樣，版本釋出後就是一個直接可用的軟體産品，或可直接用于特定網絡上，開展與UseCase對應業務的生産化部署；ONAP的版本釋出僅表明已在特定UseCase下驗證了ONAP作為平台的功能，商業部署仍須在此基礎上進行開發與定制。不同版本的功能增強，原則上由UseCase驅動開發，但在具體實作中，會将UseCase特有實作（插件、業務定義，政策定義等）與平台實作分離。社群也建立了CLAMP項目，專門儲存UseCase特有的閉環設計輸出。

3.1.2　開放性

社群緻力于建立一個開放可程式設計的軟體生态，體系結構支援随時采用業界最佳元件、部件（不耦合特定軟體産品或雲平台環境或特定程式設計語言或程式設計架構），ONAP各子產品也都設計成可插拔的，以友善替換與更新。目前ONAP涉及的程式設計語言超過50種，既有常見的Java、JSON、JavaScript、C、Python等，也有Go、Lua、Erlang等。程式設計架構有Spring、Sphinx、Hibernate、Tomcat、ODL、OSGI等多種。當然社群也在牽引歸一化，以減少學習與維護成本，比如推動相似的資料庫歸一，如MySQL、PostreSQL、MariaDB。

開放性的另一個隐藏理念則是“共享”：常用功能或元件鼓勵開發成“一次開發、多次使用”，避免重複開發，鼓勵在前人基礎上進行開發，比如CCSDK項目（控制器層公共服務Common Controller SDK）目的就是将不同領域控制器中的可重用元件與服務彙總起來，以便根據需要定制出符合自身要求的控制器，簡化與加速領域專用的控制器開發。

3.1.3　閉環自動化

CloseLoop閉環自動化（或叫閉環控制）在工業、科研等很多領域都有定義。在ONAP語境中，閉環自動化表示端到端、無人工介入、全流程自動化，且支援動态變更。它是由許多設計态和運作态元素間的協作完成的。運作态閉環始于DCAE（接收相應事件），然後經過微服務循環（如用于事件與拓撲關聯的Homles項目、用于決定動作政策的Policy項目），最後由控制器和編排器執行對應動作。CLAMP用于監視這些循環本身。CLAMP、Policy和DCAE都可以在設計态中建立循環。

圖3-1是閉環自動化示意圖，顯示了使用自動化功能後業務生命周期内的不同階段。

閉環控制是通過DCAE和一個或多個其他ONAP運作态元件共同提供的能力。閉環控制的目标是将日常運維中的FCAPS功能自動化（Fault Management，Configuration Manage-ment，Accounting Management，Performance Management，Security Management，故障管理、配置管理、計費管理、性能管理和安全管理）。其中DCAE負責收集性能、告警、使用情況等事件，并結合A&AI中的拓撲與配置資料等，應用可在這兩類資料基礎上作進一步分析，比如DCAE的子元件Holmes可提供告警或事件與拓撲對象的關聯功能。得到的分析結果再向政策、編排器等系統釋出，後者将決定執行相應動作。

在Casablanca版本中，DCAE可以內建PNDA以支援新的分析功能，利用高容量VES和批量性能管理特性來增強資料采集功能。

通過與政策架構、CLAMP協作，ONAP可以檢測網絡中存在的問題，并确定适當的補救措施。在某些情況下，這個過程是自動的，會通知SO或某個控制器采取行動。在其他場景中，根據操作人員的預先配置，它們會發出一個警報，在人工幹預後再執行操作。政策架構支援對政策的動态重新整理，架構本身也支援擴充以便與其他政策決策系統協同。

自愈或擴縮容等修複動作執行完後，ONAP會繼續對業務進行監控，以保證故障已自動排除或需要其他處理，整個過程也将被記錄為事件。

ONAP閉環自動化也可了解成一種可以分層實施的理念，比如在單ONAP中就存在SO專門負責業務級别的編排，以實作業務執行個體化、業務變更、全局優化部署等的閉環自動化。而對應的Controller控制層則負責控制資源的閉環自動化，包括本地資源的配置設定、回收、調整、擴縮容等。不同領域的控制器可分别負責域内的閉環自動化。

在實際網絡場景中還可存在邦聯部署的場景。比如，國幹網中的SO負責跨省的端到端業務編排，而子域SO則負責省内的業務閉環自動化。子域業務還可分解，進行子域的資源控制器中的閉環自動化控制。

3.1.4　DevOps一體化設計

在軟體開發生命周期中，遇到了兩次瓶頸。第一次瓶頸是在需求階段和開發階段之間，針對不斷變化的需求，對軟體開發者提出了高要求，後來出現了靈活方法論，強調适應需求、快速疊代、持續傳遞。第二個瓶頸是在開發階段和建構部署階段之間，大量完成的開發任務可能阻塞在部署階段，影響傳遞，于是有了DevOps（Development和Operation的組合詞）研發營運一體化。DevOps是一組文化、流程與工具整合後的統稱，基于靈活與精益的理念，從業務和整個價值鍊角度，推動組織優化軟體傳遞方式，從靈活開發，走向靈活運維和靈活業務。

DevOps是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟體傳遞”和“架構變更”的流程，來使建構、測試、釋出軟體能夠更加快捷、頻繁和可靠。DevOps提倡打破孤島，促進開發和運維之間高度協同，在實作小批量疊代傳遞、增量式釋出、高頻率部署、快速閉環回報的同時，提高生産環境中軟體部署及運作的可靠性、穩定性、可伸縮性和安全性。

DevOps的三大原則：

1.基礎設施即代碼（Infrastructure as Code）

DevOps的基礎是将重複的事情使用自動化腳本或軟體來實作，例如Docker（容器化）、Jenkins（持續內建）、Puppet（基礎架構建構）、Vagrant（虛拟化平台）等。

2.持續傳遞（Continuous Delivery，CD）

持續傳遞是在生産環境中釋出可靠的軟體并傳遞給使用者使用。持續部署則不一定傳遞給使用者使用，其涉及兩個時間—TTR（Time to Repair，修複時間）和TTM（Time To Market，産品上線時間）。要做到高效傳遞可靠的軟體，需要盡可能減少這兩個時間。部署可以有多種方式，比如Blue/Green Deployment（藍綠部署）、Rolling update（滾動部署）、金絲雀部署等。

• 藍綠部署：意指有兩套系統，一套是正在提供的服務系統，标記為“綠色”；另一套是準備釋出的系統，标記為“藍色”。兩套系統都是功能完善且正在運作的系統，在獨立叢集環境中運作，一次隻有一個系統對外提供服務，另一系統用于釋出前的驗證、修改等（不幹擾使用者）。更新過程中不停止老版本，在新環境中部署新版本，然後進行測試，确認沒問題後，将流量切到新版本，然後再把老版本更新到新版本。優點是可減少釋出時的中斷時間，能夠快速撤回釋出（切換環境即可）。
• 滾動部署：一般是取出一個或者多個伺服器對其停止服務，執行更新，并重新将其投入使用。周而複始，直到叢集中所有的執行個體都更新成新版本。它相對于藍綠部署，更加節約資源—不需要運作兩個叢集、兩倍的執行個體數。可以部分部署，例如每次隻取出叢集的10%進行更新。
• 金絲雀部署：又稱灰階釋出，這和藍綠部署有點像，但可以進一步規避風險。強調階段性更新或切換，而不用一次性從藍色版本切換到綠色版本。即：在生産環境的基礎設施中小範圍地部署新的應用代碼。一旦應用簽署釋出，隻有少數使用者會路由到它，此時多數使用者業務流量仍流向老版本。在此過程中觀察影響，如果沒有錯誤發生，新版本可以逐漸推廣到整個基礎設施。目前這種部署方式被雲服務提供商，比如網遊公司廣泛采用，以驗證使用者對新特性的接受情況。當然這種方式主要挑戰在于如何設計一種方法以便路由部分使用者到新應用。釋出示意如圖3-3所示。

注釋：礦井中的金絲雀

17世紀，英國礦井勞工發現，金絲雀對瓦斯氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，人類毫無察覺但金絲雀可能已毒發身亡。是以當時在采礦裝置相對簡陋的條件下，勞工們每次下井都會帶上一隻金絲雀作為“瓦斯檢測名額”，以便在危險狀況下緊急撤離。

3.協同工作（Culture of Collaboration）

開發者和運維人員必須定期進行密切合作。開發應該把運維人員了解成軟體的另一個使用者群體。協作有如下幾個建議：

• 自動化（減少不必要的協作）；
• 小範圍（每次修改内容不宜過多，減少釋出的風險）；
• 統一資訊集散地（如Wiki，讓雙方能夠共享資訊）；
• 标準化協作工具（比如Jenkins）。

ONAP構造了完整的CI/CD環境，包括：所有項目都采用Docker容器釋出，并統一采用OOM實作部署管理（短期還同時支援Heat部署方式），采用JIRA跟蹤所有問題，采用Jenkins實作持續部署管理。

3.2　架構設計原則

為了實作以上設計理念，ONAP借鑒了諸多業界軟體設計原則，本章重點介紹其中最重要的幾個原則：模型驅動、微服務化及雲原生。鑒于這幾個術語在軟體領域被普遍使用，可能有不同的了解，是以在本節中，除介紹業界通用了解外，也會補充描述ONAP對設計原則的特有了解與定義。

3.2.1　模型驅動

介紹模型驅動前需要介紹一下什麼是模型。模型是對“事物”的一種抽象化表達，從特定角度對系統進行描述，省略部分不重要的細節，聚焦感興趣的特性。

模型驅動在軟體開發領域有多種表達方式，如MBD（Model Based Development，基于模型的開發）、MDD（Model Driven Development，模型驅動開發）和MDA（Model Driven Architecture，模型驅動架構）。其主要核心都是從模型生成代碼和其他開發過程中的元件，在解決領域問題的同時，提高生産效率，比如：發生變更時，軟體設計不變或變更較少（模型不變）。與之對應的傳統開發方式則是寫死（即使用程式設計語言C、C++、Java、Python等編寫代碼）。但從本質上來說，隻要是進行變更，肯定需要某人/某個APP在某個地方進行某些修改，這樣才能讓變更真正生效。

模型驅動的修改與寫死方式的修改真正的差異在于：誰負責修改，改什麼（包括在哪修改），影響多大。對于傳統寫死方式而言，所有變更都需要由原軟體提供者（即Vendor軟體供應商）來修改，且需要在實際産品代碼上修改，包括重新編譯、釋出、打包等開發環節，再經過商業傳遞流程提供給使用者。而使用者則在此過程中則隻能等待，等待供應商提供修改後的版本，然後再經過入網測試、更新部署等流程後才能在實際網絡中使用。這樣的方式不僅代價大、周期長（一般以月為機關），而且多數情況下，産品更新時還需要将系統關機重新開機，影響較大。如果整個過程中發生任何問題，包括了解上的差異，很可能需要從頭再來。

而對于模型驅動的平台架構，能做到對多數變更，但平台開發者（供應商）不需要參與代碼修改，平台本身也不需要停機、重新編譯、釋出等開發過程。而是由使用者/使用者通過修改外部（相對平台代碼而言）的模型檔案（TOSCA或YANG等）或插件（可能包括JavaScript、Python等動态語言）即可動态生效，這一開發過程在ONAP中被稱為設計。當然為了實作這一點，需要提前定義一些約定：模型的格式（模型檔案應該如何描述）和模型生效的流程（模型如何加載、生效，如果中間出現錯誤如何處理等）。多數模型驅動的架構還會提前定義一些預定制的元模型或領域模型示例，以簡化學習門檻，加速在指定領域中的應用。

在本節中，模型驅動表達的意思是，ONAP支援在不需要修改ONAP自身架構代碼的前提下，通過對模型做組合/變更（新增，删除或修改），實作電信業新業務的上線或更新。一般是通過修改某些腳本及動态加載部分插件或驅動來實作的。

模型驅動并不意味着業務變更完全不需要修改代碼，隻是不需要修改ONAP架構代碼，即分為兩部分：一部分負責對平台的修改（盡可能少甚至不需要），平台的設計人員不參與；另一部分是（在多數場景下）負責新業務發放的業務設計員通過對模型的組合與修改完成的（也可能包括一些腳本的開發）。

ONAP各元件是中繼資料驅動和政策驅動的，以確定功能和特性能靈活使用和傳遞，支援動态增加或變更，而且作為面向電信領域的開源社群，也有利于定義面向電信自動化領域的相關模型規範。具體展現在以下幾方面：

• 全局資料結構：ONAP的全局資料結構都定義在Schema檔案中，檔案名類似aai_schema_v15.xsd（早期Amsterdam版本中的資料模型版本是V8與V9，最新的Casablanca版本已更新為V15了），正常情況下，在SDC中每次修改模型的定義（不是模型對應的執行個體，比如在網元中增加一個“名稱”屬性等），則SDC會自動觸發模型檔案的版本遞增，ONAP的A&AI支援多個版本的模型檔案并存。ONAP社群版本釋出時都會指明具體對應的模型檔案版本号，并将運作态分發到各需要通路模型的元件執行個體下。也就是說，ONAP在代碼層面并不固定描述使用者、網元或裝置的資料模型，即沒有寫死定義這些對象的結構，而是采用Schema腳本進行描述。是以，在需要變更（比如增加對象或某對象增加屬性定義）時，隻要在設計态修改對應Schema腳本，并分發到運作态涉及的元件中即可。在全局存量系統A&AI啟動時會自動加載Schema檔案，并在資料庫中建立對應的表結構與關系。
• 各資源構件：各資源構件（網絡或業務的定義，如BPMN與Policy等）都儲存于可重用資源庫目錄中，友善動态支援資源上線、服務的定義和建立，且支援通過由更簡單的、可重用的資源構件組合成複雜業務。
• ONAP平台自身：ONAP自身特異性也采取類似的中繼資料驅動的方式實作。比如從ONAP的Casablanca版本開始，在CCSDK項目中啟動CDS（Controller Design Studio），通過設計與定義不同的控制器藍圖（Controller Blueprints），即可幫助營運商根據需要靈活定義Controller模闆（比如将有線與無線融合到一個Controller，或者分成不同Controller）。政策驅動在不同層次或領域閉環機制中都有應用，以實作對雲、網絡和業務的實時自動化控制。

1.常見模型

常見模型包括業務模型、概念模型、資料模型、對象執行個體（實體資料模型）和元模型等，分别表示從現實世界到資訊世界的不同層次的抽象。

• 資訊模型、業務模型、概念模型：可簡略記成IM（Information Model，資訊模型），其為對現實世界中真實事物的描述，不涉及具體軟體實作，例如員工、合同、客戶、網絡、站點、裝置等；也包括這些抽象概念之間的關系，比如站點中“包含”裝置、而交換機“屬于”某種裝置等。
• 資料模型：可簡略記成DM（Data Model），這是對業務模型/概念模型的進一步分解和細化，包括所有的實體（抽象代表一類對象，如員工代表所有具體的員工）和關系（實體間的關系）。需要确定每個實體的屬性，定義每個實體的主鍵，指定實體的外鍵，并進行範式化處理。一般在軟體設計中定義對應的資料/對象結構，比如員工包括工号（字元Char(8)）、姓名（最長20個字元的可變字元串varchar(20)）、年齡（數字integer）和出生日期（日期date）等。
• 對象執行個體：英文一般為Instance（執行個體），用于在資料模型基礎上定義每個具體的獨立對象，比如定義員工的資料模型，此時某個具體員工A的工号是00123456，則員工A就是一個執行個體。
• 元模型（Meta Data）：即模型的模型，是模型驅動設計更高一層次的抽象。一般針對特定領域的模型定義抽象概念（元模型），并用其建構該領域中具體資料模型。比如，在網絡領域IPV4（形如“10.10.10.10”的32比特的對象）或IPV6（形如“1:123::ABCD:0:1/96”的128比特的對象）可作為元模型，然後用它來表示新的模型對象，比如VPN（每個接入點都可以是IPV4/IPV6的IP位址）。

目前很多領域都有自己特有的模型及模型語言，如前文所述，ONAP緻力于建立一個開放、可程式設計的軟體生态，支援業界最佳元件，而非一切重新開始，重新發明輪子。是以，ONAP自身也采用了多種模型，比如面向業務與VNF生命周期管理的TOSCA語言，面向網絡層配置管理的YANG語言，内部資料庫模組化又采用XML Schema語言等。下面就一一介紹。

2.常見模型語言

1）XML

XML（Extensible Markup Language，可擴充的标記語言）是1998年2月由W3C（World Wide Web Consortium，網際網路聯盟）正式準許定義的标準通用标記語言。“标記”指計算機所能了解的資訊符号，通過标記，計算機之間可以處理包含各種資訊的文章等。如何定義這些标記？既可以選擇國際通用的标記語言，比如HTML（HyperText Markup Language，超文本标記語言），也可以使用像XML這樣由相關人士自由決定的标記語言，這就是語言的可擴充性。XML是從SGML（The Standard Generalized Markup Language，标準通用标記語言）中簡化修改出來的。XML是一套定義語義标記的規則，這些标記将文檔分成很多部件并對這些部件加以辨別。XML也是元标記語言，即為定義其他與特定領域有關的、語義的、結構化的标記語言的句法語言。

直白解釋就是，XML是一種規則，其把一個文檔劃分為不同的層次或部分，并對這些層次或部分做好标記。這個文檔是能支援不同領域的（比如文學、實體、化學、音樂等），不同領域的文檔可定義其特有的領域語言（也用XML定義）。XML文檔的字元分為标記（Markup）與内容（content）兩類。标記通常以“<”開頭，以“>”結尾；或者以字元“&”開頭，以“;”結尾；不是标記的字元就是内容。

XML有如下幾個特征：

• 内容與形式分離，其設計宗旨是傳輸和存儲資料，而不是顯示資料。
• 良好的可擴充性，标簽沒有被預定義，需要自行定義。
• 被設計為具有自我描述性。
• 遵循嚴格的文法要求。
• 便于不同系統之間資訊的傳輸，是W3C的推薦标準。

一個簡單例子如下：

以圖的方式表達更好了解一些，如圖3-4所示。以上XML腳本描述的是一個學生，記錄了學生如下資訊：年齡、姓名和學校。其中的學生、年齡等即為自定義标簽（tag）。

2）XML Schema

上面的XML例子中，雖然可以描述一個對象（通過自定義标簽），但對于計算機處理來說可能還是不夠的，隻能說明它是文法正确—術語稱為well-formed XML，但不一定合法—術語稱為validating XML。

比如年齡這個标簽，在計算機進行中還需更進一步嚴格定義：資料類型是一個數值，而不是字元串。顯然，說年齡是10（歲），這是合法的（一個數值）；而把年齡說成一個字元串OK或“非常大”，則是非法的。

為了限制一個字段或者說為了限制XML的類型，就有了XML Schema（XML Schema Definition，XSD），它是一套W3C标準，即為用于XML的模式定義語言，其作為關聯的文檔來定義XML标記規範。

以下是一個對Age進行限制的例子。Age這個标簽（XML又稱元素，即element）有如下定義/限制：

• value必須是整型（xs:integer）。
• 值範圍必須是7～50。

3）YAML

YAML（Yet Another Markup Language，另一種标記語言）是一種以資料為中心的标記語言，官方定義為一種人性化的資料格式定義語言。資料組織主要依靠的是空白、縮進、分行等結構。YAML相比XML有如下優點：

• 可讀性好。
• 和腳本語言的互動性好。
• 使用實作語言的資料類型。
• 有個一緻的資訊模型。
• 易于實作。

比如上面那個學生的例子，用YAML語言表述如下。

由于YAML有較好的可擴充性與可讀性，相比XML編碼效率更高，在特定場景下具備明顯優勢。比如常用的動态語言（Python、Ruby等）就支援用YAML定義的資料結構與資料類型。一些常見IT工具也使用它來定義模闆，比如OpenStack的Heat和AWS的CloudFormation、SaltStack、Puppet、Chef。

一個環境描述的Heat執行個體（包括對Nova、Database、Chef的定義）如：

4）YANG

YANG是IETF在RFC 6020中定義的用于網絡配置的資料模型描述語言，支援NETCONF接口協定，實作了網絡配置的标準化，是一種DSL（領域特有語言）。

NETCONF協定（NETwork CONFiguration Protocol）是一個網絡配置管理協定，是由IETF标準組織定義的一套管理網絡裝置的機制。使用者可使用這套機制增加、修改、删除網絡裝置的配置，擷取網絡裝置的配置和狀态資訊。

YANG與XSD（XML Schema Definition）基本是等價的，也即YANG是一種Schema定義的語言，而不是像XML/YAML一樣為了資料的傳輸和存儲。

YANG從裝置維護的角度，将資料的層次結構模型化為一棵樹，樹中每個節點都有名稱，且要麼有一個值要麼有一個子節點集，其還給節點提供了清晰簡明的描述，同樣提供了這些節點間的互動。相比XML Schema，YANG語言定義的資料模型沒有晦澀的内容，可讀性好、簡單易懂、可擴充。目前YANG已在裝置配置領域被普遍接受，IETF、ONF等标準組織都要求送出的模型用YANG來寫。其他組織，如Openconfig，OpenDayLight等也普遍支援YANG。

下面為用YANG定義的一個RPC（遠端程序調用）的示例，表示一個activate-software-image的遠端調用方法，輸入是一個string參數image-name，輸出是string類型的status：

5）TOSCA

TOSCA全稱是Topology and Orchestration Specification for Cloud Applications，是一種資料模組化描述語言，是由OASIS組織（

https://www.oasis-open.org/

）制定的面向雲計算環境中的應用拓撲和編排描述語言，目前支援YAML和XML實作。

TOSCA的基本概念有兩個—節點（node）和關系（relationship），且都可通過程式來擴充，同時TOSCA規範中也支援Plan（即Workflow工作流檔案）。

（1）節點預定義了很多基礎類型，包括雲基礎設施中常用的計算節點、網絡節點、資料庫節點等。

（2）關系定義了node之間的關系，具體如下：

• DependsOn（依賴于）：表示節點間的順序依賴關系，一般影響執行個體化過程中的建立順序，比如A節點依賴于B節點，則在建立A對象前須提前建立B。
• HostedOn（運作于）：比如“MySQL資料庫”與“計算機”的關系就是HostedOn的關系，即資料庫運作在計算機上。
• ConnectsTo（連接配接）：表示連接配接關系。

TOSCA面向雲計算環境中的應用拓撲和編排場景來預定義一些屬性，是以一般認為較适合用于解決以下場景中的需求：

（1）自動化的軟體部署和管理。

（2）應用生命周期（安裝、擴容、解除安裝等）管理方案的可移植性（注意：不是應用本身的可移植性）。

（3）元件之間的互操作性和重用性。

注意：OpenStack中的Heat子子產品也是基于TOSCA标準的。

考慮到YANG、TOSCA都具備較強的擴充能力，個人認為語言本身沒有本質差別，也不存在誰一定更适合某領域的說法，這更多是不同領域習慣的差異問題。IETF、OASIS等組織也都在不斷擴充兩種語言。

比如，NFV領域的VNFD，就是以TOSCA描述檔案（可以是YAML或XML格式）進行說明的，包括安裝軟體過程中都有哪些元件、元件之間有什麼依賴關系等；當然，實際運作時還需要用TOSCA運作态環境來對TOSCA檔案進行讀取（分析檔案的文法、語意）和解釋執行（進行具體的軟體安裝、配置工作）。

一個TOSCA描述檔案（稱為Service Template）示例：在遵循TOSCA 1.0和描述資訊description之外，還需要遵從拓撲模闆，包括一個名為my_server的節點，類型是tosca.nodes.Compute。該類型預置了兩個capabilities資訊，一個是host，定義了硬體資訊；另一個是os，定義了作業系統資訊。

TOSCA腳本還可用于表達對輸入、輸出的模組化。比如，以下就定義了一個新節點類型—tosca.nodes.DBMS.MySQL。該類型允許接收root_password和port的參數。在requirements裡定義了mysql這個節點，該節點需要被安裝到db_server節點上，這就是“關系”。

ONAP SDC項目使用TOSCA來描述Serivce業務、Resource資源對象，而且定義了一些電信運維領域的資源/管理對象（CP連接配接點connection Point，VL虛拟連接配接Virtal Link等），以簡化設計。

由圖3-5所示可看出，一個vIPR ATM service包括兩個Node：一個VNF（vIPR ATM VF），一個外部網絡VL連接配接（vIPR ATM OAM Net）。當然，真正的場景中業務可能會複雜得多，如多VNF及多VL連接配接等。VNF自身也可能是更細粒度的對象，隻不過是以模型方式組合而已。比如上例中，VNF（vIPR ATM VF）由更小的VFC、VL及CP組成。示例模闆如圖3-6所示。

3.模型設計示例

由于對象之間存在複雜關系，且不同對象可分别對應不同模型檔案，是以在OASIS組織中就定義了一種把多個模闆檔案以特定方式組織并進行Zip打包後的存檔包格式，即CSAR雲服務存檔（Cloud Service Archive）。它支援雲應用程式生命周期執行和管理所需要的檔案，包含不同類型的多個檔案（英文叫artifacts）。這些檔案通常組織在幾個子目錄中，每個子目錄包含的檔案都是相關的（可能還有其他子目錄）。

每個CSAR必須包含一個所謂的清單檔案。此檔案名為manifest，檔案擴充名為.mf。它表示CSAR中其他檔案的中繼資料，這些中繼資料以“名稱/值”對的格式提供。

一個ONAP的CSAR檔案示例結構如圖3-7所示，商用部署場景下還可能包括License檔案、metadata中繼資料目錄等，CSAR架構細節定義可參見

https://wiki.onap.org/display/DW/Csar+Structure

。

CSAR檔案是ONAP中模型上線、校驗、分發的原子機關，且每次對模型進行修改變更之後，都必須修改模型版本号。

ONAP支援多種DM格式，如Heat、TOSCA、YANG等，但内在的IM資訊模型是保持一緻的，即從VNF廠商提供CSAR包開始，ONAP可能會對DM做一些映射與轉換，但因為有統一的IM模型，是以屏蔽了廠商差異，如圖3-8所示。

VNF網元供應商需要按VNF SDK項目的要求準備好相應的CSAR檔案，其中最重要的就是VNFD檔案（VNF Description，VNF描述檔案），它不僅定義了VNF的基本情況資訊（名稱，版本号，供應商），還明确了VNF對計算、存儲、網絡等基礎設施的細節要求，以及支援哪些操作、如何操作對應的工作流檔案等。然後将準備好的檔案按VNF SDK項目的要求，進行自動化測試驗證，之後即可加入ONAP的設計态目錄，并被ONAP系統使用（這稱為onboarding上線）。ONAP在編排過程中，可能會根據各項目的需要對相應DM資料模型做一些轉換/處理，比如，SO與Controller可能将類似資訊儲存到不同資料結構中，但整個IM資訊模型在整個ONAP中是共享的。在ONAP的A&AI全局資料庫中，盡量采用通用的DM定義，比如，業務執行個體定義可表示任何業務，即原則上并不會因為新增了一個領域的業務，或新增對某廠商VNF的支援而要求A&AI修改資料庫結構定義。

具體流程如圖3-9所示（參見

https://wiki.onap.org/display/DW/Onboarding+Services+into+

SDC+and+Instantiating+through+VID）。

步驟1　在VNF SDK中驗證VNF/CNF。

VNF SDK驗證通過的VNF/CNF（Containized Network Function容器化的網絡功能）會将相關CSAR檔案自動加入SDC目錄中，并作為資源等待處理。

步驟2　通過SDC界面進行相關設計。

使用者在SDC的GUI界面中設計生成對應的模闆檔案，包括在界面上import導入外部的資源模型檔案（上一步中VNF/CNF的TOSCA CSAR包）。

在SDC設計界面中設計資源與業務，及其之間的映射關系，如VF、Service等，并将其加入SDC目錄中（可用于後續基于此做更改或進一步設計封裝）。

将所有設計結果導出為對應的csar包（包括生成對應的版本号），并送出測試驗證。

此時由負責測試和校驗的使用者角色登入SDC，測試人員與校驗人員完成測試和校驗後（線下方式等），進入SDC中稽核并讓流程進入下一環節。如果此環節發現問題，可傳回。

步驟3　設計結果通過SDC分發引擎分發到運作态各元件。

管理者進入SDC後，可點選Distribute将模型檔案從設計态向運作态的各執行個體分發（運作态各執行個體之前就已在DMaap總線注冊了要監聽的模型檔案類型），相關SDC Message Broker分發總線則會根據注冊情況，發送通知給相應運作态執行個體。

各運作态元件執行個體（SO、A&AI、Controller等）收到通知後，會主動從SDC目錄中擷取設計态中已完成的模闆檔案—CSAR包及對應的Artifacts傳遞件，并将之導入自身目錄中。此時運作态元件即支援了新的模型對象，等待上層OSS或GUI界面對業務進行執行個體化。

4.模型定義示例

舉例而言，Device裝置的定義如下：包括device-id屬性、esn号、device name裝置名稱、Description裝置描述、Vendor供應商、Classic分類等。在A&AI全局資料庫中的定義如圖3-10所示。

打開Schema檔案，僅須關注Device類。以屬性device-id和esn号為例，對應描述如下：

Schema檔案基本上是自解釋的，可看出device-id屬性和esn号都為String字元串類型，目前沒為其指定預設值，其Description字段中簡要描述了屬性的含義。

對應的aai_schema_v15.xml則根據Schema檔案自動生成Java語言定義的XML檔案，具體如下：

最後的ref="tns:relationship-list"字段代表與Device對應的對外引用關系清單，這是ONAP模型定義的一個常見的基礎屬性類型，因為ONAP的A&AI系統是基于圖資料庫系統設計的，是以支援根據不同的relationship從一個對象查詢相關聯的對象。比如，查詢在一個AZ内，屬于某個特定租戶的所有VM的所有網卡上的IP位址清單。如果是傳統關系型資料庫，則很可能需要一個非常複雜的App才能完成。有了圖資料的關系，采用Traverse查詢方式，通過一條指令即可傳回結果。

圖3-11所示可簡要解釋關系清單的組織，它可包括一系列的關系relationship，而每個關系又有指向的對象、關系的Label描述、Link、關系對應的Key/Value對及屬性等。

對應Schema檔案定義如下（"relationship-list"是"relationship"的List清單對象）：

3.2.2　微服務化

服務化架構（Service-Oriented Architecture，SOA）是一種粗粒度、松耦合的以服務為中心的架構，服務之間通過定義明确的協定和接口進行通信。這裡說到的“服務”，本質上來說就是指RPC遠端程式調用。面向服務架構（Service-Oriented Architecture，SOA）是Gartner于20世紀90年代中期提出的概念，主要面向分布式系統的開發。多數是遵從著名SOA專家Thomas Erl的歸納：

• 标準化的服務契約（Standardized service contract）。
• 服務的松耦合（Service loose coupling）。
• 服務的抽象（Service abstraction）。
• 服務的可重用性（Service reusability）。
• 服務的自治性（Service autonomy）。
• 服務的無狀态性（Service statelessness）。

• 服務的可發現性（Service

  discoverability）。

• 服務的可組合性（Service composability）。

這些原則要達到的目的是：提高軟體重用性，減少開發和維護的成本，最終增加業務的靈活度。

微服務架構則是一種服務化架構，提倡将單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務運作在其獨立的程序中，服務與服務間采用輕量級的通信機制互相協作（通常是基于HTTP協定的RESTful API）。每個服務都圍繞着具體業務進行建構，并且能夠被獨立部署到生産環境、類生産環境等。

微服務的誕生并非偶然。它是網際網路高速發展，靈活、精益、持續傳遞方法論的深入人心，虛拟化技術與DevOps文化的快速發展，以及傳統單塊架構無法适應快速變化等多重因素的推動下所誕生的産物，涉及業務、開發、測試、部署、運維等多個環節。但具體拆分到什麼粒度才叫微服務，業界并沒有明确量化的标準，需要根據業務上下文、團隊、流程實踐等共同衡量後定義的。

具體到軟體開發中的實作技巧，推薦參考PaaS先驅Heroku公司的CTO Adam Wiggins提出的“微服務12因子”的理念（

https://12factor.net/zh_cn/

）。

SOA與微服務架構在很多地方是重合的（可以混用）。如果要區分的話，SOA關注的是服務的重用；微服務則在關注服務重用的同時，也同時關注快速傳遞。

ONAP架構支援微服務化，各項目都分成多個獨立服務，可單獨部署。服務之間的通信經由DMaap或MSB項目（都是基于Kafka建構的服務），支援彈性縮放和CI/CD環境的內建。

3.2.3　雲原生設計

什麼叫雲原生（Cloud Native）？曆史上有多個定義。2010年，WSO2的聯合創始人Paul Fremantle在業界最早提出Cloud Native，認為其有如下幾個關鍵特征：

• Distributed/Dynamically wired，分布式/動态連接配接。
• Elastic，彈性。
• Scale down as well as up, based on load，基于系統負載的動态伸縮。
• Granularly metered and billed，粒度合适的計量計費。
• Pay per user，按使用量計費。
• Multi-tenant，支援多租戶。
• Self service，支援自服務。
• Incrementally deployed and tested，支援增量的部署與測試。

雲原生系統的效果應該是更好地利用資源，更快地提供資源，更好地管理。

在2013年，AWS的雲戰略架構師，同時也是NetFlix的雲架構師Adrian Cockcroft提出對Cloud Native新的定義：基于不可靠的、易失效的基礎設施（ephermeral and assumed broken components）建構高度靈活（high agile）、高可用（highly available）的服務。

2015年，Google聯合其他20家公司宣布成立了開源組織Cloud Native Computing Foundation（CNCF），開源了Kubernetes。Kubernetes是一個以應用為中心的容器編排、排程叢集管理系統，希望成為CloudNative Application的基石。從CNCF組織來看，Cloud-Native Application應該包含微服務、容器、CI/CD特征。

根據一般的了解，Cloud Native背後的軟體架構需求有：

• 按需特性的伸縮。
• 按特性持續演進。
• 應用快速上線。
• 系統高可用。
• 全面解耦合。
• 系統自服務。
• 支援多租戶。
• 異構公有雲。

ONAP目前支援在OpenStack及微軟Azure上運作，未來還計劃支援AWS。

3.3　架構與元件

從第一個版本的Amsterdam開始定義ONAP的整體架構，後續各版本都有微調，但整體架構是一脈相承的。最新的釋出版是Casablanca版（2018年11月釋出），是以本書就以該版本為例來說明相關架構。圖3-12所示架構是2018年8月23日在社群TSC會議準許的3.0.3版本。

圖3-13是從模型驅動角度進行簡化後的ONAP概要示意圖。

注：IM表示資訊模型，DM表示資料模型，VNF SDK、SDC、SO、DCAE、A&AI、SDN-C/APPC/VF-C都是ONAP的具體項目名稱。

假設：營運商X計劃基于廠商X提供的VNF（虛拟化網元）來為最終使用者提供業務（最終建立業務A、B、C）。其大緻流程與模型在ONAP各項目中的互動流如圖3-13所示，圖3-13下部的幾方塊代表ONAP中的關鍵項目/元件。從左往右，VNF SDK（負責VNF的驗證校驗）與SDC（負責業務設計）屬于設計态項目，A&AI（全局資料庫）、SO（跨域業務編排）、SDNC/APPC/VFC（單域控制器）、DCAE（負責資料采集與分析，與政策等項目共同構成閉環控制）等都是運作态項目。圖中所示的大緻流程如下：

步驟1　廠商X按VNF SDK項目提供的SDK開發工具包與開發指導要求，準備好VNF網元的描述檔案、CSAR包等。這一步驟目的是，以機器可讀的方式讓ONAP了解VNF網元的模型情況，包括網元名稱、版本号、廠商名稱、對軟硬體的資源要求、支援的操作等。這一階段可認為是完成了VNF網元的入網測試過程。

步驟2　通過VNF SDK測試認證的CSAR包（包括對VNF網元的模型描述檔案等）被加載到SDC。此時營運商的設計人員可将VNF網元作為可重用的資源來進行設計，與之前支援的資源（比如資料中心的資源，包括計算、存儲、網絡、其他VNF或PNF、實體網元等）一起，根據需要設計成新業務模闆。設計模闆的好處在于，可要求将此類業務的通用配置在模闆中提前設計好，以降低在具體業務執行個體化過程中的輸入負擔。假設最終需要建立A、B、C共3條業務（有不同的輸入輸出IP位址、名稱，對應不同客戶），在業務模闆中就可以定義業務必須經過哪些VNF網元的處理、是否需要有保護，以及業務配置後需要重點監控哪些性能名額、一旦發生故障之後應采取哪些行動等共性配置。在這一階段輸出的資料模型稱為AID（Architecture integration document，架構內建文檔），它最終也以CSAR包格式導出，并經過測試、稽核、驗證等環境後，被分發給後續ONAP各子產品。至此就完成了新業務的設計及上線過程。

步驟3　當收到業務執行個體化相關請求時（通過BSS/OSS或者使用者手工配置等），SO（Service Orchestrator，業務編排器）根據收到的業務執行個體化參數資訊及業務模闆ID調用相應的工作流處理，包括建立具體的業務執行個體（A/B/C）及将其儲存到A&AI（全局資料庫Active and Available Inventory）；評估業務對應的資源需求，并以合适的方式滿足；将跨域的資源按要求分解成單域指令并調用對應的單域控制器（SDN-C/APPC/VF-C）完成對應的資源配置；相關資源占用情況也會同步重新整理到A&AI中。至此就完成了新業務發放過程的自動化。

步驟4　業務發放成功後，DCAE（Data Collection，Analytics and Events，資料采集&分析）模闆開始按業務設計的要求開始對特定事件進行持續監控。一旦發生指定的事件，則觸發對應的閉環控制，按預定政策觸發相應的動作。至此就完成了業務生命周期中維護過程的自動化。

從以上簡要描述可以看出，ONAP作為一個自動化平台，覆寫了從供應商裝置的入網測試、上線到将其與其他資源一起設計為新業務并自動發放、自動維護管理的全過程。

3.3.1　設計态架構和運作态架構

ONAP大體上可劃分為兩大架構：

• 設計态架構：用于對平台進行設計、定義和程式設計的設計期架構（統一上線）。
• 運作态架構：執行設計态架構所編寫的邏輯（統一進行傳遞和生命周期管理）。

ONAP并不是簡單內建這兩個架構，而是非常緊密地結合，結合兩者的就是模型，即設計态架構輸出的模型，就是運作态架構的輸入，模型檔案通過SDC中的分發功能實作二者的無縫對接，如圖3-14所示。

1.設計态架構

ONAP設計态架構是設計、定義和程式設計的架構，目标是友善開發可部署、可重用的軟體資産，滿足業務全生命周期的需要：增加新功能、修改已有能力、持續維護提升等。這是網絡DevOps人員操作的重點，未來網絡的自動化運作，多數工作都是在該平台上進行的。在ONAP上主要涉及三個項目：

• VNF REQS（VNF Requirements，VNF需求）：描述與定義可被ONAP管理的對象的需求。
• VVP（VNF Validation Program，VNF驗證程式）：驗證基于VNF REQS規範的VNF HOT模闆和環境檔案。
• VNF SDK：搭建測試驗證可被ONAP管理對象的一個工具鍊平台，對符合ETSI NFV标準的VNF（TOSCA腳本描述）進行測試驗證。它也是LFN的CVC（相容認證項目）的重要組織部分，用于支援以代碼化的方案驗證可管理對象（VNF或PNF）是否滿足VVP定義的需求。如果驗證通過，則将其上線到設計态架構的目錄中，供SDC設計使用。
• SDC（Service Design and Creation）：定義了多種角色以分别負責業務與資源設計、設計結果測試驗證、資源确認等流程。完整設計工作至少需要定義設計者、測試者、驗收者這三類角色。當然使用者還可按需定義安全專家、客戶專家、運維專家來建立相關模型、政策和工作流等。

2.運作态架構

運作态架構提供執行架構來執行邏輯，包括兩大場景：業務執行個體化的自動化部署、自動發放場景（通過協同器與控制器兩層機制來實作）及閉環控制場景（包括監控、分析、政策等閉環驅動架構能力）。

業務執行個體化的自動化部署和發放，即按使用者在設計态架構中的設計結果及相應執行個體化的輸入資訊，實作新業務發放。業務發放過程中需要根據工作負載進行優化，選擇對資源的最優部署方案，同時觸發DCAE系統對設計态明确需要關注的事件進行實時監控。這一階段完成後，即表明業務已開通，完成了與使用者的業務互動。

閉環控制場景則是由事件觸發的，即在特定事件或故障發生時，根據預置的動态政策實時閉環處理。它也是前面提到的閉環自動化中的主要使能部分，即設計→建立→收集→分析→檢測→釋出→響應中除設計之外的所有部分。

運作态架構從自行化層面可分為兩層：編排層與控制層。二者的功能有部分重疊。其中編排由跨領域的業務編排器（Service Orchestrator）實作，而控制由各單領域的Controller控制器（包括Multi-VIM，VF-C，SDN-C，APPC等）實作。

運作态架構還包括一些核心元件與服務：

• 公共服務（Common Services）：提供通路控制、消息&檔案轉發、日志、資料管理等功能。
• 控制器層公共服務（Common Controller SDKC，CSDK）。
• 全局資料庫（Active and Available Inventory，A&AI）。
• 資料采集&分析（Data Collection, Analytics and Events，DCAE）。
• 政策架構（Policy）。

運作态架構還包括一些周邊服務和子產品，它們一般是可選的：

• 管理界面（Dashboard）。
• 優化架構（OOF，ONAP Optimization Framework）。
• 安全架構（Security Framework）。
• 內建測試（Integration）。
• 外部接口（External API）。
• 運維部署服務（ONAP Operations Management，OOM）。

3.編排與控制

編排（Orchestration）本為管弦樂中的術語，主要是研究各種管弦樂器運用和配合的方法，通過各種樂器的不同音色來充分表現樂曲的内容和風格。但它在計算機領域被描述為對複雜系統、中間件（middleware）和業務的自動化安排、協調和管理。它與自動化的差别在于，自動化通常專注于一個任務，而編排通常是指與特定任務無關的自動化排程能力，常指對流程與工作流的自動化。通過某種描述語言定義相關工作流，同時由編排器（Orchestrator）負責根據加載的工作流執行對應的動作。

而控制原本是控制論中的術語，描述根據控制對象輸出回報來進行校正的控制方式，比如在實際測量值與計劃值發生偏差時，按定額或标準來進行糾正。在SDN領域也引入了控制器（Controller）的概念，負責領域内的資源自動化。

在ONAP中，對編排器和控制器都給出了自己的定義，其中控制器與行業中的一般概念是有差别的。

首先，這裡的控制器與行業中的控制器都有Orchestration編排的能力，即支援根據預先定義的工作流或流程，在運作态架構中解析并執行相應動作。這與寫死的自動化過程的最大差别表現在圖形化設計和修改工作流的能力，這跟模型驅動的設計理念是一脈相承的。借助便利的定義操作和無須開發投入的變更操作，編排器提供了靈活的适應性，縮短了新業務或變更業務的上市時間，是ONAP架構靈活性的主要使能技術，與Policy政策組合在一起，共同提供了可靈活定義流程的能力，讓使用者從業務和技術政策出發，靈活地完成自動化任務。

ONAP運作态架構在絕大部分場景中均無須人員介入，需要人員介入往往是在設計流程之前（在設計态架構中完成），但部分過程有可能需要人員幹預或是選擇動作，如進行例外或事後處理時。

編排支援同時處理大量請求，是以，編排器引擎被設計成一種可重用的服務，以便ONAP的任何元件中都可以執行預定義的過程方法。編排服務提供一套公共API來保證跨ONAP元件的互動的一緻性。編排器引擎可解析工作流并遵照執行。這種服務化的設計模式可保證跨所有編排活動的一緻性，并保證工作流執行環境一緻。

其次，ONAP中的編排器和控制器的差異僅在于：自動化适用領域的目标與範圍/層次不同，對編排效率的要求不同，被編排對象是有狀态的還是無狀态的，如圖3-15所示（注：MSO項目在ONAP最新版本中已換名為SO，ASDC換名為SDC）。

SO即業務編排器，負責從最頂層管理編排工作和實作對下層控制器間的編排，包括理順控制器間的資料互動，幫助其根據指定的流程和所需資訊去完成相應方法所指定的動作。通過自動順序執行按需建立、修改或移除網絡、應用或基礎架構業務和資源所需的活動、任務、規則和政策，執行指定的流程。SO在一個非常高的層次上進行編排，并提供基礎設施、網絡和應用的端到端視圖。

SO性能要求相比控制器更低（圖3-15所示的分鐘級隻是示例，具體要求視業務場景而定），且一般要求被編排對象是無狀态的。對新業務來說，這可能涉及業務、資源優化部署的決策，以及為滿足業務請求參數，選擇具備相應能力的控制器來處理。如果現有控制器（基礎設施、網絡或應用）不存在或不具備相關能力，SO将建立并執行個體化一個新的控制器，以執行相應業務請求。

SO通過通路A&AI取得已有網絡和對應控制器的資訊來支援業務請求。A&AI提供可支援業務請求的候選控制器的位址；然後SO詢問控制器是否仍具備相關能力；最後SO和控制器向A&AI報告完成業務請求的參考資訊，以供随後的操作使用。SO執行的編排工作包括：

• 現有業務的傳遞或變化。
• 業務伸縮、優化或遷移。
• 控制器執行個體化。
• 容量管理。

盡管重點在編排，所有方法仍需要使用配置資訊、辨別符和IP位址來更新A&AI。

控制器是一些應用程式，這些應用程式将雲和網絡業務耦合，并執行配置和實時政策，以及控制分布式元件和業務的狀态。營運商可以選擇使用多種不同類型的控制器來管理執行環境中與其配置設定的控制域中相應的資源。控制器負責單業務或網絡領域的自動化編排，效率要求一般是秒級或更高。其管理對象可能是有狀态的，意為控制器需要儲存相應領域資源的狀态，并能對相應事件進行實時響應。目前社群主要有如下控制器：

• 基礎設施控制器（Multi-VIM）：為VIM/雲提供基礎設施适配層，除了提供标準VIM的管理功能适配外，還可提供對HPA（硬體平台感覺功能）的支援，以便OOF及SO/VF-C等元件基于硬體差異對資源進行最優化部署。比如，Multi-VIM可在SO的請求下建立/啟動一個或多個虛機，并加載合适的VNF。當Multi-VIM完成請求之後，會把虛拟資源識别符和通路資訊（IP）傳回給SO并更新到A&AI等，以供其他制器使用。
• 網絡控制器（SDN-C）：建構和操作方式跟基礎設施控制器類似，支援在SO的請求之下，建立LAN或WAN連接配接并進行配置。
• 應用控制器（APPC）：在SO的請求下完成VNF的執行個體化、配置或規模伸縮等LCM操作。需要注意的是，APPC不負責VNF的建立與删除，這是在SO層面完成了的（更新A&AI即完成），即VIM基礎設施層的資源配置設定等由SO調用基礎設施控制器完成。APPC比較适用于簡單的VNF（單虛機或容器）或者多VNF，但多VNF之間沒有複雜的網絡或依賴關系。
• 虛拟功能控制器（VF-C）：ONAP的控制器領域提供了符合ETSI NFV MANO标準的解決方案，它提供的是符合ETSI NFV标準定義的NS（網絡業務，Network Service）粒度的接口。VF-C适用于類似vEPC、vIMS等複雜電信級VNF（需要多個虛機或容器資源，且互相之間有複雜的網絡與依賴關系等），VF-C一般通過自身擁有的通用VNF管理器gVNFM或對接符合ETSI NFV标準的廠商VNF管理器sVNFM來實作對NS的LCM管理。

注：控制器目前選擇與編排器不同的編排引擎，在SO中使用的是Camunda工作流引擎，編排腳本是符合BPMN标準的bpmn腳本，而SDN-C與APPC使用的是DG（有向圖）工作流引擎，腳本采用Node-Red（一個面向IoT場景的工作流開發工具

https://nodered.org/

）的XML檔案。目前DG引擎在CCSDK項目中，未來不排除某些控制器采用其他編排引擎甚至重用Camunda引擎的可能。

3.3.2　業務編排器與網絡控制器的架構對比

本節以SO與SDN-C的架構示意（見圖3-16）為例來簡要說明在ONAP中，控制與協同的異同。

SO（業務編排器）的架構從上向下描述，分别是：

API Handler：API的處理層，包括不同API的适配、分批處理等功能。

• 資料存儲部件：提供Catalog目錄存儲功能，外部系統可通過通路目錄來了解SO目前支援的業務類型（來自SDC設計結果的分發）。内部其他子產品（包括BPMN執行引擎等）也可從中擷取與指定業務模闆對應的業務邏輯腳本（Service Recipe）。請求資料庫則儲存所有收到的業務請求，包括業務的執行個體化請求、業務變更請求等。
• BPMN執行引擎：具體的工作流執行單元。根據從API Handler中獲得的業務模闆來配置相關參數、需要執行的操作類型。通路目錄DB，找到對應的業務邏輯腳本（Service Recipe），并執行之。在具體執行步驟中可能調用适配層，以觸發控制器層完成後續的配置工作。同時，也可能在A&AI全局資料庫中建立/重新整理對應的業務執行個體。
• 适配層：用于對周邊元件的适配，包含對SDN-C網絡控制器的擴充卡、對基礎設施資源管理層的擴充卡等。

SDN-C的架構如圖3-17所示。由圖可看出，SDN-C架構設計理念與SO基本上是一緻的。其他控制器也類似，這裡僅用SDN-C作為示例。社群CCSDK項目提供了控制器的通用架構，以幫助使用者快速開發類似架構的控制器。圖3-17所示架構從上向下，分别是：

• API Handler：類似SO的API處理層，唯一差别就是對接的系統不同。
• 資料存儲部件：提供單域控制器自身的Catalog目錄存儲功能。由于控制器需要處理有狀态的編排，是以SDN-C的資料存儲部件可能儲存一些單域特有的資源狀态資訊，可能與SO儲存的資源狀态不一緻。
• DG執行引擎：SDN-C的業務邏輯執行單元，選用DG（有向圖）工作流引擎，根據從API Handler中獲得的業務模闆配置相關參數、需要執行的操作類型。通路目錄DB，找到對應的DG業務邏輯腳本，并執行之。在具體執行步驟中可能調用适配層，以觸發控制器層完成後續的配置運作。同時，也可能在A&AI全局資料庫建立或重新整理對應的業務執行個體。
• 适配層：SDN-C的适配層基于OpenDayLight的MD SAL架構開發，是以對YANG語言有較好的支援，内部有配置樹與操作樹兩類處理。

從以上SO與SDN-C的對比可以看出，控制器與協同器在架構設計理念上是一脈相承的：業務邏輯處理單元一個是BPMN工作流引擎，一個是DG有向圖引擎；另外在對TOSCA與YANG的內建程度上有些差異，内部資料庫儲存的狀态根據适用場景的不同也有所不同；其他都是類似的。

3.3.3　核心服務&子產品

核心元件與服務，即使用ONAP必然涉及的服務與子產品，這些元件也是以服務形式提供的，原則上應該越少越好。

核心元件與服務提供必需的基礎能力（日志等）及與周邊系統互通的能力，包括通路控制、消息&檔案轉發、日志、資料管理等公共功能。涉及項目主要有：

• DMaaP（Data Movement as a Platform）：提供高性能的資料移動服務，因為ONAP内部需要多種資料移動，比如設計結果檔案要從設計态分發到運作态、資料采集結果檔案在各元件間轉發、資料Schema檔案變更後也要分發等。
• MSB（Micro Service BUS）：提供微服務架構能力，包括服務的注冊與發現、網關流量均衡（load balancer）等。從Casablanca版本開始，還逐漸開始增加Service Mesh的內建。
• AAF（Application Authorization Framework）：在ONAP内部元件間提供一緻的身份驗證、授權和安全性能力，以便應用程式、工具和服務能夠比對執行功能所需的通路。包括證書管理器等功能。
• Log（Logging Enhancements Project）：ONAP包括不同的元件或容器，這些需要寫入不同的日志檔案中，故日志檔案資料量可能很大（尤其是在排程等環境中），需要各元件遵循統一的日志規範和日志工具，以便對跨元件、跨檔案的日志進行跟蹤分析等。
• CCSDK（Common Controller SDK）：提供控制器之間可重用的服務化元件，用于大幅提升Controller定制/開發的效率，包括NBI接口統一處理架構、與AAI資料同步、統一的plug-in插件架構（基于OpenDayLight的MD-SAL）、LCM生命周期管理架構、統一的HealthCheck健康性檢查架構、統一控制器的日志管理元件、通用模型管理元件等。
• A&AI（Active and Available Inventory）：在服務化架構中，各個服務可擁有自身資料庫，但所有需要其他元件了解或通路的資料模型與執行個體，都須同步到A&AI中。是以，基本上所有ONAP元件都有與A&AI互動的需求。
• DCAE（Data Collection，Analytics and Events）：用于統一處理除業務與Top資訊之外的所有事件類資料的采集、存儲與分析。自身的Health事件、日志資料、異常、需要監控的異常處理等都需要與DCAE進行互動。
• Policy：政策是實作閉環自動化的一個關鍵環境，負責政策規則集的維護、分發和處理。政策為建立和管理易于更新的條件規則提供了一個集中的環境。

3.3.4　其他元件

運作态架構中除核心元件外，其他所有項目都可劃分為周邊服務&子產品，可基于特定UseCase場景選擇使用。常見的有：

• 管理界面Dashboard：提供集中的元件監控與管理界面，包括業務的執行個體化下發等。
• 優化架構ONAP Optimization Framework（OOF）：一個政策驅動的工作負載優化服務，可基于各種政策限制（包括容量、位置、平台能力和其他特定的業務限制）做到跨多站點和多雲的業務優化部署。
• 內建測試Integration：提供ONAP内部各元件間的內建服務。
• 外部接口External API：用于ONAP與外部系統（OSS/BSS）的API互動。
• 運維部署服務OOM（ONAP Operations Management）：提供基于容器的ONAP元件部署服務。
• MUSIC：記錄和管理Portal、ONAP優化架構的狀态，以確定跨地理分布的ONAP部署的一緻性、備援性和高可用性。

3.4　安全與可信的代碼品質

社群對ONAP的代碼品質進行衡量時主要是通過七個次元實作：魯棒性（Stability）、安全性（Security）、可伸縮性（Scalability）、性能（Performance）、韌性（Resiliency）、可管理性（Manageability）、可用性（Usability）。通過為各次元定義不同級别的度量名額（0～3），并在版本開發中要求各項目針對這些名額不斷優化，最終達成改善代碼品質的目标。在ONAP社群，這幾個名額簡稱為S3P（Security, Stability，Scalability, Performance）。

社群架構委員會例行與各項目協商，針對版本現狀，定義各版本的品質名額目标與适用項目等。各次元度量名額定義如下。

1.魯棒性

魯棒性又稱可靠性，是軟體系統最重要的品質名額。根據ISO9000國際品質标準（ISO/IEC9126-1991）的規定：魯棒性是指在規定時間内及條件下，軟體能維持其性能水準的能力。一般用在一段時間内密集強化輸入的測試方式來驗證，即輸入比正常輸入更惡劣（合理程度内的惡劣）的資料，同時盡可能多地覆寫調用的子子產品。這種測試方式在軟體領域也叫浸泡測試（soak test），即盡量貼近實際使用情況，在一個穩定的、有一定負載的環境上，持續長期測試并實時監控CPU、記憶體、磁盤IO等名額變化，以發現記憶體洩漏、頻繁GC等性能問題。ONAP對魯棒性的要求如下：

• Level 0（0級）：在版本釋出要求中，無魯棒性内容。
• Level 1（1級）：版本已執行過72小時元件級浸泡測試（穩定負載下的随機事務測試，且對主要代碼分支，代碼覆寫率達到80%以上）。
• Level 2（2級）：版本已執行過72小時平台級浸泡測試（穩定負載下随機事務測試，且對主要代碼分支，代碼覆寫率達到80%以上）。
• Level 3（3級）：在6個月以上長期測試中，出現缺陷率持續降低的測試跟蹤記錄。

2.安全性

ONAP采用核心基礎設施倡議聯盟（Core Infrastructure Initiative，CII）的勳章項目要求作為安全性度量标準。CII是2014年4月24日Linux基金會成立的組織，目的是為屬于網際網路基礎設施的開源軟體提供支援（包括資金支援），避免類似“心髒出血漏洞”問題的再次發生。而CII Badge（徽章）項目則給出開源軟體的安全最佳實踐要求及徽章認證。以幫助開源軟體提升安全能力。認證分三級：基礎認證、銀牌認證、金牌認證。目前已有2000多個開源項目參于了認證，具體可參見

https://bestpractices.coreinfrastructure.org/en/projects

注：心髒出血漏洞（Heartbleed bug），簡稱心血漏洞，是一個出現在加密程式庫OpenSSL中的安全漏洞。該程式庫廣泛用于實作網際網路的傳輸層安全（TLS）協定。它于2012年被引入了OpenSSL中，2014年4月首次向公衆披露。在漏洞披露時，約有17%（大約50萬）通過認證機構認證的網際網路安全網絡伺服器容易受到攻擊。

對項目的安全認證要求如下（0～3共4個級别）：

• Level 0（0級）：無要求。
• Level 1（1級）：項目通過CII基礎徽章認證，無業界已知的嚴重級别或進階别漏洞（＞60天的）。
• Level 2（2級）：項目通過CII銀級徽章認證且所有内外部通信都是支援加密，且支援基于角色的通路控制與鑒權。
• Level 3（3級）：項目通過CII金級徽章認證。

ONAP對整個版本的安全需求定義如下：

• Level 1（1級）：70%項目通過1級認證，剩下項目滿足80%條款要求，且需要符合社群安全委員會制定的特定加密标準。
• Level 2（2級）：70%項目通過2級（CII銀級徽章認證），剩下項目都已認證CII基礎徽章認證，且滿足80% CII銀級徽章認證的條款要求。
• Level 3（3級）：70%通過3級（CII金級徽章認證），剩下項目都已認證CII銀級徽章認證，且滿足80% CII金級徽章認證的條款要求。
• Level 4：所有項目100%通過3級（CII金級徽章認證）。

3.可伸縮性

可伸縮性（又稱可擴充性）是一種衡量軟體系統計算處理能力的設計名額，高可伸縮性代表在系統擴充成長過程中（常見的是容量或工作負載增長），軟體仍能持續對外提供正常服務的能力，即不出現性能急劇劣化等無法服務的瓶頸限制。可伸縮性設計與事後的性能調優是不同的，其強調在設計之初就對高性能、低成本和可維護性等諸多因素進行綜合考量和平衡，追求的是平滑、線性的性能提升，更側重于系統的水準伸縮能力，力求通過較少改動甚至隻是硬體裝置的添置，就能實作整個系統處理能力的線性增長，實作高吞吐量和低延遲等高性能。比如，如果系統設計之初将所有資料表儲存在同一資料庫伺服器，則在後續系統達到一定規模時，負載就會嚴重依賴資料系統自身能力；而如果提前将不同資料做了分區，則後續根據通路量随時做分區擴充，擴充就是更好地設計可伸縮性。ONAP對可伸縮性各級别的定義與要求如下：

• Level 0（0級）：無可伸縮性。
• Level 1（1級）：支援獨立于其他元件的單點水準擴縮容能力。
• Level 2（2級）：支援跨地理位置擴縮容能力（在獨立于其他元件的條件下）。
• Level 3（3級）：支援跨多ONAP執行個體間的元件擴縮容能力（包括提供相應的可操作性）。

4.性能

軟體性能是指軟體及時響應以滿足使用者要求的程度。常見性能名額通常包括響應時間、并發數、吞吐量及性能計數器等。狹義地講，性能是指軟體在盡可能少地占用系統資源的前提下，盡可能高地提高運作速度；廣義地講，軟體性能關注的不是軟體是否能夠完成特定功能，而是在完成該功能時展示出來的及時性。由于感受軟體性能的主體是人，不同的人對于同樣的軟體也會有不同的主觀感受，如果時間和空間效率與其心理期待一緻或能夠達到使用者的既定要求，使用者就會認為軟體性能是高的。比如，在一個需要長時間的操作中增加進度條，進度條本身對于縮短處理時間沒有幫助，但更容易讓人覺得系統性能是可接受的。在ONAP中對性能的了解是基于狹義定義的，其分為如下3級：

• Level 0（0級）：沒有專門的性能測試。
• Level 1（1級）：定義了性能标準基線且有對應測試結果（如針對各元件定義響應時間、事務/消息速率、延遲、占用空間等）。
• Level 2（2級）：針對1級中定義的性能基線，在1個版本中定義改進計劃（基于等效功能&等效硬體）。
• Level 3（3級）：對2個或以上連續版本實施性能改進計劃。

5.韌性

韌性又稱彈性，描述ONAP軟體自身在故障場景下，繼續對外服務的能力。ONAP對韌性的各級别定義與要求如下：

• Level 0（0級）：無備援能力。
• Level 1（1級）：支援在單站點内手動故障檢測、重路由或故障恢複；30分鐘内完成測試。
• Level 2（2級）：在單個地理站點内支援自動故障檢測和重路由，包括定義相關基線（存在無狀态元件與有狀态元件，可分别定義基線）。
• Level 3（3級）：跨地理站點支援自動故障檢測和重路由，包括定義相關基線。

6.可管理性

可管理性又稱易管理性，是指系統在運作過程中衡量便于管理的程度。良好的可管理性可以有效減少系統的管理和維護成本。ONAP對可管理性的定義主要關注在對ONAP進行維護運作時是否能達到友善影響範圍控制等要求。

• Level 1（1級）：所有ONAP元件統一使用單一的日志記錄，執行個體化一個簡單ONAP系統時，在滿足最小資源要求的情況下，時間應小于1小時。
• Level 2（2級）：元件可以獨立更新，而不會影響操作互動元件，支援跨元件的分布式事務跟蹤，各元件支援以通用方式實作對元件的統一配置。

7.可用性

易用性是指操作人員在學習或使用系統時的容易程度。易用性的設計重點在于讓系統或産品符合使用者的習慣與需求。ONAP對易用性的要求集中在文檔與使用者界面設計的一緻性與便利性上。

• Level 1：提供了使用者指南、部署文檔、API文檔及代碼遵從編碼指南。
• Level 2：整個ONAP中的各個項目都提供一緻的使用者界面，且進行了可用性測試，提供輔助文檔。

各版本S3P名額目标與滿足情況如下：

• 從ONAP R2（Beijing版本）開始，啟動這套品質評估機制，各項目基本處于從0到1的過程。
• R3版本則要求多數名額都需達到2級要求（可伸縮性要求達到1級，部分設計态項目對韌性要求可降低）。
• R4（都柏林版本）重點在如下領域進行增強：ONAP自身容器鏡像優化，包括大幅減少體積、增加對代碼的文檔說明、內建CNCF的ServiceMesh元件、支援更新、跨地理位置的災備、統一日志記錄等。

3.5　本章小結

ONAP作為一個開放的管理平台，是為營運商級規模的實時工作負載而設計和建造的。其設計時參考了業界諸多設計原則與最佳實踐，可幫助使用者快速引入新功能而縮短新業務上市時間。它提供了設計态架構與運作态架構。在設計态架構中提供了一個可視化的設計架構來實作對所有中繼資料和政策的管理；在運作态架構中，分成編排與控制兩層，同時提供一些核心服務元件以及周邊服務和子產品。

社群将軟體成熟度劃分為七個次元，簡稱S3P（魯棒性，安全性，可伸縮性，性能，韌性，可管理性，可用性），定義了各次元的度量名額級别，并随着社群版本釋出不斷提升。