Network line calling disaster recovery method and device under multi-service scene

Abstract

The invention provides a network line calling disaster recovery method and device in a multi-service scene, and solves the problem that in the prior art, when a service line breaks down, the user experience effect is poor due to the fact that automatic switching of the service line cannot be achieved. According to the method, the configuration information is acquired according to the service type, then the optimal line for completing the service is generated, meanwhile, when the line breaks down or the success rate of the http request in the line is lower than the preset value, the line is re-planned to generate the new line, and the current line is switched into the new line, so that automatic switching of the service line is realized, and the service efficiency is improved. And the user experience is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of third-party payment, and particularly to a network line call disaster recovery method and device in a multi-service scenario. Background Art

[0002] Currently, mainstream payment institutions on the market have provided primary and backup domain names / primary and backup dedicated lines. Most companies only use the primary domain name / dedicated line and do not enable the backup domain name / dedicated line. When a failure occurs, they manually switch or passively wait for the payment service provider to resume service. If the primary domain name fails, the payment service will be unavailable and manual switching is required, which affects the user's payment experience and makes it impossible to make payments. Summary of the Invention

[0003] The present invention provides a network line call disaster recovery method and device in a multi-service scenario to solve the problem in the prior art that when a service line fails, automatic switching of the service line cannot be achieved, resulting in a poor user experience.

[0004] In a first aspect, the present invention provides a network line call disaster recovery method in a multi-service scenario, which specifically includes the following steps:

[0005] Step S1: Obtain the service type of the current service and construct an httpclient toolkit on the client;

[0006] Step S2: Generate an optimal line for sending an http request according to the interceptor built in the httpclient toolkit and the service type of the current service;

[0007] Step S3: Send an http request according to the line address of the optimal line;

[0008] Step S4: Monitor the http request data through the interceptor to form monitoring data, and transmit the monitoring data to the server and / or database;

[0009] Step S5: Obtain the success rate of the http request in the line according to the monitoring data, and judge whether the line fails;

[0010] Step S6: When the line fails and / or the success rate of the http request in the line is lower than the first threshold, issue an alarm and regenerate an optimal line for sending an http request, switch the current line to the regenerated optimal line, and complete the subsequent service through the regenerated optimal line.

[0011] Preferably, in step S1, the service type is customized according to the actual usage scenario of the user.

[0012] Preferably, in step S2, an optimal route for sending an HTTP request is generated according to the interceptors built in the httpclient toolkit and the service type of the current service, which specifically includes the following steps:

[0013] Step S201: Obtain configuration information according to the service type of the current service;

[0014] Step S202: Screen and generate an optimal route according to the configuration information.

[0015] Preferably, in step S201, the configuration information includes information such as request address, weight, line status, whether it is the main line, and whether it is a cross-city line.

[0016] Preferably, in step S202, the screening specifically includes the following steps:

[0017] Step S202a: Select all the lines that match the current service according to the service type of the current service (in this application, the "line that matches the current service" means that for service M, if it can complete the processing of the service through line L1, then line L1 matches service M);

[0018] Step S202b: Screen out the lines with available line status according to the line status of all the lines that match the current service;

[0019] Step S202c: Judge whether the line is in the same city. If the line is in the same city, select the line in the same city. Otherwise, execute the subsequent steps;

[0020] Step S202d: When at least two selected lines are included, select the optimal line according to the weight.

[0021] Preferably, when all the lines fail, select a line from all the failed lines according to the weight as the optimal line.

[0022] Preferably, when a major failure occurs, there is no need to screen the optimal line, and directly force the selection of the forced line (in this application, the "forced line" means not to select other lines to complete the current service, but directly force the selection of the forced line to complete the current service).

[0023] More preferably, when the forced line is not enabled, generate an optimal line through step S2 again.

[0024] Preferably, in step S4, the server includes Prometheus, and the database includes Redis.

[0025] Preferably, in step S4, before the monitoring data is transmitted to the server and / or database, the monitoring data can also be locally stored and reported regularly.

[0026] More preferably, the reporting methods include pushing (pushing means that the data source actively sends data to the receiver) and pulling (pulling means that the receiver actively obtains data from the data source); actively pulling the locally stored monitoring data to the server through prometheus and actively pushing the locally stored monitoring data to redis.

