CN111147322A

CN111147322A - 5g核心网微服务架构的测试系统及方法

Info

Publication number: CN111147322A
Application number: CN201911279584.XA
Authority: CN
Inventors: 陶昕昕
Original assignee: Zhongying Youchuang Information Technology Co Ltd
Current assignee: Zhongying Youchuang Information Technology Co Ltd
Priority date: 2019-12-13
Filing date: 2019-12-13
Publication date: 2020-05-12
Anticipated expiration: 2039-12-13
Also published as: CN111147322B

Abstract

本发明公开了一种5G核心网微服务架构的测试系统及方法，该系统包括：微服务平台、测试服务器、监控平台；其中，微服务平台，用于提供采用5G核心网微服务架构的网络服务；测试服务器，与微服务平台通信，用于向微服务平台发送测试请求，并接收微服务平台返回的响应数据；监控平台，与微服务平台和测试服务器分别通信，用于监控微服务平台的资源使用情况，并返回至测试服务器；其中，测试服务器还用于根据微服务平台返回的响应数据、微服务平台的资源使用情况，确定微服务平台的测试结果。本发明能够模拟高并发负载请求，实现对5G核心网微服务架构的各种高性能测试，进而根据测试结果，确定一种性能最优的5G核心网微服务架构。

Description

5G核心网微服务架构的测试系统及方法

技术领域

本发明涉及5G通信领域，尤其涉及一种5G核心网微服务架构的测试系统及方法。

背景技术

本部分旨在为权利要求书中陈述的本发明实施例提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

伴随着5G时代的到来，单一的物理网络已经无法满足各种垂直行业、万物互联的业务需求，5G时代追求以更低的成本，支持大流量和大连接，使用新技术实现灵活的多样化服务，提升连接的价值，因而，5G网络需要一个敏捷，且可持续演进的新架构。

借鉴IT领域的“微服务”设计理念，未来的5G系统架构将基于服务的网络架构，将网络功能定义为多个相对独立可被灵活调用的服务模块。基于微服务网络架构，运营商可以按照业务需求进行灵活定制组网，使得5G网络真正面向云原生(Cloud Native)设计，具备多方面优点，例如，便于网络快速升级、提升网络资源利用率、加速网络新能力引入，以及在授权的情况下开放给第三方等。

微服务框架是服务化架构SBA(Service based Architecture：基于服务的5G网络架构)的核心，在满足基础性需求的基准上，还要具备高性能、高可靠、高稳定等能力，具备业务故障自动修复能力，在要求的最短时间内做高效处理且能够保证系统长时间高效稳定运行不出错。

基于5G核心网(5G core network，简称5GC)的微服务框架须满足以下场景：

①5GC网管计划纳管3000多台网元，每五分钟粒度下的基础采集指标记录约达200多万条，其中包含原始指标解析与集中汇总入库，高密度的解析入库要求微服务框架支持大流量和高并发的采集调用，且必须保证采集结果准确无遗漏；

②5GC网管系统中的配置域包含切片数据配置管理，切片定制管理的部署下发过程涉及到与网元的集中交互，为确保切片定制化管理进程不出错，要求微服务框架对各类破坏性场景具有极强的适应能力，微服务平台需要注册多个服务实例，分多个物理机部署API网关节点，在宕机各组件和微服务运行机器的过程中，避免单点失败对集群的影响，确保外部调用的正常运行；

③5GC网管系统需要支持水平扩容：通过提高机器性能、增加CPU或内存这种向上扩展的方式终将遇到瓶颈，而5GC网管移动网络架构结合云化技术能够更容易获得足够的计算资源，要求微服务平台针对系统运行情况实现动态扩缩容，减少机器性能瓶颈对系统业务造成的性能影响。

目前，现有微服务框架测试方案，仅针对框架本身的可用性与基础性作功能性测试，测试方法都是单一的自动化接口测试，不涉及到各种破坏性场景和动态扩缩容的情况，无法针对5GC网管的业务需求或场景进行功能定制，以提供一种专门针对5GC网管高性能、高可用微服务框架的测试方案。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供一种5G核心网微服务架构的测试系统，用以解决现有微服务框架测试方案，仅支持对微服务框架本身的可用性与基础性进行功能性测试，无法适用于高并发请求的5G核心网微服务架构的功能测试的技术问题，该测试系统包括：微服务平台、测试服务器、监控平台；其中，微服务平台，用于提供采用5G核心网微服务架构的网络服务；测试服务器，与微服务平台通信，用于向微服务平台发送测试请求，并接收微服务平台返回的响应数据；监控平台，与微服务平台和测试服务器分别通信，用于监控微服务平台的资源使用情况，并返回至测试服务器；其中，测试服务器还用于根据微服务平台返回的响应数据、微服务平台的资源使用情况，确定微服务平台的测试结果。

