Method and apparatus for handling failure of service resource

Abstract

The application discloses a service resource fault processing method and device, electronic equipment and a storage medium. The method is executed by a service server and comprises the following steps: receiving a service request; calling a target service resource according to the service request and updating a preset resource calling table, wherein the preset resource calling table is used for storing resource calling data corresponding to a service request under processing; performing asynchronous detection on the preset resource calling table; determining a fault resource list according to an asynchronous detection result, so as to perform fault processing according to the fault resource list. According to the service resource fault processing method, the fault resource can be determined in advance and removed when the service is still under processing by means of asynchronous detection on the preset resource calling table, and it is not necessary to wait for the current service processing to be completed, so that the influence of the fault resource on subsequent service processing is reduced, and the service continuity is improved.

Description

Technical Field

[0001] This application relates to the field of distributed system technology, and in particular to a method and apparatus for handling faults in business resources. Background Technology

[0002] In business systems, when downstream resources are deployed in a distributed manner in the form of clusters (such as multiple instances), when processing each business transaction, it is generally necessary to first use a routing algorithm to select a resource from the list of available resources, and then call that resource. For example, the Dubbo service framework routes service providers when making remote calls, and the transaction system routes the database when saving transaction data, etc.

[0003] When a resource in a downstream resource cluster fails, it needs to be dealt with promptly. However, existing fault handling methods take a long time and can easily have a significant impact on business continuity. Summary of the Invention

[0004] This application provides a method and apparatus for handling service resource failures, so as to reduce the impact of failed resources on service continuity.

[0005] The embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a method for handling faults in business resources, executed by a business server, wherein the method includes:

[0007] Receive service requests;

[0008] The target business resource is invoked according to the business request and the preset resource invocation table is updated, wherein the preset resource invocation table is used to store resource invocation data corresponding to the business request being processed.

[0009] Asynchronous probing is performed on the preset resource call table;

[0010] A list of faulty resources is determined based on the asynchronous detection results, and fault handling is performed based on the list of faulty resources.

[0011] Optionally, the preset resource call table is stored in the memory of the business server, and the preset resource call table contains one or more resource call data, including business identifier, resource identifier, and resource call start time.

[0012] Optionally, determining the list of faulty resources based on the asynchronous detection results includes:

[0013] Based on the resource identifier, the resource call data in the preset resource call table is grouped;

[0014] Determine the resource call time for each resource group;

[0015] The faulty resources are determined based on the resource call time of each resource group, and the resource identifier corresponding to the faulty resource is added to the faulty resource list.

[0016] Optionally, the resource group includes a service identifier and a resource call start time corresponding to the service identifier, and determining the resource call time for each resource group includes:

[0017] Determine the difference between the resource call start time corresponding to the service identifier in the target resource group and the current system time, wherein the target resource group is any one of multiple resource groups;

[0018] The resource call time of the target resource group is determined based on the difference between the resource call start time and the current system time.

[0019] Optionally, the resource call time for the target resource group may be multiple, and the step of determining the faulty resource based on the resource call time of each resource group and adding the faulty resource to the faulty resource list includes:

[0020] Based on the resource call duration of the target resource group, determine whether the target resource group has more than N service identifiers with resource call durations higher than M milliseconds, where N and M are both greater than 0;

[0021] If so, the resource identifier corresponding to the target resource group is determined to be the resource identifier of the faulty resource, and the resource identifier of the faulty resource is added to the faulty resource list;

[0022] If not, then the resource identifier corresponding to the target resource group is determined to be the resource identifier of the available resource.

[0023] Optionally, after invoking the target business resource according to the business request and updating the preset resource invocation table, the method further includes:

[0024] If the business request is processed according to the target business resource, the resource call data corresponding to the business request stored in the preset resource call table is deleted.

[0025] Optionally, the step of invoking the target business resource according to the business request and updating the preset resource invocation table includes:

[0026] The target service resource is determined and invoked based on the service request and the preset routing strategy;

[0027] Obtain the resource identifier of the target business resource;

[0028] The preset resource call table is updated based on the resource identifier of the target business resource.

[0029] Optionally, determining the target service resource based on the service request and the preset routing policy includes:

[0030] Get the list of faulty resources;

[0031] The target service resource is determined based on the list of faulty resources and the preset routing policy.

[0032] Optionally, the asynchronous probing of the preset resource call table includes:

