Request processing method, key management method, device and electronic equipment

Abstract

This application provides a request processing method, a key management method, an apparatus, and an electronic device. The method includes: responding to a service processing request for a preset service node, invoking a primary dependent service node corresponding to the preset service node to process the service processing request; obtaining a first intermediate result returned by the primary dependent service node; if the first intermediate result is an abnormal result, invoking a disaster recovery dependent service node corresponding to the preset service node to process the service processing request, wherein the distance between the disaster recovery dependent service node and the preset service node is greater than the distance between the primary dependent service node and the preset service node; and obtaining a second intermediate result returned by the disaster recovery dependent service node, the second intermediate result being used to determine the service processing result corresponding to the service processing request. In this application embodiment, when the service availability of a dependent service does not meet requirements, the stability of service operation can be guaranteed through the disaster recovery invocation of the dependent service node.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a request processing method, a key management method, an apparatus, and an electronic device. Background Technology

[0002] With the rapid development of network technology, the application scope of application services is becoming wider and wider. There are often dependencies between application services deployed on operating systems or operating platforms. That is, the normal operation of a certain user service requires the support of other services or components. At this time, the other services or components are called the dependent services corresponding to the aforementioned user service.

[0003] Currently, user services have high requirements for service stability, and generally, the service availability corresponding to a Service Level Agreement (SLA) is no less than 99.95%. However, for the dependent services of user services, their service availability often fails to meet the 99.95% requirement.

[0004] Therefore, there is an urgent need for a disaster recovery method that can be used when dependent services cannot provide the required availability, in order to ensure the service stability of users. Summary of the Invention

[0005] This application provides a request processing method, a key management method, an apparatus, and an electronic device that can ensure the stability of the preset service operation by performing disaster recovery calls on dependent service nodes when the service availability of dependent services cannot meet the requirements.

[0006] This invention provides a request processing method, including:

[0007] In response to a service processing request for a preset service node, the primary dependent service node corresponding to the preset service node is invoked to process the service processing request.

[0008] Obtain the first intermediate result returned by the main dependent service node;

[0009] If the first intermediate result is an abnormal result, the disaster recovery dependency service node corresponding to the preset service node is invoked to process the service processing request, wherein the distance between the disaster recovery dependency service node and the preset service node is greater than the distance between the main dependency service node and the preset service node.

[0010] Obtain the second intermediate result returned by the disaster recovery dependent service node. The second intermediate result is used to determine the service processing result corresponding to the service processing request.

[0011] This invention provides a request processing apparatus, comprising:

[0012] The first processing module is used to respond to a service processing request for a preset service node by calling the main dependent service node corresponding to the preset service node to process the service processing request.

[0013] The first acquisition module is used to acquire the first intermediate result returned by the main dependent service node;

[0014] The first processing module is further configured to, in the event that the first intermediate result is an abnormal result, call the disaster recovery dependency service node corresponding to the preset service node to process the service processing request, wherein the distance between the disaster recovery dependency service node and the preset service node is greater than the distance between the main dependency service node and the preset service node.

[0015] The first acquisition module is further configured to acquire a second intermediate result returned by the disaster recovery dependent service node, the second intermediate result being used to determine the service processing result corresponding to the service processing request.

[0016] This invention provides a key management method, including:

[0017] In response to the obtained key management request for the key management service node, the main dependent service node corresponding to the key management service node is invoked to process the key management request;

[0018] Obtain the first intermediate result returned by the main dependent service node;

[0019] If the first intermediate result is an abnormal result, the disaster recovery dependency service node corresponding to the key management service node is invoked to process the key management request, wherein the distance between the disaster recovery dependency service node and the key management service node is greater than the distance between the main dependency service node and the key management service node;

[0020] Obtain the second intermediate result returned by the operation of the disaster recovery dependent service node;

[0021] Based on the second intermediate result, the key management result corresponding to the key management request is determined.

[0022] This invention provides a key management device, comprising:

[0023] The second processing module is used to respond to the obtained key management request for the key management service node by calling the main dependent service node corresponding to the key management service node to process the key management request;

[0024] The second acquisition module is used to acquire the first intermediate result returned by the main dependent service node;

[0025] The second processing module is further configured to, in the event that the first intermediate result is an abnormal result, invoke the disaster recovery dependency service node corresponding to the key management service node to process the key management request, wherein the distance between the disaster recovery dependency service node and the key management service node is greater than the distance between the primary dependency service node and the key management service node.

[0026] The second acquisition module is used to acquire the second intermediate result returned by the operation of the disaster recovery dependent service node;

[0027] The second processing module is further configured to determine, based on the second intermediate result, a key management result corresponding to the key management request.

[0028] This invention provides an electronic device, including: a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions, when executed by the processor, implement the method of any one of the first to second aspects described above.

[0029] This invention provides a computer storage medium for storing a computer program, which, when executed by a computer, implements the method described in any one of the first to second aspects above.

[0030] This invention provides a computer program product, comprising: a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the method in any one of the first to second aspects described above.

[0031] The request processing method, key management method, device, and electronic device provided in this embodiment, after obtaining a service processing request for a preset service node, process the service processing request by calling the primary dependent service node corresponding to the preset service node, and obtain a first intermediate result returned by the primary dependent service node. If the first intermediate result is an abnormal result, in order to ensure the stability and reliability of the normal processing operation of the service processing request, a disaster recovery dependent service node corresponding to the preset service node can be called to process the service processing request, thereby obtaining a second intermediate result returned by the disaster recovery dependent service node for determining the service processing result corresponding to the service processing request. This effectively enables the stability of the preset service node's operation through disaster recovery calls to the primary dependent service node and the disaster recovery dependent service node when the service availability of the dependent service node cannot meet the requirements, further improving the practicality of the method. Attached Figure Description

[0032] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0033] Figure 1 A schematic diagram illustrating a scenario of a request processing method provided for an exemplary embodiment of this application;

[0034] Figure 2 A flowchart illustrating a request processing method provided for an exemplary embodiment of this application;

[0035] Figure 3 An illustration of the relationship between a preset service node and a dependent service node provided in an exemplary embodiment of this application. Figure 1 ;

[0036] Figure 4 An illustration of the relationship between a preset service node and a dependent service node provided in an exemplary embodiment of this application. Figure 2 ;

[0037] Figure 5 A flowchart illustrating another request processing method provided for an exemplary embodiment of this application;

[0038] Figure 6 A flowchart illustrating yet another request processing method provided for an exemplary embodiment of this application;

[0039] Figure 7 A flowchart illustrating another request processing method provided for an exemplary embodiment of this application;

[0040] Figure 8A timing diagram of a request processing method provided as an exemplary application embodiment of this application;

[0041] Figure 9 A flowchart illustrating a key management method provided for an exemplary embodiment of this application;

[0042] Figure 10 A schematic diagram of the structure of a request processing apparatus provided for an exemplary embodiment of this application;

[0043] Figure 11 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application;

[0044] Figure 12 A schematic diagram of the structure of a key management device provided for an exemplary embodiment of this application;

[0045] Figure 13 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0048] Additionally, it should be noted that when user interaction operations or triggering operations are involved in the embodiments of this application, these operations include, but are not limited to, various interaction methods such as touch operations, gesture operations, voice operations, head movement operations, and eye movement operations. Touch operations include, but are not limited to, click operations, double-click operations, long-press operations, swipe operations, pinch operations, or mouse hover operations. Swipe operations include, but are not limited to, straight-line swipes and curved-line swipes.

[0049] To facilitate understanding of the request processing method, key management method, apparatus, and electronic device provided in the embodiments of this application, the relevant technologies are briefly described below:

[0050] With the rapid development of network technology, the application scope of application services is becoming wider and wider. There are often dependencies between application services deployed on operating systems or operating platforms. That is, the normal operation of a certain user service requires the support of other services or components. At this time, the other services or components are called the dependent services corresponding to the aforementioned user service.

[0051] Currently, user services typically require high service stability commitments. Generally, the availability of services covered by Service Level Agreements (SLAs) is no less than 99.95%. For example, Key Management Service (KMS) is a one-stop key management and data encryption service platform that provides simple, reliable, secure, and compliant data encryption protection capabilities. KMS systems can help users reduce procurement, maintenance, and R&D costs for cryptographic infrastructure and data encryption / decryption products, allowing users to focus solely on the data itself. However, for the service nodes that depend on the user service, the service availability often falls short of the 99.95% requirement.

[0052] To address the issue of service node availability failing to meet SLAs, the relevant technologies offer two solutions:

[0053] Solution 1: Establish a caching mechanism for data calls from multiple dependent service nodes. Specifically, request processing operations can be performed based on each dependent service node, and the corresponding request call results can be obtained. Then, the caching mechanism can cache the request call results. In disaster recovery scenarios, the cached data can be used first to return the request call results to the user.