本发明实施例还提供一种5G核心网微服务架构的测试方法，用以解决现有微服务框架测试方案，仅支持对微服务框架本身的可用性与基础性进行功能性测试，无法适用于高并发请求的5G核心网微服务架构的功能测试的技术问题，该方法包括：向微服务平台发送测试请求，其中，微服务平台提供采用5G核心网微服务架构的网络服务；接收微服务平台返回的响应数据；监控微服务平台的资源使用情况；根据微服务平台返回的响应数据、微服务平台的资源使用情况，确定微服务平台的测试结果。

本发明实施例还提供一种计算机设备，用以解决现有微服务框架测试方案，仅支持对微服务框架本身的可用性与基础性进行功能性测试，无法适用于高并发请求的5G核心网微服务架构的功能测试的技术问题，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述5G核心网微服务架构的测试方法。

本发明实施例还提供一种计算机可读存储介质，用以解决现有微服务框架测试方案，仅支持对微服务框架本身的可用性与基础性进行功能性测试，无法适用于高并发请求的5G核心网微服务架构的功能测试的技术问题，该计算机可读存储介质存储有执行上述5G核心网微服务架构的测试方法的计算机程序。

本发明实施例中，通过测试服务器向提供5G核心网微服务架构网络服务的微服务平台发送测试请求，并接收微服务平台返回的响应数据，通过监控平台监控微服务平台的资源使用情况，使得测试服务器能够根据微服务平台返回的响应数据，以及监控平台监控到的微服务平台的资源使用情况，确定微服务平台的测试结果。

通过本发明实施例，能够模拟高并发负载请求，实现对5G核心网微服务架构的各种高性能测试，进而根据测试结果，确定一种性能最优的5G核心网微服务架构。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1为本发明实施例中提供的一种5G核心网微服务架构的测试系统示意图；

图2为本发明实施例中提供的一种5G核心网微服务架构示意图；

图3为本发明实施例中提供的一种5G核心网微服务架构的测试方法流程图；

图4为本发明实施例中提供的一种测试环境硬件示意图；

图5为本发明实施例中提供的一种查询采集服务解析存入My SQL数据库的记录条数是否完整的结果示意图；

图6为本发明实施例中提供的又一种查询采集服务解析存入My SQL数据库的记录条数是否完整的结果示意图；

图7为本发明实施例中提供的一种将采集服务解析入My SQL的记录与FTP服务器上原始的基准CSV文件进行抽取对比的示意图；

图8为本发明实施例中提供的一种性能采集节点故障容错测试结果示意图；

图9为本发明实施例中提供的一种微服务平台动态扩缩容功能测试界面示意图；

图10为本发明实施例中提供的一种未达到扩容阈值时的服务实例界面示意图；

图11为本发明实施例中提供的一种达到扩容阈值时的CPU利用率示意图；

图12为本发明实施例中提供的一种达到扩容阈值自动拉起另一个服务实例的界面示意图；

图13为本发明实施例中提供的一种达到缩容阈值时自动移除一个服务实例的界面示意图；

图14为本发明实施例中提供的一种达到缩容阈值时的CPU利用率示意图；

图15为本发明实施例中提供的一种API网关节点宕机测试界面示意图；

图16为本发明实施例中提供的一种API网关节点宕机操作界面示意图；

图17为本发明实施例中提供的一种API网关节点宕机恢复界面示意图；

图18为本发明实施例中提供的一种API网关节点宕机时间段内的CPU利用率示意图；

图19为本发明实施例中提供的一种API网关节点断网操作界面示意图；

图20为本发明实施例中提供的一种API网关节点断网恢复界面示意图；

图21为本发明实施例中提供的一种API网关节点断网时间段内的CPU利用率示意图；

图22为本发明实施例中提供的一种服务节点宕机操作界面示意图；

图23为本发明实施例中提供的一种服务节点宕机恢复界面示意图；

图24为本发明实施例中提供的一种服务节点宕机时间段内的CPU利用率示意图；

图25为本发明实施例中提供的一种服务节点断网操作界面示意图；

图26为本发明实施例中提供的一种服务节点断网恢复界面示意图；

图27为本发明实施例中提供的一种服务节点断网时间段内的CPU利用率示意图；

图28为本发明实施例中提供的一种查询峰值调用性能测试界面示意图；

图29为本发明实施例中提供的一种查询峰值调用性能测试中设置超时时间的界面示意图；

图30为本发明实施例中提供的一种查询峰值调用性能测试结果示意图；

图31为本发明实施例中提供的一种查询并发调用性能测试界面示意图；

图32为本发明实施例中提供的一种查询并发调用性能测试中设置超时时间的界面示意图；

图33为本发明实施例中提供的一种查询并发调用性能测试中设置并发用户数的界面示意图；

图34为本发明实施例中提供的一种查询并发调用性能测试结果示意图；

图35为本发明实施例中提供的一种稳定性测试的日志记录示意图；

图36为本发明实施例中提供的一种稳定性测试的日志记录示意图；

图37为本发明实施例中提供的一种通过zabbix监控平台查看服务节点的性能指标的界面示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

