CN116166403A - 业务系统的抖动的处理方法、介质、装置和计算设备 - Google Patents

Abstract

本公开的实施方式提供了一种业务系统的抖动的处理方法。该业务系统的抖动的处理方法包括：响应业务系统启动，执行以下流量回放流程：从存储介质中读取目标请求，目标请求是对业务请求进行序列化处理得到的，业务请求是在业务系统正常运行过程中采集到的；对目标请求进行反序列化处理，得到业务请求对应的虚拟请求；根据虚拟请求对业务系统进行预热处理。通过利用虚拟请求对业务系统的服务进行预热，可以极大程度上减少业务系统的抖动，从而保证了业务系统的稳定运行，为用户带来了更好的体验。此外，本公开的实施方式提供了一种介质、业务系统的抖动的处理装置和计算设备。

Description

业务系统的抖动的处理方法、介质、装置和计算设备

技术领域

本公开的实施方式涉及计算机领域，更具体地，本公开的实施方式涉及业务系统的抖动的处理方法、介质、装置和计算设备。

背景技术

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

随着计算机技术和互联网技术的发展，互联网产品的更新迭代速度越来越快。在产品的更新迭代过程中，业务的发布、下线和上线均需启动业务系统，而业务系统的启动可能会导致用于线上承担业务职责的业务系统的抖动。

相关技术中，为了避免业务系统的抖动，通常是对业务系统进行预热。其中，较为常见的一种具体实现为：在业务系统刚刚进行启动的时候，对流量进行较好的控制，不是一次性的将全量的流量进行释放，而是在一个时间段内缓慢的增加流量，这样可以给业务系统充分的预热时间来完成内部的预热。在该时间段内，即使有流量的波动，也会因为流量控制而减少流量的损失。但这种方式仅可以减少业务系统在启动期间的抖动，仍无法保障业务系统的稳定运行。

发明内容

本公开提供一种业务系统的抖动的处理方法、介质、装置和计算设备，以保障业务系统的稳定运行。

在本公开实施方式的第一方面中，提供了一种业务系统的抖动的处理方法，包括：响应业务系统启动，执行以下流量回放流程：从存储介质中读取目标请求，目标请求是对业务请求进行序列化处理得到的，业务请求是在业务系统正常运行过程中采集到的；对目标请求进行反序列化处理，得到业务请求对应的虚拟请求；根据虚拟请求对业务系统进行预热处理。

在本公开的一个实施例中，对目标请求进行反序列化处理，得到业务请求对应的虚拟请求，包括：对目标请求进行反序列化处理，得到请求对象；在请求对象中添加预设参数，得到虚拟请求。

在本公开的另一实施例中，根据虚拟请求对业务系统进行预热处理，包括：向业务系统发送虚拟请求，虚拟请求中包括用于指示预热处理的预热标志位，预热标志位用于指示业务系统进行预热处理。

在本公开的又一个实施例中，预热标志位还用于指示业务系统将上下文中的预设标志位对应的参数修改为预设参数。

在本公开的再一个实施例中，业务请求是通过以下方式采集到的：在业务系统正常运行过程中，采用面向切面编程方法确定业务请求对应的业务是否执行完成；响应于业务执行完成，采用面向切面编程方法确定是否获取到业务的预期结果数据；响应于获取到预期结果数据，检测业务系统中是否存在用于指示采集业务请求的标识信息；响应于检测到标识信息，采集业务请求。

在本公开的再一个实施例中，该业务系统的抖动的处理方法还包括：确定业务请求的个数；响应于业务请求的个数大于或等于预设值，取消对业务请求的采集操作。

在本公开的再一个实施例中，目标请求是通过以下方式对业务请求进行序列化处理得到：对业务请求进行参数选择处理，得到第一参数；基于JSON方案，采用异步方式对第一参数进行深度复制处理，得到第二参数；对第二参数进行序列化处理，得到目标请求。

在本公开的再一个实施例中，得到目标请求之后，还包括：根据目标请求，生成请求文件；采用异步方式将请求文件存储至存储介质中。

在本公开的再一个实施例中，从存储介质中读取目标请求，包括：根据预设目录，从存储介质中读取请求文件；在请求文件中读取目标请求。

在本公开的再一个实施例中，该业务系统的抖动的处理方法还包括：通过以下方式实现采用异步方式执行目标任务，目标任务包括对第一参数进行深度复制处理，以及将请求文件存储至存储介质中：确定线程池中的当前工作线程数和核心线程数；响应于当前工作线程数小于核心线程数，创建目标核心线程，以执行目标任务；响应于当前工作线程数大于核心线程数，且线程池的阻塞队列中任务数量小于队列阈值，将目标任务添加至阻塞队列中，以等待线程池中的空闲核心线程执行；响应于当前工作线程数等于核心线程数，且阻塞队列中任务数量大于或等于队列阈值，确定线程池中的当前线程数是否小于线程池的最大线程数；响应于当前线程数小于最大线程数，创建目标非核心线程，以执行目标任务。

