下一代電信IT架構演進初探：業務功能虛擬化（BFV）

喬穩，王曉征，孫震強，任贛，劉云新，楊愛東，王鵬，王達，葉曉舟，歐陽曄

工程與應用

下一代電信IT架構演進初探：業務功能虛擬化（BFV）

喬穩1，王曉征2，孫震強3，任贛2，劉云新4，楊愛東1，王鵬1，王達1，葉曉舟1，歐陽曄1

（1. 亞信科技（中國）有限公司，北京 100193；2. 中國移動通信集團浙江有限公司，浙江 杭州 310016；3. 中國電信股份有限公司研究院，北京 100035；4. 清華大學，北京 100084）

隨著信息和通信技術的發展，靈活多變的業務需求給傳統大型電信業務支撐系統帶來了諸多挑戰。應用場景化、服務標準化、技術組件化和資源共享化正在成為電信業務支撐系統架構演進的共識。提出了一種電信業務功能虛擬化（business function virtualization，BFV）架構，以云原生、微服務、容器、DevOps等技術為基礎，引入標準化的IT虛擬網元、單元化的設計編排器、微服務管理框架和多平面彈性計算控制器，使IT系統具備單元化部署和分布式云部署能力，滿足系統穩定擴展與平滑演進的要求，實現IT系統輕量交付和業務敏捷支撐，可作為下一代電信業務支撐系統的參考架構。

業務功能虛擬化；單元化設計編排；彈性計算控制器；單元化部署

0 引言

隨著5G、云原生、大數據、人工智能等技術的飛速發展，深度融合的信息通信技術（information and communication technologies，ICT）為全球電信業帶來重大的發展機遇，成為推動電信運營商數字化轉型的重要驅動力。然而，針對靈活多變的業務需求，基于傳統IT架構的電信業務支撐系統（business support system，BSS）面臨諸多挑戰。

5G的高速率、低時延、廣連接、網絡切片等先進網絡特征帶來了豐富的新型業務場景和商業模式，同時對BSS的敏捷業務開發和流程設計能力提出了更高的要求。現有BSS在支撐個人、家庭、集團等業務中涉及的訂購、開通、定價等業務環節，沒有抽象出基礎業務單元，模塊間交織調用、互相依賴嚴重。在應用場景化流程設計能力上，核心IT單元模塊處于“緊耦合”狀態，未形成面向業務場景可重用的單元化設計能力。因此，傳統BSS的IT架構缺乏場景化的流程設計能力，難以快速、靈活地響應5G新技術帶來的個性化需求，影響用戶體驗。

垂直行業的業務支撐需要BSS對IT服務進行服務治理和標準化，不同垂直行業的業務場景經常需要BSS提供新應用程序接口（application programming interface，API），并且業務類型和數量的增長，往往導致IT服務重復和服務邊界模糊等問題。現有IT架構缺乏自頂向下的IT服務標準設計以及全生命周期的統一視圖，在服務顆粒度、服務標準化上，IT架構需要進行不同支撐對象、不同對象屬性API能力的共性抽取，以形成標準的數字化服務接口以及標準業務流程。

在生產系統中，傳統BSS的API管理模塊缺乏組件級的集成開發框架，擴展能力受限。一旦API網關、企業服務總線（enterprise service bus，ESB）等服務調度發生故障或異常，會導致整個微服務架構體系不可用。盡管基于服務注冊方式可以實現服務注冊和發現、負載均衡等功能，但限流熔斷、日志管理、安全等能力還需要結合其他技術組件完成，這種按需引入組件的方式使BSS對IT架構的新技術兼容性或適配性要求更高。因此，在技術組件化易擴展能力上，現有BSS的IT服務架構需要進一步增強，以形成組件化框架承載能力。

在BSS資源管控方面，應用系統的IT資源利用率需要進一步提升，并具備更強的容災遷移和資源共享能力。各通信運營商在集約化運營下，對現有BSS的IT架構的資源調度和應用部署的能力需求包含：跨地域容災遷移、多資源池遷移、峰值資源遷移以及故障恢復后快速回切等。在資源共享化方面，IT架構需要在基礎設施層面將多方、異構的資源有機整合成統一的資源平面，形成運行面和控制面分離、資源多平面的管控能力。

