CN111045932A

CN111045932A - 业务系统仿真处理方法、装置、电子设备及存储介质

Info

Publication number: CN111045932A
Application number: CN201911167615.2A
Authority: CN
Inventors: 吴航
Original assignee: Hangzhou Netease Zaigu Technology Co Ltd
Current assignee: Hangzhou Netease Zaigu Technology Co Ltd
Priority date: 2019-11-25
Filing date: 2019-11-25
Publication date: 2020-04-21
Anticipated expiration: 2039-11-25
Also published as: CN111045932B

Abstract

本申请涉及仿真测试技术领域，公开了一种业务系统仿真处理方法、装置、电子设备及存储介质，所述方法包括：获取针对业务系统的仿真任务，仿真任务包括至少一个事件类型；为至少一个事件类型中的每个事件类型生产至少一个事件，并确定每个事件的触发时间；按照触发时间的先后顺序，依次将生产的事件输入业务系统，以对业务系统进行仿真处理。本申请实施例提供的业务系统仿真处理方法、装置、电子设备及存储介质，使得测试人员可以直接对已开发的业务系统进行仿真，而不再需要对业务系统进行二次编程建模，降低了对测试人员的能力要求，提高了仿真效率，同时避免了二次编程建模可能引入的错误。

Description

业务系统仿真处理方法、装置、电子设备及存储介质

技术领域

本申请涉及仿真测试技术领域，尤其涉及一种业务系统仿真处理方法、装置、电子设备及存储介质。

背景技术

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

在优化系统策略及算法过程中，存在无法拆分出流量进行A/B测试或影响周期长导致A/B测试无法短时间快速得出评估结果等情况，因此需要模拟线上真实环境，来测试评估系统策略及算法。通常的做法是，使用专业的供应链仿真建模软件，根据业务系统内在的业务逻辑和算法，编写业务系统对应的程序进行建模及仿真。该方法需要测试人员学习建模软件的使用，并按现有业务逻辑重新编写一套独立的模型程序，这无疑增加了测试人员的工作量，建模仿真效率低。

发明内容

针对上述技术问题，非常需要一种改进的方法，以降低了对测试人员的工作量，提高了仿真效率。

一方面，本申请一实施例提供了一种业务系统仿真处理方法，包括：

获取针对业务系统的仿真任务，所述仿真任务包括至少一个事件类型；

为所述至少一个事件类型中的每个事件类型生产至少一个事件，并确定每个事件的触发时间；

按照触发时间的先后顺序，依次将生产的事件输入所述业务系统，以对所述业务系统进行仿真处理。

一方面，本申请一实施例提供了一种业务系统仿真处理装置，包括：

任务获取模块，用于获取针对业务系统的仿真任务，所述仿真任务包括至少一个事件类型；

事件生成模块，用于为所述至少一个事件类型中的每个事件类型生产至少一个事件，并确定每个事件的触发时间；

事件输入模块，用于按照触发时间的先后顺序，依次将生产的事件输入所述业务系统，以对所述业务系统进行仿真处理。

可选地，所述事件输入模块，具体用于根据预先为所述事件对应的事件类型配置的消费逻辑，将所述事件输入对应的业务系统，所述消费逻辑包括事件类型对应的业务系统。

可选地，所述事件生成模块，具体用于：

针对每个事件类型，从历史触发事件数据库中获取所述事件类型对应的历史触发事件，将获取的历史触发事件确定为所述事件类型的事件，并将获取的历史触发事件的发生时间确定为对应的事件的触发时间；或

针对每个事件类型，根据所述事件类型对应的预设生成参数，为所述事件类型生产预设数量个事件以及每个事件的触发时间，所述预设生成参数包括预设数量参数和触发时间参数。

可选地，所述事件生成模块，具体用于：

针对每个事件类型，通过为所述事件类型分配的处理线程为所述事件类型生产至少一个事件，并确定每个事件的触发时间，每个事件类型的处理线程并行执行。

可选地，所述事件生成模块，还用于：

针对每个事件类型对应的处理线程，若所述处理线程生产了新的事件，则将所述新的事件添加到所述事件类型对应的优先阻塞队列中；

所述事件生成模块，具体用于：

从每个优先阻塞队列中获取触发时间最早的事件，确定为候选事件；

将所述候选事件中触发时间最早的事件输入所述业务系统；

删除优先阻塞队列中已输入所述业务系统的事件。

可选地，所述事件生成模块，还用于：从每个优先阻塞队列中获取触发时间最早的事件之前，确认每个优先阻塞队列中均存在事件，或者所有不存在事件的优先阻塞队列对应的处理线程已结束生产事件。