在本说明书的描述中，所使用的“包含”、“包括”、“具有”、“含有”等，均为开放性的用语，即意指包含但不限于。参考术语“一个实施例”、“一个具体实施例”、“一些实施例”、“例如”等的描述意指结合该实施例或示例描述的具体特征、结构或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。各实施例中涉及的步骤顺序用于示意性说明本申请的实施，其中的步骤顺序不作限定，可根据需要作适当调整。

本发明实施例中提供了一种5G核心网微服务架构的测试系统，图1为本发明实施例中提供的一种5G核心网微服务架构的测试系统示意图，如图1所示，该系统包括：微服务平台10、测试服务器20、监控平台30。

其中，微服务平台10，用于提供采用5G核心网微服务架构的网络服务；

测试服务器20，与微服务平台10通信，用于向微服务平台发送测试请求，并接收微服务平台返回的响应数据；

监控平台30，与微服务平台10和测试服务器20分别通信，用于监控微服务平台的资源使用情况，并返回至测试服务器30；

其中，测试服务器还用于根据微服务平台返回的响应数据、微服务平台的资源使用情况，确定微服务平台的测试结果。

可选地，本发明实施例中的测试服务器20上安装有Jmeter测试工具，通过Jmeter测试工具模拟负载向微服务平台发送业务请求。通过Jmeter测试工具模拟客户端调用的真实负载，能够确保测试结果准确有效。

可选地，本发明实施例采用的监控平台30可以是但不限于Zsabbix监控平台。

需要说明的是，本发明实施例中微服务平台上部署有基于5G核心网微服务架构的网络服务；图2为本发明实施例中提供的一种5G核心网微服务架构示意图。

由上可知，本发明实施例提供了一种5G核心网微服务架构的测试系统，通过测试服务器20向提供5G核心网微服务架构网络服务的微服务平台10发送测试请求，并接收微服务平台10返回的响应数据，通过监控平台30监控微服务平台10的资源使用情况，使得测试服务器20能够根据微服务平台返回的响应数据，以及监控平台30监控到的微服务平台的资源使用情况，确定微服务平台10的测试结果。

基于同一发明构思，本发明实施例中还提供了一种5G核心网微服务架构的测试方法，如下面的实施例所述。由于该方法实施例解决问题的原理与5G核心网微服务架构的测试系统相似，因此该方法实施例的实施可以参见上述系统的实施，重复之处不再赘述。

图3为本发明实施例中提供的一种5G核心网微服务架构的测试方法流程图，如图3所示，该方法可以包括如下步骤：

S301，向微服务平台发送测试请求，其中，微服务平台提供采用5G核心网微服务架构的网络服务；

S302，接收微服务平台返回的响应数据；

S303，监控微服务平台的资源使用情况；

S304，根据微服务平台返回的响应数据、微服务平台的资源使用情况，确定微服务平台的测试结果。

需要说明的是，本发明实施例通过上述S301发送的测试请求可以是但不限于网管系统向采用5G核心网微服务架构的5G核心网发送的查询请求、采集请求、登录请求、下发请求中的一种或多种。以查询或采集请求为例，本发明实施例中查询或采集请求获取到的指标信息包括但不限于：以太接口流量、CPU内存占用率等设备公共指标信息，以及5G签约用户数、5G激活用户数、鉴权请求成功次数等网元测量指标信息。

可选地，上述S301可以基于Jmeter测试工具向微服务平台发送测试请求；上述S303可以通过Zabbix监控平台监控微服务平台的资源使用情况。基于压测工具Jmeter设计测试计划，模拟真实请求流量，构造高并发访问场景，对微服务框架做性能测试，利用zabbix监控硬件性能评定微服务框架内存占用情况。

优选地，通过Jmeter测试工具梯度式增加或减少接口并发数逐渐加大或减少CPU占用率，能够验证微服务实例可随CPU增加或降低到指定阀值，自动扩展和减少实例个数，达到动态扩缩容。

需要注意的是，上述S301至S304提供的方案可以是由同一台设备执行的，也可以是由不同的设备的执行的，例如，图1所示的测试系统中，通过测试服务器执行上述S301、S302和S304；通过监控平台执行上述S303。

本发明实施例中监控的微服务平台的资源使用情况包括但不限于如下任意之一：流量、CPU利用率和内存占用率。

由上可知，本发明实施例提供的5G核心网微服务架构的测试方法，通过测试服务器向提供5G核心网微服务架构网络服务的微服务平台发送测试请求，并接收微服务平台返回的响应数据，通过监控平台监控微服务平台的资源使用情况，使得测试服务器能够根据微服务平台返回的响应数据，以及监控平台监控到的微服务平台的资源使用情况，确定微服务平台的测试结果。

通过本发明实施例提供的5G核心网微服务架构的测试方法，能够模拟高并发负载请求，实现对5G核心网微服务架构的各种高性能测试，进而根据测试结果，确定一种性能最优的5G核心网微服务架构。