針對傳統BSS面臨的挑戰，具備應用場景化、服務標準化、技術組件化、資源共享化特征的可演進BSS正在成為電信運營商的共識。本文提出了一種電信業務功能虛擬化架構，以云原生、微服務、容器、DevOps技術為基礎，引入標準化的IT虛擬網元、單元化的設計編排器、微服務管理框架和多平面彈性計算控制器，使IT系統具備單元化部署和分布式云部署能力，滿足系統穩定擴展與平滑演進的要求，實現IT系統輕量交付和業務敏捷支撐，可作為下一代電信業務支撐系統的參考架構。

1 相關研究

通信網絡BSS的架構演進和研究一直受到工業界和學術界的關注[1-3]。通信網絡BSS的IT架構演進歷程如圖1所示，在業務靈活性和系統易擴展的“雙重”驅使下，BSS的IT架構發展先后經歷了基于客戶機/服務器（client/server，C/S）和瀏覽器/服務器（browser/server，B/S）架構[4]、基于x86分布式計算架構[5]和基于面向服務的架構（service oriented architecture，SOA）微服務架構[6]等階段的演進。

2012年3月，Fred George在Agile India 會議上分享了一篇題為的主題演講，首次引入了“微服務”的概念[7]。Martin Fowler于2014年3月在文章定義了微服務IT架構。“微服務”技術的出現極大豐富了BSS的IT架構可擴展性，有效實現了IT系統的靈活服務調度和資源隔離的能力。隨后，研究者們嘗試把SOA架構與“微服務”技術相結合[8]，實現了IT服務間的解耦，很好地滿足了多技術、多應用、多系統間的互相“融合與隔離”的需求，大大提高了企業效率，減少了IT運營成本。盡管如此，該架構引發了很多“非業務”問題，如服務監控、服務權限控制、服務版本控制等。為了解決這些“非業務”問題，2017年，Twitter的基礎設施工程師 William Morgan提出了一種處理網絡問題的ServiceMesh技術[9]，并基于該技術設計了一種專注于處理服務間通信的基礎設施層，將“非業務”功能從代碼中剝離，通過注入Sidecar方式實現微服務治理管控、數據流和控制流的分離，以形成“去中心化”的IT架構幫助處理“非業務”問題。此后，隨著服務鏈路的不斷變長，微服務與微服務之間的橫向交互關系變得越來越脆弱，不能很好地與動態業務匹配。為了增強服務韌性，一種結合SOA和事件驅動架構（event-driven architecture，EDA）的混合架構事件驅動的面向服務架構（event-driven SOA）被提出[10]，通過引入事件處理的能力，一個事件的產生可以觸發一個或多個服務的調用，從而靜態服務被串聯在一起實現數據流的動態實時處理，當自動化業務流程或事件發生時，系統和組件能夠實時動態做出響應，有效地實現了業務敏捷和能力復用。

圖1 通信網絡BSS的IT架構演進歷程

Pivotal公司Matt Stine于2013年首次提出云原生（cloud native，CN）的概念，并廣泛應用于云計算領域，隨后IT架構朝著基于CN架構體系發展。CN由一系列云技術、企業管理方法集合等組成，包括DevOps、持續交付、微服務、敏捷基礎設施等。云原生計算基金會（Cloud Native Computing Foundation，CNCF）認為CN具有三大優勢：以容器作為基礎形成的代碼和組件的重用；以集中式編排調度系統實現的動態資源管理；面向微服務的服務間依賴和“解耦”能力。容器作為標準化軟件單元，將應用及其所有依賴項打包，將應用與底層運行環境解耦，屏蔽了底層架構差異性，使應用不再受環境限制，幫助應用平滑運行在不同基礎設施，實現了資源共享[11-13]。虛擬化和容器技術的融合，已成為未來重要趨勢，隨著開放式容器提案（open container initiative，OCI）標準的出現，不同技術采用了一致的方式進行容器生命周期管理，進一步促進了容器引擎技術的持續創新。以開源容器和容器編排引擎為基礎，按照容器為資源分割的基本單位，封裝各類應用和運行環境，為開發者和系統管理者提供用于構建、發布和運行分布式應用的容器云平臺——容器即服務（container as a service，CaaS）[14]。CaaS 同時提供了傳統的基礎設施即服務（infrastructure as a service，IaaS）和平臺即服務（platform as a service，PaaS ）兩種能力。IT架構基礎設施層由以資源調度為中心，向上演進為以容器為中心進行調度，使用CaaS提供的服務，實現了應用運行環境的無關性。

