Data processing method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a data processing method and device, electronic equipment, a storage medium and a program product. The method comprises the steps of determining a dependency relationship between interfaces based on an input parameter and an output parameter of each interface called by a program segment; according to the dependency relationship between the interfaces, grouping the interfaces with the dependency relationship into a group; calling the interfaces in the groups in parallel to obtain data returned by the interface in each group; and running the program segment based on the data returned by the interface in each group. Through the application, the running efficiency of the program segment can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a data processing method, device, electronic device, storage medium, and program product. Background Art

[0002] In software development, a program segment often needs to call multiple interfaces to complete a task. These interfaces may come from different services or systems. As code is continuously iterated, the number of interfaces that a program segment needs to call increases, increasing the execution time of the entire program segment. Summary of the Invention

[0003] Embodiments of the present application provide a data processing method, device, electronic device, storage medium, and program product, which can improve the operating efficiency of program segments.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] This embodiment of the present application provides a data processing method, the method comprising:

[0006] Determining dependencies between interfaces based on input parameters and output parameters of each interface called by the program segment;

[0007] According to the dependency relationship between the interfaces, the interfaces with the dependency relationship are grouped into a group;

[0008] Calling multiple interfaces in the group in parallel to obtain data returned by each interface in the group;

[0009] The program segment is executed based on the data returned by the interface in each of the packets.

[0010] An embodiment of the present application provides a data processing device, including:

[0011] A determination module, configured to determine the dependency relationship between the interfaces based on the input parameters and output parameters of each interface called by the program segment;

[0012] A grouping module, configured to group interfaces having dependencies into a group according to the dependencies between the interfaces;

[0013] A calling module, configured to call the interfaces in the plurality of groups and obtain data returned by the interfaces in each group;

[0014] An execution module is used to run the program segment based on the data returned by the interface in each of the groups.

[0015] An embodiment of the present application provides an electronic device, comprising:

[0016] a memory for storing computer executable instructions or computer programs;

[0017] The processor is used to implement the data processing method provided in the embodiment of the present application when executing the computer-executable instructions or computer programs stored in the memory.

[0018] An embodiment of the present application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the data processing method provided in the embodiment of the present application when executed by a processor.

[0019] An embodiment of the present application provides a computer program product, including a computer program or computer-executable instructions. When the computer program or computer-executable instructions are executed by a processor, the data processing method provided in the embodiment of the present application is implemented.

[0020] The embodiments of the present application have the following beneficial effects:

[0021] By analyzing the input and output parameters of interfaces, we can identify dependencies between them. Based on these dependencies, we divide interfaces into multiple groups, ensuring that dependencies exist between interfaces within each group, while ensuring that interfaces between different groups do not affect each other during the call process. By calling interfaces in multiple groups in parallel, interfaces in multiple groups can run simultaneously, reducing the total interface call time. Furthermore, program segments run based on the data returned by all interfaces, eliminating the need to call interfaces one by one based on dependency relationships. This significantly shortens the overall processing time of program segments and improves their operational efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 Schematic diagram of the data processing system provided in the embodiment of the present application;

[0023] Figure 2 is a structural diagram of an electronic device provided in an embodiment of the present application;

[0024] Figure 3 This is a flow diagram of the data processing method provided in the embodiment of the present application. Figure 1 ;

[0025] Figure 4 This is a flow diagram of the data processing method provided in the embodiment of the present application. Figure 2 ;

[0026] Figure 5 This is a flow diagram of the data processing method provided in the embodiment of the present application. Figure 3 ;

[0027] Figure 6 Schematic diagram of the data processing method provided in the embodiment of the present application;

[0028] Figure 7 This is a schematic diagram of the dependency relationship between interfaces provided in the embodiment of the present application;

[0029] Figure 8 This is a schematic diagram of the code framework provided in the embodiment of the present application;

[0030] Figure 9 This is a flowchart of an interface scan provided by an embodiment of the present application;

[0031] Figure 10 This is a schematic diagram of the interface bucketing provided in the embodiment of this application. Figure 1 ;

[0032] Figure 11 This is a schematic diagram of the interface bucketing provided in the embodiment of this application. Figure 2 ;

[0033] Figure 12 Schematic diagram of the parallel execution buckets of the thread pool provided in an embodiment of the present application;

[0034] Figure 13 This is a schematic diagram of bucket execution provided by an embodiment of the present application;

[0035] Figure 14 It is a schematic diagram of the retry mechanism provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0037] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0038] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0039] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that includes the functions of the module or unit.

[0040] Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meanings as those commonly understood by one of ordinary skill in the art. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0041] The related data collection process in the embodiments of the present application should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and within the scope of authorization of laws and regulations and the personal information subject, carry out subsequent data use and processing.

[0042] Before the embodiments of the present application are further described in detail, the terms and phrases involved in the embodiments of the present application are explained, and the terms and phrases involved in the embodiments of the present application are applicable to the following explanations.

[0043] 1) Program segment: refers to a set of logical units or code collections that implement a specific function in a software system. A program segment usually includes multiple interfaces. For example, in an e-commerce system, a program segment that implements order processing functions can include multiple interfaces such as ordering, payment, and delivery.

[0044] 2) Thread: is the smallest unit that can be scheduled for operation by an operating system, and is an entity in a process. For example, a program segment can call the inventory query interface and the user information query interface in parallel through multiple threads.

[0045] 3) Dependency relationship: refers to the sequence relationship between two or more interfaces. For example, when the input parameter of an interface needs to depend on the output parameter of another interface, there is a dependency relationship between the two interfaces. In the order processing scenario, the order total calculation interface may depend on the result of the commodity price query interface.

[0046] 4) Bytecode file: is an intermediate file generated after compiling high-level languages such as Java, with a.class extension. The bytecode file is the actual execution form of the program segment at runtime, and can run on any device that supports the Java virtual machine. For example, the logic of the order processing function program segment will be compiled into multiple.class files.

[0047] 5) Classpath information: refers to the path set that Java program uses to find bytecode files during runtime. By setting the classpath, the program can locate the required classes and resource files for program segments. For example, when running a program segment for order processing, the classpath needs to include the bytecode files of the inventory query interface and the user information query interface.