可选地，所述装置还包括初始化模块，用于：在所述任务获取模块执行之后，所述事件生成模块执行之前，获取所述仿真任务对应的业务系统配置信息，向所述业务系统发送仿真任务初始化请求，所述仿真任务初始化请求中包括所述业务系统配置信息，以使所述业务系统根据所述业务系统配置信息进行系统初始化。

一方面，本申请一实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行计算机程序时实现上述任一种方法的步骤。

一方面，本申请一实施例提供了一种计算机可读存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述任一种方法的步骤。

一方面，本申请一实施例提供了一种计算机程序产品，所述计算机程序产品包括存储在计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，所述程序指令被处理器执行时实现上述任一种方法的步骤。

本申请实施例提供的业务系统仿真处理方法、装置、电子设备及存储介质，使得测试人员可以直接对已开发的业务系统进行仿真，而不再需要对业务系统进行二次编程建模，降低了对测试人员的能力要求，提高了仿真效率，同时避免了二次编程建模可能引入的错误。此外，测试人员也无需关注业务系统内部的业务逻辑，而只需要关注输入业务系统的事件，因此，上述业务系统仿真处理方法可应用于各类仿真场景，可扩展性高。

附图说明

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

图1为本申请实施例提供的业务系统仿真处理方法的应用场景示意图；

图2为本申请一实施例提供的业务系统仿真处理方法的流程示意图；

图3为本申请一实施例提供的业务系统仿真处理方法的流程示意图；

图4为本申请一实施例提供的生产事件和消费事件的流程示意图；

图5为本申请一实施例提供的生产事件和消费事件的流程示意图；

图6为电商仓配业务的系统架构及业务逻辑的示意图；

图7为本申请一实施例提供的业务系统仿真处理装置的结构示意图；

图8为本申请一实施例提供的电子设备的结构示意图。

具体实施方式

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

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

在本文中，需要理解的是，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

为了方便理解，下面对本申请实施例中涉及的名词进行解释：

事件(Event)，是对用户或系统操作的描述，即软件系统的输入。触发事件的对象称为事件发送者，接收事件的对象称为事件接收者。

终端设备，可以安装各类应用，并且能够将已安装的应用中提供的对象进行显示的设备，该电子设备可以是移动的，也可以是固定的。例如，手机、平板电脑、各类可穿戴设备、车载设备、个人数字助理(personal digital assistant，PDA)、销售终端(point ofsales，POS)或其它能够实现上述功能的电子设备等。

应用，即应用程序，可以完成某项或多项业务的计算机程序，一般具有可视的显示界面，能与用户进行交互，比如电子地图和浏览器等都可以称为应用。

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

发明概述

本申请的发明人发现，当使用专业的供应链仿真建模软件对业务系统进行仿真处理时，需要根据业务系统内在的业务逻辑和算法，重新编写一套业务系统对应的模型程序，才能进行建模及仿真，且由于建模软件与业务系统使用的编程语言不同，测试人员还需要学习建模软件的使用，这无疑增加了测试人员的工作量，建模仿真效率低。而当业务逻辑较为复杂时，很难保证模型程序和业务系统之间的一致性，继而影响仿真结果的真实性。此外，一旦业务系统发生更改，则需要测试人员手动修改模型程序，操作过程复杂且容易出错，模型程序和业务系统之间难以保持同步更新，进一步降低了仿真效率。

为了解决上述问题，本申请实施例提供了一种业务系统仿真处理方法，具体包括：获取针对业务系统的仿真任务，仿真任务包括至少一个事件类型；为至少一个事件类型中的每个事件类型生产至少一个事件，并确定每个事件的触发时间；按照触发时间的先后顺序，依次将生产的事件输入业务系统，以对业务系统进行仿真处理。因此，上述基于事件驱动的业务系统仿真处理方法，使得测试人员可以直接对已开发的业务系统进行仿真，而不再需要对业务系统进行二次编程建模，降低了对测试人员的能力要求，提高了仿真效率，同时避免了二次编程建模可能引入的错误。此外，测试人员也无需关注业务系统内部的业务逻辑，而只需要关注输入业务系统的事件，因此，上述业务系统仿真处理方法可应用于各类仿真场景，可扩展性高。

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

应用场景总览

参考图1，其为本申请实施例提供的业务系统仿真处理方法的应用场景示意图。该应用场景包括仿真终端101、仿真服务器102和业务服务器103。其中，仿真终端101和仿真服务器102之间通过通信网络连接，仿真服务器102和业务服务器103之间通过通信网络连接。仿真终端101包括但不限于桌面计算机、移动电脑、平板电脑电子设备。仿真服务器102和业务服务器103均可以是一台服务器、若干台服务器组成的服务器集群或云计算中心。当然，图1所示的仿真服务器102和业务服务器103也可以布设在同一个服务器或服务器集群中。

