A method of invoking a third-party interface using self-healing functionality

Abstract

The present invention relates to the field of computer-aided artificial intelligence technology, and in particular to a method for calling a third-party interface using a self-healing function, comprising: S1, organizing data of an IP pool, and establishing two queues: a valid IP queue and an invalid IP queue. The present invention ensures that when the application layer calls the interface, an invalid IP is selected as far as possible, and that the invalid IP can be automatically restored to use after a certain period of time through an IP scheduling strategy mode of a dual IP queue, thereby maximally ensuring the availability of the interface service and the utilization rate of the IP. The business layer is decoupled from the interface calling layer, and the business layer does not need to pay attention to the selection of the IP. It only needs to notify the interface calling layer to call when there is a demand for calling the third-party interface, and receive the return value of the interface calling layer. The interface calling layer is responsible for the scheduling and allocation of the IP, and selects as few invalid IPs as possible, and then calls the interface through the selected IP, and provides the application layer with the return result.

Description

Technical Field

[0001] The present invention belongs to the field of computer-aided artificial technology, and particularly relates to a method for calling a third-party interface with a self-healing function. Background Art

[0002] During the operation of a business system, it is necessary to call the services of a third party. During the process of calling a third-party interface, it is often encountered that due to overly frequent calls, the service provider restricts the IP or account of the caller in terms of frequency, resulting in the interface being unable to provide services normally. Usually, it can only continue to use the interface after the service provider lifts the restriction after a certain period of time, which hinders the normal use of the business.

[0003] Generally, the call of a third-party interface is generally restricted by the service provider's limit on the IP interface call frequency to protect the maximum utilization of resources for more customers. For the caller, it means that the interface is unavailable, resulting in the business being unable to provide corresponding data normally. Although some solutions provide multiple IPs for calling, if there is no certain scheduling strategy, an invalid IP will still be selected for calling, and the business system still cannot obtain the required interface service, resulting in a high abnormal rate of interface calls and the interface service being basically unavailable.

[0004] Therefore, in view of the above technical problems, it is necessary to provide a method for calling a third-party interface with a self-healing function. Summary of the Invention

[0005] The purpose of the present invention is to provide a method for calling a third-party interface with a self-healing function to solve the problem that without a certain scheduling strategy, an invalid IP will be selected for calling when the application layer calls the interface, resulting in the interface service being basically unavailable.

[0006] To achieve the above purpose, the technical solution provided by an embodiment of the present invention is as follows:

[0007] A method for calling a third-party interface with a self-healing function includes the following steps:

[0008] S1. Organize the data in the IP pool and establish two queues: a valid IP queue and an invalid IP queue;

[0009] S2. Initialize the IP pool data and enter it into the valid IP queue;

[0010] S3. The business application layer initiates a call to the third-party interface;

[0011] S4. The scheduler determines whether the continuous pop-up times of the valid IP queue exceed the maximum pop-up times of the valid IP queue;

[0012] S5. If not exceeded, pop the IP from the valid IP queue, notify the calling interface thread for processing, and record that the number of pops from the valid IP queue is incremented by one;

[0013] S6. If exceeded, continue to determine whether the waiting time of the top IP node in the invalid IP queue exceeds the retry time. If not, continue to use the IP in the valid IP queue. If exceeded, pop the top IP of the invalid IP queue and clear the cumulative number of consecutive pops from the valid IP queue;

[0014] S7. The interface calls a third-party service, and notifies the scheduling logic based on whether data is returned as the result of the success or failure of the call;

[0015] S8. In addition to returning the call result to the business application layer, the scheduling logic also needs to process the current IP node according to the success or failure of the call result. If the result is successful, push the current IP onto the valid IP queue. If the result is failed, push the current IP onto the invalid IP queue;

[0016] S9. When the length of the valid IP queue (i.e., the number of available IPs) is lower than the threshold, a system notification is made;

[0017] S10. When the length of the valid IP queue reaches 0, it indicates that the third-party interface is basically unavailable, and only invalid IPs can be slowly recovered to available nodes or new IPs can be added for processing.

[0018] Further, both the valid IP queue and the invalid IP queue are FIFO queues. Consume the top IP node of the stack. After the call is completed, return the IP to the bottom of the stack. The IP pool of the scheduling policy is in a dual IP queue mode, which can ensure that when the application layer calls the interface, it can avoid selecting invalid IPs as much as possible, and can also ensure that invalid IPs can be automatically restored for use after a certain time, maximizing the availability of the interface service and the utilization rate of IPs. The advantage of returning the IP to the bottom of the queue is that the IPs are used in turn, and there will be no situation where a certain IP is called too frequently, which can effectively prevent the situation of being permanently restricted from accessing by the server, and it will not be used all the time when it fails, preventing the normal call of the business from being blocked.