無服務器（serverless）技術[12-13]伴隨CN技術興起從觀望逐漸落地，通過事件驅動和云服務連接，serverless能力會擴展到整個云的生態中。CN架構最顯著的特點是穩健的軟件韌性，這種韌性主要表現在所采用的單元化設計上。在單元化設計中，服務仍然是分層的，不同的是每一層中的任意一個節點都屬于且僅屬于某一個單元，上層調用下層時，僅會選擇本單元內的節點。一個單元是指一個能完成所有業務操作的自包含集合，在這個集合中包含了所有業務所需的所有服務以及分配給這個單元的數據和單元可運行的資源。相應地，單元化部署是在多個資源可用區，部署多個實例來供業務服務，業務服務需要微服務、CN、分布式事務體系支撐并設計業務模型和微服務邊界，最終形成業務單元，業務單元通過容器化的封裝，進行場景化編排和動態調度，實現業務彈性擴展、復制，由中心節點擴展到其他節點。

近年來，云網絡技術異軍突起，CN技術被廣泛應用在云網絡中，CT架構正由虛擬化的網絡架構向CN的云網絡架構演進。云網絡是指基于對網絡資源的虛擬化，將適配云特性的網絡能力開放給用戶，以滿足企業上云過程中“云?邊?端”互聯互通需求的服務的集合[15-16]。云網絡是由各種網元組成的，例如交換機、路由器、NAT 網關、負載均衡等，這些網元在云網絡中通常稱為虛擬化網元[15]。虛擬化網元是各種云網絡組件的基本承載形態，它提供標準的服務化接口以及多租戶的能力，滿足業務需求快速迭代和靈活組網。

綜上所述，CN的IT架構優勢主要表現在容器化封裝、動態管理和調度、微服務解耦，但是在微服務通信機制標準、微服務間的依賴隔離、微服務靈活部署、微服務運維與系統監控、系統測試以及微服務顆粒度與動態業務匹配等方面仍存在不足。電信業務的IT架構需要具備面向應用場景化、服務標準化、技術組件化、資源共享化的數字化平臺特征進行設計，繼承CN的IT架構優勢，同時改進其架構不足。

2 BFV架構體系

為了進一步解決服務治理管控、服務部署、服務運維、服務與動態業務失配問題，本文提出一種輕量、標準的BFV架構。不同于傳統的微服務架構體系，該架構關注業務支撐系統的應用場景化、服務標準化、技術組件化、資源共享化的能力建設，使業務支撐系統架構更具柔性和輕量。本文所提出的BFV架構體系如圖2所示，BFV架構參考框架中包含5個主要模塊，分別為業務虛擬功能化（virtualized business function，VBF）、業務功能虛擬化基礎設施（business function virtualization infrastructure，BFVI）、業務功能編排器（business functions unitization orchestrator，BFUO）、微服務管理（micro-service management，MSM）、彈性計算控制器（elastic computing controller，ECC）。

圖2 本文所提出的BFV架構體系

該架構與傳統的微服務架構體系相比，在實現業務支撐服務的方式方面存在不同。首先，在資源彈性調度和部署方式上，BFV以容器單元進行調度和部署。BFVI通過容器化封裝，實現應用運行環境所需的資源和物理資源分層隔離，容器作為資源或者服務提供給ECC調度，使應用更關注業務層面變化，對跨資源池遷移、峰值資源遷移以及故障恢復后快速回切等場景能夠有效支撐。其次，在IT能力服務提供的方式上，傳統的微服務架構以API服務總線的方式對外提供能力輸出，BFV通過VBF進行服務提供。VBF作為虛擬化的業務功能，是一類服務的集合包，提供標準的服務化接口，結合IT網元的網絡拓撲，進行VBF間的服務組網，整體對外提供IT服務能力。再次，在業務流程編排上，BFV具有自頂向下的應用服務標準設計模板，能夠更加靈活支撐個性化場景端到端流程定義。BFUO具有單元化的設計器功能，可根據不同用戶對象需求，實現業務單元不同場景的編輯和集成，業務單元可重用。最后，BFV充分利用現有的微服務組件和PaaS組件，形成一個輕量、標準開發環境。MSM作為技術組件的承載體，實現了所有組件的全生命周期的管理。

2.1 橫向和縱向解耦

BFV在橫向和縱向上進行了進一步的解耦和標準化設計。

從橫向看，為了解決微服務的治理和單元化的靈活部署，BFV架構分為運行面和控制面兩個平面，BFV橫向解耦如圖3所示。運行面是IT系統生產域，運行面上運行的IT系統主要是BSS側的各個業務中心。控制面是IT系統管理域。與現有IT側微服務架構不同，BFV增加了控制面，控制面實現了微服務治理管控、PaaS組件和容器的服務封裝，實現了數據流和控制流的分離，滿足了去中心化架構要求；控制面負責整個BFVI資源的管理和調度、業務網絡和BFVI資源的映射和關聯以及場景化行業服務流程的編排；控制面包含彈性計算控制器、微服務管理、BFUO 3個功能實體，分別完成對BFVI、VBF和場景化行業服務（scenario-based service，SBS）能力單元化設計管理。

