面向隨選網(wǎng)絡(luò)的業(yè)務(wù)編排系統(tǒng)研發(fā)實(shí)踐

羅光峰，李奕群，陳慧光

?

面向隨選網(wǎng)絡(luò)的業(yè)務(wù)編排系統(tǒng)研發(fā)實(shí)踐

羅光峰，李奕群，陳慧光

（中國電信股份有限公司北京研究院，北京 102209）

為滿足SDN/NFV時代業(yè)務(wù)快速上線的要求，需要對現(xiàn)有網(wǎng)絡(luò)運(yùn)營系統(tǒng)進(jìn)行重構(gòu)，以隨選網(wǎng)絡(luò)業(yè)務(wù)的實(shí)踐為背景，詳細(xì)介紹了編排器在運(yùn)營系統(tǒng)中的定位與作用，然后闡述了編排器的核心設(shè)計思路以及核心組件工作流引擎。

隨選網(wǎng)絡(luò)；SDN；NFV；編排器；運(yùn)營支撐系統(tǒng)

1 引言

美國運(yùn)營商AT&T在網(wǎng)絡(luò)重構(gòu)中，提出了Domain2.0和ECOMP架構(gòu)，旨在通過網(wǎng)絡(luò)的虛擬化和集中控制提升業(yè)務(wù)開通和運(yùn)維的自動化，從而提升客戶體驗。在NFV領(lǐng)域中，ETSI（European Telecommunications Standards Institute，歐州電信標(biāo)準(zhǔn)化協(xié)會）標(biāo)準(zhǔn)組織定義了相關(guān)軟件框架MANO（NFV management and orchestration，NFV管理和編排），包含orchestrator（編排器）、VNF管理器和VIM（virtualized infrastructure manager，虛擬設(shè)施管理器）。ECOMP中的MSO（master service orchestrator，主業(yè)務(wù)編排器）就承擔(dān)了MANO中NFVO的角色。另有Verizon公司的SDN/NFV計劃，目標(biāo)是同時考慮SD-WAN和NFV的業(yè)務(wù)需求，通過構(gòu)建一個端到端編排器（end-to-end orchestrator），實(shí)現(xiàn)跨SDN與NFV的端到端的業(yè)務(wù)。

在SDN/NFV技術(shù)時代，各大運(yùn)營商都有各自的技術(shù)演進(jìn)計劃。其中一個重要目標(biāo)就是通過新技術(shù)、新網(wǎng)絡(luò)體系實(shí)現(xiàn)隨選網(wǎng)絡(luò)業(yè)務(wù)。隨選網(wǎng)絡(luò)指在業(yè)務(wù)層面提供客戶自主定義網(wǎng)絡(luò)業(yè)務(wù)的功能，在配置層面實(shí)現(xiàn)業(yè)務(wù)對應(yīng)的網(wǎng)絡(luò)配置自動化、網(wǎng)絡(luò)資源按需指配。在業(yè)界的技術(shù)發(fā)展中，給負(fù)責(zé)實(shí)現(xiàn)業(yè)務(wù)層面自動配置功能的子系統(tǒng)命名為“編排器”。Linux基金會在2015年成立了針對編排器的開源項目Open-O，2017年初AT&T 開源了其ECOMP系統(tǒng)，Open-O項目與ECOMP合并，更名為ONAP項目，并吸引了更多運(yùn)營商、設(shè)備廠商、芯片廠商的加入，共同推動編排器的設(shè)計和實(shí)現(xiàn)。

本文針對SDN/NFV時代對網(wǎng)絡(luò)運(yùn)營系統(tǒng)的要求，分析了編排器設(shè)計的目標(biāo)，提出了一種業(yè)務(wù)編排器的架構(gòu)設(shè)計和實(shí)現(xiàn)方案，并通過開發(fā)實(shí)踐，對編排器做出了驗證，可為下一代運(yùn)營系統(tǒng)的設(shè)計提供參考。

2 隨選網(wǎng)絡(luò)系統(tǒng)中的業(yè)務(wù)編排

圖1 業(yè)務(wù)編排在系統(tǒng)中的位置