[0048] 6) Service layer: a logical layer in software architecture, usually located between the program segment layer and the remote layer. The service layer includes multiple logical interfaces, which are used to call dependent remote services and process the results.

[0049] 7) Logical interface: refers to the interface defined in the service layer, which describes the capabilities provided by the program segment to the outside, but does not contain specific implementation details. Each logical interface depends on multiple remote service interfaces. For example, the order service layer may define a logical interface to describe the input parameters and return values of the order placement function.

[0050] 8) Remote layer: refers to the logical layer that handles cross-network communication, used to implement the interaction between the client and the server. The remote layer includes multiple remote service interfaces.

[0051] 9) Remote service interface: an interface defined in the remote layer, used to describe the function and calling method of the remote service. The remote service interface allows the client to call the method on the remote server through the network, realizing the cooperation of the distributed system. For example, the remote service interface of the payment gateway may be used to receive the order payment request.

[0052] 10) Abstract Syntax Tree Method (ASM): an open-source framework for manipulating Java bytecode, which can dynamically generate classes or enhance the functionality of existing classes. ASM can directly generate binary class files, or dynamically change the behavior of classes before they are loaded into the Java virtual machine. In the embodiments of the present application, the parsing ability of ASM for class files is used to obtain the dependent interfaces contained in the interfaces or methods.

[0053] When assembling queries on user data and calling multiple interfaces, the code is constantly iterating, and the number of interfaces included in the program segment increases. Furthermore, the program segments are executed serially. A pause in any interface will affect the execution of the segment, increasing the execution time of the entire process. Refactoring the original code is risky and requires multiple scenarios, consuming testing resources. Interfaces also have dependencies. For example, the output of a previous interface is the input of a subsequent interface. If a query on the previous interface fails or there is no data, subsequent queries on the interface will use the default value, resulting in inaccurate data. The greater the number of interfaces, the more interfaces are interspersed throughout the program segment based on their dependencies, further increasing the inaccuracy of data queries. One related approach is to block a thread at that interface and perform periodic retries when no data is returned. The problem with this approach is that subsequent queries that do not rely on that interface are also blocked, resulting in excessively long execution times for the entire segment and a poor user experience. Furthermore, retry and delayed execution logic are required at the interface level, leading to redundant code and intrusion into the original code. Another method is to orchestrate service interfaces through configuration or interface. This method is dynamic configuration and cannot be adapted to existing code business logic. When a new interface is added for each business scenario, manual configuration or orchestration is required, which is inefficient.

[0054] Based on the problems existing in the related art, the embodiments of the present application provide a data processing method, device, electronic device, storage medium and program product, which can improve the operating efficiency of program segments. The following describes an exemplary application of the data processing device provided in the embodiments of the present application, which is an electronic device for implementing the data processing method. The electronic device provided in the embodiments of the present application can be implemented as various types of terminals such as laptops, tablet computers, desktop computers, set-top boxes, smart phones, smart speakers, smart watches, smart TVs, and car terminals, and can also be implemented as servers. Below, an exemplary application when the data processing device is implemented as a terminal or a server will be described.

[0055] See also Figure 1 , Figure 1 : This is a schematic diagram of the architecture of the data processing system provided in an embodiment of the present application. In order to perform data processing operations, a data processing application can be provided. For example, the data processing application can be an application dedicated to data processing, or it can be a functional module in other applications (such as a data processing module in a financial application, etc.). The data processing system 100 in an embodiment of the present application includes at least a terminal 400, a network 300 and a server 200, wherein the server 200 is a server for the data processing application. The server 200 can constitute the data processing device in an embodiment of the present application, that is, the data processing method in an embodiment of the present application is implemented through the server 200. The terminal 400 is connected to the server 200 via the network 300, and the network 300 can be a wide area network or a local area network, or a combination of the two.

[0056] See also Figure 1 The user can trigger a service request through the client of terminal 400, and terminal 400 sends the service request to server 200. Server 200 responds to the service request, determines the data corresponding to the service request, and determines the dependency relationship between the interfaces based on the input parameters and output parameters of each interface called by the data; server 200 groups the interfaces with dependencies into a group according to the dependency relationship between the interfaces; server 200 calls the interfaces in multiple groups in parallel to obtain the data returned by the interfaces in each group; server 200 runs the program segment based on the data returned by the interfaces in each group.

[0057] In one embodiment, in an e-commerce system, when a user submits an order, the program segment of the order processing function needs to call multiple interfaces to complete a series of operations, such as checking inventory, calculating the total price, generating a payment link, etc. There may be dependencies between these interfaces. For example, calculating the total price depends on the results of the inventory query. Based on the input parameters and output parameters of each interface, the dependencies between the multiple interfaces are determined. The multiple interfaces are grouped according to the dependencies to obtain multiple groups. The interfaces between the groups do not have dependencies, but the multiple interfaces in a group do have dependencies. The interfaces of the multiple groups are called in parallel to obtain the data returned by the interfaces in each group. Finally, based on the data returned by each interface, the program segment of the order processing function generates complete order information and returns it to the user.

[0058] In one embodiment, in a financial system, the program segment of the resource borrowing approval function needs to call multiple interfaces to complete the user's resource borrowing application review, such as querying the user's credit score, verifying income proof, calculating the resource borrowing limit, etc. There may also be dependencies between these interfaces. Based on the input parameters and output parameters of each interface, the dependencies between the multiple interfaces are determined. The multiple interfaces are grouped according to the dependencies to obtain multiple groups. The interfaces between the groups do not have dependencies, but multiple interfaces within a group do have dependencies. The interfaces of the multiple groups are called in parallel to obtain the data returned by the interfaces in each group. Finally, based on the data returned by each interface, the program segment of the resource borrowing approval function generates the approval result and notifies the user.