圖3 BFV橫向解耦

從縱向看，從下至上分為基礎設施層、能力服務層、運營支撐層3個層次，BFV縱向解耦如圖4所示。

圖4 BFV縱向解耦

在基礎設施層，從云計算的角度看，其是一個資源池，BFVI需要將物理計算/存儲/交換資源通過虛擬化轉換為虛擬的計算/存儲/交換資源池，并基于容器技術實現資源虛擬化和彈性調度。容器云平臺（container cloud platform，CCP）作為BFVI的核心部件，通過封裝容器技術，實現容器資源管理和調度，并與彈性計算控制器實現調度協同，支持跨地域容災、多資源池遷移、跨資源池部署等場景。在基礎設施層，通過容器和PaaS技術的結合，IT架構實現了IaaS層資源的隔離，資源彈性高效管理，解決資源共享化的問題，實現資源共享復用。

能力服務層是指當前各個IT業務中心，每個業務中心映射為一個VBF，VBF所需資源由容器承載，通過BFVI編排分配，VBF之間的接口采用事件驅動的異步實時通信；微服務管理負責實現業務應用進程的啟停、熔斷、分流等以及VBF全生命周期管理；在IT能力服務層，需要將PaaS的組件能力顆粒度細分和能力解耦，將技術組件進行規范和標準，通過IT能力服務層構建，解決服務標準化、技術組件承載的問題。

運營支撐層負責IT能力場景化單元設計和IT能力開放。在運營支撐層，場景化行業服務向上支撐面向個人業務、家庭業務、政企業務、物聯網等新業務，甚至基于SBS的業務能力實現垂直行業的賦能。因此，在滿足復雜業務場景要求下，SBS對能力服務層的南向接口和對控制面BFUO的東向接口提出不同的運營能力要求（如對VBF的敏捷部署、彈性復制、快速擴容的要求、對BFUO場景化功能編排設計要求），通過業務描述符（BSS service descriptor，BSD）集成固化，形成標準的業務流程，使得SBS通過復制和解析BSD，實現業務靈活部署和場景運營。

總體上，為了解決了IT架構在應用場景化、服務標準化、技術組件化、資源共享化方面的問題，BFV架構通過橫向和縱向進一步地解耦，形成了“2+3”的能力分層，“2”是指運行面和控制面的管控分離，“3”是指基礎設施、能力服務和場景運營的分層。BFV架構的核心和關鍵在于通過微服務管理，實現IT虛擬網元的標準能力構建和場景化行業服務運營；通過整合微服務組件、PaaS組件和容器技術，提供一個輕量、標準的集成開發的環境，要求PaaS平臺從有定位，到有標準、有組織。在基礎設施層面，隨著ICT融合和云網融合加劇，基礎設施層將更趨于標準和統一，BFVI將統一收斂至容器云平臺，支持跨地域容災、多資源池遷移、跨資源池部署等場景。

2.2 采用的關鍵技術

BFV以CN為核心梳理技術棧需求，BFV的技術棧如圖5所示。

在虛擬化方面，BFV使用Docker/Kubernetes技術實現基礎設施層虛擬化，由彈性計算控制器實現多平面的資源調度和管控。隨著容器技術的深度應用和能力抽象，容器將會作為一種CaaS標準服務應用。通過容器云和彈性計算控制組合，實現了應用運行環境無關性。

在微服務治理方面，BFV使用服務網格ServiceMesh技術作為服務管理的框架，實現IT微服務的治理。ServiceMesh技術實現了控制流和數據流的分離，控制平面可以攔截數據流并推送到日志消息中間件。訂閱者通過對消息報文的訂閱，進行日志分析和接口服務運行實例數據的統計分析，并可結合預先配置的規則形成最終的控制規則，實現服務管控。ServiceMesh具備松耦合的集成方式，很容易集成各種日志分析工具、服務鏈監控工具等。另外，BFV通過微服務運行框架實現分布式服務的調度和運行管理。

圖5 BFV下的技術棧

在異步實時通信方面，BFV使用事件驅動EDA技術，實現IT VBF間異步消息實時通信，在事件發生時，系統和組件實時動態做出響應，實時進行服務間調用解耦。

