CN113645102B - 路由收敛时间的确定方法及装置 - Google Patents

Abstract

本申请提供了一种路由收敛时间的确定方法及装置，涉及计算机网络技术领域；本申请实施例可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景；该方法包括：获取目标应用程序对应的服务集群，服务集群包含至少两个服务，每个服务对应至少一个服务实例；目标应用程序存在运行的服务实例时，记录初始时间并采集与各服务实例的路由变化信息；路由变化信息包括由服务实例的状态切换所导致的服务集群对应的路由数量的变化信息；基于路由变化信息确定服务集群对应的路由收敛条件得到满足时记录截止时间；基于初始时间及截止时间确定与服务集群对应的路由收敛时间。通过本申请，能够提高确定服务集群对应的路由收敛时间的准确性。

Description

路由收敛时间的确定方法及装置

技术领域

本申请涉及计算机网络技术，尤其涉及一种路由收敛时间的确定方法及装置。

背景技术

微服务架构是一项在云中部署应用和服务的新技术。旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。具体是指把一个大型的单个应用程序和服务拆分为多个甚至数十个的支持微服务。随着互联网领域的不断发展，微服务化应用越来越广泛，分布式微服务结构对应的服务集群的规模越来越复杂。针对大规模服务集群对应的路由收敛时间测试需求，越来越多。

相关技术中，确定服务集群的路由收敛时间，需要借助外部工具进行频繁的转存，存在大量集中写磁盘瞬间操作。对于服务集群起服或者停服这种服务资源消耗较大的操作容易造成较大的性能干扰，最终测试结果与真实结果之间存在较大的误差。

发明内容

本申请实施例提供一种路由收敛时间的确定方法及装置，能够提高确定服务集群路由收敛时间的准确性。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种路由收敛时间的确定方法，包括：

获取目标应用程序对应的服务集群，所述服务集群包含至少两个服务，每个所述服务对应至少一个服务实例；

在所述目标应用程序存在运行的服务实例时，记录初始时间并采集与各所述服务实例对应的路由变化信息；

其中，所述路由变化信息包括：由所述服务实例的状态切换所导致的所述服务集群对应的路由数量的变化信息；

基于所述路由变化信息，确定所述服务集群对应的路由收敛条件得到满足时，记录截止时间；

基于所述初始时间及所述截止时间，确定与所述服务集群对应的路由收敛时间。

本申请实施例提供一种路由收敛时间的确定装置，包括：

获取模块，用于获取目标应用程序对应的服务集群，所述服务集群包含至少两个服务，每个所述服务对应至少一个服务实例；

采集模块，用于在所述目标应用程序存在运行的服务实例时，记录初始时间并采集与各所述服务实例对应的路由变化信息，其中，所述路由变化信息包括：由所述服务实例的状态切换所导致的所述服务集群对应的路由数量的变化信息；

分析模块，用于基于所述路由变化信息，确定所述服务集群对应的路由收敛条件得到满足时，记录截止时间；

确定模块，用于基于所述初始时间及所述截止时间，确定与所述服务集群对应的路由收敛时间。

本申请实施例提供一种电子设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的路由收敛时间的确定方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的路由收敛时间的确定方法。

本申请实施例提供一种计算机程序产品，包括计算机程序或指令，所述计算机程序或指令被处理器执行时实现本申请实施例提供的路由收敛时间的确定方法。

上述方案中，所述获取模块，还用于监听所述服务集群中各所述服务实例的状态切换事件；

当监听到指示存在状态切换服务实例的状态切换事件时，更新所述服务集群对应的路由变化信息。

上述方案中，所述获取模块，还用于当所述状态切换事件所对应服务实例的状态由未运行状态切换为启动状态时，在所述路由变化信息中增加相应服务实例的路由信息；

当所述状态切换事件所对应服务实例的状态由运行状态切换为停止状态时，在所述路由变化信息中删除相应服务实例的路由信息。

上述方案中，所述采集模块，还用于获取信息采集周期，所述信息采集周期用于表征相邻两次对所述路由变化信息进行采集处理的时间间隔；

基于所述信息采集周期，周期性对各所述服务实例对应的路由变化信息进行采集，得到各所述服务实例对应的路由变化信息。

上述方案中，所述采集模块，还用于接收各所述服务实例周期性上报的路由变化信息，所述路由变化信息由所述服务实例调用自身的信息上报子程序所上报；

将所述路由变化信息存储到数据存储区域。

上述方案中，所述获取模块，还用于构建与各所述服务的实例相对应的实例副本，所述实例副本具有信息上报功能；

将所述实例副本作为与所述服务相对应的服务实例。

上述方案中，所述路由收敛条件包括：所述服务集群对应的路由数量达到目标路由数量，所述分析模块，还用于获取所述服务集群对应的目标路由数量；

解析所述路由变化信息，得到所述服务集群当前的路由数量；

确定当前的所述路由数量达到所述目标路由数量时的时间点，将所述时间点作为截止时间进行记录。

上述方案中，所述确定模块，还用于确定所述截止时间与所述初始时间之间的时间差值，将所述时间差值作为所述服务集群对应的路由收敛时间。

上述方案中，所述确定模块，还用于生成并输出所述目标应用程序的路由关系报告；

其中，所述路由关系报告用于指示，所述服务集群对应的路由数量与所述路由收敛时间之间的关系。

本申请实施例具有以下有益效果：

本申请实施例通过对采集得到的目标应用程序所对应的服务集群的路由变化信息进行统计分析，能够确定服务集群中路由变化信息的初始时间以及服务集群满足路由收敛条件时所确定的截止时间，然后根据初始时间和截止时间确定服务集群对应的路由收敛时间。如此，能够提高确定服务集群对应的路由收敛时间的准确性。

附图说明

图1是本申请实施例提供的路由收敛时间的确定系统的架构示意图；

图2是本申请实施例提供的电子设备的结构示意图；

图3是本申请实施例提供的路由收敛时间的确定方法的流程示意图；

图4是本申请实施例提供的确定路由收敛时间的测试系统示意图；

图5是本申请实施例提供的路由变化信息采集流程示意图；

图6是本申请实施例提供的路由变化信息的输出形式示意图；

图7是本申请实施例提供的信息上报代码示意图；

图8是本申请实施例提供的路由收敛时间确定的流程示意图；

图9是本申请实施例提供的路由收敛时间的确定方法的流程示意图；

图10是本申请实施例提供的测试参数设置的可视化示意图；

图11是本申请实施例提供的测试程序的功能结构示意图；

图12是本申请实施例提供的路由变化统计数据输出流程图；

图13是本申请实施例提供的动态测算服务网格中路由收敛时间的流程图；

图14A是本申请实施例提供的服务集群起服路由开始变化时间点示意图；

图14B是本申请实施例提供的服务集群起服路由一致时间点示意图；

图14C是本申请实施例提供的服务集群起服路由一致时间点另一示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

如果申请文件中出现“第一/第二”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1）服务网格（Service Mesh）：是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。