[0019] Furthermore, when the system is initialized: it is assumed that all IPs are available and valid, and all IPs enter the valid IP queue for queueing, for the scheduling logic to perform IP scheduling selection. When the business application layer has the need to call a third-party interface, according to a certain scheduling algorithm, the IP scheduling logic in the valid IP queue is used first. It is responsible for popping an IP from the top of the stack of the valid IP queue and notifying the interface process of the corresponding IP to call the interface. The interface process calling the interface of the third-party service will produce two results: the third-party service has business data returned (no need to care about the content of the data in the specific application layer), indicating that the call is successful; the third-party service does not return, that is, the interface times out, indicating that the call failed.

[0020] Furthermore, after scheduling the available IP queues for a certain number of times, the scheduling logic pops up an IP from the top of the invalid IP queue stack and passes it to the interface process for interface call. If the interface process call result is still a failure, this IP will continue to be pushed to the bottom of the invalid IP queue stack. If the interface call is successful, this IP will be pushed to the bottom of the valid IP queue stack. At this point, the invalid IP heals itself to become a valid IP. In this way, the scheduling logic maximizes the availability of the IP through the dual-loop mechanism of the dual IP queues, and automatically repairs the validity of the IP by driving the invalid IP to make an interface call through the interface.

[0021] Furthermore, when the valid IP queue is below a certain threshold, the user is notified that the availability of the third-party service has deteriorated, and once the service provider limits the calling frequency, it will take a certain period of time before providing services to this IP again.

[0022] Furthermore, the scheduling algorithm of the IP queue popping the top IP of the stack is:

[0023]

[0024] Among them, f(x) is the queue (F b or F a ), the F a The effective IP queue, the F b Invalid IP queue.

[0025] Furthermore, x is the number of consecutive pop-ups of the valid IP queue, and is set to 0 when an invalid IP queue is selected. a The maximum number of consecutive IP ejections from the valid IP queue.

[0026] Furthermore, the W t is the waiting time of the top IP in the invalid IP queue stack (the time from entering the stack to the time when the scheduling logic is determined), the L t The server limits the IP duration, and V is the number of invalid IP retries required within the server's IP limitation duration.

[0027] Furthermore, the scheduling logic is: prioritize the valid IP queue F a Get IP, through N a After the number of times, F b The waiting time W of the top IP in the stack t Determine whether the required test time has been exceeded If it exceeds, select invalid IP queue F b Pop the IP, and the number of consecutive pops of the valid IP queue x is reset to 0.

[0028] Compared with the prior art, the present invention has the following advantages:

[0029] The present invention uses an IP scheduling strategy mode of a dual IP queue to ensure that when the application layer calls the interface, invalid IPs are avoided as much as possible, and invalid IPs can be automatically restored after a certain period of time, thereby maximally ensuring the availability of interface services and the utilization rate of IPs. The business layer is decoupled from the interface calling layer, and the business layer does not need to pay attention to the selection of IPs. It only needs to notify the interface calling layer to call when there is a need to call a third-party interface and receive the return value of the interface calling layer. The interface calling layer is responsible for the scheduling and allocation of IPs, selects as few invalid IPs as possible, and then calls the interface through the selected IP, and provides the result to the application layer for return. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0031] Figure 1 A flowchart of a method for using a self-healing function to call a third-party interface in an embodiment of the present invention;

[0032] Figure 2 The figure is a schematic diagram of an interface call in an embodiment of the present invention. DETAILED DESCRIPTION

[0033] The present invention will be described in detail below in conjunction with the various embodiments shown in the accompanying drawings. However, these embodiments do not limit the present invention, and any structural, methodological or functional changes made by a person skilled in the art based on these embodiments are all within the scope of protection of the present invention.

[0034] The present invention discloses a method for calling a third-party interface using a self-healing function, referring to Figure 1 - Figure 2 As shown, the following steps are included:

[0035] S1. Organize the data in the IP pool and establish two queues: a valid IP queue and an invalid IP queue;

[0036] S2. Initialize the IP pool data and enter it into the valid IP queue;

[0037] S3. The business application layer initiates a third-party interface call;

[0038] S4. The scheduler determines whether the consecutive pop count of the valid IP queue exceeds the maximum pop count of the valid IP queue;

[0039] S5. If not exceeded, pop an IP from the valid IP queue, notify the call interface thread to process it, and record that the pop count of the valid IP queue is incremented by one;