在數據訪問方面，IT VBF通過分布式中間件實現微服務進程和數據庫間的數據訪問。

在持續集成和發布方面，BFV通過BFUO調用和集成DevOps與AIOps的服務能力，實現IT服務持續集成和智能運維。

BFV的架構體系中涉及微服務、DevOps、容器云和ServiceMesh等內容，更進一步地，基于CN整體技術演進，無服務器架構也是值得參考和研究的。

3 BFV核心功能

3.1 VBF

在電信行業內，相對于CT側的標準化網元帶來的電信級的穩定，支撐側的各業務中心需要以虛擬網元的方式標準化IT側的能力組件。本文給出BFV架構體系VBF，涉及BSS域的定義以及相關BSS的VBF網絡拓撲，BSS域與BSS VBF如圖6所示。

根據處理的業務對象以及業務流程不同，BSS域可以劃分為4個域，每個域包含現狀下各業務中心。一是業務辦理域，分為接觸客戶和受理業務的能力，包括個人、家庭、政企、物聯網等業務；二是業務處理域，客戶業務受理后涉及資源、開通、支付以及計費等能力，其中對合作伙伴等的結酬也在此域；三是業務管理域，主要是數據架構的數據模型、數據管理問題，涉及產商品定義、三戶定義、流程規則以及通用的能力部分；四是業務運營域，業務運營相關的部分，包含網格、營銷、報表、稽核等。

圖6 BSS域與BSS VBF

參考5GC的網絡服務拓撲[17-18]，將圖6所示的功能模塊映射到BFV架構中VBF，BSS域VBF的網絡拓撲關系如圖7所示。VBF要求各業務中心具備IT功能虛擬網元的能力，通過微服務控制臺實現靈活的組網和基于虛擬網元作為單元的靈活部署。

參考圖2 BFV的架構體系，VBF架構重點包含3個PaaS組件（API網關、微服務運行框架、單平面彈性計算控制器）。在運行面中，API網關接收來自SBS的需求，實現流量的負載和分流，微服務通過彈性計算平面控制器和BFVI的對接，實現應用服務部署，整體的VBF的服務由圖6中各域能力中心提供，部署在BFVI之上。

VBF各虛擬網元微服務顆粒度的劃分，涉及IT技術實現的耦合度、運營的效率成本等問題，可以結合領域設計模型等方法論，在核心業務與非核心業務區別、業務與技術的分離兩個過程中，持續理解業務、劃分業務、定義業務，兼顧服務組合的效率和穩定性，最終完成業務模型的建立。

3.2 BFUO

在BFV架構體系下，BFUO處在ICT融合、云網融合的關鍵位置，其定位非常關鍵。BFUO的能力涉及IT資產的全局視圖管理以及微服務管理、容器資源調度以及面向SaaS層的行業業務場景編排。與網絡服務描述（network service descriptor，NSD）[19-21]相對應，也需要研究BFUO中涉及BSD的定義、要素和標準化。相較于傳統的服務總線管理和API能力開放平臺的集成，BFUO關鍵功能與BFUO外部關系如圖8所示，BFUO存在如下功能變化：新增了服務設計功能模塊，實現業務服務中IT虛擬網元的設計；在場景服務編排中，新增IT虛擬網元的生命周期管理、策略管理、BSD信息管理，有利于服務的治理和API的管控；在運維和開發交付方面，通過服務化接口實現與DevOps/AIOps平臺的對接和數據交互。

BFUO的編排能力中應該具有設計器的功能，具備BSS域IT資產的全局視圖展現以及組網和編排能力[22]。其設計器示意圖如圖9所示。

通過新增BFUO功能，BFV架構相較于傳統的架構，有如下4個方面的優勢。

●由業務流程驅動編排到IT功能虛擬網元靈活組網編排[22]，IT服務能力具備靈活組網能力，由BFUO統一設計、管控協同生產面和控制面，實現微服務治理、VBF單元化部署和分布式云部署。

圖7 VBF網絡拓撲

圖8 BFUO關鍵功能與BFUO外部關系

圖9 設計器示意圖

●由服務總線對外提供能力到IT虛擬網元組網成邏輯實體對外提供服務，具備IT服務[23]單元復制能力。

●應用運行環境無關性，容器作為資源或者服務進行調度，實現多資源遷移等資源彈性的場景。

●通過定義和規范提供開放的接口，對IT側的API進行強管控。

3.3 微服務管理

微服務管理是基于微服務架構、高效可靠的遠程服務通信體系框架，提供服務管理、服務注冊、服務調用、負載均衡、服務治理等功能，保障服務通信的高效性，實現了微服務的可見、可管、可控。

