Request execution method, SDN system, SDN server and storage medium

Abstract

The embodiments of the present application provide a request execution method, an SDN system, an SDN server, and a storage medium, wherein the method includes: obtaining a first API request; determining the tag data of each relevant instance resource of the first API request; wherein the tag data of a relevant instance resource of an API request at least records the locking status of a relevant instance resource of the API request, and the lifecycle of the tag data of each relevant instance resource of an API request corresponds to the lifecycle of the API request; determining the execution status of the first API request based on the locking status of each relevant instance resource of the first API request and the tag data of each relevant instance resource in a second API request; wherein the second API request is a historical API request whose request time is earlier than that of the first API request and whose execution failed. The embodiments of the present application can improve the request execution performance of the SDN controller.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of network technology, and in particular to a request execution method, an SDN system, an SDN server, and a storage medium. Background Art

[0002] As a way to implement network virtualization, SDN (Software Defined Network) can separate the data plane from the control plane and achieve flexible control of network traffic.

[0003] An SDN controller, the software that manages the network within the control plane of an SDN system, can have multiple instance resources. When a user requests an SDN service, the SDN controller operates on its instance resources based on the user's request to execute it. In this context, improving the request execution performance of SDN controllers has become a pressing technical challenge for those skilled in the art. Summary of the Invention

[0004] In view of this, embodiments of the present application provide a request execution method, an SDN controller, a server, and a storage medium to improve the request execution performance of the SDN controller.

[0005] To achieve the above objectives, the embodiments of the present application provide the following technical solutions.

[0006] In a first aspect, an embodiment of the present application provides a request execution method, comprising:

[0007] Get the first API request;

[0008] Determining tag data for each instance resource associated with the first API request; wherein the tag data for each instance resource associated with an API request at least records a lock status of the instance resource associated with the API request, and the lifecycle of the tag data for each instance resource associated with an API request corresponds to the lifecycle of the API request;

[0009] The execution status of the first API request is determined based on the locking status of each related instance resource of the first API request and the tag data of each related instance resource in the second API request; wherein, the second API request is a historical API request whose request time is earlier than the first API request and whose execution failed.

[0010] In a second aspect, an embodiment of the present application provides an SDN system, comprising: an application layer, a control layer, and a data layer; the application layer is provided with an application management platform, and the application management platform is deployed with user applications; the control layer is provided with an SDN controller for managing the SDN network, the SDN controller having multiple instance resources, and there is a dependency relationship between the instance resources; the control layer is provided with multiple forwarding components for forwarding data packets, and the forwarding components are controlled by the SDN controller;

[0011] The SDN controller is configured to:

[0012] Obtaining an API request for a user to call an SDN service transmitted by an application management platform; obtaining instance resources related to the API request based on a target instance resource operated by the API request and an instance resource associated with the target instance resource;

[0013] Creating tag data for each instance resource associated with the API request; wherein the tag data for each instance resource associated with an API request at least records a lock status of the instance resource associated with the API request, and the lifecycle of the tag data for each instance resource associated with an API request corresponds to the lifecycle of the API request;

[0014] The execution status of the API request is determined based on the locking status of each related instance resource of the API request and the tag data of the previous API request that failed to execute for each related instance resource; wherein the failed API request is saved by the SDN controller and re-attempted to execute at a regular interval.

[0015] In a third aspect, an embodiment of the present application provides an SDN system, which includes: multiple forwarding components and an SDN controller, wherein the SDN controller is configured to execute the request execution method as described in the first aspect above.

[0016] In a fourth aspect, an embodiment of the present application provides an SDN server, comprising: at least one memory and at least one processor; the memory stores one or more computer-executable instructions, and the processor calls the one or more computer-executable instructions to execute the request execution method described in the first aspect above.

[0017] In a fifth aspect, an embodiment of the present application provides a storage medium, which stores one or more computer-executable instructions. When the one or more computer-executable instructions are executed, the request execution method described in the first aspect above is implemented.

[0018] In a sixth aspect, an embodiment of the present application provides a computer program, which, when executed, implements the request execution method described in the first aspect above.

[0019] An embodiment of the present application can set the tag data of each relevant instance resource of the API request when the API request is generated, and remove the tag data of each relevant instance resource of the API request when the API request is successfully executed, so that the life cycle of the tag data of each relevant instance resource of an API request corresponds to the life cycle of the API request, wherein the tag data of a relevant instance resource of an API request at least records the locking status of a relevant instance resource of the API request; thus, when obtaining the first API request and currently attempting to execute the first API request, the embodiment of the present application can determine the tag data of each relevant instance resource of the first API request and obtain the locking status of each relevant instance resource of the first API request; further, based on the locking status of each relevant instance resource of the first API request and the tag data of each relevant instance resource in the second API request, determine the execution status of the first API request to determine whether the first API request is successfully executed or failed when currently attempted to execute, wherein the second API request is a historical API request whose request time is earlier than the first API request and which fails to execute.

[0020] Because the embodiment of the present application combines the lock status of each related instance resource of the first API request and the tag data corresponding to the second API request whose request time is earlier than the first API request but whose execution fails, the embodiment of the present application can combine the related instance resources of the first API request, the lock status of the first API request, and the tag data of the second API request whose request time is earlier than the first API request but whose execution fails, to comprehensively consider the instance resource preemption of the first API request, thereby reasonably determining the current execution status of the first API request, avoiding the execution time consumed by the incorrect execution of the first API request, and improving the execution performance of the API request. For example, the embodiment of the present application can disperse the lock preemption time consumed by different API requests on the same instance resource, avoid the incorrect execution of the first API request when the related instance resource of the first API request is not locked but is locked by a previously unsuccessful API request, and avoid the incorrect execution of the first API request when the related instance resource of the first API request is locked and is set with tag data by a previously unsuccessful API request, thereby comprehensively improving the efficiency of the SDN controller in executing API requests and improving the execution performance of the SDN controller. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0022] Figure 1 This is an example diagram of an SDN system.

[0023] Figure 2A This diagram shows an example of instance resources for an SDN controller.

[0024] Figure 2B This is an example diagram of the instance tree of the SDN controller.

[0025] Figure 3A This is an example diagram of multiple pieces of tag data corresponding to an API request provided in an embodiment of the present application.

[0026] Figure 3B An example diagram of label data corresponding to multiple API requests provided in an embodiment of the present application.

[0027] Figure 4 A flowchart of a request execution method provided in an embodiment of the present application.

[0028] Figure 5 A flowchart of a method for determining the execution status of a first API request provided in an embodiment of the present application.

[0029] Figure 6 A flowchart of another method for determining the execution status of a first API request provided in an embodiment of the present application.

[0030] Figure 7 A simplified example diagram of tag data corresponding to the API request provided in an embodiment of the present application.

[0031] Figure 8 A block diagram of a request execution device provided in an embodiment of the present application.

[0032] Figure 9 Another block diagram of the request execution device provided in an embodiment of the present application.

[0033] Figure 10 This is a block diagram of an SDN server. DETAILED DESCRIPTION

[0034] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0035] Based on the idea of SDN to separate the data plane and the control plane, Figure 1 An example diagram of an SDN system is shown as follows: Figure 1 As shown, the SDN system may include: a plurality of forwarding components 110 located at the data plane, an SDN controller 120 located at the control plane, and an SDN network application 130 located at the application plane.

[0036] The forwarding components of the data plane are primarily responsible for forwarding data packets. Forwarding components include virtual switches and the hardware that hosts them. The SDN controller of the control plane can be software that manages the network, maintains global network information, and controls various forwarding rules. For example, the SDN controller can be responsible for programming forwarding components, including publishing entries and management rules, to enable rapid network deployment. The SDN network applications of the application plane can be user-deployed SDN-based network applications. Users can program and deploy new applications on the application plane based on their needs without having to worry about the underlying SDN details. The SDN network applications of the application plane can be managed by the SDN controller of the control plane.