[0033] The preset resource call table is asynchronously probed at preset time intervals.

[0034] Secondly, embodiments of this application also provide a fault handling device for business resources, applied to a business server, wherein the device is used to implement any of the methods described above.

[0035] Thirdly, embodiments of this application also provide an electronic device, including:

[0036] Processor; and

[0037] A memory configured to store computer-executable instructions, which, when executed, cause the processor to perform any of the methods described above.

[0038] Fourthly, embodiments of this application also provide a computer-readable storage medium that stores one or more programs, which, when executed by an electronic device including multiple applications, cause the electronic device to perform any of the methods described above.

[0039] The above-mentioned at least one technical solution adopted in the embodiments of this application can achieve the following beneficial effects: The business resource fault handling method in the embodiments of this application is executed by the business server. When handling business resource faults, a business request is first received, then the target business resource is called according to the business request and the preset resource call table is updated. The preset resource call table is used to store resource call data corresponding to the business request being processed. Then, the preset resource call table is asynchronously probed, and finally, a list of faulty resources is determined according to the asynchronous probe results, so as to handle the faults according to the list of faulty resources. The business resource fault handling method in the embodiments of this application can pre-determine and remove faulty resources while the business is still being processed by asynchronously probing the preset resource call table, without waiting for the current business processing to end, thereby reducing the impact of faulty resources on subsequent business processing and improving business continuity. Attached Figure Description

[0040] 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:

[0041] Figure 1 This is a flowchart illustrating a fault handling method for a service resource according to an embodiment of this application.

[0042] Figure 2 This is a schematic diagram of a fault handling process for a service resource in an embodiment of this application;

[0043] Figure 3 This is a schematic diagram of the structure of a fault handling device for a service resource in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0045] 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.

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

[0047] The existing technologies for handling faulty resources mainly include the following methods:

[0048] 1) Based on the alarm information, the faulty resource is manually removed, and the subsequent routing algorithm will not select the removed resource;

[0049] 2) Periodically check the activity of resources, or automatically remove faulty resources based on the results of business resource calls.

[0050] Both of the above methods require a certain amount of time from the occurrence of a resource failure to the removal taking effect. This time can be expressed in the following form:

[0051] Hemostasis time (fault handling time) = Fault confirmation time + Kick-off effective time

[0052] For example, if a resource fails for 10 seconds, a periodic resource detection task starts detecting the resource, determines that the resource is faulty, and then sets the resource to be removed in the business system. The setting takes effect after 5 seconds. The time to stop the bleeding is 15 seconds. During these 15 seconds, the business system still calls the faulty resource, resulting in business damage.

[0053] Another fault handling solution is to perform failover through the Dubbo registry. The Dubbo registry confirms the liveness of service providers through a heartbeat mechanism, which defaults to a heartbeat every 60 seconds. If no heartbeat is received from a service provider for 180 consecutive seconds, the service provider is confirmed to be in a faulty state, and the registry will remove the service provider.

[0054] However, this solution has a problem: if the service provider fails during the heartbeat interval, the registry center cannot remove it in a timely manner, and it may take up to 180 seconds to remove it, which obviously does not meet the needs of some business systems with high business continuity requirements. Reducing the heartbeat interval would put even greater pressure on the registry center and data center network.

[0055] As a further improvement, one fault handling method is to maintain a list of faulty resources in memory. When a business calls a resource, the perceived fault information is stored in the list of faulty resources. Each business queryes the list of faulty resources in real time, thereby reducing the fault confirmation time to the resource call timeout time and the removal time to 0. Therefore, the cessation time can be expressed in the following form:

[0056] Bleeding cessation time >= resource call timeout time

[0057] In some critical business systems, a large number of services remain impaired within the resource call timeout period (usually within 10 seconds), failing to meet business continuity requirements.

[0058] For example, in a distributed transaction system, each application server maintains a list of failed databases. When a transaction write fails on the local machine, the database corresponding to that transaction is added to the list of failed databases, ensuring that subsequent transactions will not write to databases in that list. Assuming the timeout for writing transaction data to the database is 3 seconds, in this scheme, the transaction timeout is triggered 3 seconds after a database failure, at which point the application can remove the failed database.

[0059] However, the problem with this solution is that when faced with high transaction concurrency, each database failure will still affect transactions within 3 seconds. If the timeout is further reduced, it may affect normal transactions. Therefore, this solution cannot further reduce the amount of damaged transactions.