微服務管理可以分為服務資產管理、分布式服務調用、服務治理3部分。

●服務資產管理解決服務靜態管理問題，包括服務清單管理、服務關系管理、服務生命周期管理、服務訪問策略配置等。

●分布式服務調用解決服務遠程調用問題，分布式服務調用框架致力于提供高性能、高可靠的分布式服務調用，解決分布式系統服務間通信問題。分布式服務調用框架應具備服務監聽與發現、服務路由、狀態校驗、規則校驗等功能。同時，在服務調用方式上一個完整的控制引擎應具備對服務進行本地調用、遠程調用、同步調用、異步調用等功能。

●服務治理解決了服務運行時動態控制問題，服務治理基于分布式服務調用框架，在服務調用過程中執行服務治理策略，完成運行期的服務調用控制。

在部署模式上，微服務管理實現了運行面和控制面的分離。微服務單元主要由API網關、微服務運行框架、分布式中間件組成，通過微服務控制臺實現運行面和控制面的協同管理。微服務管理的調用關系如圖10所示，其多平面管控可以分為以下3點。

●微服務相關組件運行面支持多平面部署。

●微服務主控制面可納管多個平面的運行面，控制臺可以通過切換平面，對單側進行管理。

●微服務相關組件復用基礎技術組件（如配置數據庫、注冊中心、緩存、消息中間件等）。其中配置數據庫多平面復用，采用主從架構實現高可用。

圖10 微服務管理的調用關系

3.4 彈性計算控制器

彈性計算控制器提供了對IaaS層/容器云分配的計算資源、網絡資源、存儲資源的適配與管理，為應用提供部署編排能力和彈性可擴展的、高可靠的云化運行環境，主要包括資源適配、資源管理和應用管理模塊[24]。

●資源適配功能提供對計算資源、網絡資源和存儲資源的統一適配，可對分配給容器云平臺的 IaaS 層資源進行托管，將應用與具體的部署資源形態進行解耦。

●資源管理功能負責處理租戶對相關計算、存儲和網絡資源的申請，根據資源需求，通過編排和調度進行對應的資源的分配，同時對所有資源形成的各類集群進行統一的節點擴/縮容、節點遷移、節點健康度監控等。

●應用管理功能實現容器云上多種類型應用的創建、編排、部署、彈性伸縮與滾動升級等能力，為應用提供完善的運行環境，并且根據預置的策略進行彈性的資源伸縮。

彈性計算控制器分為多平面控制和單平面控制器兩個部分，分別負責控制面和運行面。多平面彈性計算控制器是管理員和租戶在整個彈性計算平臺的操作控制臺，實現了一個控制平面管理多個運行平面。單平面彈性計算控制器負責運行平面的部分容器集群管理，用于實現基于容器化單元的部署。ECC實現了業務多生產面管控，其調用關系如圖11所示。多平面管控可以概括為以下5點。

●控制面與運行面邏輯獨立。

●運行面單元化部署，需要形成獨立的資源池。

●控制面納管所有單元化資源池，分配給租戶使用。

●控制面具備支持獨立部署，也可以和運行面合設。

●控制面軟件支持高可用部署，運行面軟件集群化部署。

圖11 彈性計算多平面調用關系

3.5 CCP

容器云平臺通過封裝Docker/Kubernetes技術，提供容器服務編排和調度，其功能主要是計算、存儲、網絡的資源管理。CCP的資源管理功能具體包含以下3個。

●容器化計算資源管理主要基于容器集群信息，統一管理集群的資源配額、申請、分配和扣減。

●容器集群中的存儲單獨維護，通過Kubernetes集群的PVC（persistent volume claim）統一管理配額、申請、分配和扣減。

●容器集群中網絡的管理主要涉及操作使用的插件對應的網絡策略的管控，包括隔離、授權、連通性策略等；容器云平臺提供標準化接口，將集群信息上報，供彈性計算統一納管，包括集群認證信息、集群部署網絡插件等信息。

容器云平臺提供標準的南向北向接口，基于多平面彈性計算控制器管控和容器化的單元能力，實現了跨地域容災遷移、多資源池遷移、部分業務系統峰值資源遷移以及故障恢復后快速回切，具備單元化的部署能力。

4 結束語