本发明实施例可以针对5GC网管的需求特性制定测试策略，通过测试微服务框架的相关性能、稳定性、高可用等能力，基于测试结果分析得出微服务框架的高可用能力和性能瓶颈，通过不断修复调优测试，直到符合测试方案评优标准，最终开发出满足5GC网管需求的高可靠、高性能的微服务框架。通过模拟各种破坏性测试场景如拔掉某台物理机网线(断网)、关闭特定服务接口(宕机)，考验微服务框架在线上环境的高可用性。

本发明实施例提供的5G核心网微服务架构的测试方法可以应用于但不限于5G核心网网管系统(5GC网管)中，下面，以5G核心网网管系统的网元信息采集和查询服务为例，来对本发明实施例进行详细说明。

为了从多个5G核心网微服务架构(例如，不同厂商提供的5G核心网微服务架构)中筛选出高性能、高可用的微服务框架，本发明实施例将不同的微服务框架搭建在统一提供的实验室环境下，且所有的硬件资源全部保持一致；测试期间微服务软件架构的开源组件均相同，测试工具均使用Jmeter(版本5.1.1)测试工具，确定统一的Jmeter执行脚本；使用Zabbix监控平台对微服务平台所用CPU利用率、内存占用率等资源使用情况进行监控。

测试内容分为采集和查询两部分标准化服务，采集服务的测试用例主要包括性能数据采集效率、性能采集节点故障容错测试；查询服务的测试用例主要包括测试微服务平台动态扩缩容功能、高可靠测试和性能测试。测试过程完全封闭，测试完毕后，结合人工校验结果、Zabbix监控平台的实时监控记录和Jmeter脚本执行数据三项内容统一汇总，分析输出最终的测试数据，分别记录不同微服务架构的测试结果，最后依据方案中测试用例的评估指标，对不同的微服务架构进行评估，从而筛选出最优的微服务框架。

(一)测试环境：

①硬件要求：如表1所示，提供6台高性能服务器、1台低性能服务器作为测试环境的硬件资源。图4为本发明实施例中提供的一种测试环境硬件示意图，如图4所示，图标10所示为由4台高性能服务器搭建的微服务平台；图标30A所示为FTP服务器A(高性能服务器)，图标30B所示为FTP服务器B(低性能服务器)，其中，FTP服务器A是用于存放原始性能文件的服务器，在执行Jmeter接口测试需要从FTP服务器A上采集原始文件做解析计算，得到数据存入My SQL数据库；FTP服务器A兼作zabbix监控平台；FTP服务器B是一个备用服务器，当FTP服务器A不可用时，可用于临时存放原始性能文件。

需要注意的是，图4中未示出安装Jmeter测试工具的测试服务器。下面，以图1为例，本发明实施例假设测试服务器的IP地址为192.168.0.1；第一网关服务器的IP地址为192.168.0.2；第二网关服务器的IP地址为192.168.0.3；第一业务承载服务器的IP地址为192.168.0.4；第二业务承载服务器的IP地址为192.168.0.5；zabbix监控平台的IP地址为192.168.0.5；备用服务器的IP地址为192.168.0.6。

表1测试环境的硬件资源

②测试组件：

测试期间微服务软件架构的开源组件要求统一化，相关要求如表2所示，要求服务调度采用Kubernetes；API网关采用Zuul网关；服务API接口采用RestFUL(http1.0/1.1/2.0)；数据库统一使用My SQL数据库。

表2测试采用的开源组件

③测试工具：

A.测试期间采用标准化测试工具，如表3所示，对于功能测试、性能测试、高可用测试均采用Jmeter测试工具；

表3测试采用的测试工具

测试项	测试工具	自动化
			功能测试	Jmeter	是
性能测试	Jmeter	是
			高可用测试	Jmeter	是

B.软件组件及版本的查询脚本：要求各验证测试厂家均提供软件组件及版本的查询脚本，测试期间，由其他厂家所提供的查询脚本、待测试厂商所提供的查询脚本均进行软件组件及版本的查询；

C.由Zabbix监控平台对微服务平台所用CPU、内存等资源使用情况进行监控。

④标准化服务：

A.采集标准化服务：以模拟采集网元性能指标数据为主，具体服务要求如下：

a.在FTP服务器中存放10个MME设备性能统计目录，每个目录名称以设备名为标识；在目录中存放该MME设备的最近7天性能统计指标文件；

b.性能统计指标文件以5分钟颗粒度进行分割，文件名称以时间加以区分；

c.采集要求：第一，在最短的时间内完成性能统计文件的采集；第二，在性能统计指标文件内随机抽取4个统计指标COUNTER值，要求实时采集过程中，通过文件解析识别，将10个MME设备的指定统计指标COUNTER值统一输出至CSV文件，并将CSV文件FTP至指定服务器目录中；第三，在实时采集过程中，同步将性能统计文件所有COUNTER均实时存入My SQL数据库。

B.查询标准化服务：以性能指标存入My SQL数据库为查询对象，具体要求如下：

