微服务架构在核心网产品中的应用

韩相国

摘要：微服务架构是目前应用较为广泛的一种软件架构，在IT领域已经有广泛的应用，但是由于电信行业的特殊性，一直没有采用微服务架构。随着5G的到来，电信核心网软件也向着微服务架构转变。通过研究电信核心网软件的特征，从架构层面分析微服务架构在电信核心网产品上应用的理论可行性，并在5G核心网NRF网元进行了实践。首先选择k8s作为基础运行平台，然后根据应用需要增加共享服务，最后对NRF网元的功能进行微服务拆分，最终形成一套完整的NRF网元软件架构。经项目验证，基于微服务架构的NRF网元能够满足商用要求，電信核心网产品完全可以基于微服务架构构建。

关键词：微服务;5G;电信软件;核心网;架构设计

引言

微服务概念的提出由来已久，早在2005年，Peter Rodgers博士在Web Services Edge大会上提出“Micro-Web-Services”的概念，他强调独立的软件组件以“Micro-Web-Services”的形式存在，组件之间完全松耦合，每个组件提供通用格式的REST 接口，通过多个组件的调用完成完整的软件功能。2011年在威尼斯举办的软件架构大会上，某工作组使用“microservice”来描述这种软件架构，随后在2012年，该工作组正式将这种软件架构命名为“microservice”（微服务）架构[1]。

一般认为，微服务架构是一种由面向服务架构（SOA）演进而来的软件架构设计方法，用于构建灵活的、松耦合、可独立部署的软件系统。与传统的SOA架构相比，两者存在显著区别：在服务间通信方面，SOA架构往往采用重量级的通信协议，例如SOAP、WSDL定义接口标准等，而微服务架构则使用轻量级的通信协议，如REST、gRPC等，相比较之下，微服务使用的通讯协议实现难度小，复杂度低;在服务规模上，SOA倾向于使用粗粒度的服务，并尽可能地粗粒度建模，通过组合一组粗粒度服务，构建出新的应用程序;而微服务架构则强调细粒度的建模，每个微服务提供的功能尽可能单一，应用程序通过多个微服务的组合调用实现所需功能。

相较于传统的软件架构，微服务架构的典型特征与优势如下：

1）软件规模小：这里的小并不是单纯的指代码量少，更多的是指将紧密相关、紧耦合的软件功能放到一个微服务中，使得程序更内聚、更容易理解，便于开发、测试。

2）基于接口：每个微服务将自身的功能封装为外部接口，外部模块/服务通过接口调用获得本服务提供的功能，这种方式很大程度上保证了微服务的独立性，功能扩展更容易。

3）分布式开发：受益于基于接口的实现方式，微服务间的接口明确后，多团队可以并行开发，独立部署、测试，降低团队之间的协作要求，提升开发效率。

4）团队自治：各团队依据自身的技术能力实现软件功能，没有统一框架束缚，团队更容易使用自身熟悉的技术，当然也更容易引入新技术。

尽管微服务架构有诸多优势，但是微服务架构只是一种软件架构，需要有一个合适的运行平台做支撑才能发挥其优势，恰在此时，容器技术应运而生，容器技术为微服务提供了部署、运行基础，就像为之量身定制，这也直接催生了微服务架构在后续的软件架构领域大放异彩。

电信核心网引入微服务架构

电信核心网产品介绍

电信核心网产品由多个独立的网元组成，这些网元一起配合完成用户的信令处理和业务流量转发。一般运营商会以省/市为单位建核心网，所以设备数量比较少，为了保证服务质量，运营商对核心网软件的要求也比较高：①高可靠性：电信设备要求全年7*24小时不间断运行，可靠性要达到99.999%;②大容量：单套设备处理百万用户业务;③高并发：有足够的能力保证百万级用户信令的处理;④低时延：电信设备需要尽最大速率转发用户流量。

与一般的软件相比，核心网软件的规模庞大（代码量千万行级别）、复杂度高，选择合理的软件架构就显得极为重要。在2/3/4G时代，核心网软件大部分都是采用单体架构，通过横向扩展单体软件数量实现容量和处理能力的增强。

电信核心网引入微服务架构

移动互联网进入了5G时代后，3GPP协议标准明确要求5G核心网网元使用服务化架构，网元之间的通讯也统一使用服务化接口。顺应协议要求，核心网软件架构也从单体架构向微服务架构转型。接下来以核心网中的NRF网元为例，介绍该网元的微服务拆分过程以及最终的软件架构。