在本公开的再一个实施例中，该业务系统的抖动的处理方法还包括：在执行流量回放流程的过程中，接收来自发布系统的用于确认业务系统是否预热完成的检验信息；响应于业务系统预热完成，向发布系统发送用于表示业务系统预热完成的反馈信息，以指示发布系统生成上线指令；接收上线指令；向业务系统发送上线指令，以指示业务系统执行服务上线操作。

在本公开实施方式的第二方面中，提供了一种介质，介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现如第一方面的业务系统的抖动的处理方法。

在本公开实施方式的第三方面中，提供了一种业务系统的抖动的处理装置，包括：执行模块，用于响应业务系统启动，执行以下流量回放流程：从存储介质中读取目标请求，目标请求是对业务请求进行序列化处理得到的，业务请求是在业务系统正常运行过程中采集到的；对目标请求进行反序列化处理，得到业务请求对应的虚拟请求；根据虚拟请求对业务系统进行预热处理。

在本公开实施方式的第四方面中，提供了一种计算设备，包括：处理器，以及与处理器连接的存储器；存储器存储计算机执行指令；处理器执行存储器存储的计算机执行指令，以实现如第一方面的业务系统的抖动的处理方法。

根据本公开实施方式的业务系统的抖动的处理方法、介质、装置和计算设备，通过采集线上正式的用户请求，对该用户请求进行序列化处理之后存储在磁盘上，当业务系统启动时，在磁盘中获取序列化处理后的用户请求，并将获取到的用户请求进行反序列化处理，得到虚拟请求，然后采用这些虚拟请求对业务系统进行预热，并且，在预热过程中，业务系统不对服务进行上线，因此，可以保证业务系统的稳定运行，为用户带来了更好的体验。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

图1为本公开实施方式提供的业务系统的抖动的处理方法的应用场景示意图；

图2为本公开实施方式提供的业务系统的抖动的处理方法的流程示意图；

图3为本公开实施方式提供的解释器和编译器的关系示意图；

图4为本公开实施方式提供的AOP对业务逻辑的各个部分进行隔离的示意图；

图5为本公开实施方式提供的AOP注解完成流量采集的示意图；

图6为本公开实施方式提供的线程池的结构示意图；

图7为本公开实施方式提供的业务系统和发布系统的通信过程示意图；

图8为本公开实施方式的存储介质的结构示意图；

图9为本公开实施方式的业务系统的抖动的处理装置的结构示意图；

图10为本公开实施方式的计算设备的结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提出了一种业务系统的抖动的处理方法、介质、装置和计算设备。在本文中，需要理解的是，所涉及的术语表示如下：

面向切面编程(Aspect Oriented Programming，简称：AOP)：一种通过预编译方式和运行期间动态代理实现程序功能的统一维护的技术。AOP是OOP的延续，是软件开发中的一个热点，也是Spring框架中的一个重要内容，是函数式编程的一种衍生范型。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高开发的效率。

序列化：将Java对象转换为字节序列的过程。

反序列化：将字节序列转换为Java对象的过程。

即时编译(Just In Time，简称：JIT)：当某段代码即将第一次被执行时进行编译。JIT是动态编译的一种特例。

深度拷贝(copy)：源对象与拷贝对象互相独立，其中任何一个对象的改动都不会对另外一个对象造成影响。

发布系统：用来控制业务系统进行发布、下线和上线等动作的调度系统。

业务系统：线上承担业务职责的系统。

此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

另外，本公开所涉及的数据可以为经用户授权或者经过各方充分授权的数据，对数据的采集、传播、使用等，均符合国家相关法律法规要求，本公开实施方式/实施例可以互相组合。

下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。

发明概述

本发明人发现，随着计算机技术和互联网技术的发展，互联网产品的更新迭代速度越来越快。在产品的更新迭代过程中，业务的发布、下线和上线均需启动业务系统，而业务系统的启动可能会导致业务系统的抖动。相关技术中主要采用以下两种方式来解决业务系统的抖动：

一种是在业务系统启动的时候，对业务系统内部的线程池进行预热，以实现在承接真正的线上流量时，线程池不会出现波动的情况，从而可以避免影响线上的服务。这种方法主要依赖java内部提供的应用程序接口(Application Programming Interface，简称：API)对线程池进行预热操作，或者利用业务系统内部的模拟循环等操作来完成线程池的预热，能够避免局部的由于线程池未预热带来的性能波动问题。

但是，这种方法只能避免由于线程池的波动带来的性能波动，如果波动的来源不是线程池，则无法避免业务系统的其他性能波动；此外，在线程池很多且用户可以自主创建线程池的情况下，无法对所有的线程池进行预热，如果存在某些线程池没有完成预热，那么整个业务系统还是会出现性能波动的情况；另外，这种方法需要针对业务系统中不同的位置进行重复的开发，也即在使用线程池时在需要添加预热逻辑的位置增加预热逻辑，没有可以整体一次性解决业务系统抖动的能力。