a.由Jmeter测试工具发起查询请求，查询请求包括：

查询条件：时间、网元设备名；

脚本要求：在指定时间范围内、10台设备范围内，随机生成查询条件；

输出要求：要求输出2个字段，字段1：随机对三个COUNTER值取平均值；字段2：随机对两个COUNTER值取累加值；

b.查询服务实例根据查询条件，对My SQL数据库查询获取对应COUNTER值，由查询实例进行平均值、累加值等计算，并将计算结果返回给Jmeter测试工具。

(二)采集服务测试：

①性能数据采集效率：Jmeter所在测试服务器192.168.0.1发起http请求，调用网关集群的IP端口192.168.0.2:8099，网关分发后台业务承载，在192.168.0.3、192.168.0.4上实现性能采集逻辑，从FTP服务器192.168.0.6中采集源文件做解析，生成的数据存入MySQL数据库。

一种实施例中，性能数据采集效率测试的测试用例如表4所示。

表4性能数据采集效率测试的测试用例

一种测试结果示例如下：

a.查询My SQL数据库，采集数据记录条数1051200个；查询为零的字段量27419451个；

b.查询FTP服务器CSV文件，CSV文件的采集数1051020个，抽查文件顺序是否正确：是；数值抽查是否一致(抽2个CSV文件)：是；

c.采集用时：2分57秒(即177s)。

图5为本发明实施例中提供的一种查询采集服务解析存入My SQL数据库的记录条数是否完整的结果示意图；图6为本发明实施例中提供的又一种查询采集服务解析存入MySQL数据库的记录条数是否完整的结果示意图；图7为本发明实施例中提供的一种将采集服务解析入My SQL的记录与FTP服务器上原始的基准CSV文件进行抽取对比的示意图。需要注意的是，对比软件可采用BCompare。

②性能采集节点故障容错测试：Jmeter所在测试服务器192.168.0.1发起http请求，调用网关集群的IP端口192.168.0.2:8099，网关分发后台业务承载，在A采集机192.168.0.3、B采集机192.168.0.4上实现性能采集逻辑，从FTP服务器192.168.0.6中采集源文件做解析，生成的数据入My SQL数据库。在任务下发过程中关闭192.168.0.3服务器，两分钟后恢复，记录性能采集业务是否存在异常，采集结果是否正确完整。

一种实施例中，性能采集节点故障容错测试的测试用例如表5所示。

表5性能采集节点故障容错测试的测试用例

一种测试结果示例如下：

功能1：

通过□不通过(关闭A采集机192.168.0.3后，系统界面能够显示A采集机状态异常)；

功能2：

通过□不通过(正在A采集机上运行的采集任务会被重新分发到B采集机192.168.0.4上，在采集机B上查看采集日志)；

功能3：a.查询My SQL数据库，采集数据记录条数1051200个；查询为零的字段量为27419451个；b.查询FTP服务器CSV文件，CSV文件的采集数105120，抽查文件顺序是否正确：是；数值抽查是否一致(抽2个CSV文件)：是。

图8为本发明实施例中提供的一种性能采集节点故障容错测试结果示意图；如图8所示，Zabbix平台监控两台采集机的流量占用情况，右侧为被拔掉网口网线的A采集机流量监控情况，可以看到拔掉网线之后，流量占用归零，恢复网线之后采集机正常运行，恢复采集任务，流量数据增加；左侧B采集机在A采集机关闭后承担了本应在A采集机上分发的任务，流量占用增加，在后续A采集机恢复后流量占用情况下降，恢复正常。

(三)采集服务测试：

①微服务平台动态扩缩容功能：

Jmeter所在测试服务器192.168.0.1发起http请求，调用网关集群的IP端口192.168.0.2:8090，网关分发后台业务承载，先只在192.168.0.3做查询服务，初始实例个数为1。通过Jmeter脚本梯度加压，使CPU或TPS持续增加直至达到扩容阈值，观察网关是否自动拉起192.168.0.4上的实例使总实例个数扩容到2；过Jmeter脚本梯度加压，使CPU或TPS持续降低直至达到缩容阈值，观察网关是否自动关闭192.168.0.4上的实例使总实例个数缩容到1个。

一种实施例中，微服务平台动态扩缩容功能测试的测试用例如表6所示。

表6微服务平台动态扩缩容功能测试的测试用例

一种测试结果示例如下：

a.基于CPU的扩容：

通过□不通过；

b.基于CPU的缩容：

通过□不通过；

c.基于TPS的扩容：

通过□不通过；

d.基于TPS的缩容：

通过□不通过。

图9为本发明实施例中提供的一种微服务平台动态扩缩容功能测试界面示意图；图10为本发明实施例中提供的一种未达到扩容阈值时的服务实例界面示意图；图11为本发明实施例中提供的一种达到扩容阈值时的CPU利用率示意图；图12为本发明实施例中提供的一种达到扩容阈值自动拉起另一个服务实例的界面示意图；图13为本发明实施例中提供的一种达到缩容阈值时自动移除一个服务实例的界面示意图；图14为本发明实施例中提供的一种达到缩容阈值时的CPU利用率示意图。