[0037] Based on the idea of separating the data plane and control plane in SDN, the forwarding components of the data plane (for example, virtual switches) can focus on the task of forwarding data packets, and the controller software of the control plane (for example, SDN controllers) can efficiently manage a wide variety of forwarding applications (for example, SDN network applications), thereby achieving flexible control of network traffic and making the SDN system more intelligent.

[0038] The SDN architecture can be applied to many fields such as enterprise networks, data centers, and cloud networks. In the field of cloud networks, VPC (Virtual Private Cloud) can be implemented based on the SDN architecture. For example, the SDN controller of the control plane can be regarded as the VPC controller in the VPC, which is responsible for the Mapping Service. In the VPC, when virtual machines communicate with each other, the communication request can be transmitted to the Mapping Service, which searches for the information corresponding to the destination virtual machine (for example, the IP address of the host where the destination virtual machine is located), and the Mapping Service can encapsulate the information corresponding to the destination virtual machine into Overlay data and then transmit it. It should be noted that VPC, as a dynamically configured pool of public cloud computing resources, can use encryption protocols, tunneling protocols and other security programs to transmit data between users and servers in the cloud.

[0039] To implement SDN services, an SDN controller can have multiple instance resources, and there are dependencies between instance resources. In an example, to meet the needs of users deploying SDN network applications and implementing network data transmission, Figure 2A An example diagram of an SDN controller's instance resources is shown as follows: Figure 2A As shown, the instance resources with which the SDN controller has an affiliated relationship may include: an ECS (Elastic Compute Service) instance 210, multiple ENI (Elastic Network Interface) instances 220 affiliated with the ECS instance, and multiple auxiliary IP instances 230 affiliated with the ENI instance.

[0040] An ECS instance can be considered an ECS virtual server based on ECS. An ECS virtual server can be hosted on a physical machine. An SDN system can have multiple physical machines, and a physical machine can host one or more ECS virtual servers based on ECS. Thus, an SDN system can have multiple ECS instances. In one example, an SDN network application that a user needs to run can be deployed on an ECS virtual server, providing a carrier for the SDN network application.

[0041] An ENI instance can be considered the network egress of an ECS instance, such as an ENI network card bound to an ECS virtual server. In a VPC scenario, ENI, as a logical network component of the VPC, can be considered a virtual network card (i.e., an ENI network card). An ENI network card can be bound to an ECS virtual server, and an ECS virtual server can be bound to one or more ENI network cards, allowing one ECS instance to have one or more attached ENI instances.

[0042] A secondary IP instance is the IP address of an ENI instance and is used to increase the number of ENI instances that an ECS instance can have. For example, the number of ENI network cards on a single ECS virtual server is limited by the hardware resources of the physical machine corresponding to the ECS virtual server. Using a secondary IP address allows an ECS virtual server to have more network egresses. In one example, a secondary IP instance can be a sub IP address. A sub IP address can virtualize a physical interface into multiple logical interfaces through protocols and technologies, thereby increasing the number of network egresses on the ECS virtual server.

[0043] As can be seen, among the instance resources of the SDN controller, ECS instances, ENI instances, and auxiliary IP instances have a progressive dependency relationship. Based on the instance resources of the SDN controller with a dependency relationship, a corresponding instance tree can be constructed for the SDN controller. The instance tree can include multiple root instance resources. Under a root instance resource, there can be multiple hierarchical instance resources. The instance resources of the previous level serve as the parent instance resources of the instance resources of the next level. Correspondingly, the instance resources of the next level serve as the child instance resources of the instance resources of the previous level, and the instance resources of the last level serve as the leaf instance resources in the instance tree.

[0044] For ease of understanding, let's take the three-layer relationship of ECS instances, ENI instances, and auxiliary IP instances as an example. Figure 2B An example diagram of an instance tree of an SDN controller is shown as follows: Figure 2BAs shown, based on multiple ECS virtual servers in the SDN system, the instance tree can have multiple ECS instances, and the ECS instance can be regarded as the root instance resource of the instance tree; there are two levels of instance resources under an ECS instance, including multiple ENI instances attached to the ECS instance, and multiple auxiliary IP instances attached to each ENI instance; among them, the multiple ENI instances attached to an ECS instance serve as child instance resources of the ECS instance (correspondingly, the ECS instance is the parent instance resource of the ENI instance), and the multiple auxiliary IP instances attached to an ENI instance serve as child instance resources of the ENI instance (correspondingly, the ENI instance is the parent instance resource of the auxiliary IP instance), and in the three-level instance tree, the auxiliary IP instance can be regarded as the leaf instance resource of the instance tree.

[0045] Based on the instance resources of the SDN controller, when a user calls an SDN service, the user's request to call the SDN service may correspond to an operation on the instance resources. For example, a user can call an SDN service through an API (Application Programming Interface), and the API request corresponds to an operation on the instance resources in the instance tree.

[0046] Taking ECS instances, ENI instances, and auxiliary IP instances as examples, when users call SDN services through the API, they can operate on a specific instance resource in the instance tree. For example:

[0047] For ECS instances, when users call SDN services through APIs, they may perform operations such as creating, deleting, expanding (for example, expanding the data capacity corresponding to an ECS instance), reducing, migrating (for example, migrating an ECS instance between physical machines), starting, and stopping the ECS instance.

[0048] For ENI instances, when users call SDN services through APIs, they may perform operations such as creating, inserting (for example, inserting an ENI network card into an ECS virtual server), removing (for example, removing an ENI network card from an ECS virtual server), and deleting the ENI instance.

[0049] For auxiliary IP instances, when users call SDN services through APIs, they may perform operations such as adding and deleting auxiliary IP instances.

[0050] When users call SDN services through APIs, they may perform configuration changes on instance resources in the instance tree (for example, changing or adjusting the configuration of instance resources in the instance tree). As the number of API calls to the SDN controller increases, the SDN controller may have multiple API requests. At this time, when a certain API request performs a configuration change on an instance resource in the instance tree, in order to prevent other API requests from missing the configuration change result of the instance resource, the root instance resource corresponding to the instance resource of the configuration change operation needs to be locked to ensure data consistency of the instance tree between the configuration change operations of multiple API requests, so that the results of the instance resources of the instance tree in multiple configuration change operations meet user expectations, thereby ensuring that the service logic of SDN to users meets user expectations.

[0051] To facilitate understanding, as an example, take API request 1 for adding an auxiliary IP instance to an ENI instance in the ECS instance, and API request 2 for migrating the ECS instance to another physical machine. For API request 2, the SDN controller needs to copy all data of the ECS instance to another physical machine. If neither API request 1 nor API request 2 locks the ECS instance (the ECS instance is the root instance resource at this time), the data copied by API request 2 may or may not contain the newly added auxiliary IP instance; if the data copied by API request 2 does not contain the newly added auxiliary IP instance, when the ECS instance is migrated to another physical machine, the network corresponding to the newly added auxiliary IP instance will be unavailable due to the missing data of the newly added auxiliary IP instance, resulting in data inconsistency in the instance tree between the configuration operations of API request 1 and API request 2. In other words, the configuration operation results of API request 1 and API request 2 for the instance resources in the instance tree do not meet user expectations.

[0052] As can be seen, when performing a configuration change on instance resources in an instance tree, locking the root instance resource of the instance tree ensures data consistency across multiple API configuration changes, ensuring that the results of multiple configuration changes on the instance resources in the instance tree meet user expectations. For example, when allowing users to perform parallel configuration changes on multiple instance resources in an instance tree, to ensure data consistency across these operations, it is necessary to lock the root instance resource corresponding to the instance resource being modified.