另一种是可以实现对业务系统的整体进行流量控制，也即，在业务系统刚刚进行启动的时候，对流量进行较好的控制，不是一次性的将全量的流量进行释放，而是在一个时间段内缓慢的增加流量，这样可以给业务系统充分的预热时间来完成内部的预热。在该时间段内，即使有流量的波动，也会因为流量控制而减少流量的损失。

这种方法虽然能够解决一部分的业务系统启动期间波动的问题，但只是控制业务系统启动的时候的流量，降低整体的损失。若业务系统需要即时编译，那么这部分的流量依然还会较大概率的因为中央处理器(central processing unit，简称：CPU)的波动而导致业务系统的异常；另外，业务系统是比较重要的系统，比如交易平台等等，这种平台对请求的成功是非常敏感的，因此，业务系统的波动带来的损失较大。

因此，本公开提供了一种业务系统的抖动的处理方法，通过采集线上正式的用户请求，对该用户请求进行序列化处理之后存储在磁盘上，当业务系统启动时，在磁盘中获取序列化处理后的用户请求，并将获取到的用户请求进行反序列化处理，得到虚拟请求，然后采用这些虚拟请求对业务系统进行预热，并且，在预热过程中，业务系统不对服务进行上线，因此，可以避免业务系统的抖动，保证业务系统的稳定运行，为用户带来了更好的体验。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。

应用场景总览

首先参考图1，图1为本公开实施方式的业务系统的抖动的处理方法的应用场景示意图。在图1中，业务系统的抖动的处理方法可以通过业务系统的抖动的处理系统实现，该业务系统的抖动的处理系统可以包括业务系统和发布系统，其中，业务系统可以包括采集模块、磁盘和预热模块。

其中，业务系统可以线上承担业务职责，采集模块可以用于通过AOP对线上真实的用户请求进行无侵入性的采集，并对采集到的用户请求进行序列化处理，也即按照请求的来源进行划分，得到不同请求文件并将这些文件夹存储在磁盘上。当采集到的用户请求的数量达到既定数量后停止采集用户请求。

当业务系统启动后，预热模块可以在磁盘中获取存储的不同文件夹，并对这些文件夹进行反序列化处理，得到虚拟请求，然后采用这些虚拟请求对业务系统进行预热处理。由于预热处理采用的是虚拟请求，因此，可以避免使用线上真实的用户请求对业务系统进行预热时对业务系统带来的损失，使业务系统可以稳定运行。

在业务系统进行预热的过程中，业务系统和发布系统之间可以进行通信，也即，发布系统按照预设的间隔时长向业务系统发送检验信息，以确定业务系统是否预热完毕，业务系统接收到检验信息之后，根据自身的预热情况向发布系统返回反馈信息。发布系统若接收到业务系统发送的用于指示预热完毕的反馈信息，则向业务系统发送上线指令，业务系统根据接收到的上线指令执行内部的上线程序，以完成服务上线的操作。从而，业务系统可以正式对外提供服务。因此，可以保证业务系统的稳定运行，为用户带来了更好的体验。

示例性方法

下面结合图1的应用场景，参考图2来描述根据本公开示例性实施方式的业务系统的抖动的处理方法。需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。

参考图2，图2为本公开实施方式的业务系统的抖动的处理方法的流程示意图，如图2所示，该业务系统的抖动的处理方法包括以下步骤：

S201：响应业务系统启动，从存储介质中读取目标请求。

具体地，目标请求是对业务请求进行序列化处理得到的，业务请求是在业务系统正常运行过程中采集到的。

具体地，可以在业务系统正常运行过程中，按照特定比例对线上正式环境的真实用户请求进行采集，得到业务请求，然后对采集到的业务请求进行序列化处理，得到目标请求。在得到目标请求之后，可以将目标请求存储到存储介质中，该存储介质可以为业务系统的磁盘、远程字典服务(Remote Dictionary Server，简称：Redis)和结构数据存储系统(tair)等，该磁盘可以为本地磁盘，也可以为云磁盘等。从而响应业务系统启动，可以从业务系统的存储介质中读取目标请求。

可选地，业务系统可以为用于搜索业务的业务系统，也可以为常见的java服务系统。

S202：对目标请求进行反序列化处理，得到业务请求对应的虚拟请求。

具体地，在存储介质中读取目标请求之后，可以对目标请求进行反序列化处理，使目标请求反序列化为虚拟请求，这样就可以使用虚拟请求对业务系统进行预热处理，从而保证业务系统在正式运行过程中，可以稳定运行。

S203：根据虚拟请求对业务系统进行预热处理。

具体地，为了保证业务系统在正式运行时可以稳定运行，需要对业务系统进行预热处理，而使用线上真实的用户请求预热业务系统会存在业务系统不稳定的问题，从而影响到用户的使用体验。因此，在业务系统正式运行前，可以利用得到的虚拟请求对业务系统进行预热。

具体地，业务系统在进行预热处理过程中，采用JIT即时编译，即时编译时，会将大量被调用的请求进行C2编译(C2 COMPILE)并固化下来，这个过程是比较耗费CPU的，但是由于使用的请求是虚拟请求，因此，可以避免线上真实的用户请求的损失。