[0027] Preferably, in step S4, the monitoring data includes data such as business type, number of http requests, whether each http request is successful, and type of exception.

[0028] Preferably, in step S5, the success rate of the http requests in the line is calculated based on the number of http requests and whether each http request is successful.

[0029] Preferably, in step S6, the first threshold changes with the specific business.

[0030] Preferably, in step S6, the ways of sending alarms include a series of ways such as email notification, phone notification, SMS notification, enterprise WeChat notification, etc., which enable users to learn that there is a problem with the http request line.

[0031] In a second aspect, the present invention also provides a disaster recovery device for network line calls in a multi-service scenario, specifically including the following modules:

[0032] An initialization module, configured to obtain the business type of the current business and construct an httpclient toolkit on the client;

[0033] An optimal line generation module, configured to generate an optimal line for sending http requests according to the interceptor built in the httpclient toolkit and the business type of the current business;

[0034] A request sending module, configured to send an http request according to the line address of the optimal line;

[0035] A request data monitoring and transmission module, configured to monitor the http request data through the interceptor, form monitoring data, and transmit the monitoring data to the server and / or database;

[0036] A line monitoring module, configured to obtain the success rate of the http requests in the line according to the monitoring data and judge whether the line fails;

[0037] A line processing module, which is used to issue an alarm and regenerate an optimal line for sending http requests when a line fails and / or the success rate of http requests in the line is lower than a first threshold, switch the current line to the regenerated optimal line, and use the regenerated optimal line until subsequent services are completed.

[0038] Preferably, in the initialization module, the service type is customized according to the actual usage scenario of the user.

[0039] Preferably, the optimal line generation module specifically includes the following sub-modules:

[0040] The first sub-module for generating the optimal line is used to obtain configuration information according to the service type of the current service;

[0041] The second sub-module for generating the optimal line is used to screen and generate an optimal line according to the configuration information.

[0042] Preferably, in the first sub-module for generating the optimal line, the configuration information includes information such as request address, weight, line status, whether it is a main line, and whether it is a cross-city line.

[0043] Preferably, the second sub-module for generating the optimal line specifically includes the following units:

[0044] The first unit is used to select all lines that match the current service according to the service type of the current service;

[0045] The second unit is used to screen out lines with available line status according to the line status of all lines that match the current service;

[0046] The third unit is used to judge whether the lines are in the same city. If the lines are in the same city, select the lines in the same city. Otherwise, execute the fourth unit;

[0047] The fourth unit is used to select the optimal line according to the weight when the selected lines include at least two.

[0048] Preferably, when all lines fail, select a line from all failed lines according to the weight as the optimal line.

[0049] Preferably, when a major failure occurs, there is no need to screen the optimal line, and directly force the use of the forced line.

[0050] More preferably, when the forced line is not enabled, generate an optimal line by screening through the optimal line generation module.

[0051] Preferably, in the request data monitoring and transmission module, the server includes Prometheus, and the database includes Redis.

[0052] Preferably, in the request data monitoring and transmission module, before the monitoring data is transmitted to the server and / or the database, the monitoring data can also be locally stored and reported regularly.

[0053] More preferably, the reporting methods include pushing and pulling; Prometheus actively pulls the locally stored monitoring data to the server, and actively pushes the locally stored monitoring data to Redis.

[0054] Preferably, in the request data monitoring and transmission module, the monitoring data includes data such as business type, number of HTTP requests, whether each HTTP request is successful, and exception type.

[0055] Preferably, in the line monitoring module, the success rate of the HTTP requests in the line is calculated based on the number of HTTP requests and whether each HTTP request is successful.

[0056] Preferably, in the line processing module, the first threshold changes with the specific business.

[0057] Preferably, in the line processing module, the ways of sending alarms include a series of ways such as email notification, phone notification, SMS notification, enterprise WeChat notification, etc., so that users can learn that there is a problem with the HTTP request line.

[0058] In a third aspect, the present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements a network line call disaster recovery method in any one of the first aspects of the present application.

[0059] In a fourth aspect, the present invention also provides an electronic device, the electronic device includes: a memory storing a computer program: a processor communicatively connected to the memory, and when the computer program is called, it executes a network line call disaster recovery method in any one of the first aspects of the present application.

[0060] Compared with the prior art, the present invention has the following obvious prominent substantive features and remarkable advantages:

[0061] The present invention provides a network line call disaster recovery method and device in a multi-service scenario, which solves the problem in the prior art that when a service line fails, the automatic switching of the service line cannot be realized, resulting in a poor user experience. By obtaining configuration information according to the service type, and then generating an optimal line for completing the service. At the same time, when a line fails or the success rate of an HTTP request in the line is lower than a preset value, the line is re-planned to generate a new line, and the current line is switched to the new line, realizing the automatic switching of the service line and improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] The accompanying drawings constituting a part of the present invention are used to provide a further understanding of the present invention. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0063] Figure 1 is a flowchart of a network line call disaster recovery method in a multi-service scenario according to a preferred embodiment of the present invention.

[0064] Figure 2 is a schematic structural diagram of a network line call disaster recovery device in a multi-service scenario according to a preferred embodiment of the present invention.

[0065] Figure 3 is a schematic structural diagram of an optimal line generation module of a network line call disaster recovery device in a multi-service scenario according to a preferred embodiment of the present invention.

[0066] Figure 4 is a schematic structural diagram of a second sub-module of the optimal line generation of a network line call disaster recovery device in a multi-service scenario according to a preferred embodiment of the present invention.

[0067] LEGEND DESCRIPTION:

[0068] 100. Initialization module; 200. Optimal line generation module; 300. Request sending module; 400. Request data monitoring and transmission module; 500. Line monitoring module; 600. Line processing module.

[0069] 110. First sub-module of optimal line generation; 120. Second sub-module of optimal line generation.

[0070] 121. First unit; 122. Second unit; 123. Third unit; 124. Fourth unit. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0071] The present invention provides a network line call disaster recovery method and device in a multi-service scenario. To make the objectives, technical solutions, and effects of the present invention clearer and more definite, the following further elaborates on the present invention with reference to the accompanying drawings and by way of examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0072] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and do not necessarily need to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or devices.

[0073] Example 1:

[0074] As Figure 1 shown, a network line call disaster recovery method in a multi-service scenario described in this embodiment specifically includes the following steps:

[0075] Step S1: Obtain the service type of the current service and construct an httpclient toolkit at the client; the service type is customized according to the actual usage scenario of the user. For example, in the scenario of using the UnionPay dedicated line for third-party payment, the service type can be divided into multiple payment service types such as Alipay, WeChat, UnionPay full-channel, and UnionPay main scan, and each service type corresponds to a service line.

[0076] Step S2: Generate an optimal line for sending an http request according to the interceptor built in the httpclient toolkit and the service type of the current service.

[0077] Optionally, step S2 specifically includes the following steps S201 and S202.

[0078] Step S201: Obtain configuration information according to the service type of the current service.

[0079] In the specific implementation of this embodiment, the configuration information can be selected to include information such as request address, weight, line status, whether it is the main line, and whether it is a cross-city line.

[0080] Step S202: Screen and generate an optimal line according to the configuration information.

[0081] Optionally, step S202 specifically includes steps S202a - S202d.

[0082] Step S202a: Select all the lines that match the current service according to the service type of the current service.

[0083] Step S202b: Filter out the lines with available line status according to the line status of all the lines that match the current service.

[0084] Step S202c: Determine whether the line is a same - city line. If the line is a same - city line, then select the same - city line. Otherwise, execute the subsequent steps.

[0085] Step S202d: When the selected lines include at least two, select the optimal line according to the weight.

[0086] Table 1 Partial configuration information of Line A - Line G

[0087] Line Line Status Is it an Intra-city Line Weight A Running No 1 B Idle No 0.8 C Idle Yes 0.7 D Idle Yes 0.3 E Idle No 0.2 F Fault No 1.2 G Idle No 0.9