仿真终端101安装有配置仿真任务以及登录仿真服务器102的仿真应用，测试人员可通过仿真终端101内的仿真应用配置业务系统对应的仿真任务，或者测试人员也可以通过仿真终端101安装的浏览器登录仿真服务器102，完成仿真任务的配置，然后，仿真终端101将配置好的仿真任务发送给仿真服务器102。仿真服务器102根据仿真任务中的事件类型生产事件，并确定每个事件的触发时间，按照触发时间的先后顺序，依次将生产的事件发送给业务服务器103。业务服务器103为运行业务系统的设备，业务服务器103接收仿真服务器102发送的事件，并输入对应的业务系统，以驱动业务系统处理输入的事件，实现对业务系统的仿真处理。

进一步地，业务服务器103还可以在仿真过程中采集业务系统产生的相关数据，并反馈给仿真服务器102。仿真服务器102根据业务服务器103采集的相关数据得到仿真结果，用以评估业务系统当前采用的策略及算法。

示例性方法

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

参考图2，本申请实施例提供了的一种业务系统仿真处理方法，可应用于图1所示的仿真服务器，具体可包括以下步骤：

S201、获取针对业务系统的仿真任务，仿真任务包括至少一个事件类型。

本申请实施例中，事件类型可根据具体的业务系统确定，此处不作限定。例如，当业务系统为订单处理系统时，对应的事件类型可以是下单类事件、订单查询类事件、退单类事件等，这类事件可以触发订单处理系统进行下单、查询、退单等处理；当业务系统为库存管理系统时，对应的事件类型可以是入库类事件、出库类事件等，这类事件可以触发库存管理系统对仓库中的物品进行库存管理；当业务系统为采购系统时，对应的事件类型可以是采购类事件，这类事件可触发采购系统查询库存管理系统中物品的库存，并根据库存确定是否需要采购。

具体实施时，测试人员可根据本次仿真任务所针对的业务系统，配置一个或多个事件类型。例如，需要针对订单处理系统进行仿真时，可配置下单类事件、订单查询类事件、退单类事件等多个事件类型。

具体实施时，除了事件类型，测试人员可以在仿真任务中选择性的配置如下内容：仿真任务编号、任务名称、仿真起始时间、仿真终止时间、仿真时长、业务系统配置列表、业务场景、统计指标列表、仿真任务状态等，以方便测试人员对大量仿真任务进行管理。

S202、为至少一个事件类型中的每个事件类型生产至少一个事件，并确定每个事件的触发时间。

本申请实施例中，触发时间是指在真实环境中事件输入业务系统的时间。具体实施时，触发时间可以根据事件生产的时间确定，也可以随机生成，或根据生成的事件携带的时间参数确定。

具体实施时，针对仿真任务中的每一事件类型，生产该事件类型对应的事件，并确定每个事件的触发时间。

S203、按照触发时间的先后顺序，依次将生产的事件输入业务系统，以对业务系统进行仿真处理。

需要说明的是，可在步骤S202完全结束后，再开始执行步骤S203，即在为本次仿真任务中所有的事件类型生产完事件后，在按照触发时间的先后顺序，依次将每个事件输入业务系统。或者，上述步骤S202和S203也可并行执行，即一边生产事件(对应步骤S202)，一边消费事件(对应步骤S203)，以提高仿真处理效率。

当一次仿真任务需要同时对多个业务系统进行仿真处理时，仿真任务中还包括每个事件类型对应的消费逻辑，该消费逻辑包括事件类型对应的业务系统。为此，步骤S203中，将生产的事件输入业务系统，具体包括：根据预先为事件对应的事件类型配置的消费逻辑，将事件输入对应的业务系统，消费逻辑包括事件类型对应的业务系统。

以图4为例，仿真任务包括针对业务系统1的事件类型1、针对业务系统2的事件类型2和事件类型3，此时，为事件类型1生产的事件包括事件E1_1、事件E1_2和事件E1_3，为事件类型2生产的事件包括事件E2_1、事件E2_2和事件E2_3，为事件类型3生产的事件包括事件E3_1和事件E3_2。根据各事件的触发时间的先后顺序，先将事件E3_1输入对应的业务系统2，然后将事件E1_1输入对应的业务系统1，依次类推，直至针对本次仿真任务产生的所有事件均已消费完毕。