[0060] Based on this, embodiments of this application provide a method for handling faults in business resources, executed by the business server, such as... Figure 1 The diagram shows a flowchart of a fault handling method for service resources according to an embodiment of this application. The method includes at least the following steps S110 to S140:

[0061] Step S110: Receive service request.

[0062] The fault handling method for business resources in this application embodiment can be executed by each business server in a business system deployed in a distributed cluster manner. When handling the fault of business resources, it is necessary to first receive a business request, which refers to a request to invoke business resources.

[0063] Step S120: Invoke the target business resource according to the business request and update the preset resource call table, wherein the preset resource call table is used to store resource call data corresponding to the business request being processed.

[0064] The types of business resources in this application embodiment can be various, such as databases, caches, message queues, or other applications. Therefore, after receiving a business request, it is necessary to determine the target business resource that the user wants to call based on the business request and update the preset resource call table at the same time.

[0065] The aforementioned preset resource call table can be a data table maintained in the business server. This data table can store some resource call data related to the business requests being processed, which can serve as the basis for subsequent prediction of the business resource status.

[0066] Step S130: Asynchronously probe the preset resource call table.

[0067] In this embodiment of the application, the detection of business resources needs to be implemented in an asynchronous manner, such as a daemon thread in a Java application. The asynchronous detection thread is executed independently of the aforementioned steps S110 and S120. Its main function is to check the resource call data in the preset resource call table, thereby determining the status of the business resources.

[0068] The asynchronous probe thread used in this application embodiment is equivalent to checking the resource call data in the preset resource call table in a bypass monitoring manner. It does not depend on the call result of business resources and can remove faulty resources while the business is still being processed. Therefore, it can promptly avoid the impact of faulty resources on subsequent business processing and improve business continuity.

[0069] Step S140: Determine the list of faulty resources based on the asynchronous detection results, and perform fault handling based on the list of faulty resources.

[0070] When asynchronously probing the preset resource call table, the asynchronous probing results of business resources can be obtained. Based on the asynchronous probing results, a list of faulty resources can be determined. The list of faulty resources will serve as the basis for subsequent routing, thereby enabling the handling of faulty resources.

[0071] It should be noted that steps S110 to S120 above can be regarded as threads that process business requests. Multiple parallel sub-threads can be set in this thread, that is, business requests are received through multiple sub-threads. Steps S130 to S140 can be executed by asynchronous probing threads. The asynchronous probing threads are a unified thread that can uniformly monitor the status of business resources through polling and other methods.

[0072] The fault handling method for business resources in this application embodiment can identify and remove faulty resources in advance while the business is still being processed by asynchronously probing a preset resource call table, without waiting for the current business to finish. This reduces the impact of faulty resources on subsequent business processing and improves business continuity.

[0073] It should be noted that since the embodiments of this application are based on the prediction of faulty resources based on the business requests that are in progress, the business requests that are currently calling faulty resources and are still in progress will not be affected in their continued processing. The prediction result is only used as the basis for subsequent routing of business requests.

[0074] In one embodiment of this application, the preset resource call table is stored in the memory of the business server, and the preset resource call table includes one or more resource call data, including business identifier, resource identifier and resource call start time.

[0075] The preset resource call table in this application embodiment is mainly stored and maintained in the memory of the business server. In this way, when reading the preset resource call table, it can be read directly from the local memory of the business server, saving the latency time of obtaining the preset resource call table, which can achieve instant acquisition and thus enable timely identification of faulty resources.

[0076] Furthermore, since the default resource call table is stored in the memory of the business server, resource call data can be obtained through pure memory read and write, with minimal impact on other threads and CPU resource usage of the business server.

[0077] The preset resource call table in this application embodiment can store resource call data as shown in Table 1 below:

[0078] Table 1

[0079] Business Request Number Business Identifier Resource Identifier Resource call start time 1 A1 B1 On [Date] at [Time] [Minute] [Second] [Millisecond] 2 A2 B2 ……

[0080] As shown in Table 1, the resource call data stored in the preset resource call table mainly includes basic data such as business identifier, resource identifier, and resource call start time. The business identifier can be represented by a business ID; each business request has its unique corresponding business ID. The resource identifier can be represented by a resource code; each specific resource has its unique corresponding resource code, such as database B1, database B2, etc. The resource call start time is the time when the business server receives the business request. Each time the business server receives a business request, it generates a record in the preset resource call table corresponding to that business request, containing the aforementioned resource call data.