[0059] The electronic device that implements the data processing method provided in the embodiment of the present application may be Figure 1 Server 200 in . Figure 2 , Figure 2 is a structural diagram of an electronic device provided in an embodiment of the present application, Figure 2The electronic device shown includes: at least one processor 210, a memory 230 and at least one network interface 220. The various components in the electronic device are coupled together via a bus system 240. It is understood that the bus system 240 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 240 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 240 is not described in detail. Figure 2 Various buses are labeled as bus system 240 .

[0060] The processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0061] The memory 230 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The memory 230 may optionally include one or more storage devices that are physically remote from the processor 210.

[0062] The memory 230 includes volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 230 described in the embodiments of the present application is intended to include any suitable type of memory.

[0063] In some embodiments, memory 230 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplarily described below.

[0064] The operating system 231 includes system programs for processing various basic system services and executing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks.

[0065] The network communication module 232 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 220 . Exemplary network interfaces 220 include Bluetooth, Wireless Authentication (WiFi), and Universal Serial Bus (USB).

[0066] In some embodiments, the apparatus provided in the embodiments of the present application may be implemented in software. Figure 2 The data processing device 233 stored in the memory 230 is shown. This device can be software in the form of a program or plug-in, and includes the following software modules: a determination module 2331, a grouping module 2332, a call module 2333, and an execution module 2334. These modules are logical and can be arbitrarily combined or further divided according to the functions they implement. The functions of each module will be described below.

[0067] In other embodiments, the apparatus provided in the embodiments of the present application may be implemented in hardware. As an example, the apparatus provided in the embodiments of the present application may be a processor in the form of a hardware decoding processor, which is programmed to execute the functional module processing method provided in the embodiments of the present application. For example, the processor in the form of a hardware decoding processor may be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0068] See also Figure 3 , Figure 3 This is a flow diagram of the data processing method provided in the embodiment of the present application. Figure 1 , will combine Figure 3 The steps shown are explained as Figure 3 As shown, the data processing method is described by taking the execution subject of the server as an example. The method includes the following steps 101 to 104:

[0069] In step 101 , the dependency relationship between interfaces is determined based on the input parameters and output parameters of each interface called by the program segment.

[0070] Here, a program segment is a code block for implementing a specific function, and the program segment can include one or more interfaces. An interface includes an interface name, input parameters of the interface, and output parameters of the interface. The interface name is used to represent the functional role of the interface. The input parameters of the interface are parameters that are dependent on external input during internal operation of the interface. The output parameters of the interface are results returned after execution of the interface. If the output parameters of an interface are used as input parameters of a subsequent interface, the interface and the subsequent interface have a dependency relationship. Embodiments of the present application can analyze all interfaces called by a program segment, and extract the input parameters and the output parameters of each interface. The input parameters and the output parameters of different interfaces are compared. If the input parameters of a certain interface contain the output parameters of another interface, it is considered that there is a dependency relationship between the two interfaces. Alternatively, if the input parameters of a certain interface are obtained by converting the data format of the output parameters of another interface, there is a dependency relationship between the two interfaces.

[0071] For example, a program segment is a program segment for implementing an order processing function. The program segment calls the following three interfaces: interface A: query commodity inventory (input parameter: commodity identity (Identity, ID); output parameter: inventory quantity). Interface B: calculate order total price (input parameters: commodity ID, inventory quantity; output parameter: total price). Interface C: generate payment link (input parameter: total price; output parameter: payment link). The input parameter "inventory quantity" of interface B depends on the output parameter of interface A, and therefore interface B depends on interface A. The input parameter "total price" of interface C depends on the output parameter of interface B, and therefore interface C depends on interface B.

[0072] In some embodiments, Figure 4 is a flowchart of a data processing method provided by an embodiment of the present application Figure 2 As shown in Figure 4 Before determining the dependency relationship between interfaces based on the input parameters and the output parameters of each interface called by a program segment, the method further includes steps 201 to 203:

[0073] In step 201, first class path information is extracted from a bytecode file of a program segment, and logical interfaces called by the program segment in a service layer are determined based on the first class path information.

[0074] Here, the data processing method provided by the embodiments of the present application is applied to a server, and the server interacts with a client. The server includes a business layer, a service layer, and a remote layer. The business layer is an entry for external calling, and is configured to receive a service request sent by the client. The business layer includes a plurality of program segments, and a corresponding program segment is determined based on the service request. The service layer is a layer between the business layer and the remote layer, and provides services for the business layer. The service layer includes a plurality of logical interfaces, and each program segment can call one or more logical interfaces. The remote layer is configured to call external systems, and the remote layer includes a plurality of remote service interfaces. Each logical interface can call one or more remote service interfaces.

[0075] In the embodiments of the present application, a bytecode file of a program segment is an intermediate file after the program segment is compiled, and is a file with a.class extension. The definition of each interface called by the program segment is compiled into a bytecode file, and is stored in a specific directory. First-type path information is extracted from the bytecode file of the program segment by using a bytecode analysis tool (for example, an ASM tool). The first-type path information includes path information of a bytecode file of each logical interface called by the program segment. Based on the path information stored in the first-type path information, the bytecode file stored in the specific directory is searched, and a logical interface corresponding to the bytecode file is taken as a logical interface called by the program segment in the service layer.

[0076] For example, it is assumed that the program segment is a program segment for implementing an order processing function, and the bytecode file includes the following first-type path information: com.example.service.OrderService (order service logical interface). It can be determined that the program segment calls the OrderService (order service) logical interface in the service layer by using the first-type path information.

[0077] In step 202, second-type path information is extracted from the bytecode file of the logical interface, and a remote service interface called by the logical interface in the remote layer is determined based on the second-type path information.

[0078] Here, the bytecode file of the logical interface is a file with a.class extension after the logical interface is compiled. The definition of each remote service interface called by the logical interface is compiled into a bytecode file, and is stored in a specific directory. Second-type path information is extracted from the bytecode file of the logical interface by using a bytecode analysis tool (for example, an ASM tool). The second-type path information includes path information of a bytecode file of each remote service interface called by the logical interface. Based on the path information stored in the second-type path information, the bytecode file stored in the specific directory is searched, and a remote service interface corresponding to the bytecode file is taken as a remote service interface called by the program segment in the remote layer. The remote service interface is configured to call a remote service through a network.