[0053] However, with the development of cloud services, the various combinations of network products have become increasingly complex, which has caused the hierarchy of the SDN controller's instance tree to continue to extend. If each API request is locked to the root instance resource, this will result in a large number of API requests being processed serially on the root instance resource, which will create a bottleneck for the request execution performance of the SDN controller.

[0054] The inventors of this application discovered that for instance resources in the instance tree, not all changes in leaf instance resources need to be locked with each other, and not all changes in root instance resources require stopping API requests for all leaf instance resources under the root instance resource. Therefore, optimizing the sequential control of API request processing can effectively improve the request execution performance of the SDN controller and improve the user's SND service experience.

[0055] Based on this, the embodiments of the present application provide an improved request execution solution, which maintains the tag data of each instance resource related to the API request during the life cycle of the API request. The tag data can indicate the locking status of each instance resource related to the API request; thus, for multiple API requests, the embodiments of the present application can optimize the sequential control of the processing of multiple API requests based on the locking status of the instance resources related to the API request, thereby improving the request execution performance of the SDN controller.

[0056] Based on the above ideas, the embodiment of the present application can maintain the tag data of the instance resources related to the API request during the life cycle of the API request. For the sake of convenience, the embodiment of the present application refers to the instance resources related to the API request as the relevant instance resources of the API request. Optionally, the relevant instance resources of the API request can be the target instance resources operated by the API request, as well as the instance resources associated with the target instance resources. Therefore, there can be multiple relevant instance resources for an API request. If tag data is set for the relevant instance resources of an API request, then one API request can correspond to multiple tag data, and one tag data corresponds to one relevant instance resource of the API request.

[0057] For ease of explanation, the embodiment of the present application refers to the instance resource operated by the API request as the target instance resource; the instance resource associated with the target instance resource can be determined according to the specific type of the API and the actual situation, and the embodiment of the present application is not limited. In one example, the instance resource that has a blood relationship with the target instance resource can be regarded as the instance resource associated with the target instance resource, for example, the parent instance resource, child instance resource, collateral instance resource (such as instance resources belonging to the same parent instance resource, etc.) of the target instance resource.

[0058] For multiple tag data corresponding to an API request, a tag data may indicate the locking status of a related instance resource of the API request, and the content of a tag data record may at least include: request time, request identifier, instance identifier, and locking status.

[0059] Among them, the request time can be regarded as the time when the API request occurs, such as the time when the user calls the SDN service through the API. When the API request occurs, the embodiment of the present application can create tag data for the instance resources related to the API request, so the request time of the tag data can also be regarded as the creation time of the tag data. The life cycle of the multiple tag data corresponding to the API request is consistent with the life cycle of the API request, that is, when the API request occurs, the embodiment of the present application can create tag data for the instance resources related to the API request, and when the API request is successfully executed, the tag data for the instance resources related to the API request can be removed.

[0060] The request identifier can be used to uniquely identify an API request, such as a request ID of an API request.

[0061] The instance identifier can be used to uniquely identify an instance resource. Different instance resources have different instance identifiers. The instance identifier of an instance resource is, for example, the instance ID of the instance resource.

[0062] The lock status is used to indicate whether the instance resource is locked, and is divided into locked and unlocked. For a certain instance resource related to an API request, the embodiment of the present application can set the lock status of the instance resource to be locked or unlocked according to the specific scenario. Optionally, if the lock status of a certain instance resource related to an API request is set to locked, it means that the API request will cause the data of the related instance resource to change; if the lock status of a certain instance resource related to an API request is set to unlocked, it means that the API request does not directly operate the related instance resource, and multiple API requests corresponding to the unlocked instance resource can be executed in parallel.

[0063] In an optional implementation, an embodiment of the present application may set the lock state of the target instance resource of the API request operation to locked, and set the lock state of other instance resources in the related instance resources of the API request to unlocked; or, set the lock state of the target instance resource of the API request operation to locked, and set the lock state of the instance resource directly associated with the target instance resource to locked, and set the lock state of other instance resources in the related instance resources of the API request to unlocked. The instance resource directly associated with the target instance resource can be regarded as an instance resource that has a strong dependency on the target instance resource, such as the target instance resource's direct parent instance resource and child instance resource.

[0064] In another optional implementation, since not all changes to leaf instance resources need to be locked with each other, and not all changes to root instance resources need to stop API requests for leaf instance resources, the embodiment of the present application can determine the locking status of each related instance resource of the API request based on the API type corresponding to the API request and the type of instance resource to determine whether the locking status of each related instance resource of the API request is locked or unlocked, and is not limited to whether the instance resource is the target instance resource of the API request operation or an instance resource that has a strong dependency on the target instance resource. For example, taking ECS instances, ENI instances, and auxiliary IP instances as an example, if the related instance resources of the API request include ECS instances, ENI instances, and auxiliary IP instances, the embodiment of the present application can set the locking status of the auxiliary IP instance to locked, and set the locking status of the ECS instance and ENI instance to unlocked.

[0065] It should be noted that after determining multiple related instance resources of an API request, when setting label data for each related instance resource of the API request, the locking status of the instance resource indicated in the label data can be determined according to the specific scenario. The method of setting the locking status for the instance resource described above is only an optional method.

[0066] In a further example, if the locking state of the instance resource is set to locked, the example of the present application can be represented by a true value in the tag data; if the locking state of the instance resource is set to unlocked, the example of the present application can be represented by a false value in the tag data; for example, is_loceck represents the locking state, then is_loceck=true means locked, and is_loceck=false means unlocked.

[0067] To make it easier to understand the multiple tag data corresponding to an API request, as an example, Figure 3A The example diagram shows an example of multiple tag data corresponding to an API request provided in an embodiment of the present application, such as Figure 3A As shown, for API request 31, API request 31 can correspond to n tag data, representing the tag data of n related instance resources 311 to 31n of API request 31 in the instance tree. One tag data can record the request time of API request 31, the request ID of API request 31, the instance ID of a related instance resource of API request 31 in the instance tree, and the locking status of the related instance resource.

[0068] The lifecycle of multiple pieces of tag data corresponding to an API request is consistent with the lifecycle of the API request. When an API request occurs, the embodiment of the present application can set tag data for each related instance resource of the API request. When an API request is successfully executed, the multiple pieces of tag data corresponding to the API request will be removed. Since SDN services allow users to make concurrent API requests, the SDN system (such as the SDN controller in the SDN system) may have multiple API requests that have not been successfully executed at the same time. Accordingly, the tag data corresponding to the multiple API requests (one API request corresponds to multiple pieces of tag data) are also maintained in the SDN system.

[0069] To facilitate understanding and maintain label data corresponding to multiple API requests, Figure 3B The example diagram shows an example of label data corresponding to multiple API requests provided in the embodiment of the present application, such as Figure 3B As shown, the request queue can save multiple API requests that the SDN controller has not yet successfully executed, that is, the API requests that the SDN controller has not yet successfully executed can be placed in the request queue, the API requests that the SDN controller has successfully executed can be removed from the request queue, and the label data corresponding to the API requests that the SDN controller has successfully executed can be removed; taking the request queue to save API requests 31 to 3m as an example, since when an API request occurs, the embodiment of the present application can set multiple label data corresponding to the API request (that is, the label data of each related instance resource of the API request), and the life cycle of the multiple label data corresponding to the API request is consistent with the life cycle of the API request, then based on the fact that the API request that the SDN controller has not currently successfully executed is API requests 31 to 3m, the SDN controller can maintain the label data corresponding to API requests 31 to 3m respectively.

[0070] Combine Figure 3A and Figure 3B As shown, for API request 31, the SDN controller can maintain n pieces of label data corresponding to API request 31 (for example, label data of n related instance resources 311 to 31n of API request 31). For API request 32, the SDN controller can maintain multiple pieces of label data corresponding to API request 32 (label data of each related instance resource of API request 32). Similarly, for API request 3m, the SDN controller can maintain multiple pieces of label data corresponding to API request 3m (label data of each related instance resource of API request 3m). The method for setting label data of each related instance resource of an API request can be referred to the previous description and will not be expanded here.