[0054] However, the above-mentioned solution for using caching to handle disaster recovery calls in response to failures of dependent services has the following problems:

[0055] (1) The data in the cache only supports user requests that have previously called the preset service. During the period when the dependent service node corresponding to the preset service is faulty, if a user who is not in the cache makes a request, the cache cannot respond correctly and can only return an error message to the user to indicate that the dependent service node is unavailable.

[0056] (2) The data in the cache is often a snapshot of the data returned by the last call to the service. If the metadata of the default service changes during the period when the dependent service node fails, the cache may return an incorrect result to the user.

[0057] Solution 2: A cross-regional disaster recovery call method can be established for different dependent service nodes of the preset service. This ensures that when a dependent service node in this region has a problem, it can call dependent service nodes in other regions for cross-regional disaster recovery, thereby ensuring the normal operation of customer services.

[0058] However, the above-mentioned solution of using service nodes to establish cross-regional disaster recovery has the following problems:

[0059] (1) Since different dependent service nodes often have different external interfaces, calling methods and error handling methods, such cross-regional call disaster recovery is usually customized for a single dependent service node. That is, for different dependent service nodes, developers need to develop separate code for the calling function. This makes the development cost required for dependent service nodes relatively high, resulting in a relatively low R&D input-output ratio.

[0060] (2) The above-mentioned cross-regional disaster recovery operation is often achieved by manually switching the calling service nodes in different regions. Such switching operation or switching phase will affect the normal return of service call results.

[0061] To address the aforementioned technical problems, embodiments of this application provide a request processing method, a key management method, an apparatus, and an electronic device, as detailed in the appendix. Figure 1 As shown, the execution entity of this request processing method can be the request processing device 100. In some instances, the request processing device 100 can be implemented as the execution engine corresponding to a preset service node, or it can be implemented as a local server, a cloud server, or a preset device corresponding to the preset service node. When the request processing device 100 is implemented as a cloud server, the request processing method can be executed in the cloud. Several computing nodes (cloud servers) can be deployed in the cloud, each with computing, storage, and other processing resources. In the cloud, multiple computing nodes can be organized to provide a certain service; of course, a single computing node can also provide one or more services. The cloud can provide this service by providing a service interface, which users call to use the corresponding service. Service interfaces include Software Development Kits (SDKs), Application Programming Interfaces (APIs), and other forms.

[0062] The request processing device 100 is communicatively connected to the client 200, which is used by users to trigger request processing operations for preset service nodes. The client 200 can be any computing device with a certain information interaction capability; specifically, it can be a mobile phone, a personal computer (PC), a tablet computer, a configuration application, etc. Furthermore, the basic structure of the client 200 may include at least one processor. The number of processors depends on the client's configuration and type. The client 200 may also include memory, which can be volatile, such as Random Access Memory (RAM), or non-volatile, such as Read-Only Memory (ROM), flash memory, etc., or both types. The memory typically stores the operating system (OS), one or more applications, and may also store program data. In addition to the processing unit and memory, the client 200 also includes some basic configurations, such as a network interface card (NIC) chip, an I / O bus, a display component, and some peripheral devices. Optionally, some peripheral devices may include, for example, a keyboard, mouse, stylus, printer, etc. Other peripheral devices are well known in the art and will not be described in detail here.

[0063] The request processing device 100 refers to a device capable of enabling the normal operation of preset service nodes in a network virtual environment. It typically refers to a device that utilizes a network for information planning and request processing. Physically, the request processing device 100 can be any device capable of providing computing services and performing corresponding request processing operations on preset service nodes, such as a processor, server, etc. The request processing device 100 mainly comprises a processor, hard disk, memory, system bus, etc., similar to a general computer architecture.

[0064] In the above embodiment, a network connection is established between the request processing device 100 and the client 200. This network connection can be a wireless or wired network connection. If the request processing device 100 and the client 200 are connected via a communication connection, the network standard of the mobile network can be any one of 2G (Global System for Mobile Communications GSM), 2.5G (General Packet Radio Service GPRS), 3G (Wideband Code Division Multiple Access (WCDMA), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), 4G (Long Term Evolution LTE), 4G+ (Enhanced Long Term Evolution LTE+), Global Microwave Access Interoperability (WiMax), 5G, 6G, etc.

[0065] In this embodiment, the client 200 is used by a user to generate or obtain service processing requests for processing operations on a preset service node. In some instances, the client 200 may display an interactive interface for human-computer interaction, where the user can input an operation to generate a service processing request for the preset service node based on the operation. Alternatively, the user can input a voice interaction operation through the client 200 and obtain a service processing request for the preset service node based on the voice interaction operation, thereby stably generating and obtaining service processing requests for the preset service node, and then sending the service processing request for the preset service node to the request processing device 100.

[0066] After receiving a service processing request for a preset service node, the request processing device 100 can, in order to perform corresponding processing operations on the preset service node, call the primary dependent service node corresponding to the preset service node to process the service processing request. That is, the service processing request can be sent to the primary dependent service node for processing, and a first intermediate result returned by the primary dependent service node can be obtained. Then, it can be identified whether the first intermediate result is a normal result corresponding to the service processing request. Specifically, the first intermediate result can be compared with the normal result range corresponding to the service processing request. If the first intermediate result is within the normal result range, the first intermediate result is determined to be a normal result; if the first intermediate result is outside the normal result range, the first intermediate result is determined to be an abnormal result.

[0067] If the first intermediate result is abnormal, the service processing result corresponding to the service processing request cannot be determined based on the first intermediate result. In order to perform normal processing operations on the service processing request, the disaster recovery dependency service node corresponding to the preset service node can be invoked to process the service processing request. Here, the disaster recovery dependency service node is a dependency service node that is different from the main dependency service node and corresponds to the preset service node. Specifically, the disaster recovery dependency service node and the main dependency service node can be located in different regions. For example, the main dependency service node can be deployed in region A, and the disaster recovery dependency service node can be deployed in region B. In this case, the distance between the disaster recovery dependency service node and the preset service node can be greater than the distance between the main dependency service node and the preset service node.

[0068] Since the disaster recovery service node and the primary service node are different service nodes corresponding to the preset service node, when the disaster recovery service node is called to analyze and process the service processing request, a second intermediate result returned by the disaster recovery service node can be obtained. It is highly unlikely that the first intermediate result returned by the primary service node and the second intermediate result returned by the disaster recovery service node will both be abnormal at the same time. Therefore, the obtained second intermediate result is likely to be a normal result. The second intermediate result is used to determine the service processing result corresponding to the service processing request. That is, the service processing result corresponding to the service processing request can then be determined based on the obtained second intermediate result. This, to a certain extent, ensures the stability of the preset service processing operation.

[0069] In this embodiment, the stability and reliability of the processing operation of the preset service node are effectively ensured by disaster recovery invocation operations of the primary dependent service node and the disaster recovery dependent service node when the service availability of the dependent service node cannot meet the requirements, thus further improving the practicality of the method.

[0070] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0071] Figure 2 A flowchart illustrating a request processing method provided for an exemplary embodiment of this application; see attached diagram. Figure 2 As shown, this embodiment provides a request processing method. The execution subject of the method is a request processing device, which can be implemented as software or a combination of software and hardware. When the request processing device is implemented as hardware, it can be various electronic devices capable of performing request processing operations, including but not limited to execution engines, personal computers, servers, etc., used to implement preset service nodes. When the request processing device is implemented as software, it can be installed in the electronic devices listed above.

[0072] Specifically, the request processing method provided in this embodiment may include:

[0073] Step S201: In response to a service processing request for a preset service node, the main dependent service node corresponding to the preset service node is invoked to process the service processing request.

[0074] Step S202: Obtain the first intermediate result returned by the main dependent service node.

[0075] Step S203: If the first intermediate result is an abnormal result, the disaster recovery dependency service node corresponding to the preset service node is called to process the service processing request. The distance between the disaster recovery dependency service node and the preset service node is greater than the distance between the main dependency service node and the preset service node.

[0076] Step S204: Obtain the second intermediate result returned by the disaster recovery dependent service node. The second intermediate result is used to determine the service processing result corresponding to the service processing request.

[0077] The specific implementation methods and principles of each of the above steps are explained in detail below:

[0078] Step S201: In response to a service processing request for a preset service node, the main dependent service node corresponding to the preset service node is invoked to process the service processing request.

[0079] The request processing device can be used to ensure that the preset service node can perform normal processing operations. For each preset service node, there can be multiple dependent service nodes. This allows for stable and normal data processing operations by performing disaster recovery calls on multiple dependent service nodes. To enable disaster recovery calls on multiple dependent service nodes corresponding to a preset service node, each preset service node can be configured with at least a primary dependent service node and a disaster recovery dependent service node. The number of primary and disaster recovery dependent service nodes can both be one, and both can be active nodes, i.e., dual-active dependent service nodes. Alternatively, there can be one primary dependent service node and at least two disaster recovery dependent service nodes. In this case, at least some of the primary dependent service node and at least two disaster recovery dependent service nodes can be active nodes, i.e., dual-active or multi-active dependent service nodes.