由图9～图14所示，未达到扩容阈值时只启用一个服务实例；伴随着并发用户数不断增加，CPU利用率持续增加到90％，达到扩容阈值，此时另一个服务实例自动拉起，分担了业务承载，CPU利用率下降；达到缩容阈值，其中一个服务实例自动移除；伴随着并发用户数不断减少，CPU利用率持续降低到20％，达到缩容阈值，此时另一个服务实例自动移除，图中剩余的这台承载了所有业务，CPU利用率有所增加。

②高可靠测试：

A.API网关节点宕机测试：Jmeter所在测试服务器192.168.0.1发起http请求，微服务平台搭建3个节点的API网关，每台物理机一个API网关节点，测试服务器对API网关集群提供的IP端口192.168.0.2:8090发起10分钟的持续查询调用，调用频次不低于1000/S。业务稳定后宕掉一个API节点所在虚机，观察待业务稳定后恢复虚机，三分钟后待业务稳定后拔掉一个API节点所在物理机的网线，观察待业务稳定后恢复网线。测试过程中，在宕机各组件和微服务运行机器的过程中，对外部应用的调用影响越小越好。

一种实施例中，API网关节点宕机测试的测试用例，如表7所示。

表7 API网关节点宕机测试的测试用例

一种测试结果示例如下：

功能1_恢复虚拟机：

a.所在API网关实例是否激活：

通过□不通过；

b.所在API网关实例是否承担业务：

通过□不通过；

功能1_恢复网线：

a.所在API网关实例是否激活：

通过□不通过；

b.所在API网关实例是否承担业务：

通过□不通过。

测试结果数据如表8所示。

表8 API网关节点宕机测试的测试结果

图15为本发明实施例中提供的一种API网关节点宕机测试界面示意图，如图15所示，微服务平台搭建起3个节点的API网关，每台物理机上一个API网关节点，由图15可以看到三个节点都处于正常运行状态。图16为本发明实施例中提供的一种API网关节点宕机操作界面示意图，如图16所示，worker15所在物理机宕机，剩余两台服务器正常运行。图17为本发明实施例中提供的一种API网关节点宕机恢复界面示意图，如图17所示，worker15所在物理机宕机后恢复，三台物理机均正常运行。图18为本发明实施例中提供的一种API网关节点宕机时间段内的CPU利用率示意图，如图18所示，worker15在宕机的时间段内，监控不到CPU利用率，曲线出现断开，宕机恢复后CPU占用率恢复正常，API网关正常运行。

图19为本发明实施例中提供的一种API网关节点断网操作界面示意图，如图19所示，worker15所在物理机断网，剩余两台服务器正常运行；图20为本发明实施例中提供的一种API网关节点断网恢复界面示意图，如图20所示，worker15所在物理机断网后恢复，三台物理机恢复初始状态，均正常运行；图21为本发明实施例中提供的一种API网关节点断网时间段内的CPU利用率示意图，如图21所示，worker15在断网的时间段内，监控不到CPU利用率，曲线出现断开，恢复断网后CPU占用率恢复，API网关正常运行。

B.服务节点宕机测试：Jmeter所在测试服务器192.168.0.1发起http请求，微服务平台搭建3个节点的服务实例，每台物理机一个服务节点，测试服务器对网关提供的IP端口192.168.0.2:8090发起10分钟的持续查询调用，调用频次不低于1000/S。业务稳定后宕掉一个服务节点所在虚机，观察待业务稳定后恢复虚机，三分钟后待业务稳定后拔掉一个服务节点所在物理机的网线，观察待业务稳定后恢复网线。测试过程中，在宕机各组件和微服务运行机器的过程中，对外部应用的调用影响越小越好。

一种实施例中，服务节点宕机测试的测试用例，如表9所示。

表9服务节点宕机测试的测试用例

一种测试结果示例如下：

功能1_恢复虚拟机：a.所在查询服务实例是否激活：

通过□不通过；b.所在查询服务实例是否承担业务：

通过□不通过；

功能1_恢复网线：a.所在查询服务实例是否激活，

通过□不通过；b.所在查询服务实例是否承担业务：

通过□不通过。

服务节点宕机测试的测试结果数据如表10所示。

表10服务节点宕机测试的测试结果

图22为本发明实施例中提供的一种服务节点宕机操作界面示意图，如图22所示，微服务平台搭建起3个节点的服务实例，每台物理机上一个服务节点，图中为一个服务节点worker17所在物理机宕机，另外两台物理机上的服务节点正常运行。

图23为本发明实施例中提供的一种服务节点宕机恢复界面示意图，如图23所示，worker17所在物理机宕机后恢复，三台物理机均正常运行；图24为本发明实施例中提供的一种服务节点宕机时间段内的CPU利用率示意图，如图24所示，worker17在宕机的时间段内，监控不到CPU利用率，曲线出现断开，宕机恢复后CPU占用率回归正常，该物理机上服务节点正常承载业务。