2）路由收敛：指网络的拓扑结构发生变化后，路由表重新建立到发送再到学习直至稳定，并通告网络中所有相关路由器都得知该变化的过程，也就是网络拓扑变化引起的通过重新计算路由而发现替代路由的行为。通过路由收敛可以使路由域中所有路由器对当前的网络结构和路由转发达成一致的状态。

3）收敛时间：是指路由器发现网络的拓扑结构发生变化后，路由信息同步的过程；而整个同步过程所共花费的时间为收敛时间，或者说是某个路由信息变化后反映到所有路由器中所需要的时间。

4）转储（dump）：在计算机领域，dump一般译作转储，有动词和名词两种场景，一般指将数据导出、转存成文件或静态形式。比如可以理解成：把内存某一时刻的内容，dump（转存，导出，保存）成文件。因为程序在计算机中运行时，在内存、中央处理器等设备上的数据都是动态的（或者说是易失的），也就是说数据使用完或者发生异常就会丢掉。如果想得到某些时刻的数据（有可能是调试程序缺陷或者收集某些信息），就要把数据转储（dump）为静态（如文件）的形式。否则，这些数据将永远无法获得。

5）微服务：是指在功能不变的情况下，把一个大型的单个应用程序和服务拆分为多个可管理的服务。每个服务根据自己的需要选择技术栈，互不影响，方便开发、维护，好处是有效的拆分应用，实现敏捷开发和部署。

相关技术中，通过调用系统提供的工具转存服务集群中服务实例的路由信息，确定收敛时间的方式。在服务集群各节点同步之前，需要频繁调用转存工具输出全量路由信息，这种大量集中写磁盘瞬间操作，对于服务集群起服或者停服操作造成较大的性能干扰；外部转存工具的操作不是实时的存在时延，导致最终测试结果存在很大的误差。

基于此，本申请实施例提供一种路由收敛时间的确定方法、装置、设备和计算机可读存储介质，能够提高确定服务集群对应的路由收敛时间的准确性。

下面说明本申请实施例提供的路由收敛时间的确定设备的示例性应用，本申请实施例提供的路由收敛时间的确定设备可以实施为笔记本电脑，平板电脑，台式计算机，机顶盒，移动设备（例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备）、智能语音交互设备、智能家电、车载终端等各种类型的用户终端，也可以实施为服务器。下面，将说明设备实施为服务器时的示例性应用。

参见图1，图1是本申请实施例提供的路由收敛时间的确定系统的架构示意图，为实现支撑一个路由收敛时间的确定应用，在路由收敛时间的确定系统100中，终端（示例性示出了终端400-1和终端400-2）通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。

在一些实施例中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络（CDN，ContentDelivery Network）、以及大数据和人工智能平台等基础云计算服务的云服务器。在另一些实施例中，本申请实施例提供的路由收敛时间的确定方法或装置中，所涉及的目标应用程序对应的服务集群可以包含至少两个服务，每个服务可以对应至少一个服务实例，每个服务在服务集群对应的各服务器上可以包含多个服务实例（如针对同一个服务的多个不同版本的服务实例），各服务实例可独立的运行在不同的服务器上，服务集群所涉及的多个服务器可以组成区块链，而各服务器为区块链上的节点。

在一些实施例中，终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、智能语音交互设备、智能家电、车载终端等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本发明实施例中不做限制。

终端用于，用于发送针对目标应用程序对应的服务集群的路由收敛时间的测试请求至服务器，以请求服务器返回目标应用程序对应的服务集群的路由收敛时间。

服务器用于响应于针对目标应用程序对应服务集群的路由收敛时间的测试请求，获取目标应用程序对应的服务集群，服务集群包含至少两个服务，每个服务对应至少一个服务实例；在目标应用程序存在运行的服务实例时，记录初始时间并采集与各服务实例对应的路由变化信息；其中，路由变化信息包括：由服务实例的状态切换所导致的服务集群对应的路由数量的变化信息；基于路由变化信息，确定服务集群对应的路由收敛条件得到满足时，记录截止时间；基于初始时间及所述截止时间，确定与服务集群对应的路由收敛时间。

在一些实施例中，终端部署有用于确定路由收敛时间的测试客户端（示例性示出了测试客户端410-1和测试客户端410-2），用户基于测试客户端对目标应用程序对应服务集群的路由收敛时间进行测试，基于对包含目标应用程序的程序唯一标识以及目标路由数量的选择操作，触发针对服务集群的路由收敛时间测试指令，测试客户端响应于测试指令，发送针对目标应用程序对应服务集群的路由收敛时间的测试请求至服务器；服务器从测试请求中解析出包含目标应用程序的程序唯一标识以及目标路由数量后，获取目标应用程序对应的服务集群，服务集群包含至少两个服务，每个服务对应至少一个服务实例；在目标应用程序存在运行的服务实例时，记录初始时间并采集与各服务实例对应的路由变化信息；其中，路由变化信息包括：由服务实例的状态切换所导致的服务集群对应的路由数量的变化信息；基于路由变化信息，确定服务集群对应的路由收敛条件得到满足时，记录截止时间；基于初始时间及所述截止时间，确定与服务集群对应的路由收敛时间，并将路由收敛时间返回至测试客户端，测试客户端呈现针对目标应用程序对应服务集群的路由收敛时间。

接下来对本申请实施例提供的用于实施上述路由收敛时间的确定方法的电子设备进行说明，参见图2，图2是本申请实施例提供的电子设备的结构示意图，在实际应用中，电子设备500可以实施为图1中的服务器，以电子设备为图1所示的服务器200为例，对实施本申请实施例的路由收敛时间的确定方法的电子设备进行说明。图2所示的电子设备500包括：至少一个处理器510、存储器550、至少一个网络接口520和用户接口530。电子设备500中的各个组件通过总线系统540耦合在一起。可理解，总线系统540用于实现这些组件之间的连接通信。总线系统540除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统540。

处理器510可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器（DSP，Digital Signal Processor），或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口530包括使得能够呈现媒体内容的一个或多个输出装置531，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口530还包括一个或多个输入装置532，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器550可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器550可选地包括在物理位置上远离处理器 510的一个或多个存储设备。

存储器550包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器（ROM，Read Only Memory），易失性存储器可以是随机存取存储器（RAM，Random Access Memory）。本申请实施例描述的存储器550旨在包括任意适合类型的存储器。

在一些实施例中，存储器550能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统551，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块552，用于经由一个或多个（有线或无线）网络接口520到达其他计算设备，示例性的网络接口520包括：蓝牙、无线相容性认证（WiFi）、和通用串行总线（USB，Universal Serial Bus）等；

呈现模块553，用于经由一个或多个与用户接口530相关联的输出装置531（例如，显示屏、扬声器等）使得能够呈现信息（例如，用于操作外围设备和显示内容和信息的用户接口）；