具体地，即时编译是动态编译的一种特例，在java运行过程中，有解释器和编译器在不同的阶段产生作用，其中，解释器和编译器的关系可以如图3所示。

图3为本公开实施方式提供的解释器和编译器的关系示意图，其中，解释器启动快，但是执行慢。编译器分为以下五个层次：第0层：程序解释执行，默认开启性能监控功能(Profiling)，如果不开启，可触发第2层编译；第1层：可称为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，不开启Profiling；第2层：也称为C1编译，开启Profiling，仅执行带方法调用次数和循环回边执行次数profiling的C1编译；第3层：也称为C1编译，执行所有带Profiling的C1编译；第4层：可称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。在常规的业务系统中，一般都会在执行一段时间之后，即时编译发现系统存在部分代码可以固化下来，然后执行到C2编译，进而导致系统在C2编译期间发生了CPU飙高，进而导致系统有波动。因此，进行C2编译并固化下来的过程中，可以使用虚拟请求，从而可以避免线上真实的用户请求的损失。

本公开的业务系统的抖动的处理方法，通过采集线上正式的用户请求，对该用户请求进行序列化处理之后存储在磁盘上，当业务系统启动时，在磁盘中获取序列化处理后的用户请求，并将获取到的用户请求进行反序列化处理，得到虚拟请求，然后采用这些虚拟请求对业务系统进行预热，因此，可以保证业务系统的稳定运行，为用户带来了更好的体验。

在本公开的一个实施例中，对目标请求进行反序列化处理，得到业务请求对应的虚拟请求，包括：对目标请求进行反序列化处理，得到请求对象；在请求对象中添加预设参数，得到虚拟请求。

具体地，在存储介质中读取目标请求之后，可以先对目标请求进行反序列化处理，将目标对象反序列化为存储介质中的请求对象，然后调整请求对象中需要补充的部分信息，也即，在请求对象中添加预设参数，该预设参数可以为用于表示是否为预热流量等参数，该预热流量可以用于表示当前的请求对象为用于进行预热处理的流量。

具体地，在请求对象中添加预设参数之后，可以得到虚拟请求，然后采用这些虚拟请求对业务系统进行预热，因此，可以保证业务系统的稳定运行，为用户带来了更好的体验。

在本公开的另一个实施例中，根据虚拟请求对业务系统进行预热处理，包括：向业务系统发送虚拟请求，虚拟请求中包括用于指示预热处理的预热标志位，预热标志位用于指示业务系统进行预热处理。

具体地，可以向业务系统发送虚拟请求，业务系统在处理虚拟请求时，可以检查虚拟请求中是否有用于指示预热处理的预热标志位，如果有预热标志位，则业务系统可以利用虚拟请求进行预热处理，保证业务系统的稳定运行，为用户带来了更好的体验。

在本公开的又一个实施例中，预热标志位还用于指示业务系统将上下文中的预设标志位对应的参数修改为预设参数。

具体地，业务系统中可能会存在一些无用的打点，为了避免这些无用的打点造成不必要的存储资源(例如，磁盘的存储资源)浪费或者产生虚假的回流信息，业务系统可以将上下文中的预设标志位对应的参数修改为预设参数，比如，将上下文的特定标志位置为true，则可以表示业务系统当前接收到的请求是一个虚拟请求，因此，业务系统可以利用虚拟请求进行预热处理。并且，预设标志位置为true的虚拟请求也不会再次存储到存储介质中，从而可以避免存储资源浪费或者产生虚假的回流信息。

在本公开的再一个实施例中，业务请求是通过以下方式采集到的：在业务系统正常运行过程中，采用面向切面编程方法确定业务请求对应的业务是否执行完成；响应于业务执行完成，采用面向切面编程方法确定是否获取到业务的预期结果数据；响应于获取到预期结果数据，检测业务系统中是否存在用于指示采集业务请求的标识信息；响应于检测到标识信息，采集业务请求。

具体地，采集业务请求，也可以称为采集流量或流量采集。在采集业务请求时，可以在需要进行流量采集的接口上加入AOP注解，从而，在业务系统正常运行过程中，可以采用AOP确定业务请求对应的业务是否执行完成，若执行完成，则再采用AOP确定是否获取到该业务对应的预期结果数据，若未得到预期结果数据，则放弃此次对业务请求的采集。若得到预期结果数据，则可以确定该业务是否需要进行流量采集，也即，检测业务系统中是否存在用于指示采集业务请求的标识信息，若需要对该业务进行流量采集，也即，业务系统中存在用于指示采集业务请求的标识信息，则采集业务请求；若不需要对该业务进行流量采集，也即，业务系统中不存在用于指示采集业务请求的标识信息，则放弃此次对业务请求的采集。

具体地，通过采集业务请求，可以将其转换成虚拟请求，这样就可以采用这些虚拟请求对业务系统进行预热，从而可以保证业务系统的稳定运行，为用户带来了更好的体验。