图25为本发明实施例中提供的一种服务节点断网操作界面示意图，如图25所示，拔掉work17所在物理机网线，可以看到服务节点不再工作；图26为本发明实施例中提供的一种服务节点断网恢复界面示意图，如图26所示，恢复网络后work17正常运行；图27为本发明实施例中提供的一种服务节点断网时间段内的CPU利用率示意图，如图27所示，worker17在断网的时间段内，监控不到CPU利用率，曲线出现断开，恢复断网后CPU占用率恢复，该物理机上服务节点正常承载业务。

③性能测试：

A.查询峰值调用性能测试：Jmeter所在测试服务器192.168.0.1发起http请求，通过API网关接口192.168.0.2:8090调用查询服务，网关分发后台业务承载，在A采集机192.168.0.3、B采集机192.168.0.4上实现查询服务。通过Jmeter自动化脚本增加TPS持续加压，设置Jmeter超时时间为1500毫秒，直至Jmeter脚本出现第一次报错。记录最大调用频次、最大响应时延，平均时延等记录。

一种实施例中，查询峰值调用性能测试的测试用例如表11所示。

表11查询峰值调用性能测试的测试用例

一种测试结果示例如下：

a.基本功能测试：在表12中填写记录，并提供相关日志及界面截图；

表12查询峰值调用性能基本功能测试记录表

记录	5分钟(30万次)	5分钟(60万次)	5分钟(120万次)
				调用总量	30万	60万	120万
平均响应时延(Jmeter)	1ms	1ms	1ms
				最大响应时延(Jmeter)	56ms	60ms	102ms
失败次数	0	0	0

b.峰值性能测试：3次；其中，最大调用频次(峰值)：31816；最大响应时延：1274ms(<＝1500ms)；平均时延：25ms。

图28为本发明实施例中提供的一种查询峰值调用性能测试界面示意图，如图28所示，Jmeter自动化测试工具编写测试脚本，实现内容：通过API网关调用查询服务，每过30s增加60个并发用户数，直至增加到2000个并发用户数，目的：通过逐步加大并发用户持续提升TPS(每秒处理请求数)，直到调用出现首次报错，脚本自动停止执行，记录最大调用频次。

图29为本发明实施例中提供的一种查询峰值调用性能测试中设置超时时间的界面示意图，如图29所示，Jmeter设置超时时间设置为1500毫秒，即为接口调用超时时间超过1500毫秒即判定为调用失败，脚本自动退出；图30为本发明实施例中提供的一种查询峰值调用性能测试结果示意图，如图30所示，Jmeter记录了最大响应时延、记录成功次数、记录失败次数等信息。

B.查询并发调用性能测试：Jmeter所在测试服务器192.168.0.1发起http请求，通过API网关接口192.168.0.2:8090调用查询服务，网关分发后台业务承载，在A采集机192.168.0.3、B采集机192.168.0.4上实现查询服务。通过Jmeter自动化脚本增加并发用户数持续加压，设置Jmeter调用频率不低于50次/秒，超时时间为5000毫秒，直至Jmeter测试脚本出现第一次报错。记录最大并发连接数、最大响应时延，平均时延等记录。

一种实施例中，查询并发调用性能测试的测试用例如表13所示。

表13查询并发调用性能测试的测试用例

一种测试结果示例如下：

测试：3次；其中，最大并发连接数：6700；最大响应时延：1162ms(<＝5000ms)；平均响应时延：24ms。

图31为本发明实施例中提供的一种查询并发调用性能测试界面示意图，如图31所示，通过Jmeter设置单个线程每秒最多发送50次请求；图32为本发明实施例中提供的一种查询并发调用性能测试中设置超时时间的界面示意图，如图32所示，通过Jmeter设置超时时间设置为5000毫秒，即为接口调用超时时间超过5000毫秒即判定为调用失败，脚本自动退出；图33为本发明实施例中提供的一种查询并发调用性能测试中设置并发用户数的界面示意图，如图33所示，可通过Jmeter自动化测试工具编写测试脚本，实现内容：通过API网关调用查询服务，每过30s增加500个并发用户数，直至增加到20000个并发用户数，目的：通过逐步加大并发用户数，直到调用出现首次报错，脚本自动停止执行，记录最大并发用户数。图34为本发明实施例中提供的一种查询并发调用性能测试结果示意图。

④高可靠测试：

A.稳定性测试：Jmeter所在测试服务器192.168.0.1发起http请求，通过API网关接口192.168.0.2:8090调用查询服务，网关分发后台业务承载，在A采集机192.168.0.3、B采集机192.168.0.4上实现查询服务。设置Jmeter调用频次不低于1000/S，连接数：20个次数，执行Jmeter自动化脚本，连续不间断调用24小时。通过zabbix监控系统，分别查看服务性能指标情况，记录Jmeter脚本执行结果。

