banner.jpg)
相關專題：
作者簡介：楊邦文，華為
隨著ONAP第二個版本Beijing的發(fā)布，以及新一批運營商包括德國電信(DT), 瑞士電信（Swisscom），意大利電信（Telecom Italia），韓國電信（KT），日本KDDI等加入ONAP陣營，ONAP成為電信產(chǎn)業(yè)當前最火最熱的話題。
ONAP是一個電信產(chǎn)業(yè)聯(lián)合打造的大型開源軟件系統(tǒng)，功能和架構比較復雜，一句兩句很難說清楚。如果讓我來回答，我的答案很簡單，ONAP是一個“自動炒菜機”。
1.電信產(chǎn)業(yè)最大的問題是“上菜速度慢”
我們中國的餐飲業(yè)非常發(fā)達，菜品創(chuàng)新層出不窮，上菜速度非�？欤瑑r格和檔次也非常豐富，我們作為消費者，很容易就找到合適的午餐或者晚餐解決方案。
今天的信息社會，個人，家庭和組織都在快速的數(shù)字化，對電信業(yè)務的需求是非常豐富的。如果把電信運營商比喻成餐館，電信消費者（個人、家庭和組織）比作客人，作為客人的最大痛苦就是：我們發(fā)現(xiàn)餐館不但菜品少，上菜速度還極慢。很多時候等不起，不得不放棄，或者自己回家做飯吃。
一個經(jīng)常流傳的例子是，某電商希望在某日搞促銷，為了保證促銷日的網(wǎng)站訪問質量，需要當天臨時大規(guī)模的提高網(wǎng)站出口帶寬。找運營商協(xié)商，得到的結果是需要2個月的時間，而且?guī)挷话慈召u，必須按照半年以上來簽合同，電商只好放棄，另外尋找解決方案。不管該例子的真實性如何，作為企業(yè)客戶，申請專線的復雜流程和時間消耗確實很大；作為普通消費者，我們申請寬帶，申請新號碼時也能體會到這種不方便。
目前電信產(chǎn)業(yè)的服務方式，面向未來會面臨很大的挑戰(zhàn)。未來電信的真正消費者其實是各個應用程序，這些應用程序運行在云端和智能終端上，隨著負載的動態(tài)變化，對網(wǎng)絡的帶寬和時延的需求是不斷變化的。最佳的方式是應用直接用API調用網(wǎng)絡的能力，因此根本就沒有等待時間，而是及時生效，自動結算。
2.電信產(chǎn)業(yè)上菜慢的原因是炒菜依賴”廚師”
電信產(chǎn)品的推出，傳統(tǒng)上是一個復雜而漫長的過程。這個過程包含規(guī)劃、設計，采購，建設，集成等，一趟下來，起碼需要兩年時間。如果一切順利，網(wǎng)絡建設完成后，基于這個網(wǎng)絡的業(yè)務還要設計一套業(yè)務開通工作流程，和相應的銷售流程等，然后就是進行市場推廣和銷售。產(chǎn)品本身是相對固定的，客戶不能進行定制，因為定制會涉及到太多部門和人員的協(xié)同。
上述過程比喻成餐館的菜品設計和生產(chǎn)過程的話，那些網(wǎng)絡設計、運維人員就是各種廚師，而且這些廚師同某一個菜品是耦合在一起的，而這個菜品也同特定的食材也是耦合在一起的，而食材可能同特定的供應商也是耦合在一起的。這個上菜的過程，實際上很大程度上取決于這些廚師的熟練程度。而如果你還想嘗新的菜品，可能就要要等廚師團隊重新進行菜品設計，可能要重新等待兩年了。
3.一個自動炒菜機的設計原則和效果
如果有一個自動炒菜機來炒菜，只要在菜單上選擇菜品，機器就自動選擇食材，自動炒菜，不是就可以大大提高上菜速度嗎？我們是否可以實現(xiàn)這樣的機器呢？
自動炒菜機是可能實現(xiàn)的，要實現(xiàn)自動炒菜機，就必須要改變傳統(tǒng)的炒菜模式。
首先，炒菜機器必須是通用的，我們不可能針對特定的一款菜品來設計機器。如果一款菜對應一款機器，那么我們需要發(fā)明多少機器呀？因此炒菜器必須是一款可編程的通用炒菜機，這款機器的編程輸入是菜譜。菜譜描述了一款菜需要如何配菜，如何炒菜，食材的先后順序，炒菜的工法（爆炒還是清蒸等）。這款機器本身不是廚師，對菜品和食材完全沒有任何認知，它只是知道爆炒、清蒸、燒烤等一些動作，怎么組合這些動作和食材，完全依賴于菜譜的指定，而真正的廚師，就從炒菜本身解放出來，只需要聚焦在不斷的制作菜譜，不斷的更加客戶的口味變換菜譜。
其次，食材的供應一定要標準化。自動炒菜器一定有一個放置各種食材的案板之類，炒菜的機器會根據(jù)食譜，在案板上先配菜，然后炒菜。放置在案板上的食材，應該符合一定的規(guī)格，比如豬肉，要分成五花肉，瘦肉等類別，并切成一定規(guī)格的塊。蔬菜等也需要洗好，切好等�？傊惺巢亩紤撚袑陌b要求，不能毫無規(guī)矩。菜農(nóng)給餐館供菜時，必須要洗好，切好，包裝好，符合這臺機器的規(guī)格。
如果我們實現(xiàn)了自動炒菜機，那么整個餐館的廚師團隊就可以大規(guī)模的減少；上菜的速度就可以極大的加快；菜品的創(chuàng)新也就可以層出不求了；而食材采購和交易也標準化了，菜農(nóng)可以大規(guī)模的生產(chǎn)；食客也一定會更加愿意到餐館吃飯而不是自己做飯，從而把整個餐飲市場空間成倍的擴大，形成一個繁榮的產(chǎn)業(yè)。
4.把ONAP打造成電信產(chǎn)業(yè)的“自動炒菜機”
ONAP的設計思路，就是一臺電信產(chǎn)業(yè)的“自動炒菜機”，那么，什么是電信網(wǎng)絡的食材，什么是菜品呢？
電信網(wǎng)絡的食材，是ICT基礎設施提供的各種能力或者說功能，但是這些功能或者能力，比如要經(jīng)過一定的抽象和封裝，變成標準功能對象。比如說光纖接入網(wǎng)絡，我們必須要抽象成一些網(wǎng)絡能力對象，比如一個VLAN連接等。還有很多網(wǎng)絡功能是軟件化的，比如虛擬的家庭網(wǎng)關vRGW，這個對象其實是一個應用程序，需要按照一定的格式封裝后，進行自動化部署和配置。
如上圖所示，電信網(wǎng)絡包含接入網(wǎng)，城域，骨干網(wǎng)絡和數(shù)據(jù)中心等。這些基礎設施都提供一些基礎的能力，比如數(shù)據(jù)中心可以提供虛擬機，虛擬網(wǎng)絡等，接入網(wǎng)絡可以提供L2的接入連接和用戶認證等，骨干網(wǎng)絡可以提供高速專線或者VPN業(yè)務等。過去這些能力可能都是同特定的業(yè)務和特定的流程耦合在一起。有了ONAP后，我們就需要把這些能力變成可重用的資源（Resource），相當于經(jīng)過特定處理和包裝的食材。
把電信網(wǎng)絡的一些原子功能描述成一個標準說明文件的過程就是建模，一般用一個文本文件來描述。這些模型要符合ONAP的規(guī)格，才能被ONAP識別。把這些模型導入到ONAP的過程叫Onboarding，就是上案板。
上圖ONAP的模塊中，SDC是業(yè)務設計和創(chuàng)建平臺，是設計態(tài)模塊，相對于廚師的案板，用來配菜和開發(fā)菜譜；后面模塊都屬于運行態(tài)模塊，其中SO和各種控制器（CTRL）是炒菜的實際執(zhí)行機構，SO是一個總的炒菜工作流，控制器是具體的菜品加工器，是具體類型的食材的加工器，分成3類，一類適合加工肉類（PNF網(wǎng)絡），一類適合加工蔬菜（VNF），一類適合熬湯（IT類資源）。AI&I是一個食材和菜品管理系統(tǒng)。DCAE是大數(shù)據(jù)監(jiān)控和分析模塊，收集食客的反饋和滿意度，Policy是策略模塊，可以進行基于策略的行為調整。
目前ONAP這臺機器的架構和功能設計得已經(jīng)比較完善了，但是要真正的把ONAP用起來，我們還需要在食材的標準化和菜譜的開發(fā)上下功夫，從而形成供應鏈生態(tài)和豐富的菜譜。這個工作就需要把ONAP逐步應用到具體的場景過程來來尋找最佳的建模標準和最佳實踐了。
要想了解ONAP的更多細節(jié)，請關注10月12日在上海舉辦的Open Source Networking Day.
來源：SDNLAB