具体地，在利用AOP采集业务请求时，可以如图4和图5所示。

图4为本公开实施方式提供的AOP对业务逻辑的各个部分进行隔离的示意图，在图4中，利用AOP可以对业务逻辑的各个部分进行隔离，也即，将代理中的被通知的bean和引入的代理进行隔离，调用者在调用代理时，可以使用现有的方法调用被通知的bean，使用被引入的方法调用引入的代理，从而使得被通知的bean和引入的代理之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。

图5为本公开实施方式提供的AOP注解完成流量采集的示意图，在图5中，在执行链路的入口处增加AOP切面，利用spring的特性对所有流经执行链路的流量(也即需要采集的线上真实的用户请求)进行特定的操作，并可针对这一AOP操作创建预设的注解，需要采集流量的接口仅需添加这个AOP注解即可完成流量的采集，因此，后续可以极大增强可扩展性。

在本公开的再一个实施例中，还包括：确定业务请求的个数；响应于业务请求的个数大于或等于预设值，取消对业务请求的采集操作。

具体地，为了节省磁盘的存储空间，在采集业务请求时，还需要实时检测已采集到的业务请求的个数，确定已采集到的业务请求的个数是否达标，也即，确定业务请求的个数是否大于或等于预设值。若业务请求的个数大于或等于预设值，则不继续采集业务请求；若业务请求的个数小于预设值，则可以继续采集业务请求。

在本公开的再一个实施例中，目标请求是通过以下方式对业务请求进行序列化处理得到：对业务请求进行参数选择处理，得到第一参数；基于JSON方案，采用异步方式对第一参数进行深度复制处理，得到第二参数；对第二参数进行序列化处理，得到目标请求。

具体地，采集到业务请求之后，需要对业务请求进行序列化处理。业务请求中包括多种复杂的参数，在对业务请求进行序列化处理时，可以先在复杂的参数中选择需要的参数，比如，在复杂的参数中去掉个性化的参数配置，这样可以降低对业务请求序列化处理的难度。

具体地，在得到第一参数之后，可以基于JSON方案对第一参数进行深度copy处理，得到第二参数，也即，将原有的参数对象复制成一个新的参数对象，这样对第二参数的操作不会影响到第一参数。为了避免执行序列化处理的线程压力过大，对第一参数进行深度复制处理的执行过程可以异步进行，也即，在另一个线程中执行。

具体地，在对第一参数进行深度copy处理，得到第二参数时，需要考虑到深度copy的性能。由于JSON方案的深度copy过程中可视化更强，可以更好地解决和分析问题，并且，JSON方案的深度copy的性能尚可，对于当前的处理对象不是很大的情况下，使用JSON方案作为深度copy足够达成目标，因此，可以选择JSON方案对第一参数进行深度copy处理。

具体地，在得到第二参数之后，可以对第二参数进行序列化处理，从而得到目标请求。

在本公开的再一个实施例中，得到目标请求之后，还包括：根据目标请求，生成请求文件；采用异步方式将请求文件存储至存储介质中。

具体地，在得到目标请求之后，可以将目标请求存储在指定的路径中，也即，业务系统的存储介质，比如，磁盘。

具体地，可以先根据目标请求的来源，将目标请求存储到请求文件中，不同请求文件对应的目标请求的来源不同，同一请求文件对应的目标请求的来源相同。在生成请求文件之后，再将请求文件存储在业务系统的存储介质中，以便于后续可以快速读取到目标请求。

在本公开的再一个实施例中，从存储介质中读取目标请求，包括：根据预设目录，从存储介质中读取请求文件；在请求文件中读取目标请求。

具体地，在根据目标请求生成请求文件，并将请求文件存储在存储介质中之后，响应业务系统启动，就可以按照预设目录，读取存储在存储介质的固定目录下的请求文件。由于请求文件可能存在多个，每个请求文件对应的目标请求的来源不同，因此，在读取到请求文件之后，可以将读取到的文件信息划分为不同种类(来源)的目标请求，从而可以在不同种类的目标请求中确定需求的目标请求。

具体地，通过获取目标请求，可以将其转换成虚拟请求，这样就可以采用虚拟请求对业务系统进行预热，从而可以保证业务系统的稳定运行，为用户带来了更好的体验。

在本公开的再一个实施例中，还包括：通过以下方式实现采用异步方式执行目标任务，目标任务包括对第一参数进行深度复制处理，以及将请求文件存储至存储介质中：确定线程池中的当前工作线程数和核心线程数；响应于当前工作线程数小于核心线程数，创建目标核心线程，以执行目标任务；响应于当前工作线程数大于核心线程数，且线程池的阻塞队列中任务数量小于队列阈值，将目标任务添加至阻塞队列中，以等待线程池中的空闲核心线程执行；响应于当前工作线程数等于核心线程数，且阻塞队列中任务数量大于或等于队列阈值，确定线程池中的当前线程数是否小于线程池的最大线程数；响应于当前线程数小于最大线程数，创建目标非核心线程，以执行目标任务。