输入处理模块554，用于对一个或多个来自一个或多个输入装置532之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的路由收敛时间的确定装置可以采用软件方式实现，图2示出了存储在存储器550中的路由收敛时间的确定装置555，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块5551、采集模块5552、分析模块5553以及确定模块5554，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的路由收敛时间的确定装置可以采用硬件方式实现，作为示例，本申请实施例提供的路由收敛时间的确定装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的路由收敛时间的确定方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路（ASIC，Application Specific Integrated Circuit）、DSP、可编程逻辑器件（PLD，ProgrammableLogic Device）、复杂可编程逻辑器件（CPLD，Complex Programmable Logic Device）、现场可编程门阵列（FPGA，Field-Programmable Gate Array）或其他电子元件。

接下来说明本申请实施例提供的路由收敛时间的确定方法。在一些实施例中，本申请实施例提供的路由收敛时间的确定可以由终端或服务器单独实施，或者由终端及服务器协同实施。以服务器实施为例，参见图3，图3是本申请实施例提供的路由收敛时间的确定方法的流程示意图，将结合图3示出的步骤进行说明。

在步骤101中，服务器获取目标应用程序对应的服务集群，服务集群包含至少两个服务，每个服务对应至少一个服务实例。

在一些实施例中，服务器上部署有测试程序（或称测试系统），测试程序用于确定目标应用程序对应的服务集群中，各服务实例能够发现的处于运行状态的服务实例的数量达到目标路由数量的所需的时间。

需要说明的是，为了便于测试系统对服务集群中路由变化信息进行统计分析，服务集群中的各服务实例还可以包括用于记录集群路由变化信息的信息记录表，该信息记录表可以以数据表的形式存储在数据库中的，也可以是以文件格式存储在各服务实例对应的本地存储区域。另外，各服务实例还以包括用于进行信息上报的信息上报子服务（子程序），如此，测试系统可以接收各服务实例通过调用自身的信息上报子服务上传的自身信息记录表中的路由变化信息。同时，由于目标应用程序对应的服务集群所处的真实环境中，各服务对应的服务实例并不具有信息上报功能。基于此，在一些实施例中，在测试目标应用程序对应服务集群的路由收敛时间的应用场景中，为了不影响目标应用程序的正常执行，同时各服务实例又能实现信息上报功能，通常会通过构建实例副本的方式确定待测试服务集群中各服务的服务实例，具体实现方式为：构建与目标应用程序对应的服务集群中各服务的实例相对应的实例副本，将构建的实例副本作为与服务相对应的服务实例，其中，实例副本具有信息上报功能。可以理解的是，测试程序获取的各服务所对应的服务实例实际上是各服务的实例的实例副本，且实例副本具有信息上报功能，能够实现路由变化信息的上报功能。

在实际实施时，参见图4，图4是本申请实施例提供的确定路由收敛时间的测试系统示意图，图中测试系统接收测试请求，启动测试程序，测试程序根据测试请求中的目标应用程序标识，构建目标应用程序对应的服务集群副本（编号1），服务集群-副本中包含目标应用程序的全部服务实例，但是基于真实环境的服务实例进行升级，以图中服务实例1（编号1-1）为例，升级的服务实例1中还包括应用于记录集群路由变化信息的信息记录表，以及用于上报路由变化信息的信息上报子服务。测试程序通过实时监控测试环境中的目标应用程序的服务集群-副本中的各服务实例，并接收各服务实例通过自身的信息上报子服务上报的路由变化信息，通过对上报的路由变化信息进行统计分析，确定测试环境中的路由收敛时间与真实环境下路由收敛时间的一致性。预测路由收敛时间与真实路由收敛时间误差越小，说明测试程序的预测结果越精确，预测效果越好。

示例性地，以测试游戏应用程序对应的服务集群的收敛时间为例，存在一个游戏应用程序A，其采用的服务集群框架结构是服务网格（Service Mesh）形式，测试程序实现一个模拟游戏应用程序A各服务的功能模块，通过模拟功能模块构建各服务对应的服务副本，各服务实例副本可记作recv_server。

在一些实施例中，服务器响应于针对目标应用程序对应的服务集群的路由收敛时间的测试请求，启动测试程序，并初始化测试程序中的各参数信息，参数信息至少包括应用程序对应的程序标识、信息采集周期以及目标路由数量。其中，目标路由数量是用于指示测试应用程序对应的服务集群的路由收敛时间时，需要启动的服务实例的数量（或称路由的数量）。

示例性地，在游戏应用程序A对应的服务集群中，启动2000个服务实例，确定各服务实例都能相互发现时的收敛时间。此时，部署在服务器上的测试程序，响应于针对游戏应用程序A对应的服务集群的路由收敛时间的测试请求，测试参数至少包括游戏应用程序A的程序标识、路由收敛时需要到的目标路由数量2000。

在步骤102中，在目标应用程序存在运行的服务实例时，记录初始时间并采集与各服务实例对应的路由变化信息，其中，路由变化信息包括：由服务实例的状态切换所导致的服务集群对应的路由数量的变化信息。

在一些实施例中，部署在服务器上的测试程序启动后，目标应用程序对应的服务集群中各服务接收到启动命令，对应的服务实例开始陆续启动，服务实例的启动方式可以单个顺序启动，也可以是批量启动预设数量的服务实例（如单次批量启动100个服务实例）。当服务集群中的第一个服务实例启动时，记录第一个服务实例的启动时间，作为整个服务集群中路由信息发生变化的初始时间。需要说明的是，路由变化信息包括由服务实例的状态切换所导致的服务集群对应的路由数量的变化信息。其中，服务实例的状态切换包括服务实例的状态由未运行状态切换为启动状态，或者服务实例的状态由运行状态切换为停止状态。

在一些实施例中，参见图5，图5是本申请实施例提供的路由变化信息采集流程示意图，结合图5示出的步骤详细说明路由变化信息的采集过程。

步骤201，启动服务器上部署的测试程序，并初始化测试参数信息以及目标应用程序对应的服务集群副本。

在实际实施时，测试程序启动时，初始化一个全局变量，变量可以是数组、集合或者结构体，记作instance_set，用于记录服务集群中路由数量的变化信息。

步骤202，测试程序在服务集群中注册监听器服务，并实时异步监听服务集群副本中的状态切换事件，得到事件回调消息。

在实际实施时，测试程序启动成功后，会先在服务集群对应的服务注册中心注册监听器服务，并通过监听器以监听服务实例的状态切换事件。当监听到服务集群中存在服务实例的服务上线（online）事件时，会接收到由其他服务实例发送的服务上线通知消息，消息的形式可以是文本格式，如“我是服务实例a，在b时间上线了”，或者当监听到服务集群中存在服务实例对应的服务下线（offline）事件时，会接收到由其他服务实例发送的服务下线通知消息，如“我是服务实例c，在d时间下线了”。

步骤203，创建服务集群中各服务对应的服务实例，并在服务集群对应的服务注册中心注册各服务实例。

在实际实施时，会在服务集群中注册各服务实例，以使服务集群内的服务实例能够相互发现。服务实例注册成功后（此时，服务实例处于就绪状态）。

步骤204，各服务实例注册成功后，按照预设的服务集群启动方式，启动各服务实例。