[0081] In one embodiment of this application, determining the list of faulty resources based on asynchronous detection results includes: grouping resource call data in the preset resource call table according to the resource identifier; determining the resource call time of each resource group; determining faulty resources based on the resource call time of each resource group, and adding the resource identifier corresponding to the faulty resource to the list of faulty resources.

[0082] The resource call data stored in the aforementioned preset resource call table is related to the received business requests. Each time a business request is received, a record containing data such as business identifier, resource identifier, and resource call start time will be generated in the table. Therefore, when determining whether a resource has failed, the aforementioned resource call data stored in the preset resource call table can be used to make the determination.

[0083] Specifically, in this embodiment, the resource call data in the preset resource call table can be grouped according to the dimension of resource identifier to obtain multiple resource groups. Each resource group can include all business identifiers and resource call start time of the resource corresponding to the resource group.

[0084] Resource call time refers to the time consumed before a resource responds to a business request after being called. It is an indicator for assessing whether a resource may fail. The longer the resource call time, the slower the resource response and the more likely a failure is. Conversely, a shorter time indicates that the resource is operating normally. Therefore, in this embodiment, after completing resource grouping, the resource call time of each resource group can be further determined. This allows for the identification of potentially faulty resources based on the resource call time of each resource group, and the corresponding resource identifiers can be added to the faulty resource list.

[0085] In one embodiment of this application, the resource group includes a service identifier and a resource call start time corresponding to the service identifier. Determining the resource call time of each resource group includes: determining the difference between the resource call start time corresponding to the service identifier in the target resource group and the current system time, wherein the target resource group is any one of multiple resource groups; and determining the resource call time of the target resource group based on the difference between the resource call start time and the current system time.

[0086] As mentioned above, each resource group in this application embodiment can include all service identifiers and resource call start times for calling the resources corresponding to that resource group, which can be specifically represented as shown in Table 2 below:

[0087] Table 2

[0088]

[0089] Therefore, a resource group may be invoked by multiple business requests. As shown in Table 2, both the business request corresponding to business identifier A1 and the business request corresponding to business identifier A2 request resource B1. When determining the resource invocation time for this resource group, a resource invocation time will be obtained based on both the business request corresponding to business identifier A1 and the business request corresponding to business identifier A2. To calculate the resource invocation time for each business request, the current system time t2 can be subtracted from the resource invocation start time t1 corresponding to that business request to obtain the resource invocation time for that business request.

[0090] In one embodiment of this application, the target resource group has multiple resource call times. The step of determining the faulty resource based on the resource call times of each resource group and adding the faulty resource to the faulty resource list includes: determining whether the target resource group has more than N service identifiers with resource call times higher than M milliseconds based on the multiple resource call times of the target resource group, where N and M are both greater than 0; if so, determining the resource identifier corresponding to the target resource group as the resource identifier of the faulty resource and adding the resource identifier of the faulty resource to the faulty resource list; if not, determining the resource identifier corresponding to the target resource group as the resource identifier of the available resource.

[0091] As mentioned earlier, when multiple business requests call the same business resource, the resource call time under the resource group to which the business resource belongs will be multiple. Therefore, when determining whether the resource corresponding to each resource group is faulty, we can determine it based on the length of time of multiple resource calls under each resource group. If the number of business requests with longer resource call times under a resource group is larger, it is more likely that the resource corresponding to that resource group is faulty.

[0092] For example, if a resource group has more than N business requests with a resource call time exceeding M milliseconds, it indicates that most business requests are experiencing long wait times when calling the resources corresponding to that resource group. This suggests that the resources corresponding to that resource group may be faulty. Therefore, the resource identifier of that resource can be added to the list of faulty resources to remove the faulty resource in a timely manner.

[0093] The values ​​of N and M can be set according to the specific business scenario. The smaller the values ​​of N and M, the more sensitive the judgment algorithm is, making it more prone to false alarms, but resulting in fewer affected services; conversely, the larger the values, the less sensitive the algorithm is, making it less prone to false alarms, but resulting in more affected services. In practical application scenarios, when a real fault occurs, the values ​​of N and M will rise sharply in a short period of time. However, if it is just ordinary network or resource jitter, it will only cause a few services to experience increased latency. Therefore, the accuracy of fault judgment can be improved by continuously adjusting the values ​​of N and M, such as by using historical data backtesting. This reduces false alarms, accurately identifies real faults, and reduces the amount of affected services.