[0088] To further explain the specific implementation of the above steps, take WeChat Pay as an example. For the service type with the current service type being WeChat Pay, select all the lines that match WeChat Pay to complete the first - round screening of the lines. For example, it includes Line A, Line B, Line C, Line D, Line E, Line F, and Line G (the partial configuration information of Line A - Line G is shown in Table 1). However, not all of them match WeChat Pay. At this time, select the lines among the above lines that can implement the WeChat Pay service. For example, the WeChat Pay service can be implemented through Line A, Line B, Line C, Line D, Line F, and Line G. Then, among Line A, Line B, Line C, Line D, Line F, and Line G, the status of Line A is the running state (which can also be called the unavailable state, indicating that the line is unavailable), the status of Line B is the idle state (which can also be called the available state, indicating that the line is available), the status of Line C is the idle state, the status of Line D is the idle state, the status of Line E is the idle state, the status of Line F is the fault state, and the status of Line G is the idle state. Then, filter out the lines with available status among the above - mentioned matching lines, including Line B, Line C, Line D, and Line G, to complete the second - round screening of the lines. Next, if there are no same - city lines after the second - round screening, skip the step of screening the same - city lines. If there are same - city lines, then retain the same - city lines to complete the third - round screening of the lines. Line C and Line D are same - city lines. Finally, because the remaining lines are two, among them, the weight of Line C is 0.7 and the weight of Line D is 0.3. After screening, Line C is obtained as the optimal line to complete the subsequent WeChat Pay service (assuming that the larger the weight, the better the line).

[0089] Optionally, step S202d may also be: when the selected lines include at least two lines, the weight of the line may also represent the probability that the line is selected as the optimal line. As described above, the weight of line C is 0.7, which means that the probability that line C is selected as the optimal line is 70%, and the weight of line D is 0.3, which means that the probability that line D is selected as the optimal line is 30%. This makes it so that line C is not selected every time, retaining the possibility that line D is selected, thereby alleviating the operating pressure on line C.

[0090] When all lines fail, select a line from all the failed lines according to the weight as the optimal line.

[0091] In case of a major failure, there is no need to screen for the optimal line, and the forced line is directly used. In addition, if the forced line is not enabled, a new optimal line is regenerated in the manner described in step S2.

[0092] Step S3: Send an http request according to the line address of the optimal line.

[0093] Step S4: Monitor the http request data through the interceptor to form monitoring data, and transmit the monitoring data to the server and / or database.

[0094] In the specific implementation of this embodiment, the server selects Prometheus (Prometheus is a monitoring and alerting system based on a time series database), and the database includes Redis (Remote Dictionary Server), which is a high-performance in-memory key-value database (In-Memory Key-Value Store), supports multiple data structures, and is widely used in scenarios such as caching, message queues, and real-time data analysis. Its design focuses on minimalism and high performance, and can achieve hundreds of thousands of read and write operations per second.

[0095] Optionally, before the monitoring data is transmitted to the server and / or database, the monitoring data can also be locally stored and reported regularly; the reporting methods include pushing and pulling; Prometheus actively pulls the locally stored monitoring data to the server, and actively pushes the locally stored monitoring data to Redis; if the locally stored monitoring data is reported to the Prometheus server, it is reported once every 15 seconds; if the locally stored monitoring data is reported to Redis, it is reported once every second; among them, the reported monitoring data includes data such as business type, number of http requests, whether each http request is successful, and exception type.

[0096] For the reported monitoring data, the storage methods in the Prometheus server and Redis are different. The Prometheus server directly saves the reported monitoring data, and during the subsequent process of calling the monitoring data, it can be directly queried using PromQL (a statement for the data stored in the Prometheus server). For Redis, Redis uses the timestamp of the current time as the score (for example, at 13:54:20 on March 21, 2025, the score is 20250321135420), and sorts the scores in the form of a zset collection (ordered set) to complete the storage of the monitoring data. Each piece of monitoring data has a unique key (the unique identifier of the data. In this embodiment, the format of the key is business type + line address + whether the line request is successful). Redis updates the monitoring data specifically as follows: Before storing new monitoring data, delete the expired data, report the new monitoring data to the zset collection, and re-sort the data in the zset collection according to the score.

[0097] Step S5: Obtain the success rate of the http requests in the line based on the monitoring data, and determine whether the line has a fault; among them, the success rate of the http requests in the line is calculated based on the number of http requests and whether each http request is successful, and is specifically expressed as: the success rate of the http requests in the line in China is equal to the number of successful http requests divided by the number of http requests.

[0098] Step S6: When the line has a fault and / or the success rate of the http requests in the line is lower than the first threshold (where the first threshold changes with the specific business), issue an alarm and regenerate an optimal line for sending http requests, switch the current line to the regenerated optimal line, and continue with the subsequent business through the regenerated optimal line until completion.