編排一詞在維基百科中的定義如下：編排在計算領(lǐng)域主要指通過相應(yīng)的工具、架構(gòu)和過程部署（開通）一個業(yè)務(wù)，此過程涉及的軟件與硬件統(tǒng)一部署，需要支持自動化的工作流程。

在隨選網(wǎng)絡(luò)系統(tǒng)中，編排器承擔(dān)著業(yè)務(wù)設(shè)計、開發(fā)/實(shí)現(xiàn)、上線、開通、變更、關(guān)閉、下線整個生命周期的管理職責(zé)，業(yè)務(wù)編排在系統(tǒng)架構(gòu)中的位置如圖1所示。

在業(yè)務(wù)的生命周期中，編排器需要滿足業(yè)務(wù)的靈活設(shè)計與快速上線要求，為業(yè)務(wù)編排設(shè)計人員（通常為網(wǎng)絡(luò)運(yùn)維人員）提供用戶友好的設(shè)計工具，滿足業(yè)務(wù)定義的直觀、準(zhǔn)確、可測試等特性；業(yè)務(wù)編排將接收客戶訂購的請求，并將其分解為預(yù)定義的工作流程，在流程中通過調(diào)用已有的原子能力實(shí)現(xiàn)每一個步驟。例如其中涉及配置相關(guān)的步驟，需要調(diào)用與控制器相對應(yīng)的原子能力，通過控制北向接口將配置指令下達(dá)控制器，并由控制器負(fù)責(zé)最終的執(zhí)行。在業(yè)務(wù)開通流程中力求無人工參與，從而大幅縮短開通時限。業(yè)務(wù)開通流程中編排器的角色和其他系統(tǒng)的配合示例如圖2所示。

圖2 自動化的業(yè)務(wù)開通流程示例

3 通過工作流引擎實(shí)現(xiàn)資源編排

編排器對外提供的業(yè)務(wù)編排功能基于工作流引擎，當(dāng)出現(xiàn)新的業(yè)務(wù)場景時，系統(tǒng)可對現(xiàn)有能力進(jìn)行重新組合，快速生成新業(yè)務(wù)以滿足需求。運(yùn)營人員通過可視化的拖拽、連線的操作，完成業(yè)務(wù)需要的配置。

工作流引擎主要由以下4個模塊組成。

（1）服務(wù)目錄

用于存儲系統(tǒng)支持哪些功能、每個功能有哪些接口、接口中有哪些參數(shù)、參數(shù)類型等。

（2）設(shè)計器

提供UI，并能從服務(wù)庫中選擇服務(wù)進(jìn)行組合，形成需要的業(yè)務(wù)配置序列，存儲成業(yè)務(wù)模板。

（3）校驗器

對設(shè)計好的流程和模板進(jìn)行測試驗證，發(fā)現(xiàn)潛在的錯誤或缺陷。

（4）執(zhí)行器

加載一個由設(shè)計器生成的業(yè)務(wù)模板，按照模板的描述執(zhí)行一系列操作，完成業(yè)務(wù)配置。

工作流引擎組成與工作原理如圖3所示。

對以上工作過程解釋如下。

步驟1 能力編排引擎從一個公共的服務(wù)庫（后述）中獲取系統(tǒng)可用的服務(wù)以及每個服務(wù)的接口規(guī)格，形成自己的服務(wù)庫。

步驟2 當(dāng)運(yùn)營人員需要設(shè)計一個工作流時，設(shè)計器可從服務(wù)目錄中讀取可用服務(wù)（并展示于UI），供設(shè)計人員使用。

步驟3 設(shè)計人員使用設(shè)計UI，通過拖拽服務(wù)及連線（接口調(diào)用），完成一個業(yè)務(wù)場景需要的流程設(shè)計。其中，接口調(diào)用過程需要指定必要I/O參數(shù)，這些參數(shù)的規(guī)格（類型、可取值范圍等），須從服務(wù)目錄中獲取，并在UI中進(jìn)行展示約束。

步驟4 設(shè)計完成的工作流，進(jìn)入校驗階段。通過自動化測試腳本，對工作流進(jìn)行測試驗證。若發(fā)生錯誤，工作流返回設(shè)計器，需要設(shè)計人員進(jìn)行調(diào)整和更正。