步骤205，服务集群中任意启动的服务实例，获取服务集群对应的全量路由信息，基于全量路由信息更新全局变量。

在实际实施时，当服务实例注册成功后，启动服务实例。在服务实例启动成功后，会主动获取服务集群的当前全量路由信息，并将全量路由信息记录在服务实例对应的信息记录表中。如此，服务实例可以通过全量路由信息，发现服务集群中当前所有处于启动状态服务实例。

步骤206，根据状态切换事件返回的回调信息，以及全量路由信息，更新

服务实例对应的路由信息。

在一些实施例中，各服务实例会实时监听服务集群中的其他服务实例的状态切换事件。当监听到服务集群中存在服务实例对应的状态切换事件时，会更新服务集群对应的路由变化信息。可以通过以下方式实现对状态切换事件的监听：监听服务集群中各服务实例的状态切换事件；当监听到指示存在状态切换服务实例的状态切换事件时，更新服务集群对应的路由变化信息。

在实际实施时，启动服务集群中的任意服务实例，都会触发服务集群对应的状态切换事件，状态切换事件触发之后，会向服务集群中的其他服务实例广播通知消息。当服务实例是从未运行状态切换至启动状态时，会向服务集群内的其他服务实例广播服务上线通知消息。常见的服务上线通知消息的形式可以为{recv_server_id对应的服务实例在online_time时间上线了}，其中，recv_server_id是对应服务实例的实例标识，实例标识是用于唯一标识服务实例的，online_time是对应服务实例的上线时间对应的时间戳。例如“5419103625794060571对应的服务实例，在1618824337016时间上线了”。其他服务实例基于服务集群内广播的上线通知消息，能够发现服务实例已上线。

同样的，停止服务集群中的任意服务实例，都会触发服务集群对应的状态切换事件。状态切换事件触发之后，会向服务集群中的其他服务实例广播通知消息。当服务实例是从运行状态切换至停止状态时，会向服务集群内的其他服务实例广播服务下线（离线）通知消息。常见的服务下线通知消息的形式可以为{recv_server_id对应的服务实例在offline_time时间上线了}，其中，recv_server_id是对应服务实例的实例标识，实例标识是用于唯一标识服务实例的，offline_time是对应服务实例的服务下线时间对应的时间戳。例如“5419103625794060571对应的服务实例，在1418524315178时间下线了”。其他服务实例基于服务集群内广播的服务下线通知消息，能够发现服务实例已下线。

在一些实施例中，当监听到指示存在状态切换服务实例的状态切换事件时，可以通过以下方式更新服务集群对应的路由变化信息：当状态切换事件所对应服务实例的状态由未运行状态切换为启动状态时，在路由变化信息中增加相应服务实例的路由信息；当状态切换事件所对应服务实例的状态由运行状态切换为停止状态时，在路由变化信息中删除相应服务实例的路由信息。

步骤207，根据信息采集周期，周期性的输出服务实例对应的路由变化信息。

在一些实例中，可以通过以下方式实现路由变化信息的采集：获取信息采集周期，信息采集周期用于表征相邻两次对所述路由变化信息进行采集处理的时间间隔；基于信息采集周期，周期性对各服务实例对应的路由变化信息进行采集，得到各服务实例对应的路由变化信息。

在实际实施时，各服务实例每隔一个信息采集周期输出自身的信息记录表中的路由变化信息，各服务实例输出的路由变化信息可以以文件的形式保存，也可以直接通过各服务实例自身的信息上报子服务通过上报端口，将路由变化信息上报至测试程序预先设置的信息存储区域。

示例性的，参见图6，图6是本申请实施例提供的路由变化信息的输出形式示意图。图中属性local_svc表示输出的路由变化信息所归属的服务实例的名称，属性local_ud表示输出的路由变化信息所归属的服务实例的唯一标识，在实际应用中，可以使用local_svc和local_ud共同表示一个服务实例。属性remote_svc表示与local_svc指代的服务实例具有交互关系的远端服务实例的名称，属性remote_ud表示remote_svc指代的服务实例的唯一标识。由于各服务实例自身具有路由变化信息记录表，所以在本申请实施例中local_svc与remote_svc的值可以相同，local_ud与remote_ud的值可以相同。cmd表示服务实例的状态切换，cmd=“online”表示local_svc对应的服务实例上线了，属性trigger表示触发的事件类型，trigger=“notify”表示触发通知事件（如服务上线通知、服务下线通知），trigger=“fetch_all_route”表示触发获取服务集群对应的全量路由信息事件。图中编号R1行，表示local_svc对应的服务实例在1618824337016时间戳对应的时间创建；编号R2行，表示服务实例上线的时间点；编号R3行表示local_svc服务实现发现的服务集群中服务实例的数量为1，也就是整个服务集群中存在运行的服务实例的初始时间；编号R4行表示服务实例启动完成；编号R5行表示服务实例启动是否成功的回调信息，bendmark_startup_code=0时表示服务实例启动成功；编号R6行表示服务实例启动成功后，触发获取服务集群中全量路由信息的事件；编号R7行表示拉取服务集群中全量路由信息后，R1行启动的服务实例能够发现的服务集群中的所有处于运行状态的服务实例的个数（可就是服务集群中的路由数量）。编号R8行表示，服务集群广播其他服务实例的上线通知，R1行启动的服务实例接收到该通知信息，更新自身的路由记录表，此时R1行启动的服务实例能够发现的路由数量由R7行中的996，变更为R9行的997，后续各行表示含义与编号R1至R9类似。

通过上述步骤201至步骤207，部署在服务器上的测试程序，能够周期性的采集得到目标应用程序对应的服务集群的路由变化信息。示例性地，以服务集群中的单个服务实例的状态切换为例，待启动的单个服务实例记作recv_server_N，测试程序启动后，监听各服务实例的状态切换事件。在服务集群中注册服务实例recv_server_N，服务实例注册成功后，启动服务实例recv_server_N，服务实例启动成功后，触发服务集群对应的状态切换事件，状态切换事件触发之后，会向服务集群中的其他服务实例，广播服务实例recv_server_N对应的服务上线通知消息，通知消息形式如“23419103625794674对应的服务实例，在1458824337016时间上线了”。其他服务实例基于服务集群内广播的服务上线通知消息，能够发现服务实例recv_server_N已上线。然后，服务实例recv_server_N自动获取服务集群中的全量路由信息，并将全量路由信息记录在recv_server_N对应的信息记录表中，如此，服务实例recv_server_N可以发现服务集群中所有处于启动状态服务实例。在服务实例recv_server_N运行的过程中，监听到服务集群广播的服务上线或服务下线通知消息后，服务实例recv_server_N更新自身的路由信息记录表。并每隔一个信息采集周期（如5s）保存一次路由变化信息。

在步骤103中，基于路由变化信息，确定服务集群对应的路由收敛条件得到满足时，记录截止时间。