[0071] Based on the tag data maintained by the SDN controller for multiple API requests that are not currently executed successfully, the embodiment of the present application can optimize the order control of multiple API requests in processing, thereby improving the request execution performance of the SDN controller. As an optional implementation, Figure 4 Schematically shows an optional flow chart of the request execution method provided in an embodiment of the present application. The method flow can be implemented by an SDN controller. Figure 4 The method flow may include the following steps.

[0072] In step S410, a first API request is obtained.

[0073] The first API request may be an API request currently being attempted to be executed, such as any API request currently being attempted to be executed.

[0074] Optionally, the first API request may be a newly generated API request, such as a newly generated API request when a user invokes an SDN service through an API. In one example, if the SDN system allows users to perform parallel operations on multiple instance resources, the SDN system may currently have multiple concurrent new API requests, and the first API request may be any of these multiple concurrent new API requests. Embodiments of the present application may attempt to execute the newly generated API request, thereby treating it as the first API request.

[0075] Optionally, the first API request may also be a historical API request that failed to be executed by the SDN controller. For example, according to the request execution method provided in the embodiment of the present application, the order of processing of API requests is controlled. Then, if the API request fails to execute, it can be periodically attempted to be re-executed, so that the API request currently being attempted to be re-executed can be regarded as the first API request. In one example, according to the request execution method provided in the embodiment of the present application, the order of processing of API requests is controlled. Then, if the API request fails to execute, it can be placed in a request queue (the request queue can save historical API requests that failed to execute), and the historical API requests in the request queue can be periodically attempted to be re-executed, so that the historical API request currently being attempted to be re-executed obtained from the request queue can be regarded as the first API request.

[0076] The content of the first API request may be determined based on the actual situation. In one example, the first API request may be to add an auxiliary IP instance to an ENI instance of an ECS instance, or to migrate an ECS instance from one physical machine to another, or to insert an ENI instance into an ECS instance (such as inserting an ENI network card).

[0077] In step S411, the tag data of each related instance resource of the first API request is determined; wherein, the tag data of a related instance resource of an API request at least records the locking status of a related instance resource of the API request, and the life cycle of the tag data of each related instance resource of an API request corresponds to the life cycle of the API request.

[0078] When an API request is generated, an embodiment of the present application can determine the various related instance resources of the API request, such as the target instance resource of the API request operation, and the instance resources associated with the target instance resource. Therefore, an embodiment of the present application can set label data for each related instance resource of the API request according to the specific scenario, and then record at least the locking status of each related instance resource of the API request through the label data of each related instance resource of the API request.

[0079] For example, for a newly generated API request, an embodiment of the present application can determine the various related instance resources of the API request, and set a lock status for each related instance resource of the API request; for each related instance resource of the API request, an embodiment of the present application can determine the tag data based on the request time of the API request, the request identifier of the API request, the instance identifier of the related instance resource, and the lock status of the related instance resource to obtain the tag data of each related instance resource of the API request.

[0080] That is, by setting tag data for each instance resource associated with an API request, and recording the request time of the API request, the request identifier of the API request, the instance identifier of the associated instance resource, and the lock status of whether the associated instance resource is locked in the tag data, a lock status can be set for each instance resource associated with the API request. The optional method of setting tag data for each instance resource associated with an API request can be referred to the description of the corresponding section above and will not be repeated here.

[0081] For an AIP request, the lifecycle of the tag data of each related instance resource of an API request corresponds to the lifecycle of the API request; for example, the tag data of each related instance resource of an API request is set when the API request is generated and removed when the API request is successfully executed.

[0082] Optionally, if the first API request is a newly generated API request, the embodiment of the present application can determine the various related instance resources of the first API request and set label data for the various related instance resources of the first API request, thereby determining the label data of the various related instance resources of the first API request.

[0083] Optionally, if the first API request is a historical API request that is attempted to be re-executed (for example, a historical API request that failed to execute and is saved in the request queue and is currently attempted to be re-executed), then since the tag data of each related instance resource of the historical API request has been set in advance, the embodiment of the present application can determine the tag data of each related instance resource of the first API request that has been set.

[0084] It is understandable that the first API request may have multiple related instance resources, and the locking status of each related instance resource may be set according to the specific scenario. Therefore, there may be locked instance resources or unlocked instance resources among the multiple related instance resources of the first API request.

[0085] In step S412, the execution status of the first API request is determined based on the locking status of each related instance resource of the first API request and the tag data of each related instance resource in the second API request; wherein the second API request is a historical API request whose request time is earlier than the first API request and whose execution fails.

[0086] As an optional implementation, after determining the tag data of each related instance resource of the first API request, the locking status of each related instance resource of the first API request can be determined through the tag data; based on the SDN controller, there may be historical API requests with a request time earlier than the first API request but failed to execute. Therefore, the embodiment of the present application can combine the locking status of each related instance resource of the first API request and the tag data corresponding to the historical API requests with a request time earlier than the first API request but failed to execute, so as to determine whether the first API request is currently executed successfully or failed, so as to obtain the execution status of the first API request, that is, the execution status of the first API request can be successful or failed.

[0087] For ease of explanation, in the embodiment of the present application, a historical API request that has any identical related instance resource as the first API request and whose request time is earlier than the first API request but whose execution fails is referred to as a second API request; that is, the request time of the second API request is earlier than the first API request, but based on the request execution method provided in the embodiment of the present application, when the order of processing API requests is controlled, the second API request fails to execute, and the related instance resources of the second API request are partially identical to the related instance resources of the first API request, for example, the second API request has at least one identical related instance resource as the first API request.

[0088] An embodiment of the present application can set the tag data of each relevant instance resource of the API request when the API request is generated, and remove the tag data of each relevant instance resource of the API request when the API request is successfully executed, so that the life cycle of the tag data of each relevant instance resource of an API request corresponds to the life cycle of the API request, wherein the tag data of a relevant instance resource of an API request at least records the locking status of a relevant instance resource of the API request; thus, when obtaining the first API request and currently attempting to execute the first API request, the embodiment of the present application can determine the tag data of each relevant instance resource of the first API request and obtain the locking status of each relevant instance resource of the first API request; further, based on the locking status of each relevant instance resource of the first API request and the tag data of each relevant instance resource in the second API request, determine the execution status of the first API request to determine whether the first API request is successfully executed or failed when currently attempted to execute, wherein the second API request is a historical API request whose request time is earlier than the first API request and which fails to execute.

[0089] Since the embodiment of the present application combines the lock status of each relevant instance resource of the first API request and the tag data corresponding to the second API request whose request time is earlier than the first API request but whose execution fails, the embodiment of the present application can combine the relevant instance resources of the first API request, the lock status of the first API request, and the tag data of the second API request whose request time is earlier than the first API request but whose execution fails, to comprehensively consider the instance resource preemption of the first API request, thereby reasonably determining the current execution status of the first API request, avoiding the execution time consumed by the incorrect execution of the first API request, and improving the execution performance of the API request. For example, the embodiment of the present application can disperse the lock preemption time consumed by different API requests on the same instance resource, avoid the incorrect execution of the first API request when the relevant instance resource of the first API request is not locked but is locked by a previously unsuccessful API request, and avoid the incorrect execution of the first API request when the relevant instance resource of the first API request is locked and is set with tag data by a previously unsuccessful API request, thereby comprehensively improving the efficiency of the SDN controller in executing API requests and improving the execution performance of the SDN controller's API requests.