[0099] Among them, the ways to issue alarms include a series of ways such as email notification, phone notification, SMS notification, enterprise WeChat notification, etc., which enable users to learn that there is a problem with the http request line. When zookeeper (zookeeper is an open-source distributed coordination service, mainly used for data management and coordination in distributed applications) is running normally, through the watch mechanism (the watch mechanism of zookeeper is a design based on the observer pattern, allowing clients to listen for changes in the state of nodes in zookeeper and receive notifications when the state changes), the status information of the line can be transmitted to the client in real time. After receiving the status information of the line, the client will update the configuration information cached locally; when zeekeeper fails, through the caffine cache mechanism, the status information of the current line will be transmitted to the client at fixed time intervals (such as 5 seconds) to update the locally cached configuration.

[0100] Example 2:

[0101] Such as Figure 2 - Figure 4 As shown, a network line call disaster recovery device in a multi-service scenario described in this embodiment specifically includes the following modules:

[0102] The initialization module 100 is used to obtain the service type of the current service and construct an httpclient toolkit on the client; among them, the service type is customized according to the actual usage scenario of the user.

[0103] The optimal line generation module 200 is used to generate an optimal line for sending http requests according to the interceptors built in the httpclient toolkit and the service type of the current service.

[0104] In this embodiment, the optimal line generation module 200 specifically includes an optimal line generation first sub-module 110 and an optimal line generation second sub-module 120.

[0105] The optimal line generation first sub-module 110 is used to obtain configuration information according to the service type of the current service; among them, the configuration information includes information such as request address, weight, line status, whether it is the main line, and whether it is a cross-city line.

[0106] The optimal line generation second sub-module 120 is used to screen and generate an optimal line according to the configuration information.

[0107] In this embodiment, the optimal line generation second sub-module 120 specifically includes a first unit 121, a second unit 122, a third unit 123, and a fourth unit 124.

[0108] The first unit 121 is used to select all the lines that match the current service according to the service type of the current service;

[0109] The second unit 122 is used to filter out the lines with available line status according to the line status of all the lines that match the current service;

[0110] The third unit 123 is used to judge whether the line is in the same city. If the line is in the same city, the line in the same city is selected. Otherwise, the fourth unit 124 is executed;

[0111] The fourth unit 124 is used to select the optimal line according to the weight when the selected lines include at least two.

[0112] Optionally, when all the lines fail, a line is selected from all the failed lines according to the weight as the optimal line.

[0113] Optionally, when a major fault occurs, there is no need to screen the optimal line, and the forced line is directly and forcibly selected.

[0114] Optionally, when the forced line is not enabled, another optimal line is screened and generated by the optimal line generation module 200.

[0115] The request sending module 300 is used to send an http request according to the line address of the optimal line.

[0116] The request data monitoring and transmission module 400 is used to monitor the http request data through the interceptor to form monitoring data, and transmit the monitoring data to the server and / or the database.

[0117] In this embodiment, the server selects Prometheus, and the database selects Redis.

[0118] Optionally, before the monitoring data is transmitted to the server and / or the database, the monitoring data can also be locally stored and reported regularly; wherein, the reporting methods include pushing and pulling; Prometheus actively pulls the locally stored monitoring data to the server, and actively pushes the locally stored monitoring data to Redis.

[0119] Among them, the monitoring data includes data such as service type, number of http requests, whether each http request is successful, and exception type.

[0120] A line monitoring module 500 is configured to obtain the success rate of HTTP requests in a line based on the monitoring data and determine whether a fault occurs in the line. The success rate of HTTP requests in the line is calculated based on the number of HTTP requests and whether each HTTP request is successful, and is specifically expressed as: the success rate of HTTP requests in the line is equal to the number of successful HTTP requests divided by the number of HTTP requests.

[0121] A line processing module 600 is configured to, when a fault occurs in the line and / or the success rate of HTTP requests in the line is lower than a first threshold, issue an alarm and regenerate an optimal line for sending HTTP requests, switch the current line to the regenerated optimal line, and continue with subsequent services through the regenerated optimal line.

[0122] In this embodiment, the first threshold changes with the specific service.

[0123] Among them, the ways of issuing alarms include a series of ways such as email notification, phone notification, SMS notification, and enterprise WeChat notification, which enable users to learn that there is a problem with the HTTP request line.