步驟5 校驗成功的工作流進(jìn)入執(zhí)行器，具備運(yùn)行條件。應(yīng)用層通過執(zhí)行器提供的API可啟動某個工作流的執(zhí)行，完成配置。

步驟6 工作流的執(zhí)行可被監(jiān)控，并可根據(jù)需要由系統(tǒng)定時或事件觸發(fā)。

圖3 工作流引擎組成與工作原理

4 業(yè)務(wù)編排的兩態(tài)（開發(fā)態(tài)與運(yùn)行態(tài)）

編排器管理業(yè)務(wù)的全生命周期，涉及開發(fā)態(tài)和運(yùn)行態(tài)。業(yè)務(wù)的設(shè)計、開發(fā)/實(shí)現(xiàn)屬于開發(fā)態(tài)，業(yè)務(wù)的開通、變更、關(guān)閉屬于運(yùn)行態(tài)。業(yè)務(wù)編排的兩態(tài)在編排器中通過DevOps平臺實(shí)現(xiàn)無縫的銜接，通過在DevOps平臺中定制業(yè)務(wù)編排相關(guān)工具（例如模型語法分析與測試、運(yùn)行環(huán)境與開發(fā)環(huán)境數(shù)據(jù)的同步等），實(shí)現(xiàn)業(yè)務(wù)從開發(fā)到部署的全流程自動化、持續(xù)化。業(yè)務(wù)編排兩態(tài)示意如圖4所示。

業(yè)務(wù)編排通過開發(fā)態(tài)和運(yùn)行態(tài)以及DevOps平臺實(shí)現(xiàn)業(yè)務(wù)的全生命周期管理，依賴于以下能力。

圖4 業(yè)務(wù)編排兩態(tài)示意

（1）業(yè)務(wù)編排的基礎(chǔ)是良好定義的原子能力

?·?從業(yè)務(wù)編排的視角看，所有能夠在業(yè)務(wù)編排中調(diào)用的服務(wù)都是原子能力。

?·? 原子能力依照提供方大致可以分為網(wǎng)絡(luò)類原子能力（例如通過Device YANG實(shí)現(xiàn)網(wǎng)元的配置）、NFV/云類原子能力（例如通過TOSCA VNFD拉起VNF）、資源類原子能力（例如電路資源的查詢與預(yù)占）、服務(wù)保障類原子能力（例如業(yè)務(wù)的端到端測試）。

（2）端到端編排依賴于全面準(zhǔn)確的資源清單在業(yè)務(wù)的開通流程中，總是需要資源的申請（例如IP地址），這些資源的申請需要自動化完成，資源管理模塊承擔(dān)著相關(guān)職責(zé)，并通過接口為業(yè)務(wù)編排模塊提供相應(yīng)的原子能力。

（3）業(yè)務(wù)編排提供靈活性與復(fù)雜性的平衡

??·?通過主工作流的編排，實(shí)現(xiàn)業(yè)務(wù)開通流程的定義與管理，可以適應(yīng)不同業(yè)務(wù)不同組織的定制化要求。

??·?子工作流、NFV-NS、SDN-service YANG都可以整合細(xì)粒度的原子能力，并能夠提供事務(wù)（例如回滾操作）的支持，作為主工作流的一個步驟（在workflow中定義的一個task）。

5 隨選網(wǎng)絡(luò)編排器開發(fā)實(shí)踐

在編排器原型系統(tǒng)實(shí)現(xiàn)中，OpenStack的Mistral組件因其輕量、簡單、易于集成和二次開發(fā)的特點(diǎn)，被用于實(shí)現(xiàn)核心編排能力的workflow引擎基礎(chǔ)。Mistral引擎基于YAML定義了一套workflow模型語言，并采用了YAQL作為數(shù)據(jù)處理的模板語言，當(dāng)前版本為2.0，Mistral的模型語言語法簡潔、易于理解、支持任務(wù)執(zhí)行結(jié)果的檢查和條件分支控制，可以滿足編排引擎的功能需求。