[0080] In addition, for the primary dependency service node and the disaster recovery dependency service node, they can be dependency service nodes deployed in different regions, such as... Figure 3 As shown, the deployment areas of the primary dependent service node and the disaster recovery dependent service node are different. For example, the primary dependent service node can be deployed in region A, and the disaster recovery dependent service node can be deployed in region B. In this case, the primary dependent service node and the preset service node can be deployed in region A at the same time, so that the distance d1 between the primary dependent service node and the preset service node can be less than the distance d2 between the preset service node and the disaster recovery dependent service node.

[0081] In other instances, the primary dependency service node and the disaster recovery dependency service node can be dependency service nodes deployed in the same region, such as... Figure 4 As shown, the deployment regions of the primary dependent service node, the disaster recovery dependent service node, and the preset service node are the same. This indicates that the preset service provided by the preset service node has regional characteristics; it only requires data resources specific to the deployment region and does not need data resources from other deployment regions. For example, the primary dependent service node, the disaster recovery dependent service node, and the preset service node can all be deployed in region A. The number of disaster recovery dependent service nodes can be one or more, for example, two: disaster recovery dependent service node 1 and disaster recovery dependent service node 2. The distance between the primary dependent service node and the preset service node can be less than the distance between any other disaster recovery dependent service node and the preset service node.

[0082] When the primary dependent service node and the disaster recovery dependent service node are deployed in the same region, in order to enable disaster recovery calls to both the primary and secondary dependent service nodes, the domain names corresponding to the primary and disaster recovery dependent service nodes are different. The stability of the primary dependent service node can be higher than that of the disaster recovery dependent service node. For example, the domain name corresponding to the primary dependent service node is the domain name of the preset network, while the domain name corresponding to the disaster recovery dependent service node can be the domain name of the disaster recovery network. When the disaster recovery dependent service nodes include Disaster Recovery Dependent Service Node 1 and Disaster Recovery Dependent Service Node 2, Disaster Recovery Dependent Service Node 1 can correspond to domain name 1 of the first disaster recovery network, and Disaster Recovery Dependent Service Node 2 can correspond to domain name 2 of the second disaster recovery network. The higher stability of the primary dependent service node helps ensure the stability and reliability of disaster recovery calls to both the primary and secondary dependent service nodes.

[0083] For example, when the deployment region of the primary dependent service node is the same as that of the disaster recovery dependent service node, the domain name corresponding to the primary dependent service node is different from that of the disaster recovery dependent service node. Furthermore, the primary dependent service node can be a public network, while the disaster recovery dependent service node can be a private network. For instance, the domain name corresponding to the primary dependent service node is domain name 1, which corresponds to a private network in deployment region A, while the domain name corresponding to the disaster recovery dependent service node can be domain name 2, which corresponds to a public network in deployment region A. This makes the stability of the primary dependent service node higher than that of the disaster recovery dependent service node, thereby helping to ensure the stability and reliability of disaster recovery call operations on both the dependent service node and the primary dependent service node.

[0084] When there is a service processing requirement for a preset service node, the request processing device can obtain the service processing request for the preset service node. For service processing requests, different application scenarios can correspond to different types of service processing requests. For example, in the application scenario of key management, the service processing request can be implemented as a key management request, a data encryption request, or a data decryption request, etc.; in the application scenario of data processing, the service processing request can be implemented as a data processing request, etc.

[0085] Specifically, after obtaining a service processing request for a preset service node, since the normal operation of the preset service node requires the main dependent service node to return a normal processing result for processing the service processing request, in order to ensure stable processing of the service processing request to a certain extent, the main dependent service node corresponding to the preset service node can be called to process the service processing request. The main dependent service node can be implemented as the dependent service node that is closest to the preset service node, or the main dependent service node can be implemented as the dependent service node with the shortest call time required for the operation to be called by the preset service node.

[0086] Step S202: Obtain the first intermediate result returned by the main dependent service node.

[0087] After the main dependent service node is invoked to analyze and process the service processing request, a first intermediate result corresponding to the service processing request can be obtained, and the first intermediate result can be returned to the request processing device, so that the request processing device can obtain the first intermediate result returned by the main dependent service node, which corresponds to the service processing request.

[0088] Step S203: If the first intermediate result is an abnormal result, the disaster recovery dependency service node corresponding to the preset service node is called to process the service processing request. The distance between the disaster recovery dependency service node and the preset service node is greater than the distance between the main dependency service node and the preset service node.

[0089] For the first intermediate result returned by the primary dependent service node, since the first intermediate result may be a normal result corresponding to the primary dependent service node, or it may be an abnormal result corresponding to the primary dependent service node, and different first intermediate results correspond to different request processing strategies, after obtaining the first intermediate result returned by the primary dependent service node, it is possible to first identify whether the first intermediate result is a normal result. Specifically, identifying whether the first intermediate result is a normal result can include: obtaining the theoretical normal result range corresponding to the service processing request; if the first intermediate result is within the theoretical normal result range, then the first intermediate result is determined to be a normal result; if the first intermediate result is outside the theoretical normal result range, then the first intermediate result is determined to be an abnormal result. This thus reliably implements the operation of identifying whether the first intermediate result is a normal result.

[0090] If the first intermediate result is an abnormal result, in order to ensure the stable operation of the preset service node, the disaster recovery dependency service node corresponding to the preset service node can be invoked to process the service processing request. That is, the service processing request can be sent to the disaster recovery dependency service node for analysis and processing. The disaster recovery dependency service node can be the second closest dependency service node to the preset service node, where the distance between the disaster recovery dependency service node and the preset service node is greater than the distance between the primary dependency service node and the preset service node.

[0091] Step S204: Obtain the second intermediate result returned by the disaster recovery dependent service node. The second intermediate result is used to determine the service processing result corresponding to the service processing request.

[0092] After the disaster recovery dependent service node analyzes and processes the service processing request, a second intermediate result corresponding to the service processing request can be obtained. The second intermediate result can be returned to the request processing device, so that the request processing device can obtain the second intermediate result returned by the disaster recovery dependent service node. The second intermediate result corresponds to the service processing request, and the obtained second intermediate result is used to determine the service processing result corresponding to the service processing request. That is, after obtaining the second intermediate result returned by the disaster recovery dependent service node, the service processing result corresponding to the service processing request can be determined based on the second intermediate result.

[0093] For example, when the service processing request is a key management request corresponding to the key management service, the main dependent service node corresponding to the key management service node can be called first. Then, the main dependent service node is used to analyze and process the key management request to obtain the first intermediate result returned by the main dependent service node corresponding to the key management request. It is then identified whether the first intermediate result is a normal result. If the first intermediate result is a normal result, it can be directly used to perform subsequent processing operations to obtain the key management result corresponding to the key management request.

[0094] When the first intermediate result is abnormal, in order to ensure the stability and reliability of the key management service operation, the disaster recovery dependency service node corresponding to the key management service node can be called. Then, the disaster recovery dependency service node is used to analyze and process the key management request to obtain the second intermediate result returned by the disaster recovery dependency service node, which is used to determine the service processing result corresponding to the service processing request. Specifically, the second intermediate result is likely to be a normal result. Then, the key management result corresponding to the key management request can be determined based on the second intermediate result. This effectively ensures the accuracy and reliability of the analysis and processing of the key management request.

[0095] Furthermore, after obtaining the second intermediate result returned by the disaster recovery dependent service node, it is possible to identify whether the obtained second intermediate result is a normal result, and to perform corresponding processing operations based on the identification result. The method in this embodiment may further include: if the second intermediate result is an abnormal result, obtaining disaster recovery configuration information corresponding to the preset service node; based on the disaster recovery configuration information, determining the backup disaster recovery service node corresponding to the preset service node, wherein the distance between the backup disaster recovery service node and the preset service node is greater than the distance between the disaster recovery dependent service node and the preset service node; and calling the backup disaster recovery service node to process the service processing request to obtain a third intermediate result.

[0096] The preset service node may have corresponding disaster recovery configuration information, which may include the main dependent service node and related configuration information of the disaster recovery dependent service node corresponding to the preset service node. There may be one main dependent service node and multiple disaster recovery dependent service nodes. When the first intermediate result returned by the main dependent service node is an abnormal result, the service processing request can be processed by any one of the multiple disaster recovery dependent service nodes or a specific disaster recovery dependent service node. After the second intermediate result returned by the disaster recovery dependent service node for the service processing request, it can be identified whether the second intermediate result is a normal result. If the second intermediate result is determined to be an abnormal result, in order to stably perform corresponding processing operations on the service processing request, the disaster recovery configuration information corresponding to the preset service node can be obtained.