[0124] The specific embodiments of the present invention have been described in detail above, but they are only examples, and the present invention is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications and substitutions to the present invention are also within the scope of the present invention. Therefore, equivalent transformations and modifications made without departing from the spirit and scope of the present invention should be covered within the scope of the present invention.

Claims

1. A network line call disaster recovery method in a multi-service scenario, characterized in that, Specifically, it includes the following steps: Step S1: Obtain the business type of the current business and construct an httpclient toolkit on the client side; Step S2: Generate an optimal route for sending http requests according to the interceptors built in the httpclient toolkit and the business type of the current business; Step S3: Send an http request according to the route address of the optimal route; Step S4: Monitor the http request data through the interceptor to form monitoring data, and transmit the monitoring data to the server and / or database; Step S5: According to the monitoring data, obtain the success rate of the http requests in the route and judge whether the route fails; Step S6: When the route fails and / or the success rate of the http requests in the route is lower than the first threshold, issue an alarm and regenerate an optimal route for sending http requests, switch the current route to the regenerated optimal route, and complete the subsequent business through the regenerated optimal route.

2. The network line call disaster recovery method in a multi-service scenario according to claim 1, wherein When a major failure occurs, there is no need to screen for the optimal route, and the forced route is directly and forcibly selected; Among them, when the forced route is not enabled, an optimal route is generated through step S2 again.

3. A network line call disaster recovery method in a multi-service scenario according to claim 1, characterized in that, In step S2, according to the interceptors built in the httpclient toolkit and the business type of the current business, generating an optimal route for sending http requests specifically includes the following steps: Step S201: Obtain configuration information according to the business type of the current business; Step S202: Screen and generate an optimal route according to the configuration information.

4. The network line call disaster recovery method in a multi-service scenario according to claim 3, characterized in that, In step S201, the configuration information includes request address, weight, line status, whether it is the main line, and whether it is an inter-city line information.

5. The network line call disaster recovery method in a multi-service scenario according to claim 4, wherein, When all routes fail, select a route from all failed routes according to the weight as the optimal route.

6. The network line call disaster recovery method in a multi-service scenario according to claim 3, wherein, In step S202, the screening specifically includes the following steps: Step S202a: Select all routes that match the current business according to the business type of the current business; Step S202b: Screen out the routes with available line status according to the line status of all routes that match the current business; Step S202c: Judge whether the route is intra-city. If the route is an intra-city route, select the intra-city route; otherwise, execute the subsequent steps; Step S202d: When at least two selected routes are included, select the optimal route according to the weight.

7. A network line call disaster recovery method in a multi-service scenario according to claim 1, characterized in that, In step S4, the server includes prometheus, and the database includes redis; Before the monitoring data is transmitted to the server and / or database, the monitoring data is also locally stored and reported regularly; Among them, the reporting methods include pushing and pulling; prometheus actively pulls the locally stored monitoring data to the server, and actively pushes the locally stored monitoring data to redis.

8. A network line call disaster recovery method in a multi-service scenario according to claim 1, characterized in that In step S4, the monitoring data includes business type, number of http requests, whether each http request is successful, and exception type.

9. The network line call disaster recovery method in a multi-service scenario according to claim 1, wherein In step S6, the ways to issue warnings include email notifications via email, phone notifications, SMS notifications, and enterprise WeChat notifications, which enable users to learn that there is a problem with the http request line.

10. A network line call disaster recovery device in a multi-service scenario, characterized in that, Specifically, it includes the following modules: An initialization module, which is used to obtain the service type of the current service and construct an httpclient toolkit on the client side; An optimal route generation module, which is used to generate an optimal route for sending http requests according to the interceptors built into the httpclient toolkit and the service type of the current service; A request sending module, which is used to send an http request according to the route address of the optimal route; A request data monitoring and transmission module, which is used to monitor the http request data through the interceptor to form monitoring data, and transmit the monitoring data to the server and / or database; A route monitoring module, which is used to obtain the success rate of http requests in the route according to the monitoring data and judge whether the route fails; A route processing module, which is used to issue a warning and regenerate an optimal route for sending http requests when the route fails and / or the success rate of http requests in the route is lower than the first threshold, switch the current route to the regenerated optimal route, and complete the subsequent service through the regenerated optimal route.

Images