[0079] For example, assume that the bytecode file of the OrderService logical interface contains the following second-class path information: com.example.remote.InventoryService (inventory query remote service interface). Based on this second-class path information, it can be determined that the logical interface calls the InventoryService (inventory query) remote service interface in the remote layer.

[0080] In step 203, the remote service interface is determined as the interface called by the program segment.

[0081] Here, the one or more remote service interfaces determined in step 202 are used as interfaces called by the program segment.

[0082] The embodiments of the present application use bytecode parsing tools to analyze the bytecode files of program segments and logical interfaces, automatically extract class path information, and determine the remote service interface that is ultimately called, thereby reducing the workload of manual configuration and improving the maintainability of the system. Each time the system is started, it will be dynamically scanned and updated. When the business logic changes, new interfaces are added, or logical processing is changed, there is no need to manually modify the interface configuration of the program segment. The interface called by the program segment can be dynamically adapted, saving labor maintenance costs and preventing interface scans from being missed due to frequent system changes.

[0083] In step 102, based on the dependency relationship between the interfaces, the interfaces with the dependency relationship are grouped into a group.

[0084] Here, interfaces with dependencies are divided into the same group to ensure that interfaces between different groups can be called in parallel, while interfaces within the same group are executed in the order of dependencies.

[0085] In some embodiments, interfaces with dependencies are grouped together based on the dependencies between interfaces. This can be achieved in the following way: first, for the first interface that is not grouped among multiple interfaces, if the first interface has no dependency with each interface, the first interface is grouped; then, if it is determined based on the dependency relationship that the first interface depends on the second interface among multiple interfaces, the first interface and the second interface are divided into the same group, and the calling order of the second interface in the group is prior to the calling order of the first interface; if it is determined based on the dependency relationship that the first interface is dependent on the third interface among multiple interfaces, the first interface and the third interface are divided into the same group, and the calling order of the first interface in the group is prior to the calling order of the third interface.

[0086] Here, all ungrouped interfaces are traversed, and one of the ungrouped interfaces is selected as the first interface. Determine whether there is a dependency relationship between the first interface and other interfaces. If the first interface has no dependency relationship with all other interfaces (neither depends on other interfaces nor is depended on by other interfaces), the first interface is treated as a separate group. If it is determined based on the dependency relationship that the first interface depends on a second interface, the first interface and the second interface are divided into the same group. In this group, the order in which the second interface is called must precede the order in which the first interface is called. If it is determined based on the dependency relationship that the first interface is depended on a third interface, the first interface and the third interface are divided into the same group. In this group, the order in which the first interface is called must precede the order in which the third interface is called. Repeat the above process for all ungrouped interfaces until all interfaces are grouped.

[0087] For example, assume that a program segment includes the following interfaces and their dependencies: Interface A: No dependencies. Interface B: Depends on the output parameters of interface C. Interface C: Depends on interface B. Interface D: Depends on interface E. Interface E: Depends on the output parameters of interface D. Interface A has no dependencies on any other interfaces, so A is grouped separately: Group 1: [A]. Interface B depends on the output parameters of interface C, so B and C are grouped together, ensuring that C is called before B: Group 2: [C, B]. Interface D is dependent on interface E, so D and E are grouped together, ensuring that D is called before E: Group 3: [D, E].

[0088] In the embodiment of the present application, there is no dependency between interfaces in different groups and they can be called in parallel, thereby reducing the total execution time. Interfaces in the same group are executed in the order of dependency to ensure data consistency and correctness of program segments.

[0089] In step 103, interfaces in multiple groups are called in parallel to obtain data returned by the interface in each group.

[0090] Here, an independent first thread can be assigned to each group to ensure a one-to-one correspondence between first threads and groups. Multiple first threads can concurrently call interfaces in multiple groups to obtain data returned by interfaces in each group. All first threads are started, and multiple first threads begin executing simultaneously. For each first thread, all interfaces in the group corresponding to the first thread are called sequentially in the order of their dependencies, and the data returned by each interface is collected.

[0091] In some embodiments, see Figure 5 , Figure 5It is shown that in step 103, interfaces in multiple groups are called in parallel to obtain data returned by the interfaces in each group. This can be achieved by following the steps 1031 to 1033:

[0092] In step 1031 , for each group, the input data of the program segment is queried.

[0093] Here, for each group, when the first thread corresponding to the group is started, the input data of the program segment is first queried. The input data can come from an external business request (such as order information submitted by the user, product ID, etc.). The input data in the business request submitted by the user is stored in the context, and the input data is queried from the context. It should be noted that if the first interface in the group does not require additional input data, this step can be skipped directly.

[0094] In step 1032, the first interface in each group is called based on the input data to obtain data returned by the first interface.

[0095] Here, for each group, the first interface in the group obtains input data from the context, calls the first interface in the group based on the input data, obtains the data returned by the first interface, and stores the data returned by the first interface in the context and cache at the same time.

[0096] It should be noted that if the group includes only one interface, after executing step 1032, step 1033 is no longer executed.

[0097] In step 1033, the n+1th interface in the group is called based on the data returned by the nth interface to obtain the data returned by the n+1th interface.

[0098] Wherein, n is a positive integer that increases in sequence, 1≤n<N, and N is the number of interfaces in the group.

[0099] Here, the other interfaces in the group are called in order of dependency, and the data returned by each interface is collected. Assuming there are N interfaces in the group (N≥2), each interface is called in sequence, starting with the second interface. For the n+1th interface (1≤n<N), the data returned by the nth interface is obtained from the context, and the data returned by the nth interface is used as the input parameter to call the n+1th interface to obtain the data returned by the n+1th interface. The data returned by the n+1th interface is stored in both the context and the cache.