具体地，在进行流量采集的过程中，需要执行目标任务，也即对第一参数进行深度复制处理，以及将请求文件存储至存储介质中，这个过程相对线上的业务流程来说时耗是比较明显的，所以需要采用异步方式执行目标任务，也即，提交目标任务之后不用阻塞等待即可执行目标任务。因此，将目标任务提交到特定的线程池中异步执行，不会影响到业务系统的主线流程。

具体地，线程池的大致结构可以如图6所示。

图6为本公开实施方式提供的线程池的结构示意图，在使用如图6所示的线程池执行目标任务时，线程池的使用有以下几个阶段：

处理模块提交目标任务后会先进行当前工作线程数(线程池里面存活的线程数)与核心线程数的比较，也即针对核心线程数进行预热的操作，如果当前工作线程数小于核心线程数，则直接调用addWorker()方法创建一个核心线程去执行目标任务。

如果当前工作线程数大于核心线程数，即线程池中的核心线程数量已满，则目标任务会被添加到阻塞队列中等待执行。由于无界队列比较危险，可能会造成JVM的内存溢出，因此，该阻塞队列可以不使用无界队列，可选择有界队列或同步移交。

如果当前工作线程数等于核心线程数，且阻塞队列已满，则确定当前工作线程数是否已经达到最大线程数maximumPoolSize，如果没有达到，则会调用addWorker()方法创建一个非核心线程去执行目标任务。

具体地，线程池在关闭后，或者线程池中当前工作线程数是否已经达到最大线程数且阻塞队列已满，则执行模块在接收到新来的任务时，可以通过以下四种拒绝策略拒绝任务：

第一策略：AbortPolicy策略，直接抛出一个异常，例如，该异常的类型可以为RejectedExecutionException的RuntimeException，通过该异常可以感知到新提交的任务被拒绝了，从而便可以根据业务逻辑选择重试或者放弃提交等策略。

第二策略：DiscardPolicy策略，直接将新提交的任务丢弃掉，且也不会给出任何的通知。

第三策略：DiscardOldestPolicy策略，如果线程池没被关闭且没有能力执行，则会丢弃阻塞队列中的头结点，通常是存活时间最长的任务，这样就可以腾出空间给新提交的任务。

第四策略：CallerRunsPolicy策略，当有新任务提交后，如果线程池没被关闭且没有能力执行，则把新提交的任务交于提交任务的线程执行，也就是谁提交任务，谁就负责执行任务。

具体地，由于创建线程会十分消耗业务系统的资源，因此，可以着重查看线程池中当前工作线程数和核心线程数，尽量避免频繁的创建和销毁线程，从而避免过多消耗业务系统的资源。

在本公开的再一个实施例中，还包括：在执行流量回放流程的过程中，接收来自发布系统的用于确认业务系统是否预热完成的检验信息；响应于业务系统预热完成，向发布系统发送用于表示业务系统预热完成的反馈信息，以指示发布系统生成上线指令；接收上线指令；向业务系统发送上线指令，以指示业务系统执行服务上线操作。

具体地，在执行流量回放的过程中，业务系统是处于不稳定的状态的，这个时候不能将业务系统的服务上线并暴露给用户，因此，需要在流量回放的过程中持续保障业务系统的服务不可上线。因此，在采用虚拟请求对业务系统进行预热的同时，发布系统需要确定业务系统是否预热完成，业务系统在预热完成之后才可以进行服务上线，执行线上真实的用户请求。因此，发布系统可以发送检验信息，以确认业务系统是否预热完成，若业务系统预热完成，则发布系统可以在接收到用于表示业务系统预热完成的反馈信息之后，生成上线指令，也即online指令，业务系统在接收到上线指令之后，会执行内部的上线程序，也即online程序，以完成服务上线操作，业务系统在完成服务上线操作之后，就可以正式对外提供服务。可选地，服务上线操作可以包括将业务系统挂到分布式应用程序协调服务软件(zookeeper，简称ZK)服务节点上等一系列的服务上线操作。

具体地，发布系统上设置有检验接口，也即check接口，发布系统感知到业务系统的预热操作完成，可以通过调用check接口发送检验信息。可选地，发布系统可以根据预设的间隔时间发送检验信息，间隔时间可以由各个业务自定义。

具体地，发布系统在接收到用于表示业务系统预热未完成的反馈信息之后，可以确定此次检验失败，从而需要在预设的间隔时间之后再次发送检验信息，直到接收到用于表示业务系统预热完成的反馈信息之后，生成上线指令。

具体地，在业务系统预热完成之后执行服务上线操作，可以避免由于预热过程中业务系统不稳定而服务上线，导致影响到用户的使用体验，从而可以保证业务系统的持续稳定运行。

可选地，检验接口也可以直接设置在业务系统上，实现业务系统和发布系统之间的直接通信。检验接口可以适配不同的发布系统。如图7所示。