[0097] It is important to note that the disaster recovery configuration information can include not only the configuration information of the primary dependent service node and the disaster recovery dependent service node, but also the configuration information of multiple standby disaster recovery service nodes. The distance between the standby disaster recovery service nodes and the preset service node is greater than the distance between the disaster recovery dependent service node and the preset service node. This means that the calling priority of multiple standby disaster recovery service nodes can be lower than the calling priority of the disaster recovery dependent service node. Then, the standby disaster recovery service nodes can be called to process the service processing request, thereby obtaining a third intermediate result corresponding to the service processing request. This effectively enables the service processing request to be processed by the standby disaster recovery service nodes when the intermediate results (including the first and second intermediate results) obtained by the primary dependent service node and the disaster recovery dependent service node do not meet the requirements, thereby improving the stability and reliability of the service processing request to a certain extent.

[0098] The request processing method provided in this embodiment, after obtaining a service processing request for a preset service node, processes the service processing request by calling the primary dependent service node corresponding to the preset service node, and obtains a first intermediate result returned by the primary dependent service node. Furthermore, if the first intermediate result is an abnormal result, and to ensure the stability and reliability of the normal processing operation of the service processing request, the method can call the disaster recovery dependent service node corresponding to the preset service node to process the service processing request. This allows obtaining a second intermediate result returned by the disaster recovery dependent service node to determine the service processing result corresponding to the service processing request. This effectively enables disaster recovery calls to the dependent service through the primary dependent service node and the disaster recovery dependent service node when the service availability of the dependent service cannot meet the requirements, thereby ensuring the stability of the processing operation performed by the preset service node and further improving the practicality of the method.

[0099] Figure 5 A flowchart illustrating another request processing method provided as an exemplary embodiment of this application; based on the above embodiments, refer to the appendix... Figure 5 As shown, in order to improve the stability and reliability of the preset service node to a certain extent and to perform reasonable disaster recovery scheduling operations on the dependent service nodes corresponding to the preset service node, before calling the main dependent service node corresponding to the preset service node to process the service processing request, the main dependent service node and the disaster recovery dependent service node can be determined based on the calling priority of each dependent service node. At this time, the method in this embodiment may also include:

[0100] Step S501: Obtain the set of dependent service nodes corresponding to the preset service node. The set of dependent service nodes includes multiple dependent service nodes.

[0101] The preset service node may correspond to a set of dependent service nodes used to ensure or support the normal operation of the preset service node. The set of dependent service nodes may include multiple dependent service nodes corresponding to the preset service node. The multiple dependent service nodes may be dependent service nodes deployed in different regions, or multiple dependent service nodes may be dependent service nodes deployed in the same region but with different domain names.

[0102] Specifically, this embodiment does not limit the specific method for obtaining the set of dependent service nodes. In some instances, the set of dependent service nodes can be determined by the node identifier of a preset service node and a preset mapping relationship. In this case, obtaining the set of dependent service nodes corresponding to the preset service node may include: determining the node identifier corresponding to the preset service node; and determining the set of dependent service nodes corresponding to the preset service node based on the node identifier and the preset mapping relationship. This ensures the accuracy and reliability of obtaining the set of dependent service nodes to a certain extent.

[0103] Step S502: Determine the call priority of each of the multiple dependent service nodes.

[0104] Since the set of dependent service nodes includes multiple dependent service nodes, and these multiple dependent service nodes may correspond to different call priorities, in order to accurately determine the primary dependent service node and the disaster recovery dependent service node in the set of dependent service nodes, the call priority of each of the multiple dependent service nodes can be determined.

[0105] In some instances, the call priority of each of the multiple dependent service nodes can be determined by the distance information between each dependent service node and the preset service node. In this case, determining the call priority of each of the multiple dependent service nodes may include: obtaining the distance information between each dependent service node and the preset service node; and determining the call priority based on the distance information.

[0106] Multiple dependent service nodes can be deployed in different regions, or multiple dependent service nodes can be deployed in different locations within the same region. Since the call priority of the preset service node when calling different dependent service nodes is often related to the distance between the dependent service node and the preset service node, in order to accurately determine the call priority of each of the multiple dependent service nodes, the distance information between each dependent service node and the preset service node can be obtained first. This distance information can be determined by the location information of the dependent service node and the location information of the preset service node; or, this distance information can be determined by sending test signals between each dependent service node and the preset service node, and by testing the transmission rate and duration of the test signals.

[0107] After obtaining the distance information between each dependent service node and the preset service node, the distance information between each dependent service node and the preset service node can be analyzed and processed to determine the calling priority of each dependent service node. Implementation method 1: The calling priority of each dependent service node can be determined by the preset mapping relationship and the distance information between each dependent service node and the preset service node.

[0108] Implementation Method Two: Distance information can be negatively correlated with call priority. That is, the smaller the distance, the higher the call priority of the dependent service node corresponding to that distance; conversely, the larger the distance, the lower the call priority. For example, consider dependent service nodes a, b, and c. The distance between dependent service node a and the preset service node is d1, the distance between dependent service node b and the preset service node is d2, and the distance between dependent service node c and the preset service node is d3. The relationship between these distances is: d1 > d3 > d2. Therefore, the call priorities of each dependent service node can be determined as follows: the call priority of dependent service node 1 is lower than that of dependent service node 3, and the call priority of dependent service node 3 is lower than that of dependent service node 2. In other words, dependent service node 2 has the highest call priority. This improves the accuracy and reliability of determining the call priorities of multiple dependent service nodes to a certain extent.

[0109] In other instances, the call priority of each of the multiple dependent service nodes can be determined not only based on the distance information between each dependent service node and the preset service node, but also based on the call duration corresponding to the call operation of each dependent service node by the preset service node. In this case, determining the call priority of each of the multiple dependent service nodes may include: obtaining the call duration required by the preset service node to call each dependent service node; and determining the call priority based on the call duration.

[0110] Specifically, multiple dependent service nodes can be deployed in different regions, or multiple dependent service nodes can be deployed in different locations within the same region. Since the call priority of a preset service node when calling different dependent service nodes is related to the call duration required for the dependent service node to be called by the preset service node, in order to accurately determine the call priority of each dependent service node, the call duration required for each dependent service node to be called by the preset service node can be obtained first. This call duration can be determined by the preset service node sending test call signals to each dependent service node.

[0111] After obtaining the call duration required for each dependent service node to be invoked by the preset service node, the call duration required for each dependent service node to be invoked by the preset service node can be analyzed and processed to determine the call priority of each dependent service node. Implementation method 1: The call priority of each dependent service node can be determined by the preset mapping relationship and the call duration required for each dependent service node to be invoked by the preset service node.

[0112] Implementation Method 2: Call duration and call priority are negatively correlated. That is, the shorter the call duration, the higher the call priority of the dependent service node corresponding to that call duration; conversely, the longer the call duration, the lower the call priority of the dependent service node corresponding to that call duration. For example, consider dependent service nodes a, b, and c. The call duration for dependent service node a when invoked by a preset service node is t1, for dependent service node b it's t2, and for dependent service node c it's t3. The relationship between these distances is: t2 > t3 > t1. Therefore, the call priorities of each dependent service node can be determined as follows: the call priority of dependent service node 2 is lower than that of dependent service node 3, and the call priority of dependent service node 3 is lower than that of dependent service node 1. In other words, dependent service node 1 has the highest call priority. This improves the accuracy and reliability of determining the call priorities of multiple dependent service nodes to a certain extent.

[0113] Step S503: Based on the call priority, determine the primary dependent service node and the disaster recovery dependent service node in the set of dependent service nodes, wherein the call priority of the primary dependent service node is higher than that of the disaster recovery dependent service node.

[0114] After obtaining the call priorities of multiple dependent service nodes, these priorities can be analyzed to determine the primary and disaster recovery dependent service nodes within the set of dependent service nodes. The primary dependent service node has a higher call priority than the disaster recovery dependent service node. In some instances, the primary dependent service node can be the one with the highest call priority in the set, and the disaster recovery dependent service node can be the one with the second highest call priority. This ensures the accuracy and reliability of determining the primary and disaster recovery dependent service nodes.

[0115] In some other instances, for a set of dependent service nodes, the set of dependent service nodes may be updated in response to the update operation of the dependent service nodes. In this case, the primary dependent service node and the disaster recovery dependent service node may be updated along with the update operation of the set of dependent service nodes. Therefore, in order to ensure the accuracy and reliability of determining the primary dependent service node and the disaster recovery dependent service node, the method in this embodiment may further include: obtaining the updated set of dependent service nodes in response to the update operation of the set of dependent service nodes; and determining whether the primary dependent service node and the disaster recovery dependent service node need to be updated based on the updated set of dependent service nodes.