本申请实施例的业务系统仿真处理方法，基于为仿真任务配置的事件类型自动批量生产相应的事件，并按照每个事件对应的触发时间的先后顺序，依次将事件输入业务系统，从而模拟真实环境中事件输入业务系统的情形，以对业务系统进行仿真处理。这使得测试人员可以直接对已开发的业务系统进行仿真，而不再需要对业务系统进行二次编程建模，降低了对测试人员的能力要求，提高了仿真效率，同时避免了二次编程建模可能引入的错误。其次，测试人员也无需关注业务系统内部的业务逻辑，而只需要关注输入业务系统的事件，因此，上述业务系统仿真处理方法可应用于各类仿真场景，可扩展性高。此外，基于事件的触发事件的先后顺序，对事件输入业务系统的时机进行时序控制，可实现全业务链路的仿真，从而反映多个业务系统间相互影响的结果，便于更真实地模拟全链路多系统影响下业务系统的真实状况。

在一种可能的实施方式中，步骤S202具体包括：针对每个事件类型，从历史触发事件数据库中获取事件类型对应的历史触发事件，将获取的历史触发事件确定为事件类型的事件，并将获取的历史触发事件的发生时间确定为对应的事件的触发时间。

本申请实施例中，历史触发事件数据库可以是本次仿真任务所针对的业务系统的历史数据库，该历史数据库中存储有该业务系统运行过程中实际输入该业务系统的历史触发事件。历史触发事件数据库也可以是专门用于存储各种事件类型对应的大量事件的数据库，可从相关的业务系统中获取各种事件类型的真实事件，并进行数据清洗、过滤、整理后作为历史触发事件存入历史触发事件数据库。

本申请实施例中，历史触发事件数据库中的每一个历史触发事件包括该历史触发事件实际输入业务系统的时间，即发生时间。

具体实施时，针对每个事件类型，可从历史触发事件数据库中随机获取一定数量的该事件类型对应的历史触发事件，作为为该事件类型生产的事件，并将获取的历史触发事件的发生时间确定为对应的事件的触发时间。其中，测试人员可预先在仿真任务中配置本次仿真任务中针对每一事件类型所需获取的历史触发事件的数量。

具体实施时，针对每个事件类型，还可根据仿真任务中配置的仿真起始时间和仿真终止时间，从历史触发事件数据库中获取发生时间在仿真起始时间和仿真终止时间之间的该事件类型对应的历史触发事件，作为为该事件类型生产的事件，并将获取的历史触发事件的发生时间确定为对应的事件的触发时间。

举例说明，假设事件类型为下单类事件，订单仿真起始时间为11月11日0点，仿真终止时间为11月11日24点，则从历史触发事件数据库中获取11月11日0点至11月11日24点的下单类事件，作为为下单类事件生产的事件。

上述实施方式中，获取真实的历史触发事件作为仿真任务中事件类型对应的事件，使得仿真过程中产生的事件更加符合真实的业务环境，提高了仿真环境的真实性。

在另一种可能的实施方式中，步骤S202具体包括：针对每个事件类型，根据事件类型对应的预设生成参数，为事件类型生产预设数量个事件以及每个事件的触发时间，预设生成参数包括预设数量参数和触发时间参数。

具体实施时，测试人员可预先在仿真任务中配置每个事件类型对应的预设生成参数。其中，预设数量参数是指本次仿真任务中需要为该事件类型生产的事件的数量。具体地，可根据触发时间参数，确定生产的每个事件对应的触发时间。

具体实施时，触发时间参数可以是为同一事件类型生产的两个相邻事件的触发时间之间的时间间隔。例如，某一事件类型对应的预设事件数量参数为100，时间间隔为10秒，则为该事件类型生成100个事件E₁、E₂、…E₁₀₀，相邻的E₁和E₂的触发时间相差10秒，E₂和E₃的触发时间相差10秒，以此类推。

具体实施时，测试人员可以不设置预设数量参数，此时，仿真服务器可根据仿真任务中的仿真时长和触发时间参数，确定每个事件的触发时间。例如，某一事件类型对应的仿真时长为1小时，触发时间参数为10秒，则总共需要为该事件类型生产360个事件，且相邻两个事件的时间间隔为10秒。

需要说明的是，根据触发时间参数生成的触发时间只是一个虚拟的时间，主要用以确定各个事件输入对应的业务系统的先后顺序。例如，根据触发时间参数生成的触发时间可以是相对仿真任务开始的时间，假设仿真任务开始时的时间为0，针对某一事件类型的触发时间参数为间隔10秒，则为该事件类型生产的第一个事件的触发时间为0:0:10，表示仿真任务开始后的10秒，第二个事件的触发时间为0:0:20，表示仿真任务开始后的20秒。