图7为本公开实施方式提供的业务系统和发布系统的通信过程示意图，在图7中，业务系统上设置有检验接口，发布系统调用检验接口向业务系统发出检验信息，业务系统在未完成预热时，向发布系统返回未完成的反馈信息，间隔预设时间后，发布系统再次向业务系统发出检验信息，直到业务系统返回已完成的反馈信息，发布系统向业务系统发送上线指令，业务系统就可以根据上线指令，执行内部的上线程序，以完成服务上线操作，业务系统在完成服务上线操作之后，就可以正式对外提供服务。

本公开的业务系统的抖动的处理方法，适用于大部分的Java应用服务。当业务系统线上的服务正常运行的时候，通过既定的AOP注解来完成无侵入性的流量采集，将采集的业务请求按照请求的来源划分为不同文件夹存储在本地磁盘上，当采集的业务请求的数量达到既定数额后停止采集。当业务系统需要重新启动时，将之前预先存储在本地磁盘上的文件反序列化为虚拟请求，并将这些虚拟请求作为真实的流量对业务系统进行模拟调用，也即预热。在模拟调用的过程中，即时编译会将大量调用的部分进行C2 COMPILE并固化下来，这个过程是比较耗费CPU的，但是由于使用的是虚拟请求，所以避免了线上真实用户请求的损失。在整个预热的过程中，需要控制业务系统不对外服务，当业务系统预热完成后，再将状态设置为在线状态，并可以对外提供真正的服务。因此，解决了由于即时编译的优化导致的CPU使用率增高从而带来的业务系统不稳定的问题；解决了采集虚拟流量的时候自适应的问题；解决了预热问题对用户请求变化感知强烈的问题。

本公开的业务系统的抖动的处理方法，极大程度上减少了业务系统的波动，保障了线上服务的稳定运行；减少了异常请求，降低了业务的流量损失；灵活可扩展的AOP切面方式使得不仅仅可以为单一的业务增加预热处理，也可以广泛地应用到其他的业务场景中；无感知的保护了业务系统，对业务系统的预热处理对常规的业务开发是无感知的，透明的，因此，减少了对业务开发的侵入性和干扰。

示例性介质

在介绍了本公开示例性实施方式的方法之后，接下来，参考图8对本公开示例性实施方式的存储介质进行说明。

图8为本公开实施方式的存储介质的结构示意图，参考图8所示，存储介质80中存储着根据本公开的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括计算机执行指令，该计算机执行指令用于使计算设备执行本公开所提供的业务系统的抖动的处理方法。然而，本公开的程序产品不限于此。

该程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机执行指令。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开公开操作的计算机执行指令，该程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。计算机执行指令可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备。

示例性装置

在介绍了本公开示例性实施方式的介质之后，接下来，参考图9对本公开示例性实施方式的业务系统的抖动的处理装置进行说明，用于实现上述任一方法实施例中的方法，其实现原理和技术效果类似，在此不再赘述。

图9为本公开实施方式的业务系统的抖动的处理装置的结构示意图，如图9所示，该业务系统的抖动的处理装置900包括：

执行模块901，用于响应业务系统启动，执行以下流量回放流程：

从存储介质中读取目标请求，目标请求是对业务请求进行序列化处理得到的，业务请求是在业务系统正常运行过程中采集到的；

对目标请求进行反序列化处理，得到业务请求对应的虚拟请求；

根据虚拟请求对业务系统进行预热处理。

可选地，执行模块901通过以下步骤实现在对目标请求进行反序列化处理，得到业务请求对应的虚拟请求：对目标请求进行反序列化处理，得到请求对象；在请求对象中添加预设参数，得到虚拟请求。

可选地，执行模块901通过以下步骤实现根据虚拟请求对业务系统进行预热处理：向业务系统发送虚拟请求，虚拟请求中包括用于指示预热处理的预热标志位，预热标志位用于指示业务系统进行预热处理。

可选地，预热标志位还用于指示业务系统将上下文中的预设标志位对应的参数修改为预设参数。

可选地，业务系统的抖动的处理装置900通过以下方式采集业务请求：在业务系统正常运行过程中，采用面向切面编程方法确定业务请求对应的业务是否执行完成；响应于业务执行完成，采用面向切面编程方法确定是否获取到业务的预期结果数据；响应于获取到预期结果数据，检测业务系统中是否存在用于指示采集业务请求的标识信息；响应于检测到标识信息，采集业务请求。

可选地，执行模块901还用于确定业务请求的个数；响应于业务请求的个数大于或等于预设值，取消对业务请求的采集操作。

可选地，业务系统的抖动的处理装置900通过以下方式对业务请求进行序列化处理得到目标请求：对业务请求进行参数选择处理，得到第一参数；基于JSON方案，采用异步方式对第一参数进行深度复制处理，得到第二参数；对第二参数进行序列化处理，得到目标请求。

可选地，执行模块901还用于在得到目标请求之后，根据目标请求，生成请求文件；采用异步方式将请求文件存储至存储介质中。

可选地，执行模块901通过以下步骤实现从存储介质中读取目标请求，包括：根据预设目录，从存储介质中读取请求文件；在请求文件中读取目标请求。