[0116] Specifically, regarding the set of dependent service nodes, users can update it according to application or scenario requirements. For example, they can add, delete, or modify dependent service nodes based on application or scenario needs. In this case, the set of dependent service nodes is updated. Since the primary and disaster recovery dependent service nodes are determined based on multiple dependent service nodes in the set, an update to the set may cause changes to the previously determined primary and disaster recovery dependent service nodes.

[0117] To ensure the accuracy and reliability of determining the primary and disaster recovery dependent service nodes, we can first check whether there are any update operations on the set of dependent service nodes. In some instances, we can check whether the set of dependent service nodes at the current moment is the same as the set of dependent service nodes at a historical moment. If the set of dependent service nodes at the current moment is the same as the set of dependent service nodes at a historical moment, it is determined that no update operation has occurred on the dependent service nodes; if the set of dependent service nodes at the current moment is different from the set of dependent service nodes at a historical moment, it is determined that an update operation has occurred on the dependent service nodes.

[0118] After responding to an update operation on the set of dependent service nodes, an updated set of dependent service nodes can be obtained, which may include the updated dependent service nodes. Once the updated set of dependent service nodes is obtained, it can be analyzed to determine whether update operations are needed on the primary dependent service nodes and disaster recovery dependent service nodes.

[0119] In some instances, determining whether to update the primary and disaster recovery service nodes can be done using a pre-trained neural network model. In this case, the process can involve: obtaining the pre-trained neural network model; inputting the updated set of dependent service nodes, the corresponding primary and disaster recovery service nodes into the neural network model for processing, and obtaining the output result. This result can be either a first result indicating that updating the primary and disaster recovery service nodes is necessary, or a second result indicating that updating the primary and disaster recovery service nodes is not necessary.

[0120] Furthermore, if the judgment result is the second result, there is no need to update the primary dependent service node and the disaster recovery dependent service node. The previously determined primary dependent service node and disaster recovery dependent service node can then be used for request processing. Conversely, if the judgment result is the first result, the updated set of dependent service nodes can be used to determine the updated primary dependent service node and the updated disaster recovery dependent service node. The specific method for determining the updated primary dependent service node and the updated disaster recovery dependent service node is similar to the specific method for determining the "primary dependent service node and disaster recovery dependent service node" in the above embodiment, and can be referred to the above description for details, which will not be repeated here.

[0121] In this embodiment, by obtaining a set of dependent service nodes corresponding to a preset service node, determining the call priority of each of the multiple dependent service nodes, and determining the primary dependent service node and the disaster recovery dependent service node in the set of dependent service nodes based on the call priority, the primary dependent service node and the disaster recovery dependent service node are effectively determined based on the call priority of each dependent service node, thereby ensuring the accuracy and reliability of determining the primary dependent service node and the disaster recovery dependent service node to a certain extent.

[0122] Figure 6 A flowchart illustrating another request processing method provided as an exemplary embodiment of this application; based on any of the above embodiments, refer to the appendix. Figure 6 As shown, for the dependent service nodes corresponding to the preset service node, in order to ensure the stable and reliable operation of the preset service node, the availability of the dependent service node can be detected periodically or irregularly. In this case, the method in this embodiment may further include:

[0123] Step S601: Generate test information corresponding to the dependent service nodes.

[0124] For any one of the dependent service nodes in the set of dependent service nodes, the dependent service node may become unavailable. In this case, it is impossible to analyze and process the service requests of the preset service node based on the dependent service node. In order to ensure the stability and reliability of the preset service node, the availability of the dependent service node can be tested. Specifically, test information corresponding to the dependent service node can be generated. This test information can be used to test communication signals. It can be generated by analyzing and processing the dependent service node through a pre-trained neural network model. Different dependent service nodes can correspond to different test information.

[0125] Step S602: Detect the availability of dependent service nodes based on test information to obtain detection information used to identify whether dependent service nodes are available.

[0126] After generating test information corresponding to the dependent service nodes, the availability of the dependent service nodes can be tested based on the test information to obtain detection information indicating whether the dependent service nodes are available. In some instances, the detection information indicating whether the dependent service nodes are available can be determined by the feedback information returned by each dependent service node in response to the test information. In this case, testing the availability of the dependent service nodes based on the test information to obtain the detection information indicating whether the dependent service nodes are available may include: sending the test information to each dependent service node; obtaining the feedback information returned by each dependent service node in response to the test information; and determining the detection information indicating whether the dependent service nodes are available based on the feedback information.

[0127] Specifically, the detection information used to identify whether a dependent service node is available based on feedback information can include: when the feedback information is within the normal result range corresponding to the test information, the detection information is determined as the first detection information to identify the availability of the dependent service node; when the feedback information is outside the normal result range corresponding to the test information, the detection information is determined as the second detection information to identify the unavailability of the dependent service node. This effectively achieves a stable detection operation for the availability of dependent service nodes.

[0128] Step S603: Manage dependent service nodes based on detection information.

[0129] The detection information can be either first detection information used to identify the availability of dependent service nodes, or second detection information used to identify the unavailability of dependent service nodes. Different detection information corresponds to different management strategies. After obtaining the detection information, management operations can be performed on the dependent service nodes based on the management strategy corresponding to the detection information. In some instances, managing dependent service nodes based on detection information may include: when the detection information is first detection information, determining a first management strategy corresponding to the first detection information, which can be a strategy that allows dependent service nodes to perform normal request processing operations; and then performing management operations on the dependent service nodes based on the first management strategy. When the detection information is second detection information, determining a second management strategy corresponding to the second detection information, which can be a strategy that prohibits dependent service nodes from performing normal request processing operations; and then performing management operations on the dependent service nodes based on the second management strategy.

[0130] Furthermore, when the detection information is the second detection information, node reminder information can be generated based on the second management strategy corresponding to the second detection information, and the node reminder information can be displayed to remind users to perform debugging or maintenance management operations on dependent service nodes, thereby facilitating the improvement of the quality and efficiency of timely maintenance of dependent service nodes.

[0131] In this embodiment, test information corresponding to the dependent service nodes is generated, and then the availability of the dependent service nodes is detected based on the test information to obtain detection information that identifies whether the dependent service nodes are available. The dependent service nodes are then managed based on the detection information. This effectively realizes the detection operation of the availability of the dependent service nodes and allows for flexible management of the dependent service nodes based on the detection information, thereby improving the stability and reliability of the request processing operations of the dependent service nodes.

[0132] Figure 7 A flowchart illustrating another request processing method provided as an exemplary embodiment of this application; based on any of the above embodiments, refer to the appendix. Figure 7 As shown, in the case where the first intermediate result is abnormal, the reason for the abnormal result may be due to the running status of the primary dependent service node, or it may not be due to the running status of the primary dependent service node. Since different reasons for the abnormal result may correspond to different request processing strategies, it is necessary to determine the reason for the abnormal result before calling the disaster recovery dependent service node corresponding to the preset service node to process the service processing request. Specifically, the method in this embodiment may further include:

[0133] Step S701: Identify whether the reason for the first intermediate result being an abnormal result is that the main dependent service node is in an abnormal state.

[0134] The abnormal state of the primary dependent service node can include at least one of the following: the primary dependent service node is in a faulty state; the primary dependent service node is in an unavailable state. The aforementioned faulty state of the primary dependent service node can include at least one of the following: the primary dependent service node is in a hardware faulty state, the primary dependent service node is in a software faulty state, the primary dependent service node is in a configuration error state, etc. The aforementioned unavailable state of the primary dependent service node can include at least one of the following: the primary dependent service node is completely down, the primary dependent service node is in offline mode, the primary dependent service node is inaccessible, etc.

[0135] Since the first intermediate result being abnormal may be due to the main dependent service node being in an abnormal state, or it may be due to other reasons, different reasons can correspond to different request processing strategies. Therefore, in order to ensure the stability and reliability of processing operations on the preset service node, after obtaining the first intermediate result returned by the main dependent service node, if the first intermediate result is abnormal, we can first identify whether the reason for the first intermediate result being abnormal is that the main dependent service node is in an abnormal state.

[0136] In some instances, identifying the reason why the first intermediate result is an abnormal result can be achieved through a large language model. In this case, identifying whether the reason why the first intermediate result is an abnormal result is that the main dependent service node is in an abnormal state may include: obtaining a pre-trained large language model; inputting the first intermediate result, the running status of the main dependent service node, and the fact that the first intermediate result is an abnormal result into the large language model for processing, and obtaining whether the reason why the first intermediate result is an abnormal result is that the main dependent service node is in an abnormal state.

[0137] Step S702: If the identification result is yes, then the disaster recovery dependency service node corresponding to the preset service node is allowed to process the service processing request. Alternatively,

[0138] Step S703: If the identification result is negative, then the disaster recovery dependency service node corresponding to the preset service node shall be prohibited from processing the service processing request.