具体实施时，触发时间参数还可以是一类随机函数，以随机生成两个相邻事件的触发时间之间的时间间隔，可规定随机函数生成的时间间隔的范围，如(0,100s]，表示随机函数生成的时间间隔大于0且不大于100秒。例如，针对某一事件类型，随机函数依次生成1、5、2、10等时间间隔，则为该事件类型生产的第一个事件的触发时间为0:0:01，表示仿真任务开始后的1秒，第二个事件的触发时间为0:0:06，表示第一事件的触发时间之后的5秒，第二个事件的触发时间为0:0:08，表示第一事件的触发时间之后的2秒，以此类推。

具体实施时，测试人员可预先确定每种事件类型对应的事件模板，该事件模板包括至少一个事件参数，每个事件参数对应多个可选的参数值。针对每个事件类型，仿真服务器可获取该事件类型对应的事件模板，针对事件模板中的每个事件参数，从该事件参数对应的多个可选的参数值中随机选取一个参数值，得到该事件类型对应的一个事件。

例如，下单类事件对应的事件模板中的事件参数可以是用户ID、商品ID、商品数量等，用户ID可对应多个可选的参数值，如用户ID_123、用户ID_qwe、用户ID_A、用户ID_88XX等，商品ID同样也对应多个可选的参数值，如商品1、商品2、商品3等，商品数量可以是1至100的随机数。基于上述事件模板中各种参数值的组合，可生成事件1{用户ID＝用户ID_123，商品ID＝商品2，商品数量＝2}、事件2{用户ID＝用户ID_88XX，商品ID＝商品1，商品数量＝1}等。

上述实施方式中，测试人员可通过为每个事件类型配置预设生成参数，来控制仿真服务器生产出符合仿真要求的事件，以模拟出各种事件输入数量和各种事件输入频率对应的仿真环境，得到不同仿真环境下业务系统的评估结果。

在上述任一实施方式的基础上，为了提高事件的生产效率，仿真服务器可为仿真任务中的每个事件类型单独创建一个处理线程，每个处理线程用于为对应的事件类型生产事件以及确定生产的每个事件的触发时间。创建的多个处理线程可并行执行，以提高事件的生产效率。

在此基础上，步骤S202具体包括：针对每个事件类型，通过为事件类型分配的处理线程为事件类型生产至少一个事件，并确定每个事件的触发时间，每个事件类型的处理线程并行执行。

进一步地，仿真服务器可为每个事件类型创建对应的优先阻塞队列，该优先阻塞队列用于缓存为每个事件类型生产的事件，以平衡事件生产和事件消费之间速率不匹配的问题，同时承担对同一事件类型的事件按触发时间进行排序的作用。

在此基础上，本申请实施例的业务系统仿真处理方法还包括如下步骤：针对每个事件类型对应的处理线程，若处理线程生产了新的事件，则将新的事件添加到事件类型对应的优先阻塞队列中。相应地，步骤S203具体包括如下步骤：从每个优先阻塞队列中获取触发时间最早的事件，确定为候选事件；将候选事件中触发时间最早的事件输入业务系统；删除优先阻塞队列中已输入业务系统的事件。

相应地，参考图3，本申请实施例还提供了一种业务系统仿真处理方法，具体包括如下步骤：

S301、获取针对业务系统的仿真任务，仿真任务包括至少一个事件类型。

S302、针对每个事件类型，通过为事件类型分配的处理线程为事件类型生产至少一个事件，并确定每个事件的触发时间。

S303、针对每个事件类型对应的处理线程，若处理线程生产了新的事件，则将新的事件添加到事件类型对应的优先阻塞队列中。

S304、从每个优先阻塞队列中获取触发时间最早的事件，确定为候选事件。

S305、将候选事件中触发时间最早的事件输入业务系统。

S306、删除优先阻塞队列中已输入业务系统的事件。

其中，步骤S302、S303和S304可并行执行，即处理线程每生产出一个事件，即将该事件添加到对应的优先阻塞队列中，与此同时，从每个优先阻塞队列中获取触发时间最早的事件确定为候选事件，将候选事件中触发时间最早的事件输入业务系统。这样一边生产事件一边消费事件，可提高仿真处理效率。