可选地，执行模块901还用于通过以下方式实现采用异步方式执行目标任务，目标任务包括对第一参数进行深度复制处理，以及将请求文件存储至存储介质中：确定线程池中的当前工作线程数和核心线程数；响应于当前工作线程数小于核心线程数，创建目标核心线程，以执行目标任务；响应于当前工作线程数大于核心线程数，且线程池的阻塞队列中任务数量小于队列阈值，将目标任务添加至阻塞队列中，以等待线程池中的空闲核心线程执行；响应于当前工作线程数等于核心线程数，且阻塞队列中任务数量大于或等于队列阈值，确定线程池中的当前线程数是否小于线程池的最大线程数；响应于当前线程数小于最大线程数，创建目标非核心线程，以执行目标任务。

可选地，执行模块901还用于在执行流量回放流程的过程中，接收来自发布系统的用于确认业务系统是否预热完成的检验信息；响应于业务系统预热完成，向发布系统发送用于表示业务系统预热完成的反馈信息，以指示发布系统生成上线指令；接收上线指令；向业务系统发送上线指令，以指示业务系统执行服务上线操作。

示例性计算设备

在介绍了本公开示例性实施方式的方法、介质和装置之后，接下来，参考图10对本公开示例性实施方式的计算设备进行说明。

图10显示的计算设备1000仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，计算设备1000以通用计算设备的形式表现。计算设备1000的组件可以包括但不限于：至少一个处理单元1001、至少一个存储单元1002，连接不同系统组件(包括处理单元1001和存储单元1002)的总线1003。其中，至少一个存储单元1002中存储有计算机执行指令；至少一个处理单元1001包括处理器，处理器执行该计算机执行指令，以实现上文描述的方法。

总线1003包括数据总线、控制总线和地址总线。

存储单元1002可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1021和/或高速缓存存储器1022，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(ROM)1023。

存储单元1002还可以包括具有一组(至少一个)程序模块1024的程序/实用工具1025，这样的程序模块1024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算设备1000也可以与一个或多个外部设备1004(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(I/O)接口1005进行。并且，计算设备1000还可以通过网络适配器1006与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图10所示，网络适配器1006通过总线1003与计算设备1000的其它模块通信。应当理解，尽管图中未示出，可以结合计算设备1000使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了业务系统的抖动的处理装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种业务系统的抖动的处理方法，包括：

响应业务系统启动，执行以下流量回放流程：

从存储介质中读取目标请求，所述目标请求是对业务请求进行序列化处理得到的，所述业务请求是在业务系统正常运行过程中采集到的；

对所述目标请求进行反序列化处理，得到所述业务请求对应的虚拟请求；

根据所述虚拟请求对所述业务系统进行预热处理。

2.根据权利要求1所述的处理方法，所述对所述目标请求进行反序列化处理，得到所述业务请求对应的虚拟请求，包括：

对所述目标请求进行反序列化处理，得到请求对象；

在所述请求对象中添加预设参数，得到所述虚拟请求。

3.根据权利要求1所述的处理方法，所述根据所述虚拟请求对所述业务系统进行预热处理，包括：

向所述业务系统发送所述虚拟请求，所述虚拟请求中包括用于指示预热处理的预热标志位，所述预热标志位用于指示所述业务系统进行预热处理。

4.根据权利要求3所述的处理方法，所述预热标志位还用于指示所述业务系统将上下文中的预设标志位对应的参数修改为预设参数。

5.根据权利要求1至4任一项所述的处理方法，所述业务请求是通过以下方式采集到的：

在业务系统正常运行过程中，采用面向切面编程方法确定所述业务请求对应的业务是否执行完成；

响应于所述业务执行完成，采用所述面向切面编程方法确定是否获取到所述业务的预期结果数据；

响应于获取到所述预期结果数据，检测所述业务系统中是否存在用于指示采集所述业务请求的标识信息；

响应于检测到所述标识信息，采集所述业务请求。

6.根据权利要求5所述的处理方法，还包括：

确定所述业务请求的个数；

响应于所述业务请求的个数大于或等于预设值，取消对所述业务请求的采集操作。

7.根据权利要求5所述的处理方法，所述目标请求是通过以下方式对业务请求进行序列化处理得到：

对所述业务请求进行参数选择处理，得到第一参数；

基于JSON方案，采用异步方式对所述第一参数进行深度复制处理，得到第二参数；

对所述第二参数进行序列化处理，得到所述目标请求。

8.一种介质，所述介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至7任一项所述的业务系统的抖动的处理方法。

9.一种业务系统的抖动的处理装置，包括：

执行模块，用于响应业务系统启动，执行以下流量回放流程：

从存储介质中读取目标请求，所述目标请求是对业务请求进行序列化处理得到的，所述业务请求是在业务系统正常运行过程中采集到的；

对所述目标请求进行反序列化处理，得到所述业务请求对应的虚拟请求；

根据所述虚拟请求对所述业务系统进行预热处理。

10.一种计算设备，包括：处理器，以及与所述处理器连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至7任一项所述的业务系统的抖动的处理方法。

Images