脚本调试方法、装置及计算机存储介质与流程

1.本申请涉及计算机技术领域，特别涉及一种脚本调试方法、装置及计算机存储介质。


背景技术：

2.脚本包括多个计算机可执行的命令，通过脚本执行引擎执行脚本，以实现脚本的功能。在脚本执行引擎执行脚本的过程中，通常还需对脚本进行调试，以定位脚本中的问题。
3.相关技术中，脚本执行引擎通常部署在容器中，且脚本执行引擎不具备调试功能，因此，为了实现对脚本进行调试，需要对于容器配置一个调试器。该调试器可以与容器之间进行通信。当调试器接收到客户端发送的调试指令时，基于调试指令中携带的目标脚本断点，向容器发送断点请求指令，该断点请求指令携带该目标脚本断点。当容器通过脚本执行引擎执行到该目标脚本断点所指示的位置处时，向调试器发送调试触发指令。当调试器接收到该调试触发指令时，如果确定当前满足断点调试条件，则进行脚本调试，并显示调试结果。如果确定当前不满足断点调试条件，调试器则向容器返回恢复执行命令。
4.在上述调试脚本的过程中，需要容器和调试器多次进行交互，如果容器和调试器没有位于同一网络环境，调试过程所需的时间较长，从而导致调试效率非常低。


技术实现要素：