[0090] As an optional implementation, for each related instance resource of the first API request, the embodiment of the present application can determine whether the sequential control of the related instance resources has passed; if each related instance resource of the first API request has passed the sequential control, it is confirmed that the first API request can currently be successfully executed, thereby determining that the execution status of the first API request is successful execution, and the embodiment of the present application can execute the first API request; if there is any related instance resource of the first API request that has not passed the sequential control, it is confirmed that the first API request cannot currently be successfully executed, thereby determining that the execution status of the first API request is failed execution.

[0091] As a further optional implementation, when judging whether the sequential control of any related instance resource of the first API request is passed, the embodiment of the present application can combine the lock status of the related instance resource corresponding to the first API request and the tag data corresponding to the second API request to obtain the result of whether the sequential control of the related instance resource is passed.

[0092] That is to say, for each relevant instance resource of the first API request, the embodiment of the present application can determine whether the relevant instance resource passes the sequential control based on the lock status of the relevant instance resource corresponding to the first API request and the tag data of the relevant instance resource corresponding to the second API request; if each relevant instance resource of the first API request passes the sequential control, it can be confirmed that the first API request can currently be successfully executed, thereby determining that the execution status of the first API request is successful execution, so as to execute the first API request; if there is any relevant instance resource of the first API request that does not pass the sequential control, it is determined that the first API request cannot currently be successfully executed, thereby determining that the execution status of the first API request is failed execution.

[0093] In a further optional implementation, if it is confirmed that the execution status of the first API request is execution failure, the embodiment of the present application can save the first API request into the request queue and maintain the multiple tag data corresponding to the first API request (that is, maintain the tag data of each related instance resource of the first API request). If it is confirmed that the execution status of the first API request is execution success, the embodiment of the present application can execute the first API request and remove the tag data of each related instance resource of the first API request. In a further optional implementation, if the first API request is the first API request obtained from the request queue for retrying execution, the embodiment of the present application can also remove the first API request from the request queue.

[0094] As an optional implementation, Figure 5 The following is an exemplary flowchart of an optional method for determining the execution status of a first API request provided in an embodiment of the present application, referring to Figure 5The method flow may include the following steps.

[0095] In step S510 , the tag data of each relevant instance resource of the first API request is traversed.

[0096] After determining the tag data of each relevant instance resource of the first API request (that is, determining multiple tag data corresponding to the first API request, and one tag data corresponds to one relevant instance resource of the first API request), the embodiment of the present application can traverse the tag data of each relevant instance resource of the first API request to determine whether the sequential control of each relevant instance resource of the first API request is passed.

[0097] In step S511, for the currently traversed tag data, it is determined whether the lock status of the instance resource related to the tag data record is locked. If not, step S512 is executed. If so, step S515 is executed.

[0098] When traversing the tag data of an instance resource related to the first API request, the embodiment of the present application can determine whether the locking state of the related instance resource is locked or unlocked based on the locking state of the related instance resource recorded in the tag data.

[0099] In step S512, it is determined whether the relevant instance resource corresponds to the tag data with the locked state being locked in the second API request. If so, step S513 is executed; if not, step S514 is executed.

[0100] When traversing to the tag data of an instance resource related to the first API request, if the lock status of the related instance resource is unlocked, the embodiment of the present application can determine whether the related instance resource has the tag data with the lock status of locked corresponding to the second API request. In an optional implementation, the request time of the API request can be recorded based on the tag data. When traversing to the tag data of an instance resource related to the first API request, and the lock status of the related instance resource is unlocked, the embodiment of the present application can determine whether the related instance resource has the tag data with the request time earlier than the first API request and the lock status of the related instance resource is locked, so as to implement step S512.

[0101] In step S513 , it is determined that the relevant instance resource fails the sequence control.

[0102] If the locking status of a related instance resource of the first API request is unlocked, but the locking status of the related instance resource of the second API request that is earlier than the first API request is locked, then the embodiment of the present application can confirm that the related instance resource of the first API request has not passed the sequential control, so that the execution status of the first API request can be set to execution failure; accordingly, the first API request can be saved in the request queue and wait for the next retry of execution. For example, the API requests in the request queue can be retried periodically.

[0103] It should be noted that if the locking status of a related instance resource of the first API request is unlocked, but the locking status of the related instance resource of the second API request that is earlier than the first API request is locked, then since the second API request has not been executed successfully, the first API request needs to wait for the second API request to be executed successfully, so that the first API request can be executed again after the second API request removes the locking status of the related instance resource. Therefore, the first API request cannot be executed at this time and needs to be placed in the request queue and wait for the next scheduling.

[0104] In step S514, it is determined whether the relevant instance resources pass the sequence control.

[0105] If the lock status of a related instance resource of the first API request is unlocked, and the lock status of the related instance resource of the second API request that precedes the first API request is also unlocked, then the related instance resource of the first API request passes the sequence control. At this time, the judgment of step S511 can be performed based on the tag data of the next related instance resource of the first API request. Until all related instance resources of the first API request pass the sequence control, it is confirmed that the execution status of the first API request can be set to execution success, and the first API request is executed.

[0106] In step S515 , it is determined whether the relevant instance resource has tag data corresponding to the second API request. If so, step S513 is executed; if not, step S514 is executed.

[0107] If the judgment result of step S511 is yes, the embodiment of the present application can enter step S515 for execution, that is, when traversing to the tag data of a related instance resource of the first API request, if the locking status of the related instance resource is locked, the embodiment of the present application can enter step S515 to determine whether the related instance resource has the tag data corresponding to the second API request; at this time, the embodiment of the present application does not focus on the locking status of the tag data corresponding to the second API request of the related instance resource, but focuses on whether the related instance resource has tag data with a request time earlier than the first API request. In an optional implementation, the request time of the API request can be recorded based on the tag data. The embodiment of the present application can determine whether the related instance resource has tag data with a request time earlier than the first API request (ignoring the record of the locking status in the tag data) when traversing to the tag data of a related instance resource of the first API request and the locking status of the related instance resource is locked, so as to implement step S515.

[0108] When traversing the tag data of a related instance resource of the first API request and the lock status of the related instance resource is locked, if the related instance resource has corresponding tag data in the second API request (that is, the request time of the related instance resource is earlier than the tag data of the first API request), the embodiment of the present application can enter step S513, confirming that the related instance resource has not passed the sequential control, so that the execution status of the first API request can be set to execution failure. Accordingly, the first API request can be saved in the request queue and wait for the next retry to execute.

[0109] It should be noted that if the lock status of a related instance resource of the first API request is locked, and the related instance resource has tag data in the second API request with an earlier request time, the first API request needs to wait for the second API request with an earlier request time to be successfully executed before executing the first API request. Therefore, the first API request cannot be executed at this time and needs to be placed in the request queue and wait for the next scheduling.

[0110] When traversing to the tag data of a related instance resource of the first API request, and the lock status of the related instance resource is locked, if the related instance resource does not have corresponding tag data in the second API request (that is, the related instance resource does not have tag data with a request time earlier than the first API request), then the embodiment of the present application can enter step S514 to confirm that the related instance resource of the first API request passes the sequential control. At this time, the judgment of step S511 can be executed based on the tag data of the related instance resource of the first API request that is traversed next, until all the related instance resources of the first API request pass the sequential control, then it is confirmed that the execution status of the first API request can be set to successful execution, thereby executing the first API request.

[0111] In step S516, it is determined whether the tag data of each relevant instance resource of the first API request are all traversed, if not, step S517 is executed, and if so, step S518 is executed.

[0112] In step S517, the next tag data to be traversed is determined, and the process goes to step S511.

[0113] In step S518 , it is confirmed that all relevant instance resources of the first API request pass the sequence control, and the first API request is executed.

[0114] After traversing the tag data of a related instance resource of the first API request and determining that the related instance resource passes the sequential control, the embodiment of the present application can determine whether the tag data of each related instance resource of the first API request are all traversed; if not, the embodiment of the present application can determine the next traversed tag data, and use the next traversed tag data as the new currently traversed tag data, thereby returning to step S511 to determine whether the sequential control of the new currently traversed tag data is passed; if so, the embodiment of the present application can confirm that each related instance resource of the first API request passes the sequential control, so that the execution status of the first API request can be set to successful execution, and the first API request is executed.