在一些实施例中，可以将采集得到的各服务实例对应的路由变化信息通过信息上报的方式，上报至测试程序对应的数据存储区域（后续称为数据中心），需要说明的是，数据存储区域可以是本地文件，也可以是数据库，另外，数据存储区域可以和测试程序共享一台服务器，也可以是其他服务器。测试程序对应的数据存储区域获取服务集群的路由变化信息可以通过以下方式：测试程序中的数据存储区域周期性的接收各服务实例上报的路由变化信息，路由变化信息由服务实例调用自身的信息上报子程序所上报；并将路由变化信息存储到数据存储区域。

在实际实施时，可以采用超文本传输协议（HTTP，Hyper Text TransferProtocol）或超文本传输安全协议（HTTPS，Hyper Text Transfer Protocol overSecureSocket Layer）的方式，周期性的将路由变化信息，通过数据中心监听的信息上报端口，传输至数据中心。参见图4，各服务实例通过自身的信息上报子程序，周期性的将自身的路由变化信息通过上报端口（编号2）上报至信息存储区域（编号3）进行保存。这里，信息上报子服务是根据预设的信息上报周期，定期上报，如信息上报周期设置为5秒，信息上报子服务每隔5秒将服务实例自身信息记录表中的路由信息通过上报端口，上报至信息存储区域（即测试程序的数据中心每隔5秒接收一次服务集群对应的路由变化信息）。对于各服务实例进行信息上报的具体方式可以是：获取信息上报周期，信息上报周期用于表征相邻两次对路由变化信息进行信息上报处理的时间间隔；获取并启动自身对应的信息上报子程序；基于信息上报周期，通过信息上报子程序，周期性的将路由变化信息上报至数据存储区域。

示例性的，参见图7，图7是本申请实施例提供的信息上报代码示意图，图中展示的是一段采用计算机编程语言（如Go语言）实现的信息上报程序代码段。在每个服务实例启动的时候，都会启动图中的代码实现自身路由变化信息的上报，信息程序的输入是各服务实例经过上述步骤201至207得到的路由变化信息统计文件，每次读取一个统计周期的数据，然后发到数据中心监听的HTTP端口，进行数据上报。图中编号C1定义了一个用于信息少报的结构体类型的变量BenchmarkHandler，包括reader类型的指针变量*bufio_Reader，以及用于表示字节数组的自定义的数据类型；编号C2定义了信息上报函数ServeHTTP，用于按行读取统计文件中的路由变化信息，并输出日志文件；编号C3定义了信息上报程序中的全局变量，字符串（string）类型的MetricFile表示目标统计文件，整数（int）类型的Port表示数据中心监听的HTTP端口号（上报端口）；编号C4是用于初始化全局变量的初始化函数（init）；编号C5表示信息上报子程序的程序入口（main），测试程序调用信息上报程序入口函数实现信息上报功能。

在一些实施例中，参见图8，图8是本申请实施例提供的路由收敛时间确定的流程示意图，基于图3，图3示出的步骤103可以通过步骤1031至步骤1033实现，将结合各步骤进行说明。

步骤1031，服务器获取服务集群对应的目标路由数量。

在一些实施例中，服务器上部署的测试程序响应于路由收敛时间的测试请求，解析测试请求中的测试参数，测试参数可以包括目标路由数量。

步骤1032，解析路由变化信息，得到服务集群当前的路由数量。

在一些实施例中，测试程序解析信息存储区域中各服务实例上报的服务集群对应的路由变化信息，得到服务集群当前的路由数量。判断当前路由数量与目标路由数量是否相等，当当前路由数量不等于目标路由数量时，测试程序需要继续周期性的解析信息存储区域的路由变化信息，直至服务集群当前的路由数量与目标路由数量一致。

步骤1033，确定当前的路由数量达到目标路由数量时的时间点，将时间点作为截止时间进行记录。

在实际实施时，当服务集群当前的路由数量与目标路由数量一致时，记录相应的时间点，将该时间点作为截止时间，即路由收敛的截止时间。在截止时间点，服务集群中的各服务实例均能够发现目标路由数量个服务实例。

示例性地，假设目标路由数量是n（n为大于0的整数），确定当前的路由数量达到目标路由数量n的时间点是t，即在时间t，服务集群中的各服务实例均能够发现n个处于启动状态的服务实例。

在步骤104中，基于初始时间及截止时间，确定与服务集群对应的路由收敛时间。

在一些实施例中，根据确定的服务集群中路由开始变化的时间点以及服务集群中路由数量达到目标路由数量的截止时间点，确定服务集群对应的路由收敛时间。可以通过以下方式实现计算路由收敛时间的方式：确定截止时间与初始时间之间的时间差值，将时间差值作为服务集群对应的路由收敛时间。

在实际实施时，记录服务集群中路由开始变化的时间点为T_sart，服务集群中路由数量达到目标路由数量的截止时间点为T_end，将T_end与T_sart的时间差值作为服务集群对应的路由收敛时间，可记作T_end-T_sart。

在一些实施例中，在步骤104之后，还可以执行生成并输出目标应用程序的路由关系报告；其中，路由关系报告用于指示，服务集群对应的路由数量与路由收敛时间之间的关系。

在实际实施时，测试程序可以提供一个应用程序编程接口（API，ApplicationProgramming Interface），供外部应用调用该API，得到相应的路由关系报告。另外，测试程序还可以提供针对路由关系报告的可视化查看界面，提升用户测试体验。

本申请实施例通过在目标应用程序对应的服务集群中各服务实例运行中，主动在各服务实例的路由信息发生变化时，实时输出路由变化信息，然后通过信息上报子程序，周期性的将路由变化信息上报到数据中心，并对数据中心的路由变化信息进行统计分析。如此，路由变化信息能够主动上报，具备实时性，减少测试误差；不需要调用外部转存工具集中转存数据，对目标应用程序对应的服务集群中路由收敛过程中没有性能干扰；且数据中心汇聚了服务集群中每个服务实例上报的路由变化信息，便于持续观察整个服务集群路由变化情况并动态计算出服务集群的路由收敛时间，另外，针对在不同规模的服务集群在不同业务场景的路由收敛时间的测试准确性，有利于对目标应用程序的推广和使用。

接下来继续对本申请实施例提供的路由收敛时间的确定方法进行介绍，参见图9，图9是本申请实施例提供的路由收敛时间的确定方法的流程示意图，由客户端、服务器协同实施。结合图9示出的步骤进行说明。

步骤301，终端发送针对目标应用程序对应的服务集群的路由收敛时间的测试请求至服务器。

在一些实施例中，终端部署有用于确定路由收敛时间的测试客户端，服务器上部署有测试程序，测试程序提供API接口供终端访问。用户可以通过测试客户端提供的可视化操作界面，触发确定服务集群的路由收敛时间的测试指令，测试客户端响应于测试指令，获取用户设置的测试参数，向服务器上部署的测试程序发送包含测试参数的测试请求。