一种实施例中，持续运行稳定性测试的测试用例如表14所示。

表14持续运行稳定性测试的测试用例

一种测试结果示例如下：调用总次数：1362619269；成功次数：1362619269；失败次数：0；最大时延：8258ms；平均时延：3ms。

图35为本发明实施例中提供的一种稳定性测试的日志记录示意图；图36为本发明实施例中提供的一种稳定性测试的日志记录示意图；图35和图36示出了Jmeter脚本的部分执行日志，使用测试工具通过API网关调用服务，调用频次不低于1000/S，连接数：20个次数；各厂家用最稳定频次调用。图37为本发明实施例中提供的一种通过zabbix监控平台查看服务节点的性能指标的界面示意图。

此处需要说明的是，本发明实施例针对5GC网管系统，提供覆盖全面、指导性强的测试用例，使用这些测试用例对5G核心网微服务架构进行测试，能够筛选出高性能高可用的微服务框架。

本发明实施例还提供了一种计算机设备，用以解决现有微服务框架测试方案，仅支持对微服务框架本身的可用性与基础性进行功能性测试，无法适用于对5G核心网微服务架构的高性能性、高可用性、高可靠性进行测试的技术问题，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述5G核心网微服务架构的测试方法。

本发明实施例还提供了一种计算机可读存储介质，用以解决现有微服务框架测试方案，仅支持对微服务框架本身的可用性与基础性进行功能性测试，无法适用于对5G核心网微服务架构的高性能性、高可用性、高可靠性进行测试的技术问题，该计算机可读存储介质存储有执行上述5G核心网微服务架构的测试方法的计算机程序。

综上所述，本发明实施例提供了一种5G核心网微服务架构的测试系统、方法、计算机设备及计算机可读存储介质，通过Jmeter压力测试工具模拟真实负载，zabbix监控内存消耗和CPU利用率，执行多组测试脚本调用微服务实例中的API接口，测试微服务总线的性能瓶颈、稳定性、可靠性等内容，输出测试结果，根据各个5G核心网微服务架构的测试结果，对各个5G核心网微服务架构进行评估打分，能够分析各个5G核心网微服务架构的有缺点，从而筛选出高性能高可用的微服务框架。本发明实施例提供的测试方案整体着重于各种破坏性场景测试，如指定采集节点故障、关闭实例所在服务器、模拟API网关物理机宕机等操作，全方位测试微服务框架的高可用性和稳定性，通过执行结果日志可分析出系统瓶颈，进而对微服务框架做调优升级。

需要注意的是，本发明实施例提供的测试方案基于5GC网管对微服务框架的多项需求特性，着重于微服务框架运行中的高性能、高可用等能力测试，不仅针对5GC的微服务框架，也可适用于绝大部分微服务框架的自动化测试。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种5G核心网微服务架构的测试系统，其特征在于，包括：微服务平台、测试服务器、监控平台；

其中，所述微服务平台，用于提供采用5G核心网微服务架构的网络服务；

所述测试服务器，与所述微服务平台通信，用于向所述微服务平台发送测试请求，并接收所述微服务平台返回的响应数据；

监控平台，与所述微服务平台和所述测试服务器分别通信，用于监控所述微服务平台的资源使用情况，并返回至所述测试服务器；

其中，所述测试服务器还用于根据所述微服务平台返回的响应数据、所述微服务平台的资源使用情况，确定所述微服务平台的测试结果。

2.如权利要求1所述的测试系统，其特征在于，所述测试服务器上安装有Jmeter测试工具，通过Jmeter测试工具模拟负载向所述微服务平台发送业务请求。

3.如权利要求1所述的测试系统，其特征在于，所述监控平台为Zabbix监控平台。

4.一种5G核心网微服务架构的测试方法，其特征在于，包括：

向微服务平台发送测试请求，其中，所述微服务平台提供采用5G核心网微服务架构的网络服务；

接收所述微服务平台返回的响应数据；

监控所述微服务平台的资源使用情况；

根据所述微服务平台返回的响应数据、所述微服务平台的资源使用情况，确定所述微服务平台的测试结果。

5.如权利要求4所述的测试方法，其特征在于，监控所述微服务平台的资源使用情况，包括：

通过Zabbix监控平台监控所述微服务平台的资源使用情况。

6.如权利要求4所述的测试方法，其特征在于，向所述微服务平台发送测试请求，包括：

基于Jmeter测试工具向所述微服务平台发送测试请求。

7.如权利要求4至6任一项所述的测试方法，其特征在于，所述微服务平台的资源使用情况包括如下任意之一：流量、CPU利用率和内存占用率。

8.如权利要求4至6任一项所述的测试方法，其特征在于，所述测试请求包括如下任意之一：查询请求、采集请求、登录请求、下发请求。

9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求4至8任一项所述5G核心网微服务架构的测试方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有执行权利要求4至8任一项所述5G核心网微服务架构的测试方法的计算机程序。