[0094] Of course, in addition to the two parameters N and M mentioned above, those skilled in the art can also introduce more other parameters according to actual business needs, thereby further improving the accuracy of fault diagnosis.

[0095] To facilitate understanding of the embodiments of this application, pseudocode of the fault resource determination algorithm of this application is provided below. Of course, the specific implementation of the algorithm is not limited to this:

[0096] / / Group and count the number of business transactions with a current latency of more than M milliseconds

[0097] var counter=new Counter();

[0098] for(data in datas){

[0099] if (now-data.beginTime>M){

[0100] counter.incr(data.resourceIndex);

[0101] }

[0102] }

[0103] / / Add resources with a statistical value exceeding N to the list of faulty resources.

[0104] var kickList = [];

[0105] for(key in counter){

[0106] if (counter.get(key) > N) {

[0107] kickList.add(key);

[0108] }

[0109] / / Return to list of faulty resources

[0110] return kickList

[0111] The determination of faulty resources in this application embodiment is essentially a predictive process. That is, the fault judgment is completed during the processing of the current business request, rather than waiting until the business request is completed and the processing result is obtained before judging the fault. Therefore, this application embodiment can further shorten the fault handling time, that is, reduce it to below the resource call timeout time, thereby further reducing the impact on business continuity.

[0112] In one embodiment of this application, after invoking the target business resource according to the business request and updating the preset resource call table, the method further includes: deleting the resource call data corresponding to the business request stored in the preset resource call table when the processing of the business request is completed according to the target business resource.

[0113] As mentioned above, the embodiments of this application complete the prediction of faulty resources during the processing of business requests. Therefore, the fault determination algorithm in the above embodiments is also aimed at the situation where the business request is still being processed, i.e., the call is not completed. If the business processing has been completed, then the result of whether the business request was successfully called, failed to call, or timed out can be obtained. At this time, there is no need to predict the fault.

[0114] Based on this, if the result of a business request to call a business resource has been received, whether the call was successful or failed, the resource call data corresponding to that business request can be deleted from the preset resource call table. That is, the preset resource call table always retains the resource call data that is currently being processed, thereby improving the accuracy of fault prediction.

[0115] In one embodiment of this application, the step of invoking the target service resource according to the service request and updating the preset resource invocation table includes: determining the target service resource and invoking it according to the service request and the preset routing policy; obtaining the resource identifier of the target service resource; and updating the preset resource invocation table according to the resource identifier of the target service resource.

[0116] In this embodiment of the application, when calling a target business resource according to a business request, a preset routing strategy can be used to determine the routing strategy. The routing strategy refers to the fact that the business server usually maintains a list of available resources. Based on the business requirements, a resource is selected from the list of available resources according to a certain strategy such as load balancing, and is used as the target business resource to be called.

[0117] After identifying the target business resource, the resource identifier, such as the resource number, is obtained. Then, the resource number, business identifier, and resource call time are stored in a preset resource call table.

[0118] In one embodiment of this application, determining the target service resource based on the service request and the preset routing policy includes: obtaining a list of faulty resources; and determining the target service resource based on the list of faulty resources and the preset routing policy.

[0119] The above embodiments can be used to obtain a list of faulty resources, which records the resource numbers that may fail. Therefore, when determining the target service resource according to the preset routing policy, the faulty resource list can be used for determination. That is, the faulty resources in the faulty resource list are removed during routing, thereby avoiding service damage and improving service continuity.

[0120] In one embodiment of this application, the asynchronous probing of the preset resource call table includes: asynchronously probing the preset resource call table at preset time intervals.

[0121] In this embodiment of the application, asynchronous probing of a preset resource call table can be performed at preset time intervals. These preset time intervals can be set to extremely small intervals, such as 20ms, to promptly detect resources with potential faults. Since the preset resource call table is stored in the memory of the business server, each probe only needs to read the resource call data from the table through pure memory read / write. Therefore, even with an extremely small probe frequency, it will not consume excessive CPU resources. Furthermore, this process is independent of the execution of the business request processing thread. Therefore, even in scenarios with high concurrent business volume, it will not affect business processing; that is, the execution of the asynchronous probe thread and CPU consumption are unrelated to the size of the business volume.

[0122] For ease of understanding of the various embodiments of this application, such as Figure 2 The diagram illustrates a fault handling process for a business resource in an embodiment of this application. First, the business server receives business requests in real time. Then, based on a preset routing strategy, it determines the downstream resource to be invoked, i.e., identifies the target business resource and invokes it. Simultaneously, it stores the resource identifier of the target business resource, along with the business identifier, resource invocation start time, and other data, in a preset resource invocation table.

[0123] The business server then periodically retrieves the aforementioned preset resource call table through asynchronous probing. It then processes the resource call data in the preset resource call table using a preset fault determination algorithm to identify faulty resources and add them to the faulty resource list. This process removes faulty resources so that subsequent preset routing strategies can exclude resources from the faulty resource list when determining available resources, thereby reducing the impact of resource failures on business continuity.

[0124] This application embodiment also provides a fault handling device 300 for business resources, applied to a business server, such as... Figure 3 The diagram shows a structural schematic of a fault handling device for service resources according to an embodiment of this application. The device 300 includes: a receiving unit 310, an updating unit 320, a detection unit 330, and a first determining unit 340, wherein:

[0125] The receiving unit 310 is used to receive service requests;

[0126] The update unit 320 is used to call the target business resource according to the business request and update the preset resource call table, wherein the preset resource call table is used to store resource call data corresponding to the business request being processed;

[0127] The detection unit 330 is used to asynchronously detect the preset resource call table;

[0128] The first determining unit 340 is used to determine a list of faulty resources based on the asynchronous detection results, so as to perform fault handling based on the list of faulty resources.

[0129] In one embodiment of this application, the preset resource call table is stored in the memory of the business server, and the preset resource call table includes one or more resource call data, including business identifier, resource identifier and resource call start time.

[0130] In one embodiment of this application, the first determining unit 340 is specifically used to: group the resource call data in the preset resource call table according to the resource identifier; determine the resource call time of each resource group; determine the faulty resource according to the resource call time of each resource group, and add the resource identifier corresponding to the faulty resource to the faulty resource list.

[0131] In one embodiment of this application, the resource group includes a service identifier and a resource call start time corresponding to the service identifier. The first determining unit 340 is specifically used to: determine the difference between the resource call start time corresponding to the service identifier in the target resource group and the current system time, wherein the target resource group is any one of a plurality of resource groups; and determine the resource call time of the target resource group based on the difference between the resource call start time and the current system time.

[0132] In one embodiment of this application, the target resource group has multiple resource call times. The first determining unit 340 is specifically configured to: determine whether the target resource group has more than N service identifiers with resource call times higher than M milliseconds based on the multiple resource call times of the target resource group, where N and M are both greater than 0; if so, determine that the resource identifier corresponding to the target resource group is the resource identifier of a faulty resource, and add the resource identifier of the faulty resource to the faulty resource list; if not, determine that the resource identifier corresponding to the target resource group is the resource identifier of an available resource.

[0133] In one embodiment of this application, the apparatus further includes: a second determining unit, configured to delete the resource call data corresponding to the service request stored in the preset resource call table when the processing of the service request is completed according to the target service resource.

[0134] In one embodiment of this application, the update unit 320 is specifically used to: determine and invoke the target service resource according to the service request and the preset routing policy; obtain the resource identifier of the target service resource; and update the preset resource invocation table according to the resource identifier of the target service resource.

[0135] In one embodiment of this application, the update unit 320 is specifically used to: obtain a list of faulty resources; and determine the target service resource based on the list of faulty resources and the preset routing policy.

[0136] In one embodiment of this application, the detection unit 330 is specifically used to: asynchronously detect the preset resource call table according to a preset time interval.

[0137] It is understood that the above-mentioned fault handling device for business resources can implement each step of the fault handling method for business resources executed by the business server provided in the foregoing embodiments. The relevant explanations of the fault handling method for business resources are applicable to the fault handling device for business resources, and will not be repeated here.

[0138] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Please refer to it. Figure 4At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0139] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0140] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0141] The processor reads the corresponding computer program from non-volatile memory into main memory and then executes it, forming a fault handling device for business resources at the logical level. The processor executes the program stored in memory and specifically performs the following operations:

[0142] Receive service requests;

[0143] The target business resource is invoked according to the business request and the preset resource invocation table is updated, wherein the preset resource invocation table is used to store resource invocation data corresponding to the business request being processed.

[0144] Asynchronous probing is performed on the preset resource call table;

[0145] A list of faulty resources is determined based on the asynchronous detection results, and fault handling is performed based on the list of faulty resources.

[0146] The above is as stated in this application. Figure 1The method executed by the fault handling device for business resources disclosed in the illustrated embodiments can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0147] The electronic device can also perform Figure 1 The method for executing the fault handling device for business resources, and the implementation of the fault handling device for business resources in... Figure 1 The functions of the embodiments shown are not described in detail here.

[0148] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform... Figure 1 The method executed by the fault handling device for service resources in the illustrated embodiment is specifically used to perform:

[0149] Receive service requests;

[0150] The target business resource is invoked according to the business request and the preset resource invocation table is updated, wherein the preset resource invocation table is used to store resource invocation data corresponding to the business request being processed.

[0151] Asynchronous probing is performed on the preset resource call table;

[0152] A list of faulty resources is determined based on the asynchronous detection results, and fault handling is performed based on the list of faulty resources.

[0153] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0154] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0155] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0156] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0157] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0158] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0159] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change 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), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0160] 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 a process, method, article, or apparatus. Without further limitation, 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 said element.