[0100] For example, group 1: [A], group 2: [C, B], group 3: [D, E]. Thread 1 corresponds to group 1, thread 2 corresponds to group 2, and thread 3 corresponds to group 3. Threads 1, 2, and 3 start at the same time. Thread 1 queries the input data of the program segment, assuming that the product ID is 12345. Thread 1 calls interface A in group 1, passes in product ID = 12345, and obtains the data returned by interface A (such as inventory quantity = 10). Group 1 has only one interface and no further calls are required. Thread 2 queries the input data of the program segment, assuming that the product ID is 12345. Thread 2 calls interface C in group 2, passes in product ID = 12345, and obtains the data returned by interface C (such as product price = 100). Based on the product price = 100 returned by interface C, thread 2 calls interface B and obtains the data returned by interface B (such as order total price = 110).

[0101] In the embodiment of the present application, each thread in its corresponding group calls the interface in sequence according to the dependency relationship, ensuring the consistency of data and the correctness of the program segment. The interfaces between different groups are called in parallel through multi-threading, which significantly reduces the total execution time. By using recursive calling (calling the n+1th interface based on the data returned by the nth interface), the logic of interface calling is simplified and the complexity is reduced.

[0102] In some embodiments, calling the n+1th interface in the group based on the data returned by the nth interface to obtain the data returned by the n+1th interface can be achieved in the following way: first, based on the data format of the input parameters of the n+1th interface, performing data conversion on the data returned by the nth interface to obtain the converted data; then, calling the n+1th interface based on the converted data to obtain the data returned by the n+1th interface.

[0103] Here, the input parameters of each interface have a specific data format. The data format may include data type, number of data bits, etc. The n+1th interface depends on the nth interface, but the data format of the input parameters of the n+1th interface may be different from the data format of the output parameters of the nth interface. Therefore, the output parameters of the nth interface cannot be directly used as the input parameters of the n+1th interface. Instead, the data returned by the nth interface needs to be converted based on the data format of the input parameters of the n+1th interface. Data conversion may include data type conversion, data bit completion, etc.

[0104] For example, the output parameters of the second interface include a "Product Code" field, and the value of the "Product Code" field is 4 digits. The data format of the "Product Code" field in the input parameters of the third interface is 6 digits. The product code output by the second interface is padded to obtain the padded 6-digit product code. Based on the 6-digit product code, the three interfaces are called to obtain the data returned by the third interface.

[0105] Similarly, for the second interface in the group, based on the data format of the second interface's input parameters, the data returned by the first interface is converted to obtain the converted data. Based on the converted data, the second interface is called to obtain the data returned by the second interface.

[0106] In this embodiment, even if the data formats of different interfaces are inconsistent, data conversion can ensure seamless cooperation between them. When the input or output format of the interface changes, only the data conversion logic needs to be adjusted without modifying the entire call process, thereby improving the stability and efficiency of program segment execution.

[0107] In some embodiments, if the n+1th interface in the group is called based on the data returned by the nth interface and no data returned by the n+1th interface is obtained, the n+1th interface is re-called. If the number of times the n+1th interface is re-called reaches a number threshold, the calling of the n+1th to Nth interfaces in the group is stopped, and the default data is determined to be the data returned by the n+1th to Nth interfaces.

[0108] Here, in actual applications, the interface call may fail due to network problems, service unavailability or other abnormal situations. For each thread, in the process of the thread calling the n+1th interface in the group based on the data returned by the nth interface, check whether the data returned by the n+1th interface is successfully obtained. If the return data is not obtained, the n+1th interface is re-called based on the preset retry cycle (i.e., the interval between each retry). Each time it is re-called, the current number of calls is recorded, and an attempt is made to call the n+1th interface again. If the re-call is successful and the return data is obtained, continue to call the next interface in the group. If the number of re-calls reaches a threshold (such as 3 times) and the return data of the n+1th interface is still not successfully obtained, stop calling all interfaces from the n+1th interface to the Nth interface in the group. The pre-defined default data is used as the return data from the n+1th interface to the Nth interface, and the return data is stored in the context and cache. It should be noted that the embodiment of the present application does not specifically limit the retry cycle, number threshold and default data, which can be set based on actual needs. The default data corresponding to each interface can be the same or different.

[0109] Similarly, if the second interface in the group is called based on the data returned by the first interface and no data is returned from the second interface, the second interface is called again. If the number of times the second interface is called again reaches the threshold, the calls to the second through Nth interfaces in the group are stopped, and the default data is determined to be the data returned by the second through Nth interfaces.

[0110] In the embodiments of the present application, even if some interface calls fail, the system will not be completely interrupted. Instead, the normal operation of the program segment is guaranteed by re-calling or using default data. When a certain interface call fails, calling subsequent dependent interfaces is immediately stopped to prevent the error from spreading further, thereby reducing the complexity of the system. When the program segment executes to the corresponding interface, it does not need to call the remote service again and uses the default data instead, achieving the purpose of rapid failure and reducing the service call time consumption.

[0111] In step 104, a program segment is executed based on the data returned by the interface in each packet.

[0112] Here, the data returned by the interface in each group is stored in a cache. A second, independent thread retrieves the data returned from the cache and runs the program segment based on the data returned by the interface. This eliminates the need for the program segment to query the remote service during execution, improving execution efficiency. Furthermore, other systems or other program segments can directly use the data stored in the cache.

[0113] The embodiment of the present application can identify the dependency between interfaces by analyzing the input parameters and output parameters of the interface. Based on the dependency, the interface is divided into multiple groups to ensure that there is a dependency between the interfaces in each group, and the interfaces between different groups do not affect each other during the call process. By using multi-threaded parallel calling of interfaces in multiple groups, the interfaces in multiple groups can run simultaneously, reducing the total time of interface calls. At the same time, the program segment runs based on the data returned by all interfaces, and no longer needs to call the interface one by one according to the dependency, which greatly shortens the overall processing time of the program segment and improves the operation efficiency of the program segment.

[0114] The following describes an exemplary application of the embodiments of the present application in a practical application scenario.

[0115] The present invention provides a data processing method, which is a method for accurately querying data and improving efficiency. Figure 6 It is a schematic diagram of the framework of the data processing method provided in the embodiment of the present application.

[0116] Step 601: Establishing interface field dependency.