在实际实施时，参见图10，图10是本申请实施例提供的测试参数设置的可视化示意图，终端上部署的测试客户端提供测试参数设置界面，用户可以在设置界面中设置如下测试参数：目标应用程序（编号1）用于指示需要确定路由收敛时间的目标应用程序，进而确定目标应用程序对应的服务集群；目标路由数量（编号2）用于指示确定路由收敛时间时，服务集群中各服务实例能够发现的路由数量；信息采集周期（编号3）用于指示路由变化信息采集时间间隔；信息上报端口（编号4）用于指示测试程序所监听的信息上报端口。参数信息设置完整后，触发确定路由收敛时间的测试指令。

示例性地，用户通过测试客户端设置测试参数P为{目标应用程序：“游戏应用A”，目标路由数量：3000，信息采集周期：5s，信息上报端口：“1011”}，通过点击“确定”按钮操作，向服务器发送携带测试参数P的测试请求至服务器。

步骤302，服务器解析测试请求，得到测试参数，并根据测试参数，获取目标应用程序对应的服务集群。

在实际实施时，服务器中部署的测试程序解析测试请求，得到相应的测试参数，根据测试参数中目标应用程序的名称以及唯一标识，确定目标应用程序对应的服务集群。

示例性地，部署在服务器上的测试程序，解析测试参数P，测试游戏应用B对应的服务集群，在目标路由数量为3000时的路由收敛时间，测试程序每隔5s采集一次服务集群的路由变化信息，并通过信息上报端口1011接收各服务实例上报的路由变化信息。

步骤303，服务器在目标应用程序对应的服务集群中存在运行的服务实例时，记录初始时间。

在实际实施时，当测试程序监听到服务集群中存在运行的服务实例时，表明该时间点服务集群中的路由信息开始变化，因此，记录路由信息开始变化的时间点作为初始时间。

步骤304，服务器根据信息采集周期，周期性的接收各服务实例调用自身的信息上报子程序所上报的路由变化信息。

在实际实施时，服务器从测试请求携带的测试参数中获取信息采集周期，然后根据信息采集周期，定时接收各服务实例调用自身的信息上报子程序所上报的路由变化信息。

步骤305，服务器获取服务集群对应的目标路由数量。

在实际实施时，服务器从测试请求携带的测试参数中获取目标路由数量，当服务集群路由收敛时，各服务实例能够发现的目标路由数量的服务实例。

步骤306，服务器解析路由变化信息，得到服务集群当前的路由数量。

在实际实施时，周期性的解析服务实例上报的路由变化信息，确定服务集群中的路由数量。

步骤307，服务器确定当前的路由数量达到目标路由数量时的时间点，将时间点作为截止时间进行记录。

在实际实施时，记录服务集群中的路由数量达到目标路由数量时的时间点，作为计算路由收敛时间的截止时间。

步骤308，服务器确定截止时间与初始时间之间的时间差值，将时间差值作为服务集群对应的路由收敛时间。

在实际实施时，根据步骤303确定的初始时间，以及步骤307确定的截止时间之间的时间差值，确定服务集群对应的路由收敛时间。

步骤309，服务器生成并输出目标应用程序的路由关系报告。

在实际实施时，部署在服务器上的测试程序，可以直接将生成的路由关系包括以二进制流的形式保存到数据库中，也可以是以文件的形式保存文件存储区域，并提供路由关系报告下载API接口，以便于其他应用通过下载API接口获取相应的路由关系报告。

步骤310，终端显示路由关系报告。

在实际实施时，终端上部署有测试客户端，测试客户端可以通过部署在服务器上的测试程序提供的用于路由关系报告下载的API接口，从服务器下下载路由关系报告，并进行可视化展示，通过可视化展示界面，可以直接分析得出服务集群对应的路由数量与路由收敛时间之间的关系。

本申请实施例通过在目标应用程序对应的服务集群中各服务实例运行中，主动在各服务实例的路由信息发生变化时，实时输出路由变化信息，然后通过信息上报子程序，周期性的将路由变化信息上报到数据中心，并对数据中心的路由变化信息进行统计分析。如此，路由变化信息能够主动上报，具备实时性，减少测试误差；不需要调用外部转存工具集中转存数据，对目标应用程序对应的服务集群中路由收敛过程中没有性能干扰；且数据中心汇聚了服务集群中每个服务实例上报的路由变化信息，便于持续观察整个服务集群路由变化情况并动态计算出服务集群的路由收敛时间。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

相关技术中，通过调用服务网格系统提供的工具去转存（dump）当前实例进程的路由信息，然后再循环通过脚本判断路由是否到了全量路由的预期值，达到了就记录当前的时间点A1，依次对当前集群所有实例进行同样的操作，分别记录A1到AN的所有时间，然后计算其中最早的时间与最晚的时间差。以下对实现步骤简要说明：记录集群预期启动的所有实例数量N，N＞1且N为整数；在服务集群中每个实例进程启动前，启动一个脚本循环调用工具，dump当前节点的全量路由；每个节点dump完路由后判断路由数量是否等于N，等于则记录当前的时间点A1；所有的节点的都达到了预期的全量路由数量，汇总时间A1-AN；计算A1-AN中的时间差。

从上面的说明中可以看出，在当前节点的全量路由达到预期值之前，需要一直调用dump工具输出全量路由所有信息，这种大量集中写磁盘瞬间操作，对于集群起服或者停服这个资源消耗比较大的瞬间造成比较大的性能干扰；dump的工具并不是实时操作，会存在秒级别的时延，导致最终测试结果存在很大的误差；大规模的集群路由收敛时间测试，分布在各个机器上面的时间点数据不利于最终结果的统计分析。

基于此，本申请实施例提供一种路由收敛时间的确定方法，参见图11，图11是本申请实施例提供的测试程序的功能结构示意图，主要包括3个阶段，阶段一是服务集群中每个服务实例（记作recv_server）实时输出路由变化相关的统计信息到统计文件（metrics文件）；阶段二是由信息上报（记作benchmark_reporter）进程实时读取metrics信息然后发给数据中心；阶段三主要在数据中心的汇总数据基础上面进行统计分析，动态得出每个路由收敛测试场景的路由收敛时间。

首先，对第一阶段进行说明，在一些实施例中，参见图12，图12是本申请实施例提供的路由变化统计数据输出流程图，结合图12进行说明实现路由变化统计数据输出过程：步骤401，测试程序启动，初始化服务进程；步骤402，实时监听服务集群中的事件回调消息，其中，事件回调消息，包括402a服务实例上线时触发的事件回调以及402b服务实例下线时触触发的事件回调；步骤403，创建服务实例，并在服务集群中注册服务实例；步骤404，服务实例注册成功后，启动服务实例；步骤405，服务实例启动成功后，获取服务集群中的全量路由信息；步骤406，根据服务集群返回的回调信息，执行更新操作，更新路由信息；步骤407，获取运行间隔，即信息采集周期；步骤408，根据监听的回调时间，判断路由信息是否发生变化；步骤409，根据运行间隔，周期性的输出路由变化信息；步骤410，执行退出操作。