[0115] In a further implementation example, taking the tag data recording request time, request identifier, instance identifier and lock status as an example, when traversing the tag data of the first API request, the embodiment of the present application can judge whether the sequence control of the tag data is passed based on the lock status, instance identifier and request time of the traversed tag data, so as to judge whether the sequence control of the instance resource corresponding to the tag data is passed. As an optional implementation, Figure 6 An exemplary flowchart of another optional method for determining the execution status of the first API request provided in an embodiment of the present application is shown. Figure 6 The method flow may include the following steps.

[0116] In step S610 , the tag data of each relevant instance resource of the first API request is traversed.

[0117] In step S611 , for the currently traversed tag data, it is determined whether the locking status of the tag data record is locked. If not, step S612 is executed. If so, step S615 is executed.

[0118] In step S612, based on the request time and instance ID recorded in the tag data, a search is performed to determine whether there is tag data with a locked state and an earlier request time. If so, step S613 is executed; otherwise, step S614 is executed.

[0119] Based on the fact that the SDN controller can maintain tag data corresponding to multiple API requests that failed to execute, when traversing to a tag data of the first API request, if the locking status of the tag data record is unlocked, the embodiment of the present application can search in the tag data maintained by the SDN controller based on the request time and instance identifier of the tag data record to see whether there is locked tag data with an earlier request time for the instance identifier, for example, to find out whether there is tag data with is_locked=true with an earlier request time for the instance ID.

[0120] In step S613 , it is determined that the tag data does not pass the sequence control, and the first API request is saved in the request queue, waiting for the next scheduling.

[0121] In step S614, it is determined whether the tag data passes the sequence control.

[0122] The tag data is represented by sequence control, and the instance resource corresponding to the instance identifier recorded by the tag data is controlled by sequence control.

[0123] In step S615, based on the request time and instance ID recorded in the tag data, it is searched whether there is tag data with an earlier request time than the instance ID. If so, step S613 is executed; otherwise, step S614 is executed.

[0124] When traversing to a tag data of the first API request, if the lock status of the tag data record is locked, the embodiment of the present application can search the tag data maintained by the SDN controller based on the request time and instance identifier of the tag data record to see whether there is tag data with an earlier request time; at this time, for tag data with an earlier request time, the embodiment of the present application can ignore the lock status of the tag data, but focus on whether there is tag data corresponding to the instance identifier with an earlier request time. If the judgment result of step S615 is yes, the embodiment of the present application can determine that the tag data has not passed the sequential control, save the first API request to the request queue, and wait for the next scheduling; if the judgment result of step S615 is no, the embodiment of the present application can determine that the tag data has passed the sequential control.

[0125] In step S616, it is determined whether the tag data of each relevant instance resource of the first API request has been traversed. If not, step S617 is executed; if so, step S618 is executed.

[0126] In step S617, the next tag data to be traversed is determined, and the process goes to step S611.

[0127] In step S618 , it is confirmed that the tag data of each relevant instance resource of the first API request passes the sequence control, and the first API request is executed.

[0128] As an implementation example, Figure 7 An example diagram of the simplified tag data corresponding to the API request provided in the embodiment of the present application is shown. Figure 7 Taking the tag data corresponding to the example API request as an example, the sequential control scheme of the API request provided in the embodiment of the present application is illustrated. It should be noted that, Figure 7 This is a simplified example of the label data for an API request. In practice, one API request may correspond to multiple pieces of label data.

[0129] Combine Figure 7 As shown, assuming that the request time t1 of API request 71 is earlier than the request time t2 of API request 72, and the request time t2 of API request 72 is earlier than the request time t3 of API request 73, the request time of API request 73 and the request time of API request 74 are both t3.

[0130] For API requests 71 and 72, the instance resource for API requests 71 and 72 is the same, that is, the instance resource with instance ID 701. Since the lock status corresponding to instance ID 701 in the tag data of API requests 71 and 72 is unlocked (is_locked=false), it can be determined whether instance ID 701 has tag data that was locked (is_locked=true) at a request time earlier than that of API requests 71 and 72. Since instance ID 701 does not have tag data that was locked at a request time earlier than that of API requests 71 and 72, the execution of API requests 71 and 72 will not cause resource preemption, and API requests 71 and 72 can be executed.

[0131] For API request 73, the instance resource of API request 73 is the same as that of API requests 71 and 72, that is, both are instance resources with instance ID 701. Since the lock status corresponding to instance ID 701 in the tag data of API request 73 is locked (is_locked=true), it can be determined whether instance ID 701 has tag data with a request time earlier than that of API request 73 (ignoring the lock status of tag data with an earlier request time). Since the request time of the tag data corresponding to instance ID 701 in API requests 71 and 72 is earlier than that of API request 73 when API requests 71 and 72 are not completed, if instance ID 701 of API request 73 is locked, API request 73 needs to wait for the completion of API requests 71 and 72 before it can be executed. After API requests 71 and 72 are completed, the tag data corresponding to API requests 71 and 72 are removed. Therefore, instance ID 701 will no longer have tag data with a request time earlier than that of API request 73, and thus API request 73 can be executed.

[0132] For API request 74, since the instance ID of the instance resource of API request 74 is 702, which is different from the instance resources of API requests 71, 72 and 73, the execution of API request 74 will not cause resource preemption, and API request 74 is allowed to be executed.

[0133] The following describes the request execution method provided by the embodiment of the present application from the perspective of the SDN controller of the SDN system processing the user's API request. The SDN system provided by the embodiment of the present application may include: an application layer (for example, Figure 1 Application plane shown), control layer (e.g., Figure 1 control plane as shown) and data plane (e.g. Figure 1 data plane shown);

[0134] The application layer can include an application management platform, where user applications (e.g., SDN network applications) can be deployed. The control layer can include an SDN controller for managing the SDN network, with the SDN controller having multiple instance resources, each of which has dependencies. The control layer can also include multiple forwarding components (e.g., virtual switches) for forwarding data packets, each of which is controlled by the SDN controller. In an optional implementation, the control layer of the SDN system can include multiple SDN controllers, with each SDN controller controlling a certain number of forwarding components at the data layer.

[0135] When a user calls an SDN service, the user can use the user terminal to transmit an API request to the SDN system. The API request can indicate the target instance resource that the user needs to operate. The application management platform of the application layer can then obtain the user's API request to call the SDN service and transmit the API request to the SDN controller of the controller. In other words, when the user calls the SDN service, the SDN controller can obtain the user's API request to call the SDN service transmitted by the application management platform.

[0136] Furthermore, the SDN controller can obtain the instance resources related to the API request based on the target instance resource operated by the API request and the instance resources associated with the target instance resource. Based on the instance resources related to the API request, the SDN controller can create tag data for each instance resource related to the API request when the API request is generated. As mentioned above, the tag data for each instance resource related to an API request at least records the locking status of the instance resource related to the API request, and the lifecycle of the tag data for each instance resource related to an API request corresponds to the lifecycle of the API request.

[0137] Based on the tag data created by the SDN controller for each relevant instance resource of the API request, the SDN controller can determine the execution status of the API request according to the locking status of each relevant instance resource of the API request and the tag data of the previous API request that failed to execute each relevant instance resource, so as to sequentially control the processing of API requests and improve the request execution performance of the SDN controller.

[0138] In one example, if the SDN controller determines that the instance resource associated with the API request is unlocked but locked by a previous failed API request, the SDN controller can determine that the execution status of the API request is failed, thereby avoiding incorrect execution of the API request. If the SDN controller determines that the instance resource associated with the API request is locked and tag data is set by a previous failed API request, the SDN controller can determine that the execution status of the API request is failed, thereby avoiding incorrect execution of the API request. In addition to the above execution failure situations, the SDN controller can determine that the API request can be successfully executed and thus execute the API request.