[0117] Here, step 601 is a prerequisite for the embodiment of the present application. The interface mainly consists of three parts: the interface name, which represents the function of the interface. The interface input parameters (corresponding to the input parameters in the above embodiment), which are the parameters that the interface relies on from the outside during its internal operation. The interface return value (corresponding to the output parameters in the above embodiment), is the result returned after the interface is executed. The output of the interface will be used as the input of the subsequent interface, which means that the two interfaces have a dependency relationship. The input parameters of the interface can be used to check the output parameters of the corresponding interface, and then the dependent interface can be found to establish a dependency relationship between the interfaces.

[0118] Figure 7 This is a schematic diagram of the dependency relationship between interfaces provided in the embodiment of this application. Figure 7 The input and output parameters of an interface both include multiple fields. For example, the input parameters of interface 1 include fields 1 and 2. The output parameters of interface 1 include fields 3 and 4. The output parameters of an interface require certain conversions before they can be used by the dependent interface. Fields 1 and 2 are converted according to the dependent field processing rules before being input into interface 1. Fields 3 and 4 are converted according to the dependent field processing rules before being input into interface 2. There is a dependency relationship between interface 1 and interface 2. The output parameters of interface 2 include fields 5 and 6.

[0119] Exemplarily, the dependent field processing rule (corresponding to the data format in the above embodiment) can be a data bit completion rule. The product code output by interface A is 4 bits, and the product code dependent on interface B requires 6 bits, so the product code needs to be completed. For the product code field that interface B depends on, it is necessary to configure the data bit completion rule. The dependent field processing rule can be a state conversion rule. The status field output by interface A is Y or N, and the status field dependent on interface B requires 0 or 1. Therefore, the status field that interface B depends on needs to be configured with a state conversion rule.

[0120] Step 602: Scan the interface.

[0121] Here, during the running process, step 602 is executed to scan all interfaces in the functional module (corresponding to the program segment in the above embodiment) based on the ASM tool. Figure 8 This is a schematic diagram of the code framework provided by the embodiment of this application. Figure 8, the client 801 sends a request (for example, a Hypertext Transfer Protocol (HTTP) request) to the server 802. The server 802 includes a functional module layer 803 (Controller layer, corresponding to the business layer in the above embodiment), a service layer 804 (Service layer) and a remote layer 805 (Remote layer). The functional module layer 803 is the entrance for the functional module processing system external call in the embodiment of the present application. The functional module layer 803 includes multiple external interfaces (corresponding to the program segments in the above embodiment): external interface 1, external interface 2, and external interface 3. Each external interface is an independent functional module. The service layer is the core business implementation layer and provides services for the functional module layer. The service layer is responsible for calling the dependent remote services and processing and calculating the results. Each logical interface depends on multiple remote service interfaces. The service layer 804 includes multiple logical interfaces: logical interface 1, logical interface 2, and logical interface 3, etc. The remote layer 805 is responsible for external system calls, shielding the external system response status code and data structure differentiation, and is the main time-consuming layer of the system. The remote layer 805 includes multiple remote service interfaces: remote service interface 1, remote service interface 2, remote service interface 3, remote service interface 4, remote service interface 5, remote service interface 6, etc. Each remote service interface sends a remote service request to the corresponding remote service. For example, remote service interface 1 sends a remote service request to remote service A.

[0122] Figure 9 This is a flow chart of the interface scanning process provided by the embodiment of the present application. Figure 9 , step 901, start scanning from the functional module layer.

[0123] When the system starts, an interface scanning tool (such as an ASM tool) scans all external interfaces of the functional module layer.

[0124] Step 902: traverse the methods contained in the functional module layer.

[0125] Among them, the methods contained in the functional module layer are the external interfaces.

[0126] Step 903: Drill down based on the bytecode to find the logical interface of the functional module layer that depends on the service layer.

[0127] Among them, the external interface in the functional module layer includes the logical interface call of the service layer. According to the class path of the dependent service layer logical interface (corresponding to the first class path information in the above embodiment), the corresponding class and interface are found based on the ASM parsing tool, which is bytecode drilling.

[0128] Step 904: Continue drilling down to find the remote service interface of the remote layer that the service layer depends on.

[0129] Similarly, the interface logic of the service layer is processed by calling the remote service interface of the remote layer. Continue drilling down until all remote service interfaces that depend on the remote layer are found.

[0130] Step 905: Establish a dependency relationship between each external interface of the functional module layer and the remote service interface in the remote layer.

[0131] Among them, the dependency relationship between the functional modules and the remote service interfaces is generated, for example, {external interface 1, [remote service interface 1, remote service interface 2, remote service interface 3, remote service interface 4, ...]}.

[0132] Step 603: divide the interface into buckets.

[0133] Here, all interfaces contained in the functional module are bucketed according to their dependencies. Figure 10 This is a schematic diagram of the interface bucketing provided in the embodiment of this application. Figure 1 See also Figure 10 , external interface 1 (corresponding to the program segment in the above embodiment) includes remote service interfaces 1-10 (corresponding to all interfaces included in the program segment in the above embodiment). Remote service interface 1, remote service interface 3, and remote service interface 5 have a dependency relationship. Remote service interface 1, remote service interface 3, and remote service interface 5 are divided into a bucket (corresponding to the grouping in the above embodiment): bucket 1. Similarly, bucket 2 includes remote service interface 2, remote service interface 8, and remote service interface 9. Bucket 3 includes remote service interface 4, remote service interface 6, remote service interface 7, and remote service interface 10.

[0134] Figure 11 This is a schematic diagram of the interface bucketing provided in the embodiment of this application. Figure 2 See also Figure 11 , based on the input parameters (input parameters) and output parameters (output parameters) of the interface (hereinafter referred to as the remote service interface), dependencies are established and bucketed based on the dependencies. Each group of independent interfaces is a bucket, and the interfaces in the bucket are ordered. Taking bucket 3 as an example, first put interface 6 into bucket 1, and match the input parameters of interface 6 with the output parameters of interface 4. Interface 6 depends on interface 4, so interface 4 is inserted before interface 6 in bucket 3. The input parameters of interface 4 match the input parameters of the functional module, so interface 4 does not depend on any other interface, so there is no upward search. The output parameters of interface 4 are only used by interface 6, and the search is completed. The output parameters of interface 6 match the input parameters of interface 10 and interface 7, and interface 10 and interface 7 are inserted after interface 6 in sequence. After searching for dependencies through the input and output parameters of interface 10, it is found that interface 10 depends on interface 7, so interface 7 is inserted before interface 10. Interface 10 and interface 7 no longer depend on other interfaces and are not depended by other interfaces, and bucketing of bucket 3 is completed.