[0040] S6. If exceeded, continue to determine whether the waiting time of the top IP node in the invalid IP queue exceeds the retry time. If not, continue to use the IP in the valid IP queue. If exceeded, pop the top IP of the invalid IP queue and clear the cumulative consecutive pop count of the valid IP queue;

[0041] S7. The interface calls a third-party service and notifies the scheduling logic based on whether data is returned as the result of the call success or failure;

[0042] S8. In addition to returning the call result to the business application layer, the scheduling logic also needs to process the current IP node according to the success or failure of the call result. If the result is successful, push the current IP onto the valid IP queue. If the result is failed, push the current IP onto the invalid IP queue;

[0043] S9. When the length of the valid IP queue (i.e., the number of available IPs) is lower than the threshold, a system notification is made;

[0044] S10. When the length of the valid IP queue reaches 0, it indicates that the third-party interface is basically unavailable, and only by slowly recovering available nodes from invalid IPs or adding new IPs can it be processed;

[0045] Reference Figure 1 - Figure 2 As shown, both the valid IP queue and the invalid IP queue are FIFO queues. The top IP node of the stack is consumed, and after the call is completed, the IP is returned to the bottom of the stack. The IP pool of the scheduling policy is in a dual-IP queue mode, which ensures that when the application layer calls the interface, it tries to avoid selecting invalid IPs as much as possible, and at the same time ensures that invalid IPs can be automatically restored for use after a certain period of time, maximizing the availability of the interface service and the utilization rate of IPs. The advantage of returning the IP to the bottom of the queue is that the IPs are used in turn, and the situation where a certain IP is called too frequently will not occur, which can effectively prevent the situation of being permanently restricted from accessing by the server. When it fails, it will not be used all the time, preventing it from hindering the normal call of the business.

[0046] refer to Figure 1 - Figure 2 As shown, when the system is initialized: by default, all IPs are available and valid, and all IPs enter the valid IP queue for queuing, so that the scheduling logic can select IP scheduling. When the business application layer needs to call a third-party interface, according to a certain scheduling algorithm, the IP scheduling logic in the valid IP queue is used first. The scheduling logic is responsible for popping an IP from the top of the stack of the valid IP queue and notifying the interface process of the corresponding IP to call the interface. The interface process calling the interface of the third-party service will produce two results: the third-party service returns business data (no need to care about the content of the specific application layer data), indicating that the call is successful; the third-party service does not return, that is, the interface times out, indicating that the call failed.

[0047] refer to Figure 1 - Figure 2 As shown, after scheduling the available IP queues for a certain number of times, the scheduling logic pops up an IP from the top of the invalid IP queue stack and passes it to the interface process for interface call. If the interface process call result is still a failure, this IP will continue to be pushed to the bottom of the invalid IP queue stack. If the interface call is successful, this IP will be pushed to the bottom of the valid IP queue stack. At this point, the invalid IP self-heals to a valid IP. In this way, the scheduling logic maximizes the availability of the IP through the dual-loop mechanism of the dual IP queues. By driving the invalid IP through the interface to make an interface call, the validity of the IP can be automatically repaired.

[0048] refer to Figure 1 - Figure 2 As shown, when the valid IP queue is below a certain threshold: the user is notified that the availability of the third-party service has deteriorated. Once the service provider limits the call frequency, it will take a certain period of time before providing services for this IP again.

[0049] refer to Figure 1 - Figure 2 As shown, the scheduling algorithm for the IP queue to pop the top IP of the stack is:

[0050]

[0051] Among them, f(x) is the queue (F b or F a ), F a Effective IP queue, F b Invalid IP queue.

[0052] refer to Figure 1 - Figure 2 As shown in the figure, x is the number of consecutive pop-ups of the valid IP queue. When an invalid IP queue is selected, it is set to 0. N a The maximum number of consecutive IP ejections from the valid IP queue.

[0053] refer to Figure 1 - Figure 2 As shown, W t is the waiting time of the top IP in the invalid IP queue stack (the time from entering the stack to the scheduling logic judgment), Lt For the server to limit the IP duration, V is the number of times of invalid IP retries required within the server's IP duration limit.

[0054] Reference Figure 1 - Figure 2 As shown, the scheduling logic is as follows: First, obtain an IP from the valid IP queue F a After N a times, for the waiting duration W b of the top IP of the F t stack, determine whether it exceeds the duration to be tested If it exceeds, select the invalid IP queue F b to pop the IP, and reset the continuous pop count x of the valid IP queue to 0.