然而，要達(dá)到前述的“可視化”和“兩態(tài)”的轉(zhuǎn)換，還需要對其進(jìn)行擴(kuò)展。首先，需要一個可視化設(shè)計器，網(wǎng)絡(luò)運(yùn)維人員使用該設(shè)計器，通過拖拽和連線，即能完成一個業(yè)務(wù)場景的設(shè)計。更重要的是，雖然Mistral的workflow模型語言語法簡潔，但運(yùn)維人員使用編輯器手動編寫，不僅效率低，且容易出錯。這就需要設(shè)計器不僅具備可視化，而且能夠自動生成Mistral的workflow模型語言。其次，要實(shí)現(xiàn)上述的拖拽，首先要具備一個“服務(wù)庫”，服務(wù)庫的每個服務(wù)就是一個可拖拽的組件。因此，需要設(shè)計器能夠從服務(wù)庫獲取服務(wù)描述，并解析出需要的信息，供設(shè)計人員使用。例如，一個服務(wù)的接口，需要何種參數(shù)，參數(shù)類型是string還是integer，參數(shù)允許何種取值范圍等。這些約束，必須在服務(wù)描述模型中包含。所以，這點(diǎn)要求，需要服務(wù)庫“生成”這種模型，設(shè)計器解析模型來展現(xiàn)。最后，工作流需要一個運(yùn)行狀況的可視化，當(dāng)一個工作流編寫驗證完成，從開發(fā)態(tài)進(jìn)入運(yùn)行態(tài)，需要對其運(yùn)行狀態(tài)進(jìn)行監(jiān)控和展現(xiàn)。便于在發(fā)生錯誤的時候，由專業(yè)人員定位和解決問題。

同時，為了滿足編排的需要，編排器的核心能力集必須原子化、組件化。這不僅滿足了編排引擎的需要，而且由于各個原子能力的自治、解耦，給系統(tǒng)的分布式部署、獨(dú)立負(fù)載均衡帶來了極大方便。本次原型開發(fā)，采用了微服務(wù)架構(gòu)實(shí)現(xiàn)了編排器的核心服務(wù)庫。為實(shí)現(xiàn)這些服務(wù)的管理，引入統(tǒng)一的微服務(wù)總線（microservice bus，MSB）。微服務(wù)向MSB注冊自己的接口信息和節(jié)點(diǎn)信息，MSB負(fù)責(zé)管理微服務(wù)的負(fù)載均衡、故障檢測，對微服務(wù)接口的調(diào)用，也是經(jīng)由MSB代理轉(zhuǎn)發(fā)。最后，上述工作流的設(shè)計器需要的服務(wù)庫，也由MSB統(tǒng)一導(dǎo)出。從實(shí)現(xiàn)上，MSB采用業(yè)界經(jīng)典的Nginx作為基礎(chǔ)服務(wù)調(diào)用代理模塊，通過擴(kuò)展的OpenResty插件，完成服務(wù)的管理。

值得提出的是，為了方便開發(fā)，保持與工作流引擎的一致性，微服務(wù)開發(fā)的數(shù)據(jù)建模，也采用了基于YAML的Swagger標(biāo)準(zhǔn)。開發(fā)態(tài)和運(yùn)行態(tài)，以YAML語言作為基礎(chǔ)傳遞信息。

對于編排器來說，南向要對接各種設(shè)備廠商的控制器或者設(shè)備。這些廠商的接口規(guī)格通常有較大差別。因此，在編排器實(shí)踐中，采用一個驅(qū)動層（driver），將各個廠商的接口統(tǒng)一抽象成公共模型。這樣，微服務(wù)層即可針對該抽象模型進(jìn)行無差異編排。

隨選網(wǎng)絡(luò)的編排器實(shí)現(xiàn)的開發(fā)架構(gòu)如圖5所示。

為了驗證在實(shí)際的生產(chǎn)環(huán)境下，上述設(shè)計是否符合業(yè)務(wù)需求，檢驗業(yè)務(wù)編排系統(tǒng)架構(gòu)是否滿足設(shè)計目標(biāo)，需要從以下兩個方面進(jìn)行。