[0135] Step 604: The thread pool executes the buckets in parallel.

[0136] Here, when the service request arrives at external interface 1, the bucket corresponding to interface 1 is queried based on interface 1. Figure 12 This is a schematic diagram of the thread pool parallel execution bucket provided by the embodiment of this application. Figure 12 The system's main thread consists of two independent threads: an interface bucket thread (corresponding to the first thread in the above embodiment) and a code block thread (corresponding to the second thread in the above embodiment). Each bucket (bucket 1, 2, and 3) executes concurrently using an independent interface bucket thread to improve the efficiency of the code block (functional module). After all buckets have completed execution, an independent code block thread is used to execute the functional module program.

[0137] Figure 13 This is a schematic diagram of the bucket execution provided by the embodiment of this application. Figure 13 First, the function module receives externally transmitted input parameters and stores them in context 1301. Taking the execution process of bucket 1 as an example, the input parameters of the first executed interface 1 in bucket 1 are the function module input parameters, which are obtained from the context. The obtained function module input parameters are processed according to the input parameter calculation rules, and a call to interface 1 is initiated based on the processed input parameters.

[0138] Step 605: Retry if failed.

[0139] Here, if the interface cannot query data due to a possible delay in data generation or network jitter, the interface will be retried in a failure cycle. Figure 14 This is a schematic diagram of the retry mechanism provided in the embodiment of the present application. Figure 14 For example, interface 1 is re-executed every 3 seconds, for a total of 3 times. The retry interval and number of times for each interface can be set according to different scenarios. If interface 1 fails to query the data, it means that the data in bucket 1 is not accurate. For subsequent interfaces 3 and 5 as well as interface 1, the default value (corresponding to the default data in the above embodiment) is stored in the cache (redis). When the functional module executes the corresponding interface, it does not need to call the remote service but uses the default value, so as to achieve the purpose of fast failure and reduce the service call time consumption. Similarly, if interface 1 successfully obtains data and interface 3 fails to obtain data successfully, interface 3 and interface 5 can also fail quickly.

[0140] Step 606: The interface result is stored in the context and cache.

[0141] Here, if the interface call is successful, the data returned by interface 1 is stored in context 1301 and cache 1302 (redis). The result written to the context is for subsequent dependent interface calls; when writing to the cache, the input parameter value and interface name are used as the key value, and the returned data is used as the value. This is used by the original function module at runtime, so that the function module does not need to query the remote service when it is actually executed. At the same time, other systems or other function blocks can also reuse the value stored in redis.

[0142] Repeat the above process until all buckets are executed.

[0143] Step 607: The actual function module runs.

[0144] Here, in the result application, the function module logic is executed. Since the data that the function module depends on is in the cache, no external interface is called, and the execution speed is very fast.

[0145] The embodiment of the present application is completely non-invasive to the original code, and the functional module processing method provided by the embodiment of the present application can be applied to both existing business functions and newly added business functions. In the embodiment of the present application, interface grouping (i.e., "bucketing") is implemented by scanning bytecode files (.class files) based on the ASM framework. Each time the system starts, the interface dependencies and related configurations are dynamically scanned and updated. Therefore, when the business logic changes (such as adding a new interface or modifying the logic processing), there is no need to manually adjust the interface information configured in the functional module, and the system can automatically adapt to these changes. This method not only significantly saves manpower maintenance costs, but also effectively avoids the problem of missing interfaces due to frequent system changes, ensuring the comprehensiveness and accuracy of interface scanning.

[0146] In the embodiment of the present application, the interfaces that were originally executed serially in the code block (functional module) are divided into buckets to establish interface dependencies, and are executed in parallel according to the buckets, thereby improving the efficiency of the functional blocks. The effect is more significant for functional blocks with higher complexity and stronger interface opposition. The functional module took 1S+ before optimization and about 20ms after optimization, with a performance improvement of more than 95%. In the embodiment of the present application, by introducing buckets and interface failure retries, the integrity of the functional module fields is increased from the original incomplete rate of 85% to 98%. When the frontmost interface in the bucket cannot query data, the default value is used to achieve fast failure, reduce subsequent interface calls to remote services, improve interface response time in the event of network jitter or data producer failure, and enhance the stability of central processing unit (CPU) resource utilization.

[0147] It should be noted that in the embodiment of the present application, dependent interfaces can be marked in the external interface layer. In this way, when the service layer logic changes, dependent interfaces need to be manually added, which is easy to miss. In the embodiment of the present application, the order of interfaces in the bucket can also be based on linked list layering, that is, multiple dependent interfaces of an interface form a linked list and are inserted before the interface. The interfaces in the linked list are then arranged in the order of dependency.

[0148] The following continues to describe the exemplary structure of the data processing device 233 provided in the embodiment of the present application implemented as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the function module processing device 233 of the memory 230 may include:

[0149] The determination module 2331 is used to determine the dependency relationship between interfaces based on the input parameters and output parameters of each interface called by the program segment.

[0150] The grouping module 2332 is used to group interfaces with dependencies into a group according to the dependencies between the interfaces.

[0151] The calling module 2333 is used to call the interfaces in multiple groups in parallel to obtain the data returned by the interfaces in each group.

[0152] The running module 2334 is used to run the program segment based on the data returned by the interface in each group.

[0153] In some embodiments, the calling module 2333 is also used to query the input data of the program segment for each group; based on the input data, the first interface in each group is called to obtain the data returned by the first interface; based on the data returned by the nth interface, the n+1th interface in the group is called to obtain the data returned by the n+1th interface, where n is a positive integer that increases in sequence, 1≤n<N, and N is the number of interfaces in the group.