以图4为例，仿真任务包括针对业务系统1的事件类型1、针对业务系统2的事件类型2和事件类型3，为每个事件类型分别创建对应的处理线程和优先阻塞队列。三个处理线程并行执行，分别为每个事件类型生产对应的事件，并存储到对应的优先阻塞队列中，每个优先阻塞队列按照触发时间的先后顺序，对优先阻塞队列中的事件进行排序。需要说明的是，处理线程每生产出一个事件，即将该事件存储到对应的优先阻塞队列中，此时，优先阻塞队列需要基于新存入的事件的触发时间，对优先阻塞队列中的事件进行重新排序。事件消费线程用于执行步骤S304、S305和S305，在处理线程运行过程的同时，事件消费线程分别从优先阻塞队列1、优先阻塞队列2和优先阻塞队列3中获取触发时间最早的事件E1_1、事件E2_1和事件E3_1，即获取各优先阻塞队列中位于队首的事件，然后从事件E1_1、事件E2_1和事件E3_1中选出触发时间最早的事件E3_1，将事件E3_1发送给对应的业务系统2，并删除优先阻塞队列3中的事件E3_1，随后事件消费线程继续获取各优先阻塞队列中位于队首的事件进行处理。

实际应用中，由于每个处理线程生产事件的速率不同，可能存在优先阻塞队列中的事件已经消费完，但是对应的处理线程还没有生产出新的事件的情况，此时，如果依然执行步骤S304，有可能导致无法选出所有事件类型中触发时间最早的事件。以图5为例，优先阻塞队列3中不存在事件且该处理线程3还在继续生产新的事件，有可能处理线程3产生的下一个事件的触发时间要早于事件E1_1。

为此，在步骤S304之前，本申请实施例的业务系统仿真处理方法还包括如下步骤：确认每个优先阻塞队列中均存在事件，或者所有不存在事件的优先阻塞队列对应的处理线程已结束生产事件。

具体实施时，事件消费线程在每一次消费优先阻塞队列中的事件时，若确认每个优先阻塞队列中均存在事件或所有不存在事件的优先阻塞队列对应的处理线程已结束生产事件，则执行步骤S304、S305和S305；若确认某一优先阻塞队列中不存在事件、且该优先阻塞队列对应的处理线程未结束生产事件，则等待该处理线程生成出至少一个事件并存入该优先阻塞队列后，再执行步骤S304、S305和S305。

在上述任一实施方式的基础上，在步骤S201和步骤S202之间，或在步骤S201和步骤S202之间，本申请实施例提供的业务系统仿真处理方法还包括如下步骤：获取仿真任务对应的业务系统配置信息，向业务系统发送仿真任务初始化请求，仿真任务初始化请求中包括业务系统配置信息，以使业务系统根据业务系统配置信息进行系统初始化。其中，每个业务系统对应的业务系统配置信息存储在业务系统配置列表中。

具体实施时，参与仿真任务的每个业务系统完成系统初始化之后，可向仿真服务器反馈完成初始化的消息，仿真服务器在收到参与仿真任务的所有业务系统反馈的完成初始化的消息后，即可开始生产事件并消费事件。

具体实施时，仿真任务初始化请求中还包括仿真任务编号和统计指标列表，其中，仿真任务编号用于在后续统计分析过程中区分不同的仿真任务，统计指标列表包括在执行本次仿真任务过程中需要业务系统采集并返回的指标对应的数据。具体的指标可根据仿真任务和业务系统确定，本申请实施例不作限定。以电商仓配业务为例，指标可以是：总成本(配送成本+仓储成本+调拨成本)、配送时效、拆单率、仓库分单比等。

在仿真任务中所有事件类型对应的事件均生产并消费完后，仿真服务器可向各业务系统发送仿真任务结束通知，该仿真任务结束通知包括本次仿真任务对应的仿真任务编号。各业务系统返回采集的指标对应的数据。然后，仿真服务器可对各业务系统返回的指标数据进行分析，得到仿真结果，以对业务系统进行评估。

为此，测试人员可在每次仿真任务之前，选择本次需要测试的业务系统配置信息，基于各业务系统配置信息的仿真结果，选择出最优的业务系统配置信息。以电商仓配业务为例，选择发货仓配的策略优化为以用户体验为主(选择送达最快的仓库快递，选择整单有货的一个仓库发货)，必然会导致配送时效及拆单率的优化，但会导致总成本的增加。根据仿真结果，综合评估被优化的指标是否达到要求，被劣化的指标是否在可接受范围内，以此来评估优化策略的好坏及是否可施行。

下面以电商仓配业务为例，对整个业务系统仿真处理方法进行说明。