業務需求和技術創新并行驅動加速網絡架構發生深刻變革。本文提出了一種電信業務功能虛擬化化架構，通過在業務功能虛擬化架構中引入IT虛擬網元和IT業務化設計編排器，使IT系統具備單元化部署能力和分布式云部署能力，支撐電信IT系統的能力“上云”，符合當前云網融合發展思路。BFV結合CN的技術理念，形成了一套標準的、輕量的業務支撐的集成開發環境。本文對于BFV的PaaS的組件在技術上進行了初步論證，但還需要更進一步地進行研究和規劃，例如：技術方面，BFV架構體系中如何引入無服務器的架構，實現更小、更靈活的動態容器單元；業務方面，對于VBF下的各業務中心如何更進一步進行服務標準化和能力解耦，如何通過引入業務網關實現核心能力和個性化功能解耦；接口方面，對于BFV的架構體系涉及的接口參考點如何進行標準化。后續需要根據業務需求與商業模式發展不斷地完善BFV的架構體系的柔性，以滿足未來業務多樣化需求。

[1] KATICA N, TAHIROVI? A. Opportunities for telecom operators in cloud computing business[C]//2012 Proceedings of the 35th International Convention MIPRO. Piscataway: IEEE Press, 2012: 495-500.

[2] SUZUKI M, OHTA M, NISHIKI K, et al. Next-generation telecom management system[J]. Hitachi Review, 1999, 48(4): 179.

[3] OUYANG Y, WANG L, YANG A, et al. The next decade of telecommunications artificial intelligence[J]. 2021, 37(3): 1-36.

[4] JINM S, QIUC L, LIJ. The designment of student information management system based on B/S architecture[C]//Proceedings of 2012 2nd International Conference on Consumer Electronics, Communications and Networks (CECNet). Piscataway: IEEE Press, 2012: 2153-2155.

[5] BORCEA C, DING X N, GEHANI N, et al. Avatar: mobile distributed computing in the cloud[C]//Proceedings of 2015 3rd IEEE International Conference on Mobile Cloud Computing, Services, and Engineering. Piscataway: IEEE Press, 2015: 151-156.

[6] ENGEL T, LANGERMEIER M, BAUER B, et al. Evaluation of microservice architectures: a metric and tool-based approach[C]// Information Systems in the Big Data Era, [S.L:s.n], 2018.

[7] HASSELBRING W, STEINACKER G. Microservice architectures for scalability, agility and reliability in E-commerce[C]// Proceedings of 2017 IEEE International Conference on Software Architecture Workshops. Piscataway: IEEE Press, 2017: 243-246.

[8] Microservices and SOA: Better together[EB]. 2016.

[9] LI W B, LEMIEUX Y, GAO J, et al. Service mesh: challenges, state of the art, and future research opportunities[C]//Proceedings of 2019 IEEE International Conference on Service- Oriented System Engineering. Piscataway: IEEE Press, 2019: 122-1225.

[10] CLARK T, BARN B S. Event driven architecture modelling and simulation[C]//Proceedings of 2011 IEEE 6th International Symposium on Service Oriented System. Piscataway: IEEE Press, 2011: 43-54.

[11] GANNON D, BARGA R, SUNDARESAN N. Cloud-native applications[C]//Proceedingsof IEEE Cloud Computing. Piscataway:IEEE Press, 2021: 16-21.

[12] Cloud native infrastructure: Patterns for scalable infrastructure and applications in a dynamic environment[EB]. 2017.

[13] SILL A. Cloud native standards and call for community participation[C]//Proceedingsof IEEE Cloud Computing. Piscataway: IEEE Press, 2021: 56-61.

[14] Mao Y, Fu Y, Gu S, et al. Resource management schemes for cloud-native platforms with computing containers of docker and kubernetes[J]. arXiv preprint arXiv: 2010.10350, 2020.

[15] CESELLI A, PREMOLI M, SECCI S. Mobile edge cloud network design optimization[J]. ACM Transactions on Networking, 2017, 25(3): 1818-1831.

[16] TALEB T, KSENTINI A, SERICOLA B. On service resilience in cloud-native 5G mobile systems[J]. IEEE Journal on Selected Areas in Communications, 2016, 34(3): 483-496.

[17] 3GPP. System architecture for the 5G system (5GS): TS 23.501 V16.5.1 [S]. 2020.

[18] 3GPP. Management and orchestration: TS 28.533 V16.4.0[S]. 2020.

[19] ETSI. Network functions virtualisation use cases: GS NFV 001 V1.1.1 [S]. 2012.

[20] ETSI. Network functions virtualisation (NFV) release 2; management and orchestration; architectural framework specification: GS NFV 006 V2.1.1[S]. 2021.