[0154] In some embodiments, the calling module 2333 is also used to re-call the n+1th interface if the n+1th interface in the group is called based on the data returned by the nth interface, and no data returned by the n+1th interface is obtained; if the number of times the n+1th interface is re-called reaches a threshold number, stop calling the n+1th interface to the Nth interface in the group, and determine the default data as the data returned by the n+1th interface to the Nth interface.

[0155] In some embodiments, the calling module 2333 is also used to perform data conversion on the data returned by the nth interface based on the data format of the input parameters of the n+1th interface to obtain the converted data; and call the n+1th interface based on the converted data to obtain the data returned by the n+1th interface.

[0156] In some embodiments, the grouping module 2332 is also used to treat the first interface that is not grouped among multiple interfaces as a group if the first interface has no dependency relationship with each interface; if it is determined based on the dependency relationship that the first interface depends on the second interface among multiple interfaces, the first interface and the second interface are divided into the same group, and the calling order of the second interface in the group is prior to the calling order of the first interface; if it is determined based on the dependency relationship that the first interface is dependent on the third interface among multiple interfaces, the first interface and the third interface are divided into the same group, and the calling order of the first interface in the group is prior to the calling order of the third interface.

[0157] In some embodiments, the data processing device 233 also includes an interface determination module, which is used to extract first-class path information from the bytecode file of the program segment, and determine the logical interface called by the program segment in the service layer based on the first-class path information; extract second-class path information from the bytecode file of the logical interface, and determine the remote service interface called by the logical interface in the remote layer based on the second-class path information; and determine the remote service interface as the interface called by the program segment.

[0158] An embodiment of the present application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the data processing method described in the embodiment of the present application.

[0159] The embodiment of the present application provides a computer-readable storage medium in which computer-executable instructions or computer programs are stored. When the computer-executable instructions or computer programs are executed by a processor, the processor will execute the data processing method provided in the embodiment of the present application, for example, Figure 3 The data processing method is shown.

[0160] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

[0161] In some embodiments, computer-executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0162] By way of example, computer-executable instructions can include but are not limited to: a) program modules, b) program data, and c) program libraries.

[0163] By way of example, computer-executable instructions can be deployed to be executed by using one electronic device or by using multiple electronic devices that are located at one site or that are distributed across multiple sites and that are interconnected by a communication network.

[0164] In summary, the embodiments of the present application can improve the efficiency of program segment running.

[0165] The above merely provides an example of the embodiments of the present application, but is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, and improvement within the spirit and scope of the present application shall be included in the protection scope of the present application.

Claims

1. A data processing method, characterized in that: The method comprises: Determining dependencies between interfaces based on input parameters and output parameters of each interface called by the program segment; According to the dependency relationship between the interfaces, the interfaces with the dependency relationship are grouped into a group; Calling multiple interfaces in the group in parallel to obtain data returned by each interface in the group; The program segment is executed based on the data returned by the interface in each of the packets.

2. The method according to claim 1, characterized in that The calling of the interfaces in the plurality of groups in parallel to obtain data returned by the interfaces in each group includes: For each of the groups, query the input data of the program segment; Calling the first interface in each of the groups based on the input data to obtain data returned by the first interface; Based on the data returned by the nth interface, the n+1th interface in the group is called to obtain the data returned by the n+1th interface, where n is a positive integer that increases successively, 1≤n<N, and N is the number of interfaces in the group.

3. The method according to claim 2, characterized in that The method further comprises: If the n+1th interface in the group is called based on the data returned by the nth interface, and no data is returned by the n+1th interface, the n+1th interface is called again; If the number of times the n+1th interface is re-called reaches a threshold, the calling of the n+1th to Nth interfaces in the group is stopped, and the default data is determined to be the data returned by the n+1th to Nth interfaces.

4. The method according to claim 2, characterized in that The calling of the (n+1)th interface in the group based on the data returned by the (n)th interface to obtain the data returned by the (n+1)th interface includes: Performing data conversion on the data returned by the nth interface based on the data format of the input parameters of the n+1th interface to obtain converted data; The n+1th interface is called based on the converted data to obtain data returned by the n+1th interface.

5. The method according to claim 1, wherein The method of grouping the interfaces having the dependency relationship into a group according to the dependency relationship between the interfaces includes: For a first interface that is not grouped among the multiple interfaces, if the first interface has no dependency relationship with each interface, the first interface is grouped; If it is determined based on the dependency relationship that the first interface depends on a second interface among the multiple interfaces, the first interface and the second interface are grouped into the same group, and the calling order of the second interface in the group is earlier than the calling order of the first interface; If it is determined based on the dependency relationship that the first interface is dependent on a third interface among the multiple interfaces, the first interface and the third interface are divided into the same group, and the calling order of the first interface in the group is prior to the calling order of the third interface.

6. The method according to claim 1, characterized in that The method further comprises: Extracting first type path information from the bytecode file of the program segment, and determining a logical interface called by the program segment in the service layer based on the first type path information; Extracting second-type path information from the bytecode file of the logical interface, and determining a remote service interface called by the logical interface in the remote layer based on the second-type path information; The remote service interface is determined as the interface called by the program segment.

7. A data processing device, characterized in that: The device comprises: A determination module, configured to determine the dependency relationship between the interfaces based on the input parameters and output parameters of each interface called by the program segment; A grouping module, configured to group interfaces having dependencies into a group according to the dependencies between the interfaces; A calling module, configured to call the interfaces in the plurality of groups and obtain data returned by the interfaces in each group; The running module is used to run the program segment based on the data returned by the interface in each of the groups.

8. An electronic device, characterized in that: The electronic device comprises: a memory for storing computer-executable instructions or computer programs; The processor is configured to implement the data processing method according to any one of claims 1 to 6 when executing the computer-executable instructions or computer programs stored in the memory.

9. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that: When the computer executable instructions or computer program are executed by a processor, the data processing method according to any one of claims 1 to 6 is implemented.

10. A computer program product comprising computer executable instructions or a computer program, characterized in that When the computer executable instructions or computer program are executed by a processor, the data processing method according to any one of claims 1 to 6 is implemented.

Images