[0139] If the identification result is yes, it means that the reason why the first intermediate result is abnormal is that the main dependent service node is in an abnormal state. That is, because the main dependent service node is in an abnormal state, the first intermediate result returned by the main dependent service node is abnormal. In this case, in order to ensure that the preset service node can operate stably to a certain extent, when the main dependent service node is in an abnormal state, it is allowed to call the disaster recovery service node corresponding to the preset service node to process the service processing request.

[0140] Conversely, if the identification result is negative, it indicates that the reason for the first intermediate result being abnormal is not that the main dependent service node is in an abnormal state. In this case, the first intermediate result being abnormal may be due to errors in the input data corresponding to the service processing request, rather than because the main dependent service node is in an abnormal state, thus causing the first intermediate result returned by the main dependent service node to be abnormal. In this case, if the disaster recovery dependent service node corresponding to the preset service node is called to analyze and process the service processing request, the second intermediate result corresponding to the service processing request will most likely also be abnormal. Therefore, in order to ensure the effective utilization of data resources, it is advisable to prohibit the call to the disaster recovery dependent service node corresponding to the preset service node to process the service processing request.

[0141] Furthermore, after prohibiting the use of the disaster recovery dependency service node corresponding to the preset service node to process the service processing request, a reminder message can be generated and displayed if the first intermediate result is abnormal. This allows the user to be informed of the abnormal status of the first intermediate result in a timely and rapid manner, thereby enabling quick manual intervention and / or inspection of the request processing operation, which in turn helps to improve the accuracy and reliability of the service processing request operation.

[0142] In this embodiment, by identifying whether the reason for the first intermediate result being an abnormal result is that the main dependent service node is in an abnormal state, if the identification result is yes, then it is allowed to call the disaster recovery dependent service node corresponding to the preset service node to process the service processing request; or, if the identification result is no, then it is prohibited to call the disaster recovery dependent service node corresponding to the preset service node to process the service processing request. This effectively realizes that different request processing operations can be performed based on different reasons that cause the first intermediate result to be an abnormal result, further improving the stability and reliability of the service request processing operation.

[0143] For specific applications, please refer to the appendix. Figure 8As shown in the illustration, this application embodiment provides a request processing method. The execution entity of this request processing method can be implemented as an execution engine of a preset service. This execution engine communicates with the primary dependent service node (live node) and the disaster recovery dependent service node (second node) used to implement request processing operations, enabling disaster recovery scheduling operations. The execution engine can have the following functions: 1) Initializing the configuration and deployment of dependent service nodes across multiple regions, and selecting the primary dependent service node and the disaster recovery dependent service node to be invoked; 2) Performing automatic disaster recovery operations for invoking dependent service nodes corresponding to multiple regions. It is important to note that the primary dependent service node and the disaster recovery dependent service node can implement invoking operations through preset interfaces. Furthermore, the implementation code of the primary dependent service node and the disaster recovery dependent service node is independent of the implementation code of the preset service node. This eliminates the need for developers to modify the implementation code of the preset service node to achieve disaster recovery scheduling operations for dependent service nodes, thereby reducing development and labor costs to a certain extent.

[0144] Specifically, the method may include the following steps:

[0145] Step 1: The execution engine performs initialization loading operations on the preset service nodes.

[0146] Specifically, when a startup or trigger operation is performed on a preset service node, an initialization loading operation can be performed on the preset service node. This initialization loading operation can include: database loading operation, configuration information loading and calling operation. The aforementioned configuration information can include relevant data of dependent service nodes. Specifically, dependent service nodes can have the following characteristics: a) Multi-region deployment, the data of dependent service nodes in different regions are asynchronously synchronized by the central region through data synchronization; b) The request service results corresponding to each dependent service node are not related to the region. Specifically, the parameters and request results of calling dependent service nodes in the local region are the same as the parameters and request results of calling dependent service nodes across regions. That is, there is no difference in service request and response data when processing the same data service request; c) Dependent service nodes can be called across regions. Specifically, the cross-region call operation corresponding to the dependent service node is not subject to network restrictions and interception.

[0147] After loading the configuration information, the primary dependency service node and disaster recovery dependency service node corresponding to the preset service node can be determined through the configuration information. There can be one primary dependency service node and one or more disaster recovery dependency service nodes. The calling priority of the primary dependency service node can be higher than that of the disaster recovery dependency service node, or the distance between the primary dependency service node and the preset service node can be less than the distance between the disaster recovery dependency service node and the preset service node; or the call time required for the primary dependency service node to be called by the preset service node can be less than the call time required for the disaster recovery dependency service node to be called by the preset service node.

[0148] It should be noted that both the primary dependency service node and the disaster recovery dependency service node can be active dependency service nodes, that is, the primary dependency service node and the disaster recovery dependency service node are dual-active dependency service nodes; or, at least some of the primary dependency service node and the disaster recovery dependency service node are active dependency service nodes, that is, the primary dependency service node and the disaster recovery dependency service node are multi-active dependency service nodes.

[0149] Step 2: When a service processing request corresponding to a preset service node is obtained, the execution engine can call the main dependent service node to analyze and process the service processing request, and can obtain the call result returned by the main dependent service node.

[0150] Identify whether the call result returned by the main dependent service node is a normal result.

[0151] Step 31: When it is determined that the call result returned by the main dependent service node is a normal result, the execution engine can proceed to the next process based on the call result, that is, it can determine the request processing result corresponding to the service processing request based on the call result.

[0152] Step 32: When it is determined that the call result returned by the main dependent service node is an error result, the execution engine can further determine whether the error result is due to a service failure or service unavailability.

[0153] Specifically, when an error result is obtained, the error code information used to identify the error result can be retrieved, and the standard error code information for service failure or service unavailability can be determined. The error code information used to identify the error result is compared with the standard error code information. If the error code information matches the standard error code information, it is determined that the error result is caused by service failure or service unavailability; if the error code information does not match the standard error code information, it is determined that the error result is not caused by service failure or service unavailability.

[0154] Step 41: If it is determined that the error result of the call is not caused by a service unavailability problem, the execution engine can proceed to the next step of the process.

[0155] Step 42: If it is determined that the error result is caused by the service being unavailable, the execution engine can call the disaster recovery dependent service node to perform cross-region disaster recovery operation. That is, the disaster recovery dependent service node is called to analyze and process the service processing request in order to obtain the call result returned by the disaster recovery dependent service node corresponding to the service processing request.

[0156] Step 5: The execution engine will proceed to the next step based on the call result to determine the corresponding request processing result for the service processing request. This, to a certain extent, ensures the stability and reliability of the preset service node operation.

[0157] In some instances, the default service node can be implemented as a key management service node providing SaaS-based data plane services to cloud customers, and the execution engine can be implemented as an execution engine for key management operations. The service stability corresponding to the key management service node is crucial. During system stability construction, the dependent service nodes corresponding to the key management service node can perform local and cross-regional calls. This allows for rapid degradation and disaster recovery when dependent service nodes experience service issues, ensuring the stability of the key management service node's operation and reducing the access cost of supporting dependent service nodes across multiple regions.

[0158] In addition, the key management service node can periodically perform self-checks on the availability of dependent service nodes deployed in various regions. This can prevent cross-regional access services from being unavailable due to changes in network rules. Furthermore, the key management service node can periodically re-plan the primary and disaster recovery dependent service nodes as new dependent service regions are added. This ensures that suitable dependent service nodes are identified as primary dependent service nodes, guaranteeing both the effectiveness of cross-regional service calls and short response times in disaster recovery scenarios.

[0159] The technical solution provided in this application embodiment implements a rapid access service framework that enables cross-regional calls for dependent services. It allows for quick access to dependent service nodes across regions, reducing access costs. If a primary dependent service node in the local region experiences a service problem, automatic cross-regional disaster recovery can be implemented to ensure the stability of the preset service nodes and the correctness of service calls. Furthermore, the solution includes a service inspection mechanism. The execution engine can periodically or irregularly collect statistics on the cross-regional call duration of each dependent service node to ensure the availability and reliability of cross-regional disaster recovery dependent service nodes. Then, based on the call duration, the regional call order for cross-regional calls can be optimized according to the distance information corresponding to the dependent service nodes, ensuring the effectiveness of cross-regional calls during fault recovery and minimizing service response time. Furthermore, compared to the service disaster recovery operations provided by related technologies, this solution also has the following advantages: Since the disaster recovery scheduling operations of the primary dependent service node, disaster recovery dependent service node, or other dependent service nodes do not require any modification or configuration of the code of the preset service node, the development workload of the disaster recovery scheduling operations of the dependent service nodes is reduced, thus lowering the development cost. In addition, each dependent service node can communicate with the execution engine through a preset interface, which effectively reduces the access cost of the dependent service nodes; this further improves the practicality of the solution and is conducive to market promotion and application.