[0139] Furthermore, for API requests that fail to execute, the SDN controller may save the API requests that fail to execute and retry the execution at a fixed time.

[0140] It can be seen that the request execution scheme provided by the embodiment of the present application can effectively disperse the lock preemption time of different API requests on the same instance resource, reduce the time consumption of the SDN controller to synchronously execute API requests, and improve the execution performance of API requests; and, by setting the locking status of the relevant instance resources of each API request (for example, according to the API type and the type of instance resource, the locking status is set separately for the relevant instance resources of the API request, rather than directly locking the root instance resource from the instance resource of the API request operation), it is possible to finely control the locking requirements of each API request for different instance resources in different dimensions, avoid the time consumption of serial execution of API requests caused by coarse-grained execution of API requests, reduce the completion time consumption of the SDN controller for asynchronous execution of API requests, and improve the execution performance of API requests.

[0141] The present application also provides a request execution device, which can be considered as a functional module required by the SDN controller to implement the request execution method provided in the present application. The following description can be referenced in conjunction with the above description.

[0142] As an optional implementation, Figure 8 An optional block diagram of a request execution device provided in an embodiment of the present application is shown as an example. The request execution device can be applied to an SDN controller. Figure 8 , the request execution device may include:

[0143] An API request acquisition module 810 is configured to acquire a first API request;

[0144] a tag data determining module 811 configured to determine tag data for each instance resource associated with the first API request; wherein the tag data for each instance resource associated with an API request at least records a lock status of the instance resource associated with the API request, and the lifecycle of the tag data for each instance resource associated with an API request corresponds to the lifecycle of the API request;

[0145] The execution status determination module 812 is used to determine the execution status of the first API request based on the locking status of each related instance resource of the first API request and the tag data of each related instance resource in the second API request; wherein, the second API request is a historical API request whose request time is earlier than the first API request and whose execution fails.

[0146] Optionally, the execution status determination module 812 is configured to determine the execution status of the first API request based on the lock status of each related instance resource of the first API request and the tag data of each related instance resource in the second API request, including:

[0147] For each instance resource related to the first API request, determining whether the instance resource passes sequence control based on a lock state of the instance resource corresponding to the first API request and tag data of the instance resource corresponding to the second API request;

[0148] If all relevant instance resources of the first API request pass the sequence control, determining that the execution status of the first API request is successful;

[0149] If any instance resource related to the first API request fails to pass sequence control, the execution status of the first API request is determined to be execution failure.

[0150] Optionally, the execution state determination module 812 is configured to determine, for each instance resource related to the first API request, whether the related instance resource passes the sequence control based on the lock state of the related instance resource corresponding to the first API request and the tag data of the related instance resource corresponding to the second API request, including:

[0151] Traversing the tag data of each relevant instance resource of the first API request;

[0152] For the currently traversed tag data, determine whether the lock status of the instance resource related to the tag data record is locked;

[0153] If the lock state of the relevant instance resource is unlocked, determining whether the relevant instance resource has tag data corresponding to the lock state of locked in the second API request; if so, determining that the relevant instance resource has not passed the sequence control; if not, determining that the relevant instance resource has passed the sequence control;

[0154] If the lock state of the relevant instance resource is locked, determine whether the relevant instance resource corresponds to the tag data in the second API request; if so, determine that the relevant instance resource does not pass the sequence control; if not, determine that the relevant instance resource passes the sequence control.

[0155] Optionally, the tag data of a related instance resource of an API request further records: the request time of the API request, the request identifier of the API request, and the instance identifier of the related instance resource.

[0156] Optionally, the execution state determination module 812 is configured to determine whether the tag data corresponding to the lock state of the relevant instance resource is locked in the second API request if the lock state of the relevant instance resource is unlocked, including:

[0157] If the lock status of the currently traversed tag data record is unlocked, based on the request time and instance ID of the tag data record, find out whether there is tag data with a request time earlier than the first API request and a lock status of locked.

[0158] Optionally, the execution state determination module 812 is configured to, if the lock state of the relevant instance resource is locked, determine whether the relevant instance resource has the tag data corresponding to the second API request, including:

[0159] If the lock state of the currently traversed tag data record is locked, the instance identifier is searched for tag data with a request time earlier than the first API request based on the request time and instance identifier of the tag data record.

[0160] In a further optional implementation, Figure 9 Another optional block diagram of the request execution device provided in the embodiment of the present application is shown as an example. Figure 8 and Figure 9 As shown, the request execution device may further include:

[0161] An execution module 910 is configured to execute the first API request if the execution status of the first API request is successful, and remove tag data of each instance resource related to the first API request;

[0162] The queue saving module 911 is used to save the first API request into the request queue if the execution status of the first API request is execution failure, and maintain the tag data of each related instance resource of the first API request; wherein, the request queue saves API requests that have failed to execute, and the API requests saved in the request queue are periodically retried to execute.

[0163] Optionally, the API request obtaining module 810 is configured to obtain the first API request, including:

[0164] Get the newly generated API request as the first API request;

[0165] Alternatively, a historical API request currently being retried is obtained from the request queue as the first API request.

[0166] Optional, combined Figure 9 As shown, the request execution device may further include:

[0167] The tag data generation module 912 is used to determine the relevant instance resources of the API request for the newly generated API request, and set a lock status for the relevant instance resources of the API request; for each relevant instance resource of the API request, the tag data is determined at least based on the lock status of the relevant instance resource to obtain the tag data of each relevant instance resource of the API request.

[0168] Optionally, if the first API request is a newly generated API request, after the tag data generation module 912 generates the corresponding tag data for the first API request, the tag data determination module 811 can obtain the tag data generated by the tag data generation module 912 for the first API request, thereby determining the tag data of each instance resource related to the first API request. Optionally, if the first API request is a historical API request that is currently being retried, the tag data determination module 811 can determine the tag data of each instance resource related to the first API request from the tag data corresponding to the currently maintained historical API requests.

[0169] Optionally, the tag data generating module 912 is configured to determine each relevant instance resource of the API request, including determining a target instance resource operated by the API request and instance resources associated with the target instance resource.

[0170] Optionally, the tag data generating module 912 is configured to set a lock status for each instance resource related to the API request, including:

[0171] Set the lock status of the target instance resource of the API request operation to locked, and set the lock status of other instance resources in the related instance resources of the API request to unlocked;

[0172] Alternatively, the lock state of the target instance resource of the API request operation is set to locked, and the lock state of the instance resource directly associated with the target instance resource is set to locked, and the lock state of other instance resources in the instance resources associated with the API request is set to unlocked;

[0173] Alternatively, the locking status of each instance resource related to the API request is determined according to the API type corresponding to the API request and the type of the instance resource.

[0174] Optionally, the tag data generating module 912 is configured to determine tag data for each instance resource related to the API request based at least on the lock status of the related instance resource, so as to obtain tag data for each instance resource related to the API request, including:

[0175] For each relevant instance resource of the API request, the tag data is determined according to the request time of the API request, the request identifier of the API request, the instance identifier of the relevant instance resource, and the locking status of the relevant instance resource to obtain the tag data of each relevant instance resource of the API request.

[0176] The present application also provides an SDN system. Figure 1 As shown, the SDN system may include: multiple forwarding components and an SDN controller, wherein the SDN controller may be configured to execute the request execution method provided in the embodiment of the present application.

[0177] The embodiment of the present application further provides an SDN server, which may be a server device carrying an SDN controller. As an optional implementation, Figure 10 An optional block diagram of an SDN server is shown as an example. Figure 10 As shown, the SDN server may include: at least one processor 01 , at least one communication interface 02 , at least one memory 03 and at least one communication bus 04 .