? 需要滿足業(yè)務(wù)需求：業(yè)務(wù)模型的定義、業(yè)務(wù)開通、業(yè)務(wù)變更、業(yè)務(wù)關(guān)閉。

? 需要滿足運(yùn)維管理需求：業(yè)務(wù)流程執(zhí)行過程的監(jiān)控、業(yè)務(wù)執(zhí)行過程故障的檢查、系統(tǒng)擴(kuò)展、系統(tǒng)運(yùn)維管理。

在實(shí)際驗證過程中，為了更貼近實(shí)際業(yè)務(wù)需求，在實(shí)施方案中采用一個典型的業(yè)務(wù)場景作為業(yè)務(wù)需求，用于驗證業(yè)務(wù)編排系統(tǒng)。圖6給出了一個在園區(qū)通過一個虛擬化網(wǎng)元vCPE，為客戶提供site-to-internet的場景。

圖5 隨選網(wǎng)絡(luò)的編排器實(shí)現(xiàn)的開發(fā)架構(gòu)

圖6 園區(qū)隨選業(yè)務(wù)開通流程示意

在實(shí)際驗證環(huán)境中按照實(shí)際生產(chǎn)環(huán)境進(jìn)行部署，系統(tǒng)完整支持熱備份和集群，業(yè)務(wù)編排系統(tǒng)包含了幾個關(guān)鍵組件。

（1）設(shè)計態(tài)

服務(wù)目錄管理：為了實(shí)現(xiàn)直觀便捷的編排，所有業(yè)務(wù)編排系統(tǒng)中的微服務(wù)接口是通過Swagger規(guī)范定義的，這些接口需要登記到服務(wù)目錄中，用于輔助設(shè)計器的實(shí)現(xiàn)。

工作流設(shè)計器：通過圖形化的界面，為運(yùn)維人員提供可視化的工作流編排設(shè)計工具，管理設(shè)計好的工作流模板，并將確認(rèn)版本發(fā)布到工作流引擎。

（2）運(yùn)行態(tài)

? 微服務(wù)總線：業(yè)務(wù)編排系統(tǒng)完全基于微服務(wù)架構(gòu)實(shí)現(xiàn)，所有的功能模塊和驅(qū)動以微服務(wù)的方式開發(fā)和部署，微服務(wù)總線實(shí)現(xiàn)了微服務(wù)的注冊、路由和負(fù)載均衡。

? 工作流引擎：基于OpenStack的Mistral引擎，為了滿足業(yè)務(wù)編排中訂單處理的需求，對引擎進(jìn)行了擴(kuò)展，用以實(shí)現(xiàn)工作流執(zhí)行的控制和工作流執(zhí)行信息的通知。

? 北向接口和訂單處理：API、訂單校驗與分析、訂單監(jiān)控、在途訂單管理。

? 微服務(wù)：資源管理、租戶管理、路由管理、VPN配置、QoS配置、接口配置。

? 南向驅(qū)動層：實(shí)現(xiàn)了多廠商（中興、華為、華三）SDN控制器的適配。

驗證結(jié)果記錄如下。

步驟1 完成業(yè)務(wù)編排系統(tǒng)的搭建，所有的微服務(wù)都要完成部署和測試，并注冊到微服務(wù)總線。

步驟2 完成服務(wù)目錄的更新，將所有的微服務(wù)登記到服務(wù)目錄中，并完成適當(dāng)?shù)淖⑨屨f明，比如輸入/輸出參數(shù)的中文簡介、是否為異步調(diào)用接口等。

步驟3 使用設(shè)計器完成業(yè)務(wù)模型的定義，通過圖形化的界面，拖拽服務(wù)目錄中的服務(wù)項作為工作流模型中的任務(wù)，并實(shí)現(xiàn)任務(wù)之間的先后順序，完成任務(wù)中服務(wù)需要的參數(shù)配置。

VPN業(yè)務(wù)開通工作流模板樣例如圖7所示，工作流的模型以YAML格式保存。