参考图6，为电商仓配业务的系统架构及业务逻辑的示意图。其中，涉及的业务系统包括：发货仓配系统、出入库系统、库存调拨系统、库存管理系统、采购系统、配送系统、费用配置系统和配送波次系统。系统业务操作包括：用户下单操作、调拨计算操作、采购操作和业务人工干预操作，这些操作即为输入业务系统的事件。业务系统逻辑策略包括：选择发货仓配策略、库存调拨策略、采购入库策略。业务配置包括：运费配置、配送波次。其中，业务系统逻辑策略和业务配置可作为业务系统配置信息，由测试人员预先设置好。

实际应用中，系统业务操作、业务系统逻辑策略、业务配置之间相互影响，任一方面的变化都可能会引起连锁反应，对电商仓配业务造成难以估量的影响。例如，若改用更积极的库存调拨策略，则可维持库存的平衡，若发货仓配策略为有库存下运费最低仓，则会使得更多订单就近发货，运费成本减少。然而由于仓库间调拨量大，使用大车及大件物流，运输相对于配送快递慢，因此调拨运输时间加上配送时间，用户下单到收获的时间反而延长。这种情况下就需要仿真，进行全面的评估及权衡。

明确了仿真目的后，下面进行仿真前的部署工作：

第一步、将图6中涉及的多个业务系统，单独部署到业务服务器中。

第二步、在每个业务系统中，按定义规范实现仿真任务起始通知接口和仿真任务结束通知接口。仿真任务起始通知接口用于接收仿真任务初始化请求，以完成系统初始化，例如配置库存调拨策略、调整运费配置等，以及结束仿真任务。仿真任务结束通知接口用于接收仿真任务结束通知，以结束仿真任务。

第三步、将现实中驱动整个电商仓配业务链路运行的每类操作，定义为一类事件，共4类事件：用户下单类事件、调拨计算类事件、采购类事件、业务人工干预类事件。按照定义实现每类事件的事件生产接口以及事件消费接口。

例如，针对用户下单事件，事件生产接口中通过根据仿真起始时间和仿真终止时间获取历史真实订单，或基于未来的销量预测构造订单产生事件。事件消费接口中根据事件中的订单信息构造下单请求，并发送给发货仓配系统。

完成部署工作后即可对业务系统进行仿真，具体过程如下：

第一步、终端设备按照仿真任务定义向仿真服务器发送一个仿真任务。

第二步、仿真服务器根据仿真任务，调用各个业务系统的仿真任务起始通知接口，各系统收到的仿真任务初始化请求进行系统初始化。

例如：库存管理系统中库存设置为模拟起始时间库存，库存调拨系统选用指定调拨算法、费用配置系统中设置运费报价等。

第三步、仿真服务器获取本次仿真任务所需的全部4种事件类型：用户下单类事件、调拨计算类事件、采购类事件、业务人工干预类事件。

第四步、仿真服务器根据本次仿真任务所需的事件类型，为每个事件类型分配处理线程，并通过为事件类型分配的处理线程为事件类型生产至少一个事件，并确定每个事件的触发时间。

第五步、针对每个事件类型对应的处理线程，仿真服务器将处理线程生产的新的事件添加到事件类型对应的优先阻塞队列中。

第六步、仿真服务器从每个优先阻塞队列中获取触发时间最早的事件，确定为候选事件，将候选事件中触发时间最早的事件输入业务系统，并删除优先阻塞队列中已输入业务系统的事件；当某一优先阻塞队列为空且对应的处理线程未结束生产事件时，仿真服务器等待该处理线程生产出事件后，再确定为候选事件。

第七步、若所有事件类型的优先阻塞队列均为空、且所有处理线程均已结束生产事件，则仿真任务结束，仿真服务器可向各业务系统发送仿真任务结束通知。

第八步、各业务系统返回采集的指标对应的数据。

第九步、仿真服务器对各业务系统返回的指标数据进行分析，得到仿真结果。

示例性设备

在介绍了本申请示例性实施方式的方法之后，接下来对本申请示例性实施方式的业务系统仿真处理装置进行介绍。

如图7所示，为本申请实施例提供的业务系统仿真处理装置的结构示意图。在一个实施例中，业务系统仿真处理装置包括：任务获取模块701、事件生成模块702和事件输入模块703。

任务获取模块701，用于获取针对业务系统的仿真任务，仿真任务包括至少一个事件类型。

事件生成模块702，用于为至少一个事件类型中的每个事件类型生产至少一个事件，并确定每个事件的触发时间。

事件输入模块703，用于按照触发时间的先后顺序，依次将生产的事件输入业务系统，以对业务系统进行仿真处理。

可选地，事件输入模块703，具体用于根据预先为事件对应的事件类型配置的消费逻辑，将事件输入对应的业务系统，消费逻辑包括事件类型对应的业务系统。