在实际实施时，以测试一个游戏应用对应的服务网格系统中，各服务实例都能发现服务集群内路由数量达到3000个的路由收敛时间为例，在测试程序里面定义了一个全局的实例集合变量，记作instance_set，变量类型可以是结构体形式。测试程序初始化后，会实时监听游戏应用对应的服务网格系统的回调消息，然后再创建服务实例，向游戏应用对应的服务网格系统进行服务注册，服务实例注册成功后，继续启动服务实例，以便于服务网格系统中的其它实例能够发现当前启动的服务实例，若上述操作过程中有任何失败，都会直接执行退出操作，输出“服务实例的路由数量为-1”的统计信息，此时，服务实例的路由数量为-1，表示服务实例进程启动失败退出。

服务实例进程启动成功后，先主动拉取一下服务集群系统中的全量路由信息，并更新到全局变量instance_set中，然后主动输出一次对应当前服务实例的全量路由的数量和时间到统计数据（metrics）中，在服务实例进程运行的过程中会持续调用更新（Update）操作去获取消息，且每隔一个信息采集周期（如，图中所示的5s）进行一次路由统计数据输出。

每次Update结束，都会判断一下当前服务实例的instance_set中路由数量是否有变化，路由数量的变化主要是由服务集群中其它服务实例的上线或者下线操作引起，当事件回调收到其它服务实例的服务上线（online）消息，会在当前服务实例的instance_set中增加这条记录，当事件回调收到其它服务实例的服务下线（offline）消息，会在当前服务实例的instance_set中删除这条记录。

示例性地，参见图6示出的第一阶段输出的路由统计信息，图中编号R1行，表示local_svc对应的服务实例在1618824337016时间戳对应的时间创建；编号R2行，表示服务实例上线的时间点；编号R3行表示服务实例发现的服务集群中服务实例的数量为1，也就是整个服务集群中存在运行的服务实例的初始时间；编号R4行表示服务实例启动完成；编号R5行表示服务实例启动是否成功的回调信息，bendmark_startup_code=0时表示服务实例启动成功；编号R6行表示服务实例启动成功后，触发获取服务集群中全量路由信息（trigger=“notify”）的事件；编号R7行表示拉取服务集群中全量路由信息后，服务集群中的路由数量。编号R8行表示，服务集群广播服务实例的上线通知，服务实例接收到该通知信息，更新自身的路由信息，此时服务实例能够发现的路由数量由R7行中的996，变更为R9行的997，后续各行表示含义与编号R1至R9类似。

其次，对第二阶段进行说明，在一些实施例中，参见图7，图中展示的是实时上报数据中心代码实现。在每个服务实例启动的时候，会启动图7中的go代码实现的一个上报程序benchmark_reporter，上报程序的输入是第一阶段中recv_server进程所输出的metrics统计文件，每次读取一个统计周期的数据，然后发到数据中心监听的HTTP端口（图7中所示的10001端口），进行数据上报。

再次，对第三阶段进行说明，在一些实施例中，参见图13，图13是本申请实施例提供的动态测算服务网格中路由收敛时间的流程图，结合图13进行说明。动态测算服务网格中路由收敛时间的实现过程如下：步骤501，测试程序获取初始路由数量以及设置的预期路由数量；步骤502，从数据中心获取各服务实例上报的统计数据；步骤503，解析统计数据，获取路由数量不等于初始路由数量的服务实例数量大于1时的时间点，作为路由变化初始时间，记作T_start；步骤504，解析统计数据，获取路由数量等于预期路由数量的服务实例数量等于预期路由数量的时间点，作为路由变化截止时间，记作T_end；步骤505，根据路由变化初始时间以及路由变化截止时间，计算路由收敛时间。

在实际实施时，在测试程序启动时，记录当前服务集群的初始全量路由数量为S，服务实例起服或者停服等引起路由变化的操作后，整个服务集群会设置一个预期的最终全量路由数量A（服务集群同步成功时的目标路由数量），测试程序循环从数据中心中获取路由变化统计数据，当获取到当前集群中全量路由数量不等于S的服务实例数量大于1时，表示服务集群中路由数量开始进行变化，记录下当前的变化的时间点记作T_start，继续循环获取路由变化信息，当服务集群中的当前路由数量等于预期路由数量A的服务实例数量时，表示服务集群的路由已经收敛（即服务集群同步成功），记录下当前的时间点T_end，计算T_end以及T_start两个时间点的时间差值作为服务集群对应的路由变化收敛时间。

示例性地，为了验证本申请实施例提供的路由收敛时间的确定方法的实际效果，以测试包含3000个节点规模的服务集群不同业务场景的路由收敛时间的测试为例，路由收敛能力如下：参见图14A，图14A是本申请实施例提供的服务集群起服路由开始变化时间点示意图，图中服务集群起服路由开始变化时间点（T_start）是2021-03-29 16:00:00.090（图中编号A-1），即在编号A-1指示的时间点，服务集群中存在正常启动的服务实例。

参见图14B，图14B是本申请实施例提供的服务集群起服路由一致时间点示意图，由图中可知，服务集群中3000个节点同时启动，服务集群起服路由一致时间点（T_end）是2021-03-29 16:00:05.820（图中编号B-1），结合图14A中的编号A-1表示的服务集群起服路由开始变化时间点T_start，可以得到3000节点同时启动，整个服务集群同步成功时间：T_end -T_start = 5730ms。另外，根据实际测试（图中未示出），3000节点启动后，再停止一个服务实例，整个服务集群同步成功时间：270ms；3000节点启动后，再批量启动200节点同时上线，整个服务集群同步成功时间：2880ms；3200节点启动后，再批量停止200节点同时下线，整个服务集群同步成功时间：2600ms。

参见图14C，图14C是本申请实施例提供的服务集群起服路由一致时间点另一示意图，图中所示为服务集群上线1个实例路由一致时间点，即服务集群中3000节点启动后，再启动一个新的实例，达到3001个节点，整个服务集群同步成功时间：510ms。

本申请实施例通过测试程序可以实时获取目标应用程序对应服务集群的全量路由变化信息，能够减少路由收敛时间的测试值与路由收敛时间的真实值之间的误差；在统计路由变化信息时，通过信息上报的方式，不需要再在路由变化过程中持续调用系统工具集中转存全量路由，减少对用户服务的影响；另外所有路由变化数据都可以在数据中心持续观察，便于统计分析，动态测算路由收敛时间。

下面继续说明本申请实施例提供的路由收敛时间的确定装置555的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器550的路由收敛时间的确定装置555中的软件模块可以包括：

获取模块5551，用于获取目标应用程序对应的服务集群，所述服务集群包含至少两个服务，每个所述服务对应至少一个服务实例；

采集模块5552，用于在所述目标应用程序存在运行的服务实例时，记录初始时间并采集与各所述服务实例对应的路由变化信息，其中，所述路由变化信息包括：由所述服务实例的状态切换所导致的所述服务集群对应的路由数量的变化信息；

分析模块5553，用于基于所述路由变化信息，确定所述服务集群对应的路由收敛条件得到满足时，记录截止时间；