NRF网元主要提供网元服务发现注册功能，核心网网元服务上线后需要向NRF注册，服务下线时撤销注册，这样NRF网元就具有了本系统中所有网元的服务实例信息。在运行过程中，任意网元都可以通过服务化接口从NRF网元获取特定的服务信息。

根据NRF网元提供的功能进行服务拆分，总体可分为四个业务服务[2]：①NFManagement：网元服务实例注册管理;②NFDiscovery：服务发现功能的处理;③AccessToken：安全认证管理;④Bootstraping：提供本网元的服务端点信息。除了基础业务服务外，系统还需要一些辅助功能：⑤DB：负责网元运行中状态数据的存储;⑥OAM：业务管理，提供配置管理、跟踪、日志等功能。

为了保证业务高可用，以上服务均采用负荷分担工作模式。

系统架构设计

底层平台架构设计

目前比较成熟的虚拟化运行平台主要有两种，分别是虚机虚拟化和容器虚拟化，两者适用的场景也有很大差异。前者适合于单体软件架构，以虚机为单位进行部署，后者适用于微服务架构，以容器为单位进行部署。本文中的NRF网元使用微服务架构，所以本网元考虑使用业界成熟的k8s作为基础运行平台。

除了基础运行平台外，还有几部分公共功能需要考虑：

1）通讯平台：用于实现微服务之间的通讯，服务网格是很好的选择。服务网格是致力于解决服务间通信的基础设施层，负责微服务间灵活、高效和可靠地通讯 [3]。本网元使用Istio作为底层通讯平台。

2）业务接口/负载均衡组件：NRF网元对外通讯全部使用服务化接口，使用的通讯协议为HTTP/HTTPS，接口组件优先选择NGINX。

3）系统公共服务：包括性能指标、告警、KPI监控、跟踪、日志收集等，这些公共服务实时监测系统运行状態。

整体架构设计

整体软件架构如下：

上图中每个虚线框代表一个逻辑服务，每个逻辑服务对应k8s系统中的一个Service。每个Service内部由一个或者多个POD组成，每个POD内运行一个或者两个容器。对于业务POD，内部包含业务容器和istio-proxy容器，前者用于处理业务逻辑，后者负责业务容器与其他容器之间的通讯。

前文已经描述了各业务服务的功能，这里介绍下其他服务：

1）负载均衡服务（LB）：LB绑定了本网元的业务地址，负责从外部系统接收信令，同时将内部的外发报文送到系统外部。

2）共享服务（Share Service）：主要分为三部分功能：①Metric统计：业务和istio-proxy上报运行过程中的统计数据，用户可以通过这些数据判断系统运行状态，也可以自定义告警规则，当满足特定条件后，触发告警;②调用链跟踪：用于呈现系统对特定报文的处理过程，数据上报到jaeger，jaeger最终形成完整的调用过程图;③日志系统：业务将运行过程中的产生的日志推送到elastic search中，后续有故障发生时，运维可以根据日志进行回溯。

3）网元管理（ADM）：使用operator对接k8s系统管理，将本网元需要的运行数据直接写入到k8s系统中，减少人工干预。

结语

微服务架构是目前应用较为广泛的一种分布式软件架构，本文结合了电信核心网产品的特点，以NRF网元为例，进行了以微服务架构为核心的整体软件架构设计。从网元运行平台的选型、网元业务微服务拆分和共享服务构建三个方面，分析了核心网网元微服务架构的构建过程，并给出了一个完整的架构设计方案。从项目的开发情况看，本架构能够满足商用要求。当然随着需求增加，系统还会不断增加功能，后续根据实际系统运行情况再进行有针对性的改进。最后，架构是为产品服务的，未来也会根据需要对现有架构进行改进，确保架构始终满足产品需求。

参考文献

[1]Dragoni， Nicola ... "Microservices： yesterday， today， and tomorrow". Present and Ulterior Software Engineering： 195–216.ISBN 978-3-319-67424-7. S2CID 14612986

[2]3GPP TS 29.510-Network Function Repository Services Stage 3

[3]杨怡滨等.服务网格性能优化关键技术研究[J].计算机应用与软件，2021，38（11）：24-30，85