5.本申请实施例提供了一种脚本调试方法、装置及计算机存储介质。所述技术方案如下：
6.一方面、提供了一种脚本调试方法，该方法应用于容器，所述容器中部署有脚本执行引擎和代理模块，所述容器中注册有一个或多个断点、以及断点触发配置信息，所述断点触发配置信息用于指示一个断点是否满足断点调试条件。在该方法中，通过所述脚本执行引擎执行脚本；在通过所述脚本执行引擎执行至所述一个或多个断点中的任一断点的情况下，调用所述代理模块基于所述断点触发配置信息对所述任一断点进行检测；在通过所述代理模块检测出所述任一断点不满足所述断点调试条件的情况下，通过所述脚本执行引擎继续执行所述脚本。
7.在本申请中，可以预先在容器中部署代理模块和脚本执行引擎，并注册断点触发配置信息，以便于后续由代理模块基于断点触发配置信息来判断断点是否满足断点调试条件，无需通过调试器来判断，不仅可以实现不支持调试功能的脚本执行引擎最终具有调试功能，还进一步减少了调试过程中调试器和容器之间的交互次数，进而提高脚本调试的效率。
8.可选地，所述调用所述代理模块基于所述断点触发配置信息对所述任一断点进行检测之后，还包括：在通过所述代理模块检测出所述任一断点满足所述断点调试条件的情况下，向调试器发送调试触发指令，用于指示所述调试器基于所述调试触发指令对所述任
一断点进行调试。
9.也即是，在容器通过脚本执行引擎执行脚本的过程中，只有在代理模块检测出断点满足断点调试条件时，容器才会和调试器交互，以触发调试器对该断点进行调试。在代理模块检测出断点不满足断点调试条件时，容器则无需和调试器交互，直接继续恢复脚本执行引擎继续执行脚本。
10.可选地，所述方法还包括：接收容器启动指令；加载所述代理模块和所述脚本执行引擎；
11.接收调试器发送的断点配置请求，所述断点配置请求携带所述一个或多个断点、以及所述断点触发配置信息；将所述一个或多个断点注册在所述脚本执行引擎中，将所述断点触发配置信息注册在所述代理模块中。
12.由于需要通过代理模块来替代相关技术中调试器来执行部分调试功能，如此，就需要预先在容器中注册用于调试的一些信息。这些信息包括待调试的一个或多个断点、以及断点触发配置信息。该断点触发配置信息用于指示一个断点是否满足断点调试条件。以便于后续容器在通过脚本执行引擎执行脚本时，可以减少和调试器进行交互的次数以完成高效的脚本调试过程。
13.可选地，所述断点触发配置信息包括多个关键信息和与所述多个关键信息中每个关键信息对应的类信息，每个断点关联有所述多个关键信息中的一个或多个关键信息；所述调用所述代理模块基于所述断点触发配置信息对所述任一断点进行检测，包括：从所述断点触发配置信息中确定所述任一断点关联的关键信息对应的类信息；从确定的类信息中获取所述任一断点对应的局部变量的值；如果所述局部变量的值与所述脚本执行引擎执行所述任一断点所需的值不一致，则检测出所述任一断点不满足所述断点调试条件。
14.相应地，所述从确定的类信息中获取所述任一断点对应的局部变量的值之后，还包括：如果所述局部变量的值与所述脚本执行引擎执行所述任一断点所需的值一致，则检测出所述任一断点满足所述断点调试条件。
15.在一种可能的实现方式中，代理模块可以通过上述方式实现对断点是否满足断点调试条件的判断，以减少容器和调试器之间交互的次数。
16.另一方面，提供了一种脚本调试装置，所述脚本调试装置的结构中包括处理器和存储器，所述存储器用于存储支持脚本调试装置用于实现上述提供的脚本调试方法的程序，以及存储用于实现上述提供的脚本调试方法所涉及的数据。所述处理器被配置为用于执行所述存储器中存储的程序。所述存储设备的操作装置还可以包括通信总线，该通信总线用于该处理器与存储器之间建立连接。
17.另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述提供的脚本调试方法。
18.另一方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述提供的脚本调试方法。
附图说明
19.图1是本申请实施例提供的一种脚本调试系统的架构示意图；
20.图2是本申请实施例提供的一种脚本调试方法流程图；
21.图3是本申请实施例提供的一种容器与调试器之间的交互示意图；
22.图4是本申请实施例提供的另一种脚本调试方法流程图；
23.图5是本申请实施例提供的一种脚本调试装置框图；
24.图6是本申请实施例提供的另一种脚本调试装置框图；
25.图7是本申请实施例提供的另一种计算机设备的结构示意图。
具体实施方式
26.为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
27.在对本申请实施例进行详细解释说明之前，先对本申请实施例的应用场景进行解释说明。
28.脚本是使用一种特定描述性语言，依据一定格式编写的可执行文件。脚本也被称为脚本语言(script languages,scripting programming languages,scripting languages等)。脚本是为了缩短传统的编写-编译-链接-运行(edit-compile-link-run)过程而创建的计算机编程语言。此命名起源于一个脚本“screenplay”，每次运行脚本都会使对话框逐字重复。早期的脚本经常被称为批处理语言或工作控制语言。一个脚本通常是解释运行而非编译。虽然许多脚本都超越了计算机简单任务自动化的领域，成熟到可以编写精巧的程序，但仍然还是被称为脚本。几乎所有计算机系统的各个层次都有一种脚本。包括操作系统层，如计算机游戏，网络应用程序，文字处理文档，网络软件等。在许多方面，高级编程语言和脚本之间互相交叉，二者之间没有明确的界限。一个脚本可以使得本来要用键盘进行的相互式操作自动化。一个脚本主要由原本需要在命令行输入的命令组成，或在一个文本编辑器中，用户可以使用脚本把一些常用的操作组合成一组序列。很多脚本实际上已经超过简单的用户命令序列的指令，还可以编写更复杂的程序。
29.脚本一般都有相应的脚本执行引擎来执行。脚本有很多类型，脚本执行引擎也有很多类型，不同类型的脚本需要不同类型的脚本执行引擎来执行。只有脚本的类型与脚本执行引擎的类型对应，才能正确执行脚本。
30.脚本执行引擎，就是一个计算机编程语言的解释器，它的功能是执行用户的程序文本(也即是脚本)，将它译成计算机能执行的机器代码，从而完成一系列的功能。
31.常用的脚本执行引擎大致可以分为以下三类：
32.一类是将脚本直接编译为类(class)文件，不需要单独的脚本执行引擎，直接使用java调试接口(java debug interface，jdi)jdi的调试能力。脚本执行引擎包括脚本语言描述、执行、调试功能。这一类脚本执行引擎通常包括groovy、scala、kotlin、fantom、jython、jruby等等。由于这类脚本执行引擎不需要单独的引擎来调试，不在本申请的讨论范围内。
33.另一类是提供了调试功能的脚本执行引擎，支持在脚本执行引擎执行脚本时打断点、单步执行等动作。这一类脚本执行引擎通常包括python、perl、php、ruby、lua、ant、xslt等等。由于需要脚本执行引擎支持调试功能，执行与调试的代码一起在执行引擎中运行，可以将其归类为侵入式调试技术。
34.另一类是没有调试功能的脚本执行引擎，官方宣称没有调试能力，这一类脚本执
行引擎通常包括freemarker、bpmn、smooks、gradle、shell、drools等等。
35.每种脚本引擎都需要实现调试功能，基于上述内容可知，目前有很多脚本引擎没有提供调试功能，导致这些脚本不能调试。这种脚本开发时，只能通过在运行环境中查看执行日志、执行结果等信息来确定脚本是否存在问题。发现问题之后，不能直接定位到脚本中的出现问题的位置。此时，通常通过二分法，删除部分脚本后再次执行脚本这种方式来找出问题位置。导致开发周期长、开发效率低。
36.而如果直接在脚本执行引擎支持调试功能，则需要修改脚本执行引擎中的代码，通常需要经过很长时间。并且如果调试功能和运行功能是在一起执行的，增加调试功能可能导致运行功能出问题。而脚本执行引擎一般是开源的，比较难接收功能影响大的调试功能的合入。因此，亟需研究一种如何通过没有调试功能的脚本执行引擎来调试脚本的方法。
37.本申请实施例提供的脚本调试方法就应用于在脚本执行引擎没有调试功能时如何实现对脚本的调试的场景中。
38.图1是本申请实施例提供的一种脚本调试系统的架构示意图。如图1所示，该系统100包括容器101和调试器102。本申请实施例并不限定容器101和调试器102的数量，图1仅仅是以1个容器101和一个调试器102为例进行说明。调试器102与容器101之间可通信。
39.图1中的容器101可部署/运行在虚拟机上。容器101中部署有进行脚本编译的脚本执行引擎。以java容器为例，该java容器可具体是指运行脚本执行引擎的java进程。在启动java容器时，可使用漏洞工具的相关参数来开启java虚拟机的调试特性。java容器中的脚本执行引擎可以是指具有脚本解析执行能力的程序包。
40.调试器102中部署有调试插件，调试器102通过调试插件与容器101之间进行通信，以实现对脚本的调试功能。
41.调试器102与容器101之间进行通信时所使用的接口可以为jdi等调试接口。jdi是java平台调试架构((java platform debugger architecture，jpda)包括的三层模块中的最高层的接口，定义了调试器(debugger)所需要的一些调试接口。基于这些接口，调试器可以及时地了解目标虚拟机的状态，例如查看目标虚拟机上有哪些类和实例等。另外，调试器还可以控制目标虚拟机的执行，例如挂起和恢复目标虚拟机上的线程，设置断点等。
42.目前，大多数的jdi调试器实现都是通过java语言编写的。比如，java开发者再熟悉不过的eclipse ide，intellij idea。
43.此外，在本申请实施例中，为了避免在调试脚本过程容器101和调试器102之间交互次数太多，在容器101中部署有代理模块，该代理模块可以实现相关技术中调试器102的一些判断操作，以减少调试脚本过程容器101和调试器102之间交互次数。关于代理模块的相关功能将在下述方法实施例中详细解释说明，在此就先不阐述。
44.示例地，以java容器为例，java容器部署在java虚拟机上。java虚拟机工具接口(jvmtool interface，jvmti)是java虚拟机所提供的原生(native)编程接口，是java虚拟机性能分析器(java virtual machine profiler interface，jvmpi)和java虚拟机调试接口(java virtual machine debug interface，jvmdi)的更新版本。从这个应用程序接口(application interface，api)的发展历史轨迹中就可以知道，jvmti提供了可用于调试(debug)和性能分析(profiler)的接口；同时，在java 5/6中，虚拟机接口也增加了监听(monitoring)，线程分析(thread analysis)以及覆盖率分析(coverage analysis)等功
能。正是由于jvmti的强大功能，它是实现java调试器，以及其它java运行态测试与分析工具的基础。
45.也即是，jvmti是一套java虚拟机的本地代码接口，因此开发时可以通过部署一个代理模块(agent)的方式来使用jvmti，代理模块使用jvmti函数，设置一些回调函数，并从java虚拟机中得到当前的运行态信息，并作出自己的判断，最后还可能操作虚拟机的运行态，以实现本申请实施例提供的代理模块的功能。
46.此外，可以先将代理模块编译成一个动态链接库，在把代理模块编译成一个动态链接库之后，就可以在java程序启动的时候来加载它(启动加载模式)，也可以在java 5之后使用运行时加载(活动加载模式)。以便于后续容器通过代理模块执行一些操作。
47.需要说明的时，jvmti并不一定在所有的java虚拟机上都有实现，不同的虚拟机的实现也不尽相同。不过在一些主流的虚拟机中，比如sun和ibm，以及一些开源的如apache harmony drlvm中，都提供了标准jvmti实现。
48.上述部署代理模块仅仅是以jvmti为例进行说明，关于代理模块的配置也可以通过其他实现方式来实现，只需容器可以通过配置的代理模块实现本申请实施例提供的脚本执行方法即可。
49.下面对本申请实施例提供的脚本调试方法进行解释说明。基于上述系统架构可知，可以通过代理模块来替代相关技术中调试器来执行部分调试功能，如此，就需要预先在容器中注册用于调试的一些信息。这些信息包括待调试的一个或多个断点、以及断点触发配置信息。该断点触发配置信息用于指示一个断点是否满足断点调试条件。以便于后续容器在通过脚本执行引擎执行脚本时，可以减少和调试器进行交互的次数以完成高效的脚本调试过程。因此，本申请实施例提供的脚本调试方法可以包括如下两个过程：首先注册断点和断点触发配置信息的过程，其次是脚本执行过程中的脚本调试过程。下述两个实施例分别用于对这两个过程进行解释说明。
50.图2是本申请实施例提供的一种脚本调试方法流程示意图。用于对上述注册断点和断点触发配置信息的过程进行详细解释说明。如图2所示，该方法包括如下几个步骤：
51.步骤201：容器接收容器启动指令。
52.脚本调试通常是由开发人员触发的，并且开发人员的客户端是与调试器连接的，因此，在一种可能的实现方式中，当客户端检测到开发人员通过预设操作触发的调式指令时，客户端向调试器发送脚本调试启动请求。当调试器接收到该脚本调试启动请求时，启动本地部署的调试插件，通过调试插件注册回调接口，以使调试器通过回调接口与容器建立通信连接。之后调试器向容器发送容器启动指令，当容器接收到该容器启动指令时，便可通过下述步骤202加载代理模块和脚本执行引擎。上述过程可以通过图3所示的容器与调试器之间的交互过程来表示，在此不再详细说明。
53.上述调试器向容器发送的容器启动指令中携带代理模块的配置信息，该代理模块的配置信息用于指示代理模块的动态库位置，该动态库位置可以是容器所在的系统中的任意位置，以便于后续容器通过步骤202加载代理模块。示例地，以java容器为例，该动态库位置可以在java规范中由启动参数java代理(javaagent)配置或者由虚拟机(virtualmachine)的本地代理(loadagent)函数来加载，在此不再详细说明。
54.此外，以java容器为例，上述调试器与容器之间的通信连接可以为调试器与java
容器建立套接字(socket)的连接，以用来发送后续的jdi调试命令。
55.步骤202：容器加载代理模块和脚本执行引擎。
56.基于步骤201可知，容器启动指令中还携带有代理模块的配置信息，因此容器可以基于该代理模块的配置信息初始化代理模块，也即是加载代理模块。在本申请实施例中，由于需要通过代理模块来进行断点调试条件的判断，因此，如图3所示，在初始化代理模块之后，需要在该代理模块中注册断点事件回调函数。该断点事件回调函数用于判断一个断点是否满足指定的断点调试条件。
57.关于容器加载脚本执行引擎(也即是初始化脚本执行引擎)的方式在此不再详细说明。
58.步骤203：容器接收调试器发送的断点配置请求，断点配置请求携带一个或多个断点、以及断点触发配置信息。
59.如图3所示，当容器加载完代理模块和脚本执行引擎之后，还可以向调试器发送初始化完成消息。当调试器接收到该初始化完成消息之后，确定待调试的一个或多个断点，以及断点触发配置信息。该断点触发配置信息用于指示一个断点是否满足断点调试条件。然后调试器向容器发送断点配置请求，该断点配置请求携带这一个或多个断点，以及断点触发配置信息。
60.可选地，容器加载完代理模块和脚本执行引擎之后，也可以不向调试器发送初始化完成消息。这种情况下，调试器可以在发送容器启动指令时开始计时，当计时时长达到参考时长时，直接向调试器发送断点配置请求，进一步降低容器与调试器之间的交互次数。该参考时长可以由开发人员在开发端配置，在此不再详细说明。比如，调试器可以在发送容器启动指令后5秒时向容器发送该断点配置请求。
61.上述调试器发送断点配置请求之前，需要先确定这一个或多个断点、以及断点触发配置信息。在一种可能的实现方式中，如图3所示，调试器确定这一个或多个断点的实现过程可以为：调试器可通过调试插件确定脚本中的关键代码，得到一个或多个关键代码，将得到每个关键代码设置为一个断点。其中，开发人员可以通过调试插件打开脚本，然后设置这些关键代码，以使调试器获取到这一个或多个关键代码。
62.在一种可能的实现方式中，调试器确定断点触发配置信息的实现过程可以为：调试器在确定出这一个或多个断点之后，在第一映射表中获取每个断点关联的关键信息对应的类(class)信息，得到多个关键信息和与多个关键信息中每个关键信息对应的类信息，每个断点关联有多个关键信息中的一个或多个关键信息。其中，在脚本中，关键信息对应的类信息用于指示相应关键信息的上下文。每个断点关联的关键信息包括该断点所在的行代码中的关键字等信息，该关键字可以为servicetaskbeginnode、servicetaskendnode等。
63.上述第一映射表可以为关键信息与类信息之间的映射表。表1是本申请实施例提供的一种第一映射表，如表1所示，第一映射表中包括每个关键信息对应的类信息。由于不同的脚本行可能包括同一关键信息，因此为了根据断点的位置精确查找到断点关联的关键信息对应的类信息，第一映射表中还包括关键信息所在的脚本行。
64.表1
[0065][0066][0067]
此外，上述每个关键信息对应的类信息还可以包括关键信息对应的局部变量，也即是，每个断点关联的关键信息还对应一个局部变量，以便于后续根据每个断点关联的关键信息对应的局部变量的值来确定该断点是否满足断点调试条件。
[0068]
其中，上述关键信息对应的局部变量可以从第二映射表中获取到，第二映射表中多个关键信息和与多个关键信息一一对应的多个局部变量。表2是本申请实施例提供的一种第二映射表。如表2所示，每个关键信息可以对应一个局部变量。此外，有些关键信息不能在顶层堆栈直接获取到，可能在其他层次的堆栈才能找到该关键信息。因此，第二映射表中还包括堆栈编号，该堆栈编号的作用是指示在第几层堆栈去获取这一行的关键信息。
[0069]
表2
[0070][0071]
也即是，断点触发配置信息包括多个关键信息和与这多个关键信息中每个关键信息对应的类信息，类信息中还包括局部变量。预先设置的一个或多个断点中每个断点关联有这多个关键信息中的一个或多个关键信息。
[0072]
需要说明的是，上述表1和表2中的关键信息、类信息以及局部变量是以java容器，调试接口是jdi、或者、基于java调试线协议(java debug wire protocol，jdwp)的接口为例进行说明的。本申请实施例中的容器不限于java容器，可以是c++等语言直接编译的脚本执行引擎所在的容器，此时可以通过其他方式(比如可以为ld_library、dll注入等方式)实现代理模块的加载，使用的调试接口对应系统的调试接口，如windows的dbghelp(windows操作系统中的一种调试跟踪相关模块)等。这种场景下，上述类信息具体是指汇编导出函数名，上述脚本行是指偏移量。在此不再一一详细解释说明。
[0073]
步骤204：容器将一个或多个断点注册在脚本执行引擎中，将断点触发配置信息注册在代理模块中。
[0074]
由于后续需要通过通过脚本执行引擎发现断点，同时需要通过代理模块来确定是否触发调试，因此，在容器接收到上述断点配置请求之后，便可将一个或多个断点注册在脚本执行引擎中，将断点触发配置信息注册在代理模块中，以便于通过下述图4所示的实施例来进行脚本的调试。
[0075]
通过图2所示的实施例，可以预先在容器的代理模块中注册断点触发配置信息，以便于后续由代理模块来判断断点是否满足断点调试条件，无需通过调试器来判断，从而减少调试器和容器之间的交互次数，进而提高脚本调试的效率。
[0076]
需要说明的是，上述实施例是以在每次进行脚本调试时先注册断点和断点触发配置信息，然后通过下述图4所示的实施例来调试脚本为例来进行说明的。
[0077]
可选地，对于同一类型的脚本，断点和断点触发配置信息通常一致，因此，上述图2所示的实施例中注册断点和断点触发配置信息过程可以进行脚本调试之前先在容器中实现，后续当需要调试属于该类型的脚本中的任一脚本时，便可直接通过下述图4所示的实施例来实现。这种场景下，步骤201中的容器接收到的容器启动指令并不是调试器在接收到调试指令时发送的，而是调试器在检测到需要初始化容器时发送的。
[0078]
图4是本申请实施例提供的一种脚本调试方法流程示意图。用于对上述注册断点和断点触发配置信息之后，脚本执行过程中的脚本调试过程进行详细解释说明。如图4所示，该方法包括如下几个步骤：
[0079]
步骤401：容器通过脚本执行引擎执行脚本。
[0080]
在一种可能的实现方式中，开发人员可通过调试器向容器发送调试指令，当容器在接收到调试指令后，在完成图2所示的相关信息的注册之后，便可直接开始通过脚本执行引擎执行脚本。
[0081]
可选地，当容器在接收到调试指令后，在完成图2所示的相关信息的注册之后，容器还可以向调试器返回一个准备完成消息。当调试器接收到该准备完成消息后，可以显示该准备完成消息，开发人员便可通过调试器向容器再次发送一个调试指令，当容器接收到该调试指令时，便可通过脚本执行引擎执行脚本。
[0082]
可选地，如果在对同一类型的各个脚本进行调试之前，已经通过图2所示的实施例对容器中的相关信息进行了注册，此时当调试器接收到客户端发送的调试指令时，便可直接向容器发送该调试指令，以触发容器通过脚本执行引擎执行脚本。
[0083]
步骤402：在通过脚本执行引擎执行至一个或多个断点中的任一断点的情况下，容器调用代理模块基于断点触发配置信息对该断点进行检测。
[0084]
由于脚本执行引擎中已经注册有待调试的一个或多个断点，因此，在脚本执行引擎执行脚本的过程中，可以判断当前执行的脚本位置是否是这一个或多个断点中的某个断点，如果是，如图3所示，则暂停脚本执行过程，并调用代理模块基于断点触发配置信息对该断点进行检测。
[0085]
由于代理模块中预先注册有断点事件回调函数，因此，容器调用代理模块基于断点触发配置信息对该断点进行检测的实现方式可以为：代理模块以该断点为参数调用断点事件回调函数来判断该断点是否满足断点调试条件。
[0086]
基于图2所示的实施例可知，代理模块中还注册有断点触发配置信息，因此，调用代理模块基于断点触发配置信息对该断点进行检测的实现方式具体为：从断点触发配置信息中确定该断点关联的关键信息对应的类信息；从确定的类信息中获取该断点对应的局部变量的值；如果获取的局部变量的值与脚本执行引擎执行该断点所需的值不一致，则检测出该断点不满足断点调试条件。相应地，如果局部变量的值与脚本执行引擎执行该断点所需的值一致，则检测出该断点满足断点调试条件。其中，脚本执行引擎执行该断点所需的值可以是代理模块预先根据该断点的位置信息确定得到的，示例地，可以根据断点的位置信息确定断点所在的行代码的上下文，基于确定的上下文得到局部变量，此时得到的局部变量即为脚本执行引擎执行该断点所需的值，在此不再详细说明。
[0087]
在一种可能的实现方式中，如图3所示，在代理模块对该断点进行检测之后，如果代理模块输出的值为空值(null)，则表明该断点不满足断点调试条件。此时，容器可以通过下述步骤直接恢复脚本执行引擎继续执行脚本。
[0088]
如果代理模块输出的值不为空值，则表明该断点满足断点调试条件。此时，容器通过下述步骤调用调试接口向调试器发送调试触发指令，以实现对该断点的调试。
[0089]
步骤403：在通过代理模块检测出该断点不满足断点调试条件的情况下，容器通过脚本执行引擎继续执行脚本。
[0090]
基于步骤402可知，如果代理模块检测出该断点不满足断点调试条件，此时容器可直接通过脚本执行引擎继续执行脚本，这种场景下容器无需与调试器进行交互。
[0091]
相应地，在通过代理模块检测出该断点满足断点调试条件的情况下，容器才向调试器发送调试触发指令，用于指示调试器基于调试触发指令对该断点进行调试。
[0092]
也即是，在本申请实施例中，在容器通过脚本执行引擎执行脚本的过程中，只有在代理模块检测出断点满足断点调试条件时，容器才会和调试器交互，以触发调试器对该断点进行调试。在代理模块检测出断点不满足断点调试条件时，容器则无需和调试器交互，直接继续恢复脚本执行引擎继续执行脚本。
[0093]
上述调试器基于调试触发指令对该断点进行调试之后，调试器还可以向客户端发送调试结果，客户端显示该调试结果。比如，在编辑窗口中显示脚本文件并且焦点置于断点行，在堆栈窗口中显示调用栈，最顶层堆栈显示为脚本行，在局部变量窗口中显示脚本执行上下文等等。
[0094]
图5是本申请实施例提供的一种脚本调试装置框图。该装置应用于容器中，容器中部署有脚本执行引擎和代理模块，容器中注册有一个或多个断点、以及断点触发配置信息，断点触发配置信息用于指示一个断点是否满足断点调试条件。如图5所示，该装置500包括：
[0095]
执行模块501，用于通过脚本执行引擎执行脚本。具体实现过程可以参考图4实施
例中的步骤401。
[0096]
检测模块502，用于在通过脚本执行引擎执行至一个或多个断点中的任一断点的情况下，调用代理模块基于断点触发配置信息对任一断点进行检测。具体实现过程可以参考图4实施例中的步骤402。
[0097]
执行模块501，还用于在通过代理模块检测出任一断点不满足断点调试条件的情况下，通过脚本执行引擎继续执行脚本。具体实现过程可以参考图4实施例中的步骤403。
[0098]
可选地，该装置500还包括：
[0099]
发送模块，用于在通过代理模块检测出任一断点满足断点调试条件的情况下，向调试器发送调试触发指令，用于指示调试器基于调试触发指令对任一断点进行调试。
[0100]
可选地，如图6所示，该装置500还包括：
[0101]
接收模块503，用于接收容器启动指令。具体实现过程可以参考图2实施例中的步骤201。
[0102]
加载模块504，用于加载代理模块和脚本执行引擎。具体实现过程可以参考图2实施例中的步骤202。
[0103]
接收模块503，还用于接收调试器发送的断点配置请求，断点配置请求携带一个或多个断点、以及断点触发配置信息。具体实现过程可以参考图2实施例中的步骤203。
[0104]
注册模块505，用于将一个或多个断点注册在脚本执行引擎中，将断点触发配置信息注册在代理模块中。具体实现过程可以参考图2实施例中的步骤204。
[0105]
可选地，断点触发配置信息包括多个关键信息和与多个关键信息中每个关键信息对应的类信息，每个断点关联有多个关键信息中的一个或多个关键信息；
[0106]
检测模块502，用于：
[0107]
从断点触发配置信息中确定任一断点关联的关键信息对应的类信息；
[0108]
从确定的类信息中获取任一断点对应的局部变量的值；
[0109]
如果局部变量的值与脚本执行引擎执行任一断点所需的值不一致，则检测出任一断点不满足断点调试条件。
[0110]
可选地，检测模块502用于：
[0111]
如果局部变量的值与脚本执行引擎执行任一断点所需的值一致，则检测出任一断点满足断点调试条件。
[0112]
在本申请实施例中，可以预先在容器中部署代理模块和脚本执行引擎，并注册断点触发配置信息，以便于后续由代理模块基于断点触发配置信息来判断断点是否满足断点调试条件，无需通过调试器来判断，不仅可以实现不支持调试功能的脚本执行引擎最终具有调试功能，还进一步减少了调试过程中调试器和容器之间的交互次数，进而提高脚本调试的效率。
[0113]
需要说明的是：上述实施例提供的触发智能网业务的装置在触发智能网业务时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的触发智能网业务的装置与触发智能网业务的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
[0114]
图7是本申请实施例提供的一种计算机设备的结构示意图。图1中的脚本调试系统
可以通过图7所示的计算机设备来实现。参见图7，该计算机设备包括至少一个处理器701，通信总线702、存储器703以及至少一个通信接口704。
[0115]
处理器701可以是一个通用中央处理器(central processing unit，cpu)、特定应用集成电路(application-specific integrated circuit，asic)或一个或多个用于控制本申请方案程序执行的集成电路。
[0116]
通信总线702可包括一通路，在上述组件之间传送信息。
[0117]
存储器703可以是只读存储器(read-only memory，rom)或可存储静态信息和指令的其它类型的静态存储设备，随机存取存储器(random access memory，ram)或者可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、只读光盘(compact disc read-only memory，cd-rom)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘或者其它磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器703可以是独立存在，通过通信总线702与处理器701相连接。存储器703也可以和处理器701集成在一起。
[0118]
其中，存储器703用于存储执行本申请方案的程序代码，并由处理器701来控制执行。处理器701用于执行存储器703中存储的程序代码。程序代码中可以包括一个或多个软件模块，这一个或多个软件模块可以为图5或图6所示的实施例中的模块。图1中所示的脚本调试系统可以通过处理器701以及存储器703中的程序代码中的一个或多个软件模块，来确定用于开发应用的数据。
[0119]
通信接口704，使用任何收发器一类的装置，用于与其它设备或通信网络通信，如以太网，无线接入网(radio access networkran)，无线局域网(wireless local area networks，wlan)等。
[0120]
在具体实现中，作为一种实施例，计算机设备可以包括多个处理器，例如图7中所示的处理器701和处理器705。这些处理器中的每一个可以是一个单核(single-cpu)处理器，也可以是一个多核(multi-cpu)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
[0121]
上述的计算机设备可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，计算机设备可以是台式机、便携式电脑、网络服务器、掌上电脑(personal digital assistant，pda)、移动手机、平板电脑、无线终端设备、通信设备或者嵌入式设备。本申请实施例不限定计算机设备的类型。
[0122]
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
[0123]
以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。