[21] DEJESUS GIL HERRERA J, BOTERO VEGA J F. Network functions virtualization: asurvey[J]. IEEE Latin America Transactions, 2016, 14(2): 983-997.

[22] MIJUMBI R, SERRAT J, GORRICHO J L, et al. Management and orchestration challenges in network functions virtualization[J]. IEEE Communications Magazine, 2016, 54(1): 98-105.

[23] 中國電信集團公司. 中國電信IT云服務能力平臺技術白皮書[R]. 2017.

China Telecom. White paper on IT cloud services capacity of platform technology from China Telecom[R]. 2017.

[24] 雷波, 王江龍, 趙倩穎, 等. 基于計算、存儲、傳送資源融合化的新型網絡虛擬化架構[J]. 電信科學, 2020, 36(7): 42-54.

LEI B, WANG J L, ZHAO Q Y, et al. Novel network virtualization architecture based on the convergence of computing, storage and transport resources[J]. Telecommunications Science, 2020, 36(7): 42-54.

A pilot study of Telco’s next generation IT architecture evolution:business function virtualization (BFV)

QIAO Wen1, WANG Xiaozheng2, SUN Zhenqiang3, REN Gan2, LIU Yunxin4, YANG Aidong1, WANG Peng1, WANG Da1, YE Xiaozhou1, OUYANG Ye1

1. AsiaInfo Technologies (China) Co., Ltd., Beijing 100193, China 2. China Mobile Group Zhejiang Co., Ltd., Hangzhou 310016, China 3. China Telecom Co., Ltd., Research Institute, Beijing 100035, China 4. Tsinghua University, Beijing 100084, China

With the development of information and communication technologies, traditional telecom business support systems (BSS) are facing the challenge of agilely meeting the flexible needs from business. Application scenarization, service standardization, technology componentization and resource sharing have gradually become the consensual features among the evolution of telecom BSS architectures. A business function virtualization (BFV)-based BSS architecture, which is based on cloud-native, micro-services, containers, and DevOps technologies, was proposed. By embedding four components into the architecture, including standardized virtual network functions, modular design orchestrator, micro-service management framework, and multi-plane elastic computing controller, the system is able to deploy unitized system and distributed cloud. Therefore, the requirements of flexible telecom business development and frequent evolution of the system could be satisfied by the proposed BFV-based BSS architecture. In other words, the lightweight delivery of IT technologies and agile business support could be fulfilled by using the proposed BFV-based BSS architecture, and the proposed architecture will eventually become the standard architecture of next generation telecom BSS.

business function virtualization, modular design orchestration, elastic computing controller, unitized deployment

TP181

A

10.11959/j.issn.1000?0801.2022093

2021?11?09；

2022?03?14

喬穩（1977? ），男，亞信科技（中國）有限公司產品研發中心產品與技術規劃中心IT技術資深專家，主要研究方向為企業級IT系統架構、 5G 通信智能計費、BSS業務支撐、云原生技術電信應用。

王曉征（1975? ），男，中國移動通信集團浙江有限公司信息技術部總經理，主要研究方向為云計算、人工智能、數據科學、科技研發創新與管理。

孫震強（1964? ），男，博士，中國電信股份有限公司研究院CTNet2025研究所所長，主要研究方向為移動通信、無線頻譜工程、HAPS和SDN。

任贛（1975? ），男，中國移動通信集團浙江有限公司信息技術部副總經理，主要研究方向為企業級IT系統架構、中臺體系框架、電信業務模型。

劉云新（1975? ），男，博士，清華大學教授、智能產業研究院首席研究員，主要研究方向為智能計算系統、AIoT、移動計算、邊緣計算。

楊愛東（1984? ），男，博士，亞信科技（中國）有限公司通信人工智能實驗室首席數據科學家，主要研究方向為5G無線通信、大數據挖掘、機器學習及其應用。

王鵬（1976? ），男，亞信科技（中國）有限公司產品研發中心中臺產品研發中心總經理，主要研究方向為企業級IT系統架構、中臺體系框架、研發創新與管理。

王達（1985? ），男，博士，亞信科技（中國）有限公司技術創新與標準化部總監，主要研究方向為移動通信、網絡傳輸、人工智能。

葉曉舟（1980? ），男，博士，亞信科技（中國）有限公司通信人工智能實驗室資深總監/首席科學家，主要研究方向為通信網絡與人工智能。

歐陽曄（1981? ），男，博士，亞信科技（中國）有限公司首席技術官、高級副總裁，國家特聘專家，北京市政府特聘專家，主要研究方向為移動通信、人工智能、數據科學、科技研發創新與管理。