這個工作流模型中定義了多個任務(wù)，任務(wù)采用了順序執(zhí)行方式，首先執(zhí)行的是task1，當(dāng)task1執(zhí)行成功后，執(zhí)行task2，然后是task3。從工作流模型中可以看到，工作流中的一個任務(wù)就是調(diào)用一個微服務(wù)，微服務(wù)的調(diào)用都是通過微服務(wù)總線的統(tǒng)一入口實(shí)現(xiàn)，微服務(wù)的數(shù)據(jù)輸入?yún)?shù)都可以在模型中指定，微服務(wù)的輸出亦可以保存并用于后續(xù)任務(wù)。

步驟4 通過用戶門戶，用戶可以訂購產(chǎn)品，并將訂單發(fā)送給業(yè)務(wù)編排系統(tǒng)。

步驟5 業(yè)務(wù)編排系統(tǒng)接收到訂單后，通過訂單處理查詢并確認(rèn)通過哪一個工作流模型實(shí)現(xiàn)

version: '2.0' serviceopenworkflow: description: workflow type: direct input: - ORDER_IPVPN tasks: task1: action: yihe.sync input: headers: Content-Type: application/json method: post body: orderid: <% $.ORDER_IPVPN.get(orderId) %> atom: Bisop.OrderOrcha.iomReviewOrderInfo url: http://172.18.1.105:8080/iom/reviewOrderInfo publish: task1_r: <% task(task1).result.content %> on-success: - task2 task2: action: yihe.async input: headers: Content-Type: application/json method: post body: dispatchType: <% $.ORDER_IPVPN.get(OperType) %> totalInterVPC: <% $.ORDER_IPVPN.get(TotalInterVPC) %> vpcIdZ: '' ctYUNRegEmail: <% $.ORDER_IPVPN.get(CTYUNRegEmail) %> speedA: <% $.ORDER_IPVPN.get(AppSpeedA) %> yunResCityA: <% $.ORDER_IPVPN.get(YUNCityA) %> routeProtocol: <% $.ORDER_IPVPN.get(RoutProtocol) %> custId: <% $.ORDER_IPVPN.get(CustId) %> vpnNetCode: <% $.ORDER_IPVPN.get(vpnNbr) %> ctYUNACCNBR: <% $.ORDER_IPVPN.get(CTYUNACCNBR) %> netStruct: <% $.ORDER_IPVPN.get(Networkexp) %> ceIpA: <% $.ORDER_IPVPN.get(VPC_IPSegmentA) %> yunRespoolldZ: '' yunRespoolIdA: <% $.ORDER_IPVPN.get(YUNNameA) %> formType: <% $.ORDER_IPVPN.get(FormType) %> comments: <% $.ORDER_IPVPN.get(ProjectRemark) %> speedZ: '' yunResCityZ: '' changeType: '' vpcIdA: <% $.ORDER_IPVPN.get(VPCIDA) %> custName: <% $.ORDER_IPVPN.get(CustName) %> proInstId: <% $.ORDER_IPVPN.get(CircuitID) %> workId: <% $.ORDER_IPVPN.get(orderId) %> centerPoint: <% $.ORDER_IPVPN.get(CenterPoint) %> vpnLinkCode: '' ceIpZ: '' workType: <% $.ORDER_IPVPN.get(ProductID) %> atom: Bisop.OrderOrcha.cloudResourceRequest url: http:// 172.18.1.105:8080/CloudClientService/cloudResourceRequest publish: task2_r: <% task(task2).result.content %> on-success: - task3…

此訂單，然后通過工作流引擎的接口啟動相應(yīng)的流程。

步驟6 工作流引擎將依據(jù)模型中定義的步驟和任務(wù)執(zhí)行的條件逐一完成任務(wù)。

步驟7 工作流引擎在執(zhí)行過程中會通過通知訂單，處理任務(wù)執(zhí)行的進(jìn)展情況和結(jié)果。

步驟8 用戶門戶隨時可以通過北向接口獲得訂單執(zhí)行的進(jìn)展情況，并向用戶展示。