[0161] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0162] The above description is merely an embodiment of this application and is 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 method for handling faults in business resources, executed by a business server, wherein, The method includes: Receive service requests; The target business resource is invoked according to the business request and the preset resource invocation table is updated, wherein the preset resource invocation table is used to store resource invocation data corresponding to the business request being processed. Asynchronous probing is performed on the preset resource call table; A list of faulty resources is determined based on the asynchronous detection results, and fault handling is performed based on the list of faulty resources. The preset resource call table includes a service identifier, a resource identifier, and a resource call start time; The process of determining the list of faulty resources based on asynchronous detection results includes: Based on the resource identifier, the resource call data in the preset resource call table is grouped; Determine the resource call time for each resource group; The faulty resources are determined based on the resource call time of each resource group, and the resource identifier corresponding to the faulty resource is added to the faulty resource list. The resource group includes a service identifier and a resource call start time corresponding to the service identifier. Determining the resource call time for each resource group includes: Determine the difference between the resource call start time corresponding to the service identifier in the target resource group and the current system time, wherein the target resource group is any one of multiple resource groups; The resource call time of the target resource group is determined based on the difference between the resource call start time and the current system time.

2. The method as described in claim 1, wherein, The preset resource call table is stored in the memory of the business server.

3. The method as described in claim 1, wherein, The resource call time for the target resource group is multiple. The step of determining the faulty resource based on the resource call time of each resource group and adding the faulty resource to the faulty resource list includes: Based on the resource call duration of the target resource group, determine whether the target resource group has more than N service identifiers with resource call durations higher than M milliseconds, where N and M are both greater than 0; If so, the resource identifier corresponding to the target resource group is determined to be the resource identifier of the faulty resource, and the resource identifier of the faulty resource is added to the faulty resource list; If not, then the resource identifier corresponding to the target resource group is determined to be the resource identifier of the available resource.

4. The method as described in claim 1, wherein, After invoking the target business resource according to the business request and updating the preset resource invocation table, the method further includes: If the business request is processed according to the target business resource, the resource call data corresponding to the business request stored in the preset resource call table is deleted.

5. The method as described in claim 1, wherein, The step of invoking the target business resource according to the business request and updating the preset resource invocation table includes: The target service resource is determined and invoked based on the service request and the preset routing strategy; Obtain the resource identifier of the target business resource; The preset resource call table is updated based on the resource identifier of the target business resource.

6. The method as described in claim 5, wherein, The step of determining the target service resource based on the service request and the preset routing policy includes: Get the list of faulty resources; The target service resource is determined based on the list of faulty resources and the preset routing policy.

7. The method according to any one of claims 1 to 6, wherein, The asynchronous detection of the preset resource call table includes: The preset resource call table is asynchronously probed at preset time intervals.

8. A fault handling device for business resources, applied to a business server, wherein, The apparatus is used to implement the method according to any one of claims 1 to 7.

Images