面向隨選網絡的業務編排系統研發實踐

羅光峰，李奕群，陳慧光

?

面向隨選網絡的業務編排系統研發實踐

羅光峰，李奕群，陳慧光

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

為滿足SDN/NFV時代業務快速上線的要求，需要對現有網絡運營系統進行重構，以隨選網絡業務的實踐為背景，詳細介紹了編排器在運營系統中的定位與作用，然后闡述了編排器的核心設計思路以及核心組件工作流引擎。

隨選網絡；SDN；NFV；編排器；運營支撐系統

1 引言

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

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

本文針對SDN/NFV時代對網絡運營系統的要求，分析了編排器設計的目標，提出了一種業務編排器的架構設計和實現方案，并通過開發實踐，對編排器做出了驗證，可為下一代運營系統的設計提供參考。

2 隨選網絡系統中的業務編排

圖1 業務編排在系統中的位置

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

在隨選網絡系統中，編排器承擔著業務設計、開發/實現、上線、開通、變更、關閉、下線整個生命周期的管理職責，業務編排在系統架構中的位置如圖1所示。

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

圖2 自動化的業務開通流程示例

3 通過工作流引擎實現資源編排

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

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

（1）服務目錄

用于存儲系統支持哪些功能、每個功能有哪些接口、接口中有哪些參數、參數類型等。

（2）設計器

提供UI，并能從服務庫中選擇服務進行組合，形成需要的業務配置序列，存儲成業務模板。

（3）校驗器

對設計好的流程和模板進行測試驗證，發現潛在的錯誤或缺陷。

（4）執行器

加載一個由設計器生成的業務模板，按照模板的描述執行一系列操作，完成業務配置。

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

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

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

步驟2 當運營人員需要設計一個工作流時，設計器可從服務目錄中讀取可用服務（并展示于UI），供設計人員使用。

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

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

步驟5 校驗成功的工作流進入執行器，具備運行條件。應用層通過執行器提供的API可啟動某個工作流的執行，完成配置。

步驟6 工作流的執行可被監控，并可根據需要由系統定時或事件觸發。

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

4 業務編排的兩態（開發態與運行態）

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

業務編排通過開發態和運行態以及DevOps平臺實現業務的全生命周期管理，依賴于以下能力。

圖4 業務編排兩態示意

（1）業務編排的基礎是良好定義的原子能力

?·?從業務編排的視角看，所有能夠在業務編排中調用的服務都是原子能力。

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

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

（3）業務編排提供靈活性與復雜性的平衡

??·?通過主工作流的編排，實現業務開通流程的定義與管理，可以適應不同業務不同組織的定制化要求。

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

5 隨選網絡編排器開發實踐

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

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

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

值得提出的是，為了方便開發，保持與工作流引擎的一致性，微服務開發的數據建模，也采用了基于YAML的Swagger標準。開發態和運行態，以YAML語言作為基礎傳遞信息。

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

隨選網絡的編排器實現的開發架構如圖5所示。

為了驗證在實際的生產環境下，上述設計是否符合業務需求，檢驗業務編排系統架構是否滿足設計目標，需要從以下兩個方面進行。

? 需要滿足業務需求：業務模型的定義、業務開通、業務變更、業務關閉。

? 需要滿足運維管理需求：業務流程執行過程的監控、業務執行過程故障的檢查、系統擴展、系統運維管理。

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

圖5 隨選網絡的編排器實現的開發架構

圖6 園區隨選業務開通流程示意

在實際驗證環境中按照實際生產環境進行部署，系統完整支持熱備份和集群，業務編排系統包含了幾個關鍵組件。

（1）設計態

服務目錄管理：為了實現直觀便捷的編排，所有業務編排系統中的微服務接口是通過Swagger規范定義的，這些接口需要登記到服務目錄中，用于輔助設計器的實現。

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

（2）運行態

? 微服務總線：業務編排系統完全基于微服務架構實現，所有的功能模塊和驅動以微服務的方式開發和部署，微服務總線實現了微服務的注冊、路由和負載均衡。