在業(yè)務(wù)驗證過程中，完成全部業(yè)務(wù)流程的實(shí)現(xiàn)，包括業(yè)務(wù)開通、業(yè)務(wù)變更、業(yè)務(wù)關(guān)閉，也包括了一些異常流程的驗證，例如業(yè)務(wù)開通過程中的停開、業(yè)務(wù)開通過程中異常情況的處理等。

在完成的驗證過程中，異常情況的處理最為復(fù)雜，例如任務(wù)的執(zhí)行異常，需要重新執(zhí)行，在重新執(zhí)行時還需要修改任務(wù)的輸入?yún)?shù)，Mistral開源項目并不完全支持，需要通過擴(kuò)展實(shí)現(xiàn)。

通過開發(fā)實(shí)踐，對業(yè)務(wù)編排系統(tǒng)的設(shè)計做出了驗證，基本滿足了最初對業(yè)務(wù)編排的要求。

新系統(tǒng)架構(gòu)帶來的優(yōu)勢如下。

? 工作流引擎不僅實(shí)現(xiàn)了控制流的調(diào)度管理，同時實(shí)現(xiàn)了數(shù)據(jù)流的傳遞，可以結(jié)合微服務(wù)總線完美實(shí)現(xiàn)對微服務(wù)的調(diào)用。

? 微服務(wù)作為基礎(chǔ)能力可以通過工作流方式完成編排，有利于微服務(wù)的重用。

? 微服務(wù)由于實(shí)現(xiàn)的是基礎(chǔ)功能，功能需求穩(wěn)定變化少，對應(yīng)的微服務(wù)軟件版本穩(wěn)定，通過編排隨時可以為新的業(yè)務(wù)需求創(chuàng)建工作流模板，無需編寫軟件代碼，即可為新業(yè)務(wù)提供服務(wù)。

? 在實(shí)踐驗證過程，對工作流引擎進(jìn)行了必要的擴(kuò)展。

? 通過對開源項目的擴(kuò)展，實(shí)現(xiàn)了異常情況下任務(wù)的干預(yù)（重試），對工作流的執(zhí)行實(shí)現(xiàn)回滾操作。

現(xiàn)有業(yè)務(wù)編排系統(tǒng)版本還有如下不足。

? 開源的工作流引擎在性能方面存在不足，雖然執(zhí)行集群方式的水平擴(kuò)展，但是單機(jī)的壓力測試表明，高并發(fā)下的流程啟動處理能力不足，還無法滿足大型項目的需求。需要對工作流引擎進(jìn)行重構(gòu)才能實(shí)現(xiàn)單機(jī)性能的提升。

? 在實(shí)踐過程中，遇到了不同種類的業(yè)務(wù)，既有低數(shù)量耗時長（以天為單位）的長流程，也有高并發(fā)耗時短（以秒為單位）的短流程，目前的流程引擎采用公平原則進(jìn)行處理，對于需要盡快處理的訂單，無法確保優(yōu)先執(zhí)行。建議通過劃分資源分區(qū)的方式對不同類型的流程進(jìn)行單獨(dú)處理。

? 通過圖形化的界面和服務(wù)目錄結(jié)合使用，已經(jīng)可以設(shè)計工作流模型，但是在設(shè)計過程中對于任務(wù)的輸入/輸出參數(shù)的配置還稍顯復(fù)雜，對于運(yùn)維人員要求較高，需要理解微服務(wù)的概念。

? 運(yùn)維工具不足，開源項目提供的運(yùn)維工具只實(shí)現(xiàn)了查詢和管理基本功能，無法提供統(tǒng)計、監(jiān)控和聯(lián)合查詢等需求，也沒有與統(tǒng)一運(yùn)維框架（例如Zabbix）結(jié)合。

6 結(jié)束語

本文所描述的編排器在設(shè)計上參考了國際標(biāo)準(zhǔn)最新進(jìn)展及業(yè)界網(wǎng)絡(luò)運(yùn)營系統(tǒng)的實(shí)踐。通過面向工作流的編排引擎，組合基礎(chǔ)設(shè)施能力形成業(yè)務(wù)能力，實(shí)現(xiàn)業(yè)務(wù)與資源的映射；通過模板化的NFV和業(yè)務(wù)建模，規(guī)范化研發(fā)實(shí)現(xiàn)，提高系統(tǒng)的可維護(hù)和可擴(kuò)展能力。構(gòu)建開發(fā)和運(yùn)營的雙態(tài)系統(tǒng)，使得業(yè)務(wù)需求能迅速轉(zhuǎn)化成系統(tǒng)能力，不斷擴(kuò)充業(yè)務(wù)場景，實(shí)現(xiàn)自身的迭代演進(jìn)。