[0055] For those skilled in the art, it is obvious that the present invention is not limited to the details of the above exemplary embodiments, and without departing from the spirit or basic characteristics of the present invention, the present invention can be implemented in other specific forms. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-limiting. The scope of the present invention is defined by the appended claims rather than the above description. Therefore, all changes falling within the meaning and scope of the equivalent elements of the claims are intended to be included in the present invention. Any reference signs in the claims should not be construed as limiting the claims involved.

[0056] In addition, it should be understood that although this specification is described according to embodiments, not every embodiment only contains an independent technical solution. This narrative way of the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other implementation manners understandable by those skilled in the art.

Claims

1. A method for calling a third - party interface using a self - healing function, characterized in that, It includes the following steps: S1. Organize the data in the IP pool and establish two queues: a valid IP queue and an invalid IP queue; S2. Initialize the IP pool data and enter it into the valid IP queue; S3. The business application layer initiates a third-party interface call; S4. The scheduler determines whether the consecutive pop-up times of the valid IP queue exceed the maximum pop-up times of the valid IP queue; S5. If not exceeded, pop an IP from the valid IP queue, notify the call interface thread to process it, and record that the pop-up times of the valid IP queue increase by one; S6. If exceeded, continue to determine whether the waiting time of the top IP node in the invalid IP queue exceeds the retry time. If not, continue to use the IP in the valid IP queue. If exceeded, pop the top IP of the invalid IP queue and clear the cumulative consecutive pop-up times of the valid IP queue; S7. The interface calls the third-party service and notifies the scheduling logic based on whether data is returned as the result of the call success or failure; S8. In addition to returning the call result to the business application layer, the scheduling logic also needs to process the current IP node according to the success or failure of the call result. If the result is successful, push the current IP onto the stack of the valid IP queue. If the result is failed, push the current IP onto the stack of the invalid IP queue; S9. When the length of the valid IP queue (i.e., the number of available IPs) is lower than the threshold, a system notification is made; S10. When the length of the valid IP queue reaches 0, it indicates that the third-party interface is basically unavailable, and only the available nodes can be slowly restored from the invalid IPs or new IPs can be added for processing.

2. The method for calling a third - party interface using a self - healing function according to claim 1, characterized in that, Both the valid IP queue and the invalid IP queue are FIFO queues. The IP node at the top of the stack is consumed, and after the call is completed, the IP is returned to the bottom of the stack. The IP pool of the scheduling policy is in a dual IP queue mode.

3. The method for calling a third - party interface using a self - healing function according to claim 1, characterized in that, When the system is initialized: By default, all IPs are available and valid, and all IPs enter the valid IP queue to queue up for the scheduling logic to select IPs for scheduling.

4. The method for calling a third - party interface using a self - healing function according to claim 1, characterized in that, After the scheduling logic schedules the available IP queue a certain number of times: Pop an IP from the top of the invalid IP queue and pass it to the interface process for interface call. If the call result of the interface process is still failed, this IP will continue to be pushed onto the bottom of the invalid IP queue. If the interface call is successful, this IP is pushed onto the bottom of the valid IP queue.

5. The method for calling a third - party interface using a self - healing function according to claim 1, characterized in that, When the valid IP queue is lower than a certain threshold: Notify the user that the availability of the third-party service has deteriorated.

6. The method for calling a third - party interface using a self - healing function according to claim 1, characterized in that, Once the call frequency of the service provider is restricted, it will take a certain period of time to provide services for this IP again.

7. The method for calling a third - party interface using a self - healing function according to claim 1, characterized in that, The scheduling algorithm for popping the top IP of the IP queue: Among them, is the queue from which the scheduling logic needs to pop IPs ( or ), the is the valid IP queue, the is the invalid IP queue, x is the number of consecutive pops from the valid IP queue, which is set to 0 after the invalid IP queue is selected, N_a is the maximum number of consecutive IP pops from the valid IP queue, W_t is the waiting duration of the top IP in the invalid IP queue (the duration from when it is pushed onto the stack to when the scheduling logic makes a judgment), L_t is the server-side restricted IP duration, and V is the number of retries for the invalid IP within the server-side restricted IP duration.

8. The method for calling a third - party interface using a self - healing function according to claim 7, characterized in that, The scheduling logic is as follows: preferentially obtain an IP from the valid IP queue After going through times, for the waiting duration of the top IP in the stack judge whether it exceeds the duration to be tested , if it exceeds, then select the invalid IP queue pop the IP, and reset the continuous pop count x of the valid IP queue to 0.

Images