随着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系统轻量交付和业务敏捷支撑，可作为下一代电信业务支撑系统的参考架构。
相关研究
通信网络BSS的架构演进和研究一直受到工业界和学术界的关注。通信网络BSS的IT架构演进历程如图1 所示，在业务灵活性和系统易扩展的“双重”驱使下，BSS的IT架构发展先后经历了基于客户机/服务器（client/server，C/S）和浏览器/服务器（browser/server，B/S）架构、基于 x86 分布式计算架构和基于面向服务的架构（service oriented architecture，SOA）微服务架构等阶段的演进。
2012年3月，Fred George在Agile India 会议上分享了一篇题为Micro(u)services architecture- small, short lived services rather than SOA的主题演讲，首次引入了“微服务”的概念。Martin Fowler于2014年3月在文章Micro-services定义了微服务 IT 架构。“微服务”技术的出现极大丰富了BSS的IT架构可扩展性，有效实现了IT系统的灵活服务调度和资源隔离的能力。随后，研究者们尝试把SOA架构与“微服务”技术相结合，实现了IT服务间的解耦，很好地满足了多技术、多应用、多系统间的互相“融合与隔离”的需求，大大提高了企业效率，减少了IT运营成本。尽管如此，该架构引发了很多“非业务”问题，如服务监控、服务权限控制、服务版本控制等。为了解决这些“非业务”问题，2017年，Twitter的基础设施工程师 William Morgan 提出了一种处理网络问题的ServiceMesh技术，并基于该技术设计了一种专注于处理服务间通信的基础设施层，将“非业务”功能从代码中剥离，通过注入Sidecar方式实现微服务治理管控、数据流和控制流的分离，以形成“去中心化”的IT架构帮助处理“非业务”问题。此后，随着服务链路的不断变长，微服务与微服务之间的横向交互关系变得越来越脆弱，不能很好地与动态业务匹配。为了增强服务韧性，一种结合SOA和事件驱动架构（event-driven architecture，EDA）的混合架构事件驱动的面向服务架构（event-driven SOA）被提出，通过引入事件处理的能力，一个事件的产生可以触发一个或多个服务的调用，从而静态服务被串联在一起实现数据流的动态实时处理，当自动化业务流程或事件发生时，系统和组件能够实时动态做出响应，有效地实现了业务敏捷和能力复用。
图1 通信网络BSS的IT架构演进历程
Pivotal公司Matt Stine于2013年首次提出云原生（cloud native，CN）的概念，并广泛应用于云计算领域，随后IT架构朝着基于CN架构体系发展。CN由一系列云技术、企业管理方法集合等组成，包括DevOps、持续交付、微服务、敏捷基础设施等。云原生计算基金会（Cloud Native Computing Foundation，CNCF）认为 CN具有三大优势：以容器作为基础形成的代码和组件的重用；以集中式编排调度系统实现的动态资源管理；面向微服务的服务间依赖和“解耦”能力。容器作为标准化软件单元，将应用及其所有依赖项打包，将应用与底层运行环境解耦，屏蔽了底层架构差异性，使应用不再受环境限制，帮助应用平滑运行在不同基础设施，实现了资源共享。虚拟化和容器技术的融合，已成为未来重要趋势，随着开放式容器提案（open container initiative， OCI）标准的出现，不同技术采用了一致的方式进行容器生命周期管理，进一步促进了容器引擎技术的持续创新。以开源容器和容器编排引擎为基础，按照容器为资源分割的基本单位，封装各类应用和运行环境，为开发者和系统管理者提供用于构建、发布和运行分布式应用的容器云平台——容器即服务（container as a service，CaaS）。CaaS 同时提供了传统的基础设施即服务（infrastructure as a service，IaaS） 和平台即服务（platform as a service，PaaS ）两种能力。IT架构基础设施层由以资源调度为中心，向上演进为以容器为中心进行调度，使用CaaS提供的服务，实现了应用运行环境的无关性。
无服务器（serverless）技术[12-13]伴随 CN 技术兴起从观望逐渐落地，通过事件驱动和云服务连接，serverless能力会扩展到整个云的生态中。CN架构最显著的特点是稳健的软件韧性，这种韧性主要表现在所采用的单元化设计上。在单元化设计中，服务仍然是分层的，不同的是每一层中的任意一个节点都属于且仅属于某一个单元，上层调用下层时，仅会选择本单元内的节点。一个单元是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务以及分配给这个单元的数据和单元可运行的资源。相应地，单元化部署是在多个资源可用区，部署多个实例来供业务服务，业务服务需要微服务、CN、分布式事务体系支撑并设计业务模型和微服务边界，最终形成业务单元，业务单元通过容器化的封装，进行场景化编排和动态调度，实现业务弹性扩展、复制，由中心节点扩展到其他节点。
近年来，云网络技术异军突起，CN技术被广泛应用在云网络中，CT架构正由虚拟化的网络架构向 CN 的云网络架构演进。云网络是指基于对网络资源的虚拟化，将适配云特性的网络能力开放给用户，以满足企业上云过程中“云-边-端”互联互通需求的服务的集合。云网络是由各种网元组成的，例如交换机、路由器、NAT 网关、负载均衡等，这些网元在云网络中通常称为虚拟化网元。虚拟化网元是各种云网络组件的基本承载形态，它提供标准的服务化接口以及多租户的能力，满足业务需求快速迭代和灵活组网。
综上所述，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的网络服务拓扑，将图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）相对应，也需要研究 BFUO中涉及BSD的定义、要素和标准化。相较于传统的服务总线管理和 API 能力开放平台的集成， BFUO关键功能与BFUO外部关系如图8所示， BFUO 存在如下功能变化：新增了服务设计功能模块，实现业务服务中IT虚拟网元的设计；在场景服务编排中，新增IT虚拟网元的生命周期管理、策略管理、BSD 信息管理，有利于服务的治理和API 的管控；在运维和开发交付方面，通过服务化接口实现与DevOps/AIOps平台的对接和数据交互。
BFUO 的编排能力中应该具有设计器的功能，具备BSS域IT资产的全局视图展现以及组网和编排能力。其设计器示意图如图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点。
● 微服务相关组件运行面支持多平面部署。
● 微服务主控制面可纳管多个平面的运行面，控制台可以通过切换平面，对单侧进行管理。
● 微服务相关组件复用基础技术组件（如配置数据库、注册中心、缓存、消息中间件等）。其中配置数据库多平面复用，采用主从架构实现高可用。
3.4 弹性计算控制器弹性计算控制器提供了对 IaaS 层/容器云分配的计算资源、网络资源、存储资源的适配与管理，为应用提供部署编排能力和弹性可扩展的、高可靠的云化运行环境，主要包括资源适配、资源管理和应用管理模块。
● 资源适配功能提供对计算资源、网络资源和存储资源的统一适配，可对分配给容器云平台的 IaaS 层资源进行托管，将应用与具体的部署资源形态进行解耦。
● 资源管理功能负责处理租户对相关计算、存储和网络资源的申请，根据资源需求，通过编排和调度进行对应的资源的分配，同时对所有资源形成的各类集群进行统一的节点扩/缩容、节点迁移、节点健康度监控等。
图10 微服务管理的调用关系
● 应用管理功能实现容器云上多种类型应用的创建、编排、部署、弹性伸缩与滚动升级等能力，为应用提供完善的运行环境，并且根据预置的策略进行弹性的资源伸缩。
弹性计算控制器分为多平面控制和单平面控制器两个部分，分别负责控制面和运行面。多平面弹性计算控制器是管理员和租户在整个弹性计算平台的操作控制台，实现了一个控制平面管理多个运行平面。单平面弹性计算控制器负责运行平面的部分容器集群管理，用于实现基于容器化单元的部署。ECC实现了业务多生产面管控，其调用关系如图11所示。多平面管控可以概括为以下5点。
● 控制面与运行面逻辑独立。
● 运行面单元化部署，需要形成独立的资源池。
● 控制面纳管所有单元化资源池，分配给租户使用。
● 控制面具备支持独立部署，也可以和运行面合设。
● 控制面软件支持高可用部署，运行面软件集群化部署。
3.5 CCP容器云平台通过封装 Docker/Kubernetes 技术，提供容器服务编排和调度，其功能主要是计算、存储、网络的资源管理。CCP 的资源管理功能具体包含以下3个。
● 容器化计算资源管理主要基于容器集群信息，统一管理集群的资源配额、申请、分配和扣减。
● 容器集群中的存储单独维护，通过Kubernetes集群的PVC（persistent volume claim）统一管理配额、申请、分配和扣减。
● 容器集群中网络的管理主要涉及操作使用的插件对应的网络策略的管控，包括隔离、授权、连通性策略等；容器云平台提供标准化接口，将集群信息上报，供弹性计算统一纳管，包括集群认证信息、集群部署网络插件等信息。
容器云平台提供标准的南向北向接口，基于多平面弹性计算控制器管控和容器化的单元能力，实现了跨地域容灾迁移、多资源池迁移、部分业务系统峰值资源迁移以及故障恢复后快速回切，具备单元化的部署能力。
图11 弹性计算多平面调用关系
结束语
业务需求和技术创新并行驱动加速网络架构发生深刻变革。本文提出了一种电信业务功能虚拟化化架构，通过在业务功能虚拟化架构中引入 IT虚拟网元和IT业务化设计编排器，使IT系统具备单元化部署能力和分布式云部署能力，支撑电信IT系统的能力“上云”，符合当前云网融合发展思路。BFV结合CN的技术理念，形成了一套标准的、轻量的业务支撑的集成开发环境。本文对于BFV的PaaS 的组件在技术上进行了初步论证，但还需要更进一步地进行研究和规划，例如：技术方面，BFV架构体系中如何引入无服务器的架构，实现更小、更灵活的动态容器单元；业务方面，对于VBF下的各业务中心如何更进一步进行服务标准化和能力解耦，如何通过引入业务网关实现核心能力和个性化功能解耦；接口方面，对于BFV的架构体系涉及的接口参考点如何进行标准化。后续需要根据业务需求与商业模式发展不断地完善BFV的架构体系的柔性，以满足未来业务多样化需求。