該系統(tǒng)未來將在實(shí)際運(yùn)行中根據(jù)需求持續(xù)優(yōu)化，支持隨選網(wǎng)絡(luò)系統(tǒng)形態(tài)和相關(guān)業(yè)務(wù)形態(tài)分步分階段地演進(jìn)。同時通過積極加入業(yè)界開源組織，吸納先進(jìn)設(shè)計理念，并將自身創(chuàng)新成果貢獻(xiàn)于開源項目，實(shí)現(xiàn)開放共贏，共同推動網(wǎng)絡(luò)技術(shù)革新和重構(gòu)。

[1] IETF. YANG-a data modeling language for the network configuration protocol (NETCONF): RFC6020[S]. 2010.

[2] IETF. NETCONF configuration protocol: RFC4741[S]. 2006.

[3] Wikipedia. Orchestration[EB/OL]. (2016-09-20)[2017-11-10]. https://en.wikipedia.org/wiki/Orchestration_(computing).

[4] 何曉明, 冀暉, 毛東峰, 等. 電信IP網(wǎng)向SDN演進(jìn)的探討[J]. 電信科學(xué), 2014, 30(6): 131-137.

HE X M, JI H, MAO D F, et al. Discussion of evolution of carrier IP network to SDN[J]. Telecommunications Science, 2014, 30(6): 131-137.

[5] 顧戎, 王瑞雪, 李晨, 等. 云數(shù)據(jù)中心SDN/NFV組網(wǎng)方案、測試及問題分析[J]. 電信科學(xué), 2016, 32(1): 126-130.

GU R, WANG R X, LI C, et al. Analysis on network scheme and resolution test of SDN/NFV technology co-deployed in cloud datacenter[J]. Telecommunications Science, 2016, 32(1): 126-130.

[6] 馬書惠, 毋濤. NFV標(biāo)準(zhǔn)與開源技術(shù)現(xiàn)狀[J]. 電信科學(xué), 2016, 32(3): 43-47.

MA S H, WU T. Standards and open source technology of NFV[J]. Telecommunications Science, 2016, 32(3): 43-47.

[7] 張松. 精益軟件度量——實(shí)踐者的觀察與思考[M]. 北京: 人民郵電出版社, 2013.

ZHANG S. Lean software measurement-observer’s observation and reflection[M]. Beijing: Posts&Telecom Press, 2013.

[8] NEWMAN S. Building microservices[M]. Sebastopol: O’Reilly Media, 2015.

R&D practice of service orchestration system for on-demand network

LUO Guangfeng, LI Yiqun, CHEN Huiguang

Beijing Research Institute of China Telecom Co., Ltd., Beijing 102209, China

In order to meet the requirements of services quickly on line in the SDN/NFV era, existing network operating system needs to be refactored. Based on the background of the practice of on-demand network services, R&D practice of orchestrator for on-demand network service was introduced, then the orchestrator’s role in software system architecture was explained in detail.

on-demand network, software defined networking, network function virtualization, orchestrator, operation support system

TN929

A

10.11959/j.issn.1000?0801.2017327

2017?11?10；

2017?12?08

羅光峰（1973?），男，中國電信股份有限公司北京研究院軟件工程師，主要研究方向為SDN領(lǐng)域軟件架構(gòu)與實(shí)現(xiàn)。

李奕群（1975?），男，中國電信股份有限公司北京研究院軟件工程師，主要從事隨選網(wǎng)絡(luò)編排器、控制器相關(guān)開發(fā)工作。

陳慧光（1985?），男，中國電信股份有限公司北京研究院軟件工程師，主要從事隨選網(wǎng)絡(luò)編排器、控制器相關(guān)開發(fā)工作。