? 工作流引擎：基于OpenStack的Mistral引擎，為了滿足業務編排中訂單處理的需求，對引擎進行了擴展，用以實現工作流執行的控制和工作流執行信息的通知。

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

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

? 南向驅動層：實現了多廠商（中興、華為、華三）SDN控制器的適配。

驗證結果記錄如下。

步驟1 完成業務編排系統的搭建，所有的微服務都要完成部署和測試，并注冊到微服務總線。

步驟2 完成服務目錄的更新，將所有的微服務登記到服務目錄中，并完成適當的注釋說明，比如輸入/輸出參數的中文簡介、是否為異步調用接口等。

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

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

這個工作流模型中定義了多個任務，任務采用了順序執行方式，首先執行的是task1，當task1執行成功后，執行task2，然后是task3。從工作流模型中可以看到，工作流中的一個任務就是調用一個微服務，微服務的調用都是通過微服務總線的統一入口實現，微服務的數據輸入參數都可以在模型中指定，微服務的輸出亦可以保存并用于后續任務。

步驟4 通過用戶門戶，用戶可以訂購產品，并將訂單發送給業務編排系統。

步驟5 業務編排系統接收到訂單后，通過訂單處理查詢并確認通過哪一個工作流模型實現

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…

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

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

步驟7 工作流引擎在執行過程中會通過通知訂單，處理任務執行的進展情況和結果。

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

在業務驗證過程中，完成全部業務流程的實現，包括業務開通、業務變更、業務關閉，也包括了一些異常流程的驗證，例如業務開通過程中的停開、業務開通過程中異常情況的處理等。

在完成的驗證過程中，異常情況的處理最為復雜，例如任務的執行異常，需要重新執行，在重新執行時還需要修改任務的輸入參數，Mistral開源項目并不完全支持，需要通過擴展實現。

通過開發實踐，對業務編排系統的設計做出了驗證，基本滿足了最初對業務編排的要求。

新系統架構帶來的優勢如下。

? 工作流引擎不僅實現了控制流的調度管理，同時實現了數據流的傳遞，可以結合微服務總線完美實現對微服務的調用。

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

? 微服務由于實現的是基礎功能，功能需求穩定變化少，對應的微服務軟件版本穩定，通過編排隨時可以為新的業務需求創建工作流模板，無需編寫軟件代碼，即可為新業務提供服務。

? 在實踐驗證過程，對工作流引擎進行了必要的擴展。

? 通過對開源項目的擴展，實現了異常情況下任務的干預（重試），對工作流的執行實現回滾操作。

現有業務編排系統版本還有如下不足。

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

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

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

? 運維工具不足，開源項目提供的運維工具只實現了查詢和管理基本功能，無法提供統計、監控和聯合查詢等需求，也沒有與統一運維框架（例如Zabbix）結合。

6 結束語

本文所描述的編排器在設計上參考了國際標準最新進展及業界網絡運營系統的實踐。通過面向工作流的編排引擎，組合基礎設施能力形成業務能力，實現業務與資源的映射；通過模板化的NFV和業務建模，規范化研發實現，提高系統的可維護和可擴展能力。構建開發和運營的雙態系統，使得業務需求能迅速轉化成系統能力，不斷擴充業務場景，實現自身的迭代演進。

該系統未來將在實際運行中根據需求持續優化，支持隨選網絡系統形態和相關業務形態分步分階段地演進。同時通過積極加入業界開源組織，吸納先進設計理念，并將自身創新成果貢獻于開源項目，實現開放共贏，共同推動網絡技術革新和重構。

[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網向SDN演進的探討[J]. 電信科學, 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] 顧戎, 王瑞雪, 李晨, 等. 云數據中心SDN/NFV組網方案、測試及問題分析[J]. 電信科學, 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標準與開源技術現狀[J]. 電信科學, 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] 張松. 精益軟件度量——實踐者的觀察與思考[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領域軟件架構與實現。

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

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