[0160] Figure 9 A flowchart illustrating a key management method provided for an exemplary embodiment of this application; see attached diagram. Figure 9 As shown, this embodiment provides a key management method. The execution subject of this method is a key management device, which can be implemented as software or a combination of software and hardware. When the key management device is implemented as hardware, it can be various electronic devices capable of performing key management operations, including but not limited to execution engines, personal computers, servers, etc., used to implement key management service nodes. When the key management device is implemented as software, it can be installed in the electronic devices listed above. Specifically, the key management method provided in this embodiment may include:

[0161] Step S901: In response to the obtained key management request for the key management service node, call the main dependent service node corresponding to the key management service node to process the key management request.

[0162] The key management service node can be implemented as a Key Management Service (KMS) system or platform, specifically a one-stop key management and data encryption service platform that provides simple, reliable, secure, and compliant data encryption protection capabilities. Key management requests to the key management service node can be at least one of the following: key generation request, key storage request, key distribution request, key usage request, key update request, key backup request, key recovery request, etc. Those skilled in the art can generate different key management requests according to specific application scenarios or application requirements.

[0163] Step S902: Obtain the first intermediate result returned by the main dependent service node.

[0164] Step S903: If the first intermediate result is an abnormal result, the disaster recovery dependency service node corresponding to the key management service node is invoked to process the key management request. The distance between the disaster recovery dependency service node and the key management service node is greater than the distance between the main dependency service node and the key management service node.

[0165] Step S904: Obtain the second intermediate result returned by the disaster recovery dependent service node operation.

[0166] In this embodiment, the specific implementation method and effect of steps S901-S904 are the same as those described above. Figure 2 The specific implementation methods and effects of steps S201-S204 in the corresponding embodiments are similar. Please refer to the above description for details, which will not be repeated here.

[0167] Step S905: Based on the second intermediate result, determine the key management result corresponding to the key management request.

[0168] After obtaining the second intermediate result, it can be analyzed and processed to determine the key management result corresponding to the key management request. Different types of key management requests can correspond to different key management results. For example, if the key management request is implemented as a key generation request, the key management result is implemented as the corresponding key generation information, which is used to implement the key generation operation; if the key management request is implemented as a key distribution request, the key management result is implemented as the corresponding key distribution information, which is used to implement the key distribution operation, and so on. This effectively realizes the practicality of the method.

[0169] The key management method provided in this embodiment, after a key management request is made to a key management service node, processes the key management request by calling the primary dependent service node corresponding to the key management service node, and obtains a first intermediate result returned by the primary dependent service node. Furthermore, if the first intermediate result is an abnormal result, and to ensure the stability and reliability of normal processing of the key management request, a disaster recovery dependent service node corresponding to the key management service node can be called to process the key management request. This allows the acquisition of a second intermediate result returned by the disaster recovery dependent service node, used to determine the key management result corresponding to the key management request. This effectively enables disaster recovery calls to dependent services through the primary dependent service node and the disaster recovery dependent service node when the service availability of the dependent service cannot meet the requirements, thereby ensuring the stability of the key management service node's processing operations and further improving the practicality of the method.

[0170] Figure 10 A schematic diagram of a request processing apparatus provided for an exemplary embodiment of this application; see attached diagram. Figure 10 As shown, this embodiment provides a request processing device for performing the above-described... Figure 2 The request processing method shown may include:

[0171] The first processing module 11 is used to respond to a service processing request for a preset service node by calling the main dependent service node corresponding to the preset service node to process the service processing request.

[0172] The first acquisition module 12 is used to acquire the first intermediate result returned by the main dependent service node;

[0173] The first processing module 11 is also used to call the disaster recovery dependency service node corresponding to the preset service node to process the service processing request when the first intermediate result is an abnormal result, wherein the distance between the disaster recovery dependency service node and the preset service node is greater than the distance between the main dependency service node and the preset service node.

[0174] The first acquisition module 12 is also used to acquire the second intermediate result returned by the disaster recovery dependent service node. The second intermediate result is used to determine the service processing result corresponding to the service processing request.

[0175] The request processing apparatus in this embodiment may also include the above-mentioned components. Figures 1-8 The description of the embodiments shown is for reference only, and will not be elaborated upon here.

[0176] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 11, 12, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0177] Figure 11 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application; as shown Figure 11 As shown, this embodiment provides an electronic device for performing the above-described... Figure 2 The request processing method shown may include an electronic device that includes a memory 24 and a processor 25.

[0178] Memory 24 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0179] The processor 25, coupled to the memory 24, is used to execute a computer program in the memory 24 for: responding to a service processing request for a preset service node, invoking the primary dependent service node corresponding to the preset service node to process the service processing request; obtaining a first intermediate result returned by the primary dependent service node; if the first intermediate result is an abnormal result, invoking the disaster recovery dependent service node corresponding to the preset service node to process the service processing request, wherein the distance between the disaster recovery dependent service node and the preset service node is greater than the distance between the primary dependent service node and the preset service node; and obtaining a second intermediate result returned by the disaster recovery dependent service node, the second intermediate result being used to determine the service processing result corresponding to the service processing request.

[0180] In some instances, before the primary dependent service node corresponding to the preset service node is invoked to process the service processing request, the processor 25 performs the following: obtaining a set of dependent service nodes corresponding to the preset service node, the set of dependent service nodes including multiple dependent service nodes; determining the invocation priority of each of the multiple dependent service nodes; and determining the primary dependent service node and the disaster recovery dependent service node in the set of dependent service nodes based on the invocation priority, wherein the invocation priority of the primary dependent service node is higher than the invocation priority of the disaster recovery dependent service node.

[0181] In some instances, when processor 25 determines the call priority of each of the multiple dependent service nodes, processor 25 performs the following: obtaining distance information between each dependent service node and a preset service node; and determining the call priority based on the distance information.

[0182] In some instances, distance information is negatively correlated with call priority.

[0183] In some instances, when processor 25 determines the call priority corresponding to each of the multiple dependent service nodes, processor 25 is used to perform: obtaining the call duration required for a preset service node to perform a call operation on each dependent service node; and determining the call priority based on the call duration.

[0184] In some instances, call duration is negatively correlated with call priority.

[0185] In some instances, the processor 25 is also used to: generate test information corresponding to the dependent service nodes; detect the availability of the dependent service nodes based on the test information to obtain detection information for identifying whether the dependent service nodes are available; and manage the dependent service nodes based on the detection information.

[0186] In some instances, the processor 25 is also configured to: obtain an updated set of dependent service nodes in response to an update operation on the set of dependent service nodes; and determine, based on the updated set of dependent service nodes, whether the primary dependent service node and the disaster recovery dependent service node need to be updated.

[0187] In some instances, before calling the disaster recovery dependency service node corresponding to the preset service node to process the service processing request, the processor 25 is further configured to: identify whether the reason why the first intermediate result is an abnormal result is that the main dependency service node is in an abnormal state; if the identification result is yes, then the call to the disaster recovery dependency service node corresponding to the preset service node to process the service processing request is allowed; or, if the identification result is no, then the call to the disaster recovery dependency service node corresponding to the preset service node to process the service processing request is prohibited.

[0188] In some instances, the main dependent service node is in an abnormal state including at least one of the following:

[0189] The primary dependent service node is in a faulty state;

[0190] The primary dependent service node is unavailable.

[0191] In some instances, after obtaining the second intermediate result returned by the disaster recovery dependent service node, the processor 25 is further configured to: if the second intermediate result is an abnormal result, obtain disaster recovery configuration information corresponding to the preset service node; based on the disaster recovery configuration information, determine the standby disaster recovery service node corresponding to the preset service node, wherein the distance between the standby disaster recovery service node and the preset service node is greater than the distance between the disaster recovery dependent service node and the preset service node; and call the standby disaster recovery service node to process the service processing request to obtain the third intermediate result.

[0192] In some instances, both the primary dependency service node and the disaster recovery dependency service node are active nodes.

[0193] In some instances, the deployment region of the primary dependency service node is different from the deployment region of the disaster recovery dependency service node; or,

[0194] When the deployment region of the primary dependent service node is the same as that of the disaster recovery dependent service node, the domain name corresponding to the primary dependent service node is different from that of the disaster recovery dependent service node.

[0195] Furthermore, such as Figure 11 As shown, the electronic device also includes other components such as a communication component 26, a display 27, a power supply component 28, and an audio component 29. Figure 11 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 11 The components shown. Additionally... Figure 11 The components within the center frame are optional, not mandatory, and their specific requirements depend on the product form of the work node. In this embodiment, the work node can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the work node in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 11 The components within the center frame; if the working node in this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include... Figure 11 The component within the center frame.

[0196] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0197] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0198] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0199] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0200] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0201] Figure 12 A schematic diagram of a key management device provided for an exemplary embodiment of this application; as shown Figure 12 As shown, this embodiment provides a key management device, which is used to perform the above-described... Figure 9 The key management method shown. Specifically, the key management device may include:

[0202] The second processing module 31 is used to respond to the obtained key management request for the key management service node by calling the main dependent service node corresponding to the key management service node to process the key management request.

[0203] The second acquisition module 32 is used to acquire the first intermediate result returned by the main dependent service node;

[0204] The second processing module 31 is also used to call the disaster recovery dependency service node corresponding to the key management service node to process the key management request when the first intermediate result is an abnormal result, wherein the distance between the disaster recovery dependency service node and the key management service node is greater than the distance between the main dependency service node and the key management service node.

[0205] The second acquisition module 32 is used to acquire the second intermediate result returned by the operation of the disaster recovery dependent service node;

[0206] The second processing module 31 is further configured to determine the key management result corresponding to the key management request based on the second intermediate result.

[0207] The performance analysis device in this embodiment may also include the above-mentioned components. Figures 8-9 The description of the embodiments shown is for reference only, and will not be elaborated upon here.

[0208] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 11, 12, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0209] Figure 13 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application; as shown Figure 13As shown, this embodiment provides an electronic device for performing the above-described... Figure 9 The key management method shown includes an electronic device that may include a memory 44 and a processor 45.

[0210] Memory 44 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0211] The processor 45, coupled to the memory 44, is used to execute a computer program in the memory 44 for: responding to a obtained key management request for a key management service node, invoking the primary dependent service node corresponding to the key management service node to process the key management request; obtaining a first intermediate result returned by the primary dependent service node; if the first intermediate result is an abnormal result, invoking the disaster recovery dependent service node corresponding to the key management service node to process the key management request, wherein the distance between the disaster recovery dependent service node and the key management service node is greater than the distance between the primary dependent service node and the key management service node; obtaining a second intermediate result returned by the operation of the disaster recovery dependent service node; and determining the key management result corresponding to the key management request based on the second intermediate result.

[0212] Regarding the processor 45 in the electronic device of this embodiment, it can also perform the above-described functions. Figures 8-9 The description of the embodiments shown is for reference only, and will not be elaborated upon here.

[0213] Furthermore, such as Figure 13 As shown, the electronic device also includes other components such as a communication component 46, a display 47, a power supply component 48, and an audio component 49. Figure 13 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 13 The components shown. Additionally... Figure 13 The components within the center frame are optional, not mandatory, and their specific requirements depend on the product form of the work node. In this embodiment, the work node can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the work node in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 13 The components within the center frame; if the working node in this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include... Figure 13 The component within the center frame.

[0214] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0215] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0216] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0217] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0218] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0219] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0220] Accordingly, this application also provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the processor is able to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0221] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0222] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A request processing method, characterized in that, include: In response to a service processing request for a preset service node, the primary dependent service node corresponding to the preset service node is invoked to process the service processing request. Obtain the first intermediate result returned by the main dependent service node; If the first intermediate result is an abnormal result, the disaster recovery dependency service node corresponding to the preset service node is invoked to process the service processing request, wherein the distance between the disaster recovery dependency service node and the preset service node is greater than the distance between the main dependency service node and the preset service node. Obtain the second intermediate result returned by the disaster recovery dependent service node. The second intermediate result is used to determine the service processing result corresponding to the service processing request.

2. The method according to claim 1, characterized in that, Before invoking the primary dependent service node corresponding to the preset service node to process the service processing request, the method further includes: Obtain a set of dependent service nodes corresponding to the preset service node, wherein the set of dependent service nodes includes multiple dependent service nodes; Determine the invocation priority of each of the multiple dependent service nodes; Based on the invocation priority, the primary dependent service node and the disaster recovery dependent service node are determined in the set of dependent service nodes, wherein the invocation priority of the primary dependent service node is higher than that of the disaster recovery dependent service node.

3. The method according to claim 2, characterized in that, Determining the invocation priority of each of the multiple dependent service nodes includes: Obtain the distance information between each dependent service node and the preset service node; The call priority is determined based on the distance information.

4. The method according to claim 3, characterized in that, The distance information is negatively correlated with the call priority.

5. The method according to claim 2, characterized in that, Determining the invocation priority of each of the multiple dependent service nodes includes: Obtain the call duration required when the preset service node performs call operations on each dependent service node; The call priority is determined based on the call duration.

6. The method according to claim 5, characterized in that, The call duration is negatively correlated with the call priority.

7. The method according to any one of claims 2-6, characterized in that, The method further includes: Generate test information corresponding to the dependent service nodes; The availability of the dependent service nodes is detected based on the test information to obtain detection information that identifies whether the dependent service nodes are available. The dependent service nodes are managed based on the detection information.

8. The method according to any one of claims 2-6, characterized in that, The method further includes: In response to an update operation on the set of dependent service nodes, an updated set of dependent service nodes is obtained; Based on the updated set of dependent service nodes, determine whether it is necessary to update the primary dependent service node and the disaster recovery dependent service node.

9. The method according to any one of claims 1-6, characterized in that, Before invoking the disaster recovery dependency service node corresponding to the preset service node to process the service processing request, the method further includes: Identify whether the reason the first intermediate result is an abnormal result is that the main dependent service node is in an abnormal state; If the identification result is yes, then the disaster recovery dependency service node corresponding to the preset service node is allowed to process the service processing request; or, If the identification result is negative, then the disaster recovery dependency service node corresponding to the preset service node is prohibited from processing the service processing request.

10. The method according to claim 9, characterized in that, The main dependent service node being in an abnormal state includes at least one of the following: The primary dependent service node is in a fault state; The primary dependent service node is in an unavailable state.

11. The method according to any one of claims 1-6, characterized in that, After obtaining the second intermediate result returned by the disaster recovery dependency service node, the method further includes: If the second intermediate result is an abnormal result, obtain the disaster recovery configuration information corresponding to the preset service node; Based on the disaster recovery configuration information, a backup disaster recovery service node corresponding to the preset service node is determined, wherein the distance between the backup disaster recovery service node and the preset service node is greater than the distance between the disaster recovery dependent service node and the preset service node; The backup disaster recovery service node is invoked to process the service processing request and obtain a third intermediate result.

12. The method according to any one of claims 1-6, characterized in that, Both the primary dependent service node and the disaster recovery dependent service node are active nodes.

13. The method according to any one of claims 1-6, characterized in that, The deployment area of ​​the primary dependent service node is different from the deployment area of ​​the disaster recovery dependent service node; or, When the deployment region of the primary dependent service node is the same as the deployment region of the disaster recovery dependent service node, the domain name corresponding to the primary dependent service node is different from the domain name of the disaster recovery dependent service node.

14. A key management method, characterized in that, include: In response to the obtained key management request for the key management service node, the main dependent service node corresponding to the key management service node is invoked to process the key management request; Obtain the first intermediate result returned by the main dependent service node; If the first intermediate result is an abnormal result, the disaster recovery dependency service node corresponding to the key management service node is invoked to process the key management request, wherein the distance between the disaster recovery dependency service node and the key management service node is greater than the distance between the main dependency service node and the key management service node; Obtain the second intermediate result returned by the operation of the disaster recovery dependent service node; Based on the second intermediate result, the key management result corresponding to the key management request is determined.

15. A request processing apparatus, characterized in that, include: The first processing module is used to respond to a service processing request for a preset service node by calling the main dependent service node corresponding to the preset service node to process the service processing request. The first acquisition module is used to acquire the first intermediate result returned by the main dependent service node; The first processing module is further configured to, in the event that the first intermediate result is an abnormal result, call the disaster recovery dependency service node corresponding to the preset service node to process the service processing request, wherein the distance between the disaster recovery dependency service node and the preset service node is greater than the distance between the main dependency service node and the preset service node. The first acquisition module is further configured to acquire a second intermediate result returned by the disaster recovery dependent service node, the second intermediate result being used to determine the service processing result corresponding to the service processing request.

16. A key management device, characterized in that, include: The second processing module is used to respond to the obtained key management request for the key management service node by calling the main dependent service node corresponding to the key management service node to process the key management request; The second acquisition module is used to acquire the first intermediate result returned by the main dependent service node; The second processing module is further configured to, in the event that the first intermediate result is an abnormal result, invoke the disaster recovery dependency service node corresponding to the key management service node to process the key management request, wherein the distance between the disaster recovery dependency service node and the key management service node is greater than the distance between the primary dependency service node and the key management service node. The second acquisition module is used to acquire the second intermediate result returned by the operation of the disaster recovery dependent service node; The second processing module is further configured to determine, based on the second intermediate result, a key management result corresponding to the key management request.

17. An electronic device, characterized in that, include: A memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions, when executed by the processor, implement the method of any one of claims 1-14.

18. A computer storage medium, characterized in that, Used to store a computer program that, when executed by a computer, implements the method of any one of claims 1-14.

19. A computer program product, characterized in that, include: A computer program, when executed by a processor of an electronic device, causes the processor to perform the steps of the method of any one of claims 1-14.

Images