可选地，事件生成模块702，具体用于：针对每个事件类型，从历史触发事件数据库中获取事件类型对应的历史触发事件，将获取的历史触发事件确定为事件类型的事件，并将获取的历史触发事件的发生时间确定为对应的事件的触发时间；或针对每个事件类型，根据事件类型对应的预设生成参数，为事件类型生产预设数量个事件以及每个事件的触发时间，预设生成参数包括预设数量参数和触发时间参数。

可选地，事件生成模块702，具体用于：针对每个事件类型，通过为事件类型分配的处理线程为事件类型生产至少一个事件，并确定每个事件的触发时间，每个事件类型的处理线程并行执行。

可选地，事件生成模块702，还用于：针对每个事件类型对应的处理线程，若处理线程生产了新的事件，则将新的事件添加到事件类型对应的优先阻塞队列中。

相应地，事件生成模块702，具体用于：从每个优先阻塞队列中获取触发时间最早的事件，确定为候选事件；将候选事件中触发时间最早的事件输入业务系统；删除优先阻塞队列中已输入业务系统的事件。

可选地，事件生成模块702，还用于：从每个优先阻塞队列中获取触发时间最早的事件之前，确认每个优先阻塞队列中均存在事件，或者所有不存在事件的优先阻塞队列对应的处理线程已结束生产事件。

可选地，业务系统仿真处理装置还包括初始化模块，用于：在任务获取模块执行之后，事件生成模块执行之前，获取仿真任务对应的业务系统配置信息，向业务系统发送仿真任务初始化请求，仿真任务初始化请求中包括业务系统配置信息，以使业务系统根据业务系统配置信息进行系统初始化。

本申请实施例提供的业务系统仿真处理装置，与上述业务系统仿真处理方法采用了相同的发明构思，能够取得相同的有益效果，在此不再赘述。

基于与上述业务系统仿真处理方法相同的发明构思，本申请实施例还提供了一种电子设备，该电子设备具体可以为桌面计算机、便携式计算机、服务器等。如图8所示，该电子设备80可以包括处理器801和存储器802。

处理器801可以是通用处理器，例如中央处理器(CPU)、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器802作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random Access Memory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器802还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

示例性程序产品

本申请实施例提供了一种计算机可读存储介质，用于储存为上述电子设备所用的计算机程序指令，其包含用于执行上述业务系统仿真处理方法的程序。

上述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等。

在一些可能的实施方式中，本申请的各个方面还可以实现为一种计算机程序产品，其包括程序代码，当该计算机程序产品在服务器设备上运行时，该计算机程序产品用于使所述服务器设备执行本说明书上述“示例性方法”部分中描述的根据本申请各种示例性实施方式的业务系统仿真处理方法中的步骤。

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

根据本申请的实施方式的用于即时通信应用的计算机程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在服务器设备上运行。然而，本申请的程序产品不限于此，在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

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

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

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

Claims

1.一种业务系统仿真处理方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述将生产的事件输入所述业务系统，具体包括：

根据预先为所述事件对应的事件类型配置的消费逻辑，将所述事件输入对应的业务系统，所述消费逻辑包括事件类型对应的业务系统。

3.根据权利要求1或2所述的方法，其特征在于，所述为所述至少一个事件类型中的每个事件类型生产至少一个事件，并确定每个事件的触发时间，具体包括：

4.根据权利要求1或2所述的方法，其特征在于，所述为所述至少一个事件类型中的每个事件类型生产至少一个事件，并确定每个事件的触发时间，具体包括：

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

所述按照触发时间的先后顺序，依次将生产的事件输入所述业务系统，具体包括：

将所述候选事件中触发时间最早的事件输入所述业务系统；

删除优先阻塞队列中已输入所述业务系统的事件。

6.根据权利要求5所述的方法，其特征在于，所述从每个优先阻塞队列中获取触发时间最早的事件之前，所述方法还包括：

确认每个优先阻塞队列中均存在事件，或者所有不存在事件的优先阻塞队列对应的处理线程已结束生产事件。

7.根据权利要求1或2所述的方法，其特征在于，所述获取针对业务系统的仿真任务之后，所述为所述至少一个事件类型中的每个事件类型生产至少一个事件之前，所述方法还包括：

获取所述仿真任务对应的业务系统配置信息，向所述业务系统发送仿真任务初始化请求，所述仿真任务初始化请求中包括所述业务系统配置信息，以使所述业务系统根据所述业务系统配置信息进行系统初始化。

8.一种业务系统仿真处理装置，其特征在于，包括：

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序指令，其特征在于，该计算机程序指令被处理器执行时实现权利要求1至7任一项所述方法的步骤。