确定模块5554，用于基于所述初始时间及所述截止时间，确定与所述服务集群对应的路由收敛时间。

在一些实施例中，获取模块5551，还用于监听所述服务集群中各所述服务实例的状态切换事件；当监听到指示存在状态切换服务实例的状态切换事件时，更新所述服务集群对应的路由变化信息。

在一些实施例中，获取模块5551，还用于当所述状态切换事件所对应服务实例的状态由未运行状态切换为启动状态时，在所述路由变化信息中增加相应服务实例的路由信息；当所述状态切换事件所对应服务实例的状态由运行状态切换为停止状态时，在所述路由变化信息中删除相应服务实例的路由信息。

在一些实施例中，采集模块5552，还用于获取信息采集周期，所述信息采集周期用于表征相邻两次对所述路由变化信息进行采集处理的时间间隔；基于所述信息采集周期，周期性对各所述服务实例对应的路由变化信息进行采集，得到各所述服务实例对应的路由变化信息。

在一些实施例中，采集模块5552，还用于接收各所述服务实例周期性上报的路由变化信息，所述路由变化信息由所述服务实例调用自身的信息上报子程序所上报；将所述路由变化信息存储到数据存储区域。

在一些实施例中，获取模块5551，还用于构建与各所述服务的实例相对应的实例副本，所述实例副本具有信息上报功能；将所述实例副本作为与所述服务相对应的服务实例。

在一些实施例中，路由收敛条件包括：服务集群对应的路由数量达到目标路由数量，所述分析模块5553，还用于获取所述服务集群对应的目标路由数量；解析所述路由变化信息，得到所述服务集群当前的路由数量；确定当前的所述路由数量达到所述目标路由数量时的时间点，将所述时间点作为截止时间进行记录。

在一些实施例中，确定模块5554，还用于确定所述截止时间与所述初始时间之间的时间差值，将所述时间差值作为所述服务集群对应的路由收敛时间。

在一些实施例中，确定模块5554，还用于生成并输出所述目标应用程序的路由关系报告；其中，所述路由关系报告用于指示，所述服务集群对应的路由数量与所述路由收敛时间之间的关系。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的路由收敛时间的确定方法。

本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的路由收敛时间的确定方法，例如，如图3示出的路由收敛时间的确定方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言（包括编译或解释语言，或者声明性或过程性语言）来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言（HTML，Hyper TextMarkup Language）文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件（例如，存储一个或多个模块、子程序或代码部分的文件）中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，本申请实施例在各服务实例进程运行中，各服务实例主动在路由发生变化时实时输出少量统计信息，并进行路由变化信息主动上报，具备实时性，减少测试误差；且对系统路由收敛过程中没有性能干扰；数据中心汇聚了集群中每个节点全量路由持续上报数据，便于持续观察整个服务集群路由变化情况并动态计算出路由收敛时间。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种路由收敛时间的确定方法，其特征在于，所述方法包括：

获取目标应用程序对应的服务集群，所述服务集群包含至少两个服务，每个所述服务对应至少一个服务实例；

在所述目标应用程序存在运行的服务实例时，记录初始时间并采集与各所述服务实例对应的路由变化信息；

其中，所述路由变化信息包括：由所述服务实例的状态切换所导致的所述服务集群对应的路由数量的变化信息；

基于所述路由变化信息，确定所述服务集群对应的路由收敛条件得到满足时，记录截止时间；

基于所述初始时间及所述截止时间，确定与所述服务集群对应的路由收敛时间。

2.根据权利要求1所述的方法，其特征在于，在所述采集与各所述服务实例对应的路由变化信息之前，所述方法还包括：

监听所述服务集群中各所述服务实例的状态切换事件；

当监听到指示存在状态切换服务实例的状态切换事件时，更新所述服务集群对应的路由变化信息。

3.根据权利要求2所述的方法，其特征在于，所述当监听到指示存在状态切换服务实例的状态切换事件时，更新所述服务集群对应的路由变化信息，包括：

当所述状态切换事件所对应服务实例的状态由未运行状态切换为启动状态时，在所述路由变化信息中增加相应服务实例的路由信息；

当所述状态切换事件所对应服务实例的状态由运行状态切换为停止状态时，在所述路由变化信息中删除相应服务实例的路由信息。

4.根据权利要求1所述的方法，其特征在于，所述采集与各所述服务实例对应的路由变化信息，包括：

获取信息采集周期，所述信息采集周期用于表征相邻两次对所述路由变化信息进行采集处理的时间间隔；

基于所述信息采集周期，周期性对各所述服务实例对应的路由变化信息进行采集，得到各所述服务实例对应的路由变化信息。

5.根据权利要求4所述的方法，其特征在于，所述周期性对各所述服务实例对应的路由变化信息进行采集，得到各所述服务实例对应的路由变化信息，包括：

接收各所述服务实例周期性上报的路由变化信息，所述路由变化信息由所述服务实例调用自身的信息上报子程序所上报；

将所述路由变化信息存储到数据存储区域。

6.根据权利要求1所述的方法，其特征在于，所述获取目标应用程序对应的服务集群之后，所述方法还包括：

构建与各所述服务的实例相对应的实例副本，所述实例副本具有信息上报功能；

将所述实例副本作为与所述服务相对应的服务实例。

7.根据权利要求1所述的方法，其特征在于，所述路由收敛条件包括：所述服务集群对应的路由数量达到目标路由数量，

所述基于所述路由变化信息，确定所述服务集群对应的路由收敛条件得到满足时，记录截止时间，包括：

获取所述服务集群对应的目标路由数量；

解析所述路由变化信息，得到所述服务集群当前的路由数量；

确定当前的所述路由数量达到所述目标路由数量时的时间点，将所述时间点作为截止时间进行记录。

8.根据权利要求1所述的方法，其特征在于，所述基于所述初始时间及所述截止时间，确定与所述服务集群对应的路由收敛时间，包括：

确定所述截止时间与所述初始时间之间的时间差值，将所述时间差值作为所述服务集群对应的路由收敛时间。

9.根据权利要求1所述的方法，其特征在于，所述方法还包括：

生成并输出所述目标应用程序的路由关系报告；

其中，所述路由关系报告用于指示，所述服务集群对应的路由数量与所述路由收敛时间之间的关系。

10.一种路由收敛时间的确定装置，其特征在于，所述装置包括：

获取模块，用于获取目标应用程序对应的服务集群，所述服务集群包含至少两个服务，每个所述服务对应至少一个服务实例；

采集模块，用于在所述目标应用程序存在运行的服务实例时，记录初始时间并采集与各所述服务实例对应的路由变化信息，其中，所述路由变化信息包括：由所述服务实例的状态切换所导致的所述服务集群对应的路由数量的变化信息；

分析模块，用于基于所述路由变化信息，确定所述服务集群对应的路由收敛条件得到满足时，记录截止时间；

确定模块，用于基于所述初始时间及所述截止时间，确定与所述服务集群对应的路由收敛时间。

Images