[0178] In the embodiment of the present application, the number of the processor 01 , the communication interface 02 , the memory 03 , and the communication bus 04 is at least one, and the processor 01 , the communication interface 02 , and the memory 03 communicate with each other through the communication bus 04 .

[0179] Optionally, the communication interface 02 may be an interface of a communication module for performing network communication.

[0180] Optionally, processor 01 may be a CPU, a GPU (Graphics Processing Unit), an NPU (embedded neural network processor), an FPGA (Field Programmable Gate Array), a TPU (Tensor Processing Unit), an AI chip, an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement an embodiment of the present application.

[0181] The memory 03 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0182] Among them, the memory 03 stores one or more computer-executable instructions, and the processor 01 calls the one or more computer-executable instructions to execute the request execution method provided in the embodiment of the present application.

[0183] An embodiment of the present application also provides a storage medium that stores one or more computer-executable instructions. When the one or more computer-executable instructions are executed, the request execution method provided in the embodiment of the present application is implemented.

[0184] The embodiment of the present application also provides a computer program, which, when executed, implements the request execution method provided in the embodiment of the present application.

[0185] The above describes multiple embodiment schemes provided by the embodiments of the present application. The various optional methods introduced in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending a variety of possible embodiment schemes, which can all be considered as embodiment schemes disclosed and open in the embodiments of the present application.

[0186] Although the embodiments of the present application are disclosed above, the present application is not limited thereto. Any person skilled in the art may make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims.

Claims

1. A request execution method, wherein: include: Get the first API request; Determining tag data for each instance resource associated with the first API request; wherein the tag data for each instance resource associated with an API request at least records a lock status of the instance resource associated with the API request, and the lifecycle of the tag data for each instance resource associated with an API request corresponds to the lifecycle of the API request; The execution status of the first API request is determined based on the locking status of each related instance resource of the first API request and the tag data of each related instance resource in the second API request; wherein, the second API request is a historical API request whose request time is earlier than the first API request and whose execution failed.

2. The method according to claim 1, wherein Determining the execution status of the first API request according to the locking status of each related instance resource of the first API request and the tag data of each related instance resource in the second API request includes: For each instance resource related to the first API request, determining whether the instance resource passes sequence control based on a lock state of the instance resource corresponding to the first API request and tag data of the instance resource corresponding to the second API request; If all relevant instance resources of the first API request pass the sequence control, determining that the execution status of the first API request is successful; If any instance resource related to the first API request fails to pass sequence control, the execution status of the first API request is determined to be execution failure.

3. The method according to claim 2, wherein: For each instance resource related to the first API request, determining whether the instance resource passes the sequence control according to a lock state of the instance resource corresponding to the first API request and tag data of the instance resource corresponding to the second API request includes: Traversing the tag data of each relevant instance resource of the first API request; For the currently traversed tag data, determine whether the lock status of the instance resource related to the tag data record is locked; If the lock state of the relevant instance resource is unlocked, determining whether the relevant instance resource has tag data corresponding to the lock state of locked in the second API request; if so, determining that the relevant instance resource has not passed the sequence control; if not, determining that the relevant instance resource has passed the sequence control; If the lock state of the relevant instance resource is locked, determine whether the relevant instance resource corresponds to the tag data in the second API request; if so, determine that the relevant instance resource does not pass the sequence control; if not, determine that the relevant instance resource passes the sequence control.

4. The method according to claim 3, wherein: The tag data of an instance resource related to an API request further records: the request time of the API request, the request identifier of the API request, and the instance identifier of the related instance resource.

5. The method according to claim 4, wherein If the lock state of the relevant instance resource is unlocked, determining whether the tag data corresponding to the lock state of the relevant instance resource in the second API request is locked includes: If the lock status of the currently traversed tag data record is unlocked, based on the request time and instance ID of the tag data record, search the instance ID to see if there is any tag data with a request time earlier than the first API request and a lock status of locked; If the lock state of the relevant instance resource is locked, determining whether the relevant instance resource corresponds to the tag data in the second API request includes: If the lock state of the currently traversed tag data record is locked, the instance identifier is searched for tag data with a request time earlier than the first API request based on the request time and instance identifier of the tag data record.

6. The method according to any one of claims 1 to 5, wherein: Also includes: If the execution status of the first API request is successful, execute the first API request and remove the tag data of each related instance resource of the first API request; If the execution status of the first API request is execution failure, the first API request is saved in a request queue, and the tag data of each related instance resource of the first API request is maintained; wherein, the request queue saves historical API requests that failed to execute, and the historical API requests saved in the request queue are periodically retried to execute.

7. The method according to claim 6, wherein: Obtaining the first API request includes: Get the newly generated API request as the first API request; Alternatively, a historical API request currently being retried is obtained from the request queue as the first API request.

8. The method according to any one of claims 1 to 5, wherein: Also includes: For a newly generated API request, determine each instance resource related to the API request, and set a lock status for each instance resource related to the API request; For each instance resource related to the API request, the tag data is determined at least according to the locking status of the related instance resource to obtain the tag data of each instance resource related to the API request.

9. The method according to claim 8, wherein Determining the instance resources related to the API request includes: determining the target instance resource operated by the API request, and the instance resources associated with the target instance resource; Setting a lock status for each instance resource related to the API request includes: Set the lock status of the target instance resource of the API request operation to locked, and set the lock status of other instance resources in the related instance resources of the API request to unlocked; Alternatively, the lock state of the target instance resource of the API request operation is set to locked, and the lock state of the instance resource directly associated with the target instance resource is set to locked, and the lock state of other instance resources in the instance resources associated with the API request is set to unlocked; Alternatively, the locking status of each instance resource related to the API request is determined according to the API type corresponding to the API request and the type of the instance resource.

10. The method according to claim 8, wherein The step of determining tag data for each instance resource related to the API request based at least on a lock state of the instance resource to obtain tag data for each instance resource related to the API request includes: For each relevant instance resource of the API request, the tag data is determined according to the request time of the API request, the request identifier of the API request, the instance identifier of the relevant instance resource, and the locking status of the relevant instance resource to obtain the tag data of each relevant instance resource of the API request.

11. An SDN system, wherein: include: Application layer, control layer and data layer; the application layer is provided with an application management platform, and the application management platform is deployed with user applications; The control layer is provided with an SDN controller for managing the SDN network, the SDN controller has multiple instance resources, and there is an affiliation relationship between the instance resources; the control layer is provided with multiple forwarding components for forwarding data packets, and the forwarding components are controlled by the SDN controller; The SDN controller is configured to: Obtaining an API request for a user to call an SDN service transmitted by an application management platform; obtaining instance resources related to the API request based on a target instance resource operated by the API request and an instance resource associated with the target instance resource; Creating tag data for each instance resource related to the API request; wherein the tag data for each instance resource related to an API request at least records a lock status of the instance resource related to the API request, and the lifecycle of the tag data for each instance resource related to an API request corresponds to the lifecycle of the API request; The execution status of the API request is determined based on the locking status of each related instance resource of the API request and the tag data of the previous API request that failed to execute each related instance resource; wherein the failed API request is saved by the SDN controller and re-attempted to execute it at a regular interval.

12. An SDN system, wherein: include: A plurality of forwarding components and an SDN controller, wherein the SDN controller is configured to execute the request execution method according to any one of claims 1 to 10.

13. An SDN server, wherein: include: at least one memory and at least one processor; The memory stores one or more computer-executable instructions, and the processor calls the one or more computer-executable instructions to execute the request execution method according to any one of claims 1 to 10.

14. A storage medium, wherein: The storage medium stores one or more computer-executable instructions, and when the one or more computer-executable instructions are executed, the request execution method according to any one of claims 1 to 10 is implemented.

Images