Multi-supplier service scheduling method and multi-supplier service scheduling system

Abstract

The invention provides a multi-supplier service scheduling method and a multi-supplier service scheduling system, and the method comprises the steps: enabling a scheduling strategy configuration module to determine at least one supplier service, the scheduling information of each supplier service, and the scheduling rule of the target local service after a local demand side calls the target local service through a local API, the health detection module determines the health state of each supplier service according to the historical service data, the dynamic routing module determines a target scheduling scheme and at least one target supplier service according to the health state, the scheduling information and the scheduling rule, and the dynamic routing module performs scheduling on the at least one target supplier service based on the target scheduling scheme. And sending the calling request to each target supplier service, so that each target supplier service receives the calling request and executes the corresponding service. According to the method, the health state of the supplier is monitored in real time, so that the target supplier service and the target scheduling scheme are adjusted, the target local service is ensured to be smooth, and the service continuity and high availability are ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of service scheduling, in particular to a multi-supplier service scheduling method and a multi-supplier service scheduling system. BACKGROUND

[0002] With the promotion of enterprise digital transformation, project and product teams integrate third-party atomization capabilities such as optical character recognition (OCR) recognition and SMS verification to quickly build business capabilities and reduce development costs.

[0003] There are three main types of existing technical solutions for integrating third-party atomization capabilities: first, single supplier binding, that is, the project team selects a fixed supplier; second, manually switching suppliers by changing application programming interface keys (API keys) or configuration files; and third, calling each supplier through a simple load strategy, which supports parallel calling of multiple suppliers.

[0004] However, the existing technical solutions have significant shortcomings: first, the application programming interface (API) layer does not have switching capabilities, and a single supplier failure can cause business interruption and a decline in user experience; second, manual configuration modification is required, which cannot respond in a timely manner and increases operational costs; and third, a simple load strategy cannot support complex calling scenarios. SUMMARY

[0005] The present application aims to address the shortcomings of the existing technology by providing a multi-supplier service scheduling method and a multi-supplier service scheduling system to solve the problem of unstable supplier services and high operational costs in the existing technology.

[0006] To achieve the above-mentioned purpose, the technical solutions adopted by the present application are as follows: In a first aspect, the present application provides a multi-supplier service scheduling method applied to a multi-supplier service scheduling system, the system comprising a scheduling strategy configuration module, a health detection module, and a dynamic routing module; the method comprising: After a local demand side calls a target local service through a local API, the scheduling strategy configuration module determines at least one supplier service corresponding to the target local service, scheduling information of each supplier service, and a scheduling rule corresponding to the target local service; The health detection module determines the health status of each supplier service based on historical service data of each supplier service; The dynamic routing module determines the target scheduling scheme and at least one target supplier service based on the health status of each supplier service, the scheduling information of each supplier service, and the scheduling rules of the target local service. The dynamic routing module sends the call request to each of the target supplier services based on the target scheduling scheme, so that each target supplier service receives the call request and executes the corresponding service.

[0007] Optionally, determining the health status of each supplier's service based on historical service data includes: The error rate of each supplier's service is determined based on the historical service data of each supplier's service. Iterate through each supplier service. For the first current supplier service encountered, determine whether the error rate of the first current supplier service exceeds a preset error rate threshold. If so, the health status of the first current supplier service is: unhealthy.

[0008] Optionally, determining the health status of each supplier's service based on historical service data includes: Based on the service quality prediction model, the service quality information of each supplier's service is determined according to the historical service data of each supplier's service. The service quality information includes: latency rate and return speed. Based on the service quality information of each supplier, determine the health status of each supplier's services.

[0009] Optionally, determining the target scheduling scheme and at least one target supplier service based on the health status of each of the supplier services, the scheduling information of each of the supplier services, and the scheduling rules of the target local service includes: If the scheduling rule for the target local service is to schedule according to weight, then at least one target supplier service is determined based on the health status of each supplier service, and the target weight is determined based on the scheduling information of each target supplier service. The target scheduling scheme is to allocate the call request to each corresponding target supplier according to the target weight of each target supplier. If the scheduling rule for the target local service is to schedule according to the primary / backup strategy, then according to the pre-set order of the supplier services, each supplier service is traversed. For the second current supplier service encountered, it is determined whether the health status of the second current supplier service is healthy. If not, the next supplier service is traversed. If yes, the second current supplier service is taken as the target supplier service. The target scheduling scheme is to send the call request to the target supplier service.

[0010] Optionally, the method further includes: The dynamic routing module obtains real-time monitoring information of each supplier's services from the health detection module, and the real-time monitoring information includes: the current health status of each supplier's services; The dynamic routing module treats a supplier service whose current health status is unhealthy as an abnormal supplier service, and determines whether there is an abnormal supplier service whose current health status has returned to normal. If so, it determines a new target scheduling scheme and a new target supplier based on the current health status of the abnormal supplier service that has returned to normal, the current health status of the target supplier, the scheduling information, and the scheduling rules of the target local service.

[0011] Optionally, determining a new target scheduling scheme and a new target supplier based on the current health status of the abnormal supplier service that has recovered to normal, the current health status of the target supplier, scheduling information, and the scheduling rules of the target local service includes: A preset weight is set for the abnormal supplier service, so that the abnormal supplier service receives the call request according to the preset weight and executes the corresponding service; Receive the current health status of the abnormal supplier service detected and sent by the health detection module; If the current health status of the abnormal supplier service is healthy, then the abnormal supplier service and the target supplier service are taken as the new target supplier service, and a new target scheduling scheme is determined based on the scheduling information of the new target supplier service and the scheduling rules of the target local service.

[0012] Optionally, the method further includes: If the health detection module confirms that the health status of each supplier is unhealthy, it will generate text information from the pre-set local cache information and send it to the local demand party through the local API.

[0013] Optionally, the multi-vendor service scheduling system further includes an adaptation module, and the method further includes: The adaptation module receives multiple service data sent by various vendor services, encapsulates each target service data, and sends the encapsulated data to the local API.

[0014] Optionally, the method further includes: The adaptation module receives the call request sent by the dynamic routing module, encapsulates the call request, and sends the encapsulated call request to each of the target supplier services.

[0015] Secondly, this application provides a multi-vendor service scheduling system, which includes a scheduling strategy configuration module, a health detection module, and a dynamic routing module. The multi-vendor service scheduling system is used to execute the multi-vendor service scheduling method as described in the first aspect.

[0016] The beneficial effects of this application are as follows: After the local demander calls the target local service through the local API, the scheduling strategy configuration module determines at least one supplier service corresponding to the target local service, the scheduling information of each supplier service, and the scheduling rules corresponding to the target local service. The health detection module determines the health status of each supplier service based on its historical service data. The dynamic routing module determines the target scheduling scheme and at least one target supplier service based on the health status of each supplier service, the scheduling information of each supplier service, and the scheduling rules of the target local service. The dynamic routing module sends the call request to each target supplier service based on the target scheduling scheme, so that each target supplier service receives the call request and executes the corresponding service. This embodiment adjusts the target supplier service and the target scheduling scheme by monitoring the health status of suppliers in real time, ensuring the smooth operation of the target local service, avoiding service interruptions caused by the failure of a single supplier, and ensuring service continuity and high availability. Furthermore, the scheduling method of this embodiment does not require manual intervention, saving time and manpower costs, reducing downtime and potential risks, and improving service quality. In addition, this embodiment supports the integration of multiple supplier capabilities, improving the scalability of the system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the structure of a multi-vendor service invocation system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a multi-vendor service scheduling method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating a process for determining a new target scheduling scheme and a new target supplier, provided in an embodiment of this application. Figure 4 This is a schematic diagram of another multi-vendor service scheduling system provided in the embodiments of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0020] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0022] Existing technical solutions for integrating third-party atomic capabilities mainly fall into three categories: first, single vendor binding; second, manually switching vendors by changing API keys or configuration files; and third, calling various vendors through simple load balancing strategies, which support parallel calls from multiple vendors. However, existing technical solutions have the following shortcomings: first, the API layer lacks switching capabilities, and a single point of failure in a vendor may lead to business interruption and a decline in user experience; second, manual configuration modification is required, which cannot provide timely responses and increases operational costs; and third, simple load balancing strategies cannot support complex calling scenarios.

[0023] Based on this, this application proposes a multi-vendor service scheduling method. In this method, after a local requester invokes a target local service, at least one vendor service corresponding to the target local service, the scheduling information of each vendor service, and the scheduling rules of the target local service are determined. Then, based on the health status of each vendor service, the scheduling information of each vendor service, and the scheduling rules of the target local service, a target scheduling scheme and target vendor services are determined. Finally, based on the target scheduling scheme, the invocation request is sent to each target vendor service, enabling each target vendor service to receive the invocation request and execute the corresponding service. This application automatically selects target vendor services by monitoring each vendor service in real time, thereby providing stable and high-quality services to the local requester and reducing development, maintenance, and operational costs.

[0024] Figure 1 This is a schematic diagram of the structure of a multi-vendor service invocation system provided in an embodiment of this application. For example... Figure 1 As shown, the multi-vendor service scheduling system includes a scheduling strategy configuration module, a health check module, and a dynamic routing module. The local API is used to forward call requests sent by local demanders. The dynamic routing module receives call requests from the local API, receives health status information for each vendor service from the health check module, and receives at least one vendor service corresponding to the target local service, scheduling information for each vendor service, and scheduling rules corresponding to the target local service from the scheduling strategy configuration module. After determining the target scheduling scheme and at least one target vendor service, the dynamic routing module sends the call request to the target vendor service, enabling each target vendor service to receive the call request and execute the corresponding service.

[0025] Figure 2 This is a flowchart illustrating a multi-vendor service scheduling method provided in an embodiment of this application. Next, refer to... Figure 2 The process of multi-vendor service scheduling method is introduced.

[0026] S201. After the local demander calls the target local service through the local API, the scheduling strategy configuration module determines at least one supplier service corresponding to the target local service, the scheduling information of each supplier service, and the scheduling rules corresponding to the target local service.

[0027] In this context, the local demander can be the entity that initiates the service request in a local environment. The local demander can vary depending on the application scenario. For example, if the scenario is a city's water system, the local demander could refer to water service terminals within that city. If the scenario is an internal enterprise system, the local demander could refer to the enterprise's internal financial system, human resources system, etc.

[0028] A local API can be a standardized interface for local users to call, used to forward interaction information between local users and target local services. A local API can correspond to one or more target local services, and the specific local services can be set according to the actual situation. This embodiment does not impose any restrictions here.

[0029] A target local service can be a service carrier that provides specific atomic capabilities to the outside world within a local environment. It is the direct service interface for local requesters. However, the target local service does not actually execute the core capabilities; instead, it achieves functionality by aggregating at least one vendor service. These atomic capabilities can be, for example, data recognition, computational processing, or message push. It is worth noting that for the local requester, the target local service is the only service provider; the requester does not need to know the corresponding vendor service.

[0030] Supplier services are atomic service capabilities provided by external suppliers or third-party service providers that are consistent with the functionality of the target local service. Multiple supplier services may possess core functionalities that match the target local service. For example, supplier services corresponding to the target local invoice recognition service can all perform invoice information extraction.

[0031] Scheduling information can be a pre-defined dataset describing the services of each vendor, which may include processing capacity data and weights. Processing capacity data refers to the performance metrics of the vendor services, such as the number of requests per second, the maximum number of concurrent connections, and data processing throughput, reflecting the vendor's ability to handle the request load from the demand side. Weights are pre-defined priority values ​​based on business needs; for example, vendor service A might have a weight of 60, while vendor service B might have a weight of 40. These weights directly affect the allocation ratio of request calls.

[0032] Scheduling rules can be pre-defined logical rules for selecting a target execution object from multiple vendor services. Scheduling rules can be flexibly adjusted according to business objectives, such as prioritizing stability, cost, or performance. Scheduling rules can include, for example, round-robin strategies, weighted strategies, minimum response time strategies, and primary / standby strategies.

[0033] S202. The health monitoring module determines the health status of each supplier's services based on their historical service data.

[0034] Optionally, historical service data refers to various quantitative data related to the operation of the supplier's services that the health monitoring module continuously records through active detection, passive collection, and other methods within a preset historical time period. This data can reflect the foundation of the supplier's long-term service performance and trends. Historical service data may include error rate, service downtime, and historical response time, etc.

[0035] Optionally, the health status of each supplier's service is a qualitative description of the current operational quality of the supplier's service, typically categorized as healthy or unhealthy. As an optional implementation, if the error rate exceeds a preset threshold, the supplier's service is considered unhealthy. Optionally, the health status of the supplier's service can be assessed multiple times, and the combined result of these multiple assessments can be used as the overall health status of the supplier's service.

[0036] S203. The dynamic routing module determines the target scheduling scheme and at least one target supplier service based on the health status of each supplier service, the scheduling information of each supplier service, and the scheduling rules of the target local service.

[0037] Optionally, the target scheduling scheme can be a proportion of the data sent to each target vendor. For example, 30% of the data could be allocated to vendor service A, and 70% of the data to vendor weight B.

[0038] As an optional implementation, supplier services with a healthy status are prioritized for screening. If multiple healthy supplier services exist, the target supplier service is determined from among the multiple healthy supplier services according to the scheduling rules of the target local service and the scheduling information allocation request.

[0039] S204. The dynamic routing module sends the call request to each target supplier service based on the target scheduling scheme, so that each target supplier service receives the call request and executes the corresponding service.

[0040] The invocation request can include basic request metadata and service execution data. The basic request metadata describes the attributes of the request itself and is used for distributed tracing, route location, and rule validation. The service execution data includes business data related to the provider's service execution capabilities.

[0041] As an optional implementation, the system receives call requests initiated by local demanders, first supplements the call request with metadata such as unique identifier and timeout to complete standardized encapsulation, then splits the batch or concurrent call requests according to the target scheduling scheme, converts the call requests into a format that can be recognized by the vendor according to the interface specifications of each target vendor service, and then distributes them to the corresponding target vendor service.

[0042] Optionally, after receiving the call request, the target supplier service parses the execution data and executes the service. Simultaneously, the dynamic routing module can monitor the execution status and trigger retries or supplier switching for timeouts, errors, or other anomalies. Once execution is complete, the aggregated results are sent back to the local requester.

[0043] In this embodiment, after the local requester calls the target local service via the local API, the scheduling strategy configuration module determines at least one vendor service corresponding to the target local service, the scheduling information of each vendor service, and the scheduling rules corresponding to the target local service. The health detection module determines the health status of each vendor service based on its historical service data. The dynamic routing module determines the target scheduling scheme and at least one target vendor service based on the health status of each vendor service, its scheduling information, and the scheduling rules of the target local service. The dynamic routing module sends the call request to each target vendor service based on the target scheduling scheme, enabling each target vendor service to receive the call request and execute the corresponding service. This embodiment adjusts the target vendor service and the target scheduling scheme by monitoring the health status of vendors in real time, ensuring smooth operation of the target local service, avoiding service interruptions due to single vendor failures, and guaranteeing service continuity and high availability. Furthermore, the scheduling method in this embodiment does not require manual intervention, saving time and manpower costs, reducing downtime and potential risks, and improving service quality. In addition, this embodiment supports multi-vendor capability integration, improving the system's scalability.

[0044] Next, we will introduce the first implementation method of determining the health status of each supplier's service based on the historical service data of each supplier's service in step S202 above.

[0045] Optionally, the error rate of each supplier's service can be determined based on historical service data.

[0046] Optionally, the total number of requests and the number of error requests for each provider's services can be recorded within a preset time period. The total number of requests refers to the total number of call requests sent to the provider's services during that period, and the number of error requests refers to the number of requests for which the provider returned error responses. Error responses include, for example, specific error codes, timeouts without response, and connection failures. The quotient of the number of error requests and the total number of requests is then used as the error rate.

[0047] It is worth noting that data can be collected and calculated repeatedly according to a set period to dynamically update the error rate of each supplier's service, so as to reflect their recent service quality.

[0048] Optionally, each supplier service is traversed, and for the first current supplier service encountered, it is determined whether the error rate of the first current supplier service exceeds a preset error rate threshold. If so, the health status of the first current supplier service is: unhealthy.

[0049] Optionally, if the error rate of the first current supplier service does not exceed a preset error rate threshold, then the health status of the first current supplier service is: healthy.

[0050] The preset error rate threshold can be set in advance based on the type of the target local service. If the target local service has a low fault tolerance, the preset error rate threshold can be set to a lower value.

[0051] In this embodiment, the error rate of each supplier's service is determined based on the historical service data of each supplier's service, and the health status of the supplier's service is determined by judging whether the error rate of the first current supplier's service exceeds a preset error rate threshold. Through this method of real-time monitoring of the health of supplier services, the routing strategy is automatically adjusted according to the actual situation.

[0052] Next, we will introduce the second implementation method of determining the health status of each supplier's service based on the historical service data of each supplier's service in the above step S202.

[0053] Optionally, based on the service quality prediction model, the service quality information of each supplier's service is determined according to the historical service data of each supplier's service. The service quality information includes latency rate and return speed.

[0054] As an optional implementation, key features of each provider's services are extracted from historical service data, including the number of historical delayed requests, total number of requests, return time for each request, request initiation time, and request type. The data is then cleaned and organized into a model input dataset according to the provider's service dimension. The preprocessed data is then further processed for features, such as calculating the average return time of provider services at different times, peak-hour latency rates, and service quality differences for different request types, to construct the model input data. This preprocessed input data is then fed into the trained prediction model, triggering the model inference process. Based on the input historical feature data, the model outputs predicted latency and return speed values ​​for the corresponding provider. The latency and return speed data from the model's prediction results are extracted as service quality information for the provider's services.

[0055] Latency rate is the probability that a service will not respond within the agreed time, used to determine if there are any issues with service lag or timeouts. Data return speed is the rate at which the provider's service returns data to the local requester; data return speed directly affects user waiting time.

[0056] Optionally, the health status of each supplier's services can be determined based on the service quality information of each supplier's services.

[0057] Optionally, a latency rate threshold and a return speed threshold are preset. If the latency rate in the service quality information is less than the latency rate threshold and the return speed is less than the return speed threshold, the health status of the supplier's service is healthy. If the latency rate in the service quality information is greater than the latency rate threshold or the return speed is greater than the return speed threshold, the health status of the supplier's service is unhealthy.

[0058] In this embodiment, based on the service quality prediction model, the service quality information of each supplier's service is determined according to the historical service data of each supplier's service. Based on the service quality information of each supplier's service, the health status of each supplier's service is determined. Through this method of real-time monitoring of supplier service health, the routing strategy is automatically adjusted according to the actual situation.

[0059] As an optional implementation, the error rate, latency rate, and return speed of the supplier's services can be monitored simultaneously as a basis for determining service quality information, thereby improving accuracy.

[0060] Next, we will introduce the steps in step S203 above, which involve determining the target scheduling scheme and at least one target supplier service based on the health status of each supplier service, the scheduling information of each supplier service, and the scheduling rules of the target local service.

[0061] Optionally, if the scheduling rule for the target local service is to schedule according to weight, then at least one target supplier service is determined based on the health status of each supplier service, and the target weight is determined based on the scheduling information of each target supplier service. The target scheduling scheme is to allocate call requests to the corresponding target suppliers according to the target weight of each target supplier.

[0062] Optionally, the supplier services with a healthy health status among all supplier services are selected as target supplier services. Then, the target weight of each target supplier service is determined based on its scheduling information. For example, if the scheduling information for target supplier services X, Y, and Z are 60%, 70%, and 70%, respectively, then the target weights for target supplier service X are 30%, 35%, and 35%. The target scheduling scheme is to allocate 30% of call requests to target supplier service X, 35% to target supplier service Y, and 35% to target supplier service Z.

[0063] Optionally, if the scheduling rule for the target local service is to schedule according to the primary / backup strategy, then according to the pre-set order of the supplier services, each supplier service is traversed. For the second current supplier service encountered, it is determined whether the health status of the second current supplier service is healthy. If not, the next supplier service is traversed. If so, the second current supplier service is taken as the target supplier service, and the target scheduling scheme is to send the call request to the target supplier service.

[0064] Optionally, the initial primary and backup supplier service order is preset, and each supplier is traversed in order. If the primary supplier is healthy, the primary supplier service is used as the target supplier service. At the same time, the health status of the primary supplier service is monitored in real time. When the primary supplier service changes from healthy to unhealthy, the subsequent backup suppliers are traversed in the preset order, and the first healthy backup supplier service is found as the new target supplier service. The call request is switched to the new target supplier service.

[0065] In this embodiment, by determining the target scheduling scheme and at least one target supplier service based on the health status of each supplier service, the scheduling information of each supplier service, and the scheduling rules of the target local service, the priority and selection strategy of supplier services are dynamically adjusted to maximize the performance and stability of the system and ensure that high-quality supplier services are found to improve service quality.

[0066] As an alternative implementation, the multi-vendor service scheduling method may also perform the following steps to improve service quality.

[0067] Optionally, the dynamic routing module obtains real-time monitoring information of each supplier's services from the health monitoring module. The real-time monitoring information includes the current health status of each supplier's services.

[0068] The current health status indicates that the target supplier is currently performing its service. The health monitoring module acquires relevant real-time service data and extracts and calculates the health status based on this data. The current health status can be either "healthy" or "unhealthy".

[0069] Optionally, the dynamic routing module treats a supplier service whose current health status is unhealthy as an abnormal supplier service, determines whether the current health status of an abnormal supplier service has returned to normal, and if so, determines a new target scheduling scheme and a new target supplier based on the current health status of the abnormal supplier service that has returned to normal, the current health status of the target supplier, scheduling information, and the scheduling rules of the target local service.

[0070] Optionally, there may be one or more abnormal supplier services; this embodiment does not impose any restrictions on this.

[0071] Optionally, when the health detection module determines that the current health status of the abnormal supplier service has changed from unhealthy to healthy, a new target scheduling scheme and a new target supplier are determined based on the current health status of the abnormal supplier service that has recovered to health, the current health status of the target supplier, scheduling information, and the scheduling rules of the target local service.

[0072] As an optional implementation, if the scheduling rule for the target local service is to schedule according to the primary / backup strategy, and the dynamic routing module detects that the original primary supplier service has recovered from unhealthy to healthy, while the existing target supplier service is the original backup supplier and is still healthy, then based on the existing target supplier service and the scheduling rule that "the primary supplier has higher priority than the backup supplier", it is determined to reset the original primary supplier service as the new target supplier service. The new target scheduling scheme is to gradually switch the call requests from the original backup supplier back to the original primary supplier according to the preset switching strategy. The preset switching strategy is, for example, gradual traffic switching to avoid instantaneous traffic surges.

[0073] In this embodiment, supplier services with an unhealthy current health status are designated as abnormal supplier services. It is then determined whether any abnormal supplier services have recovered to normal health status. If so, a new target scheduling scheme and a new target supplier are redefined. This ensures service stability while revitalizing supplier resources that have recovered to normal status, thus avoiding resource idleness or overload of a single supplier.

[0074] As an optional implementation method, Figure 3 This is a schematic diagram illustrating a process for determining a new target scheduling scheme and a new target supplier, provided in an embodiment of this application. (Refer to...) Figure 3 The process of determining the new target scheduling scheme and the new target supplier will be described.

[0075] S301. Set a preset weight for abnormal supplier services so that abnormal supplier services receive call requests and execute corresponding services according to the preset weight.

[0076] Optionally, the preset weight can be a small weight, much smaller than the weight of the original target supplier service. For example, if the original target supplier service A has a weight of 40% and the original target supplier service B has a weight of 60%, then the preset weight could be 2%. When an abnormal supplier service receives a call request according to the preset weight, one of the following two operations can be performed: First, the weight of the original target supplier service is subtracted by the average value of the preset weight. For example, if the preset weight is 2%, then target supplier service A has a weight of 39% and target supplier service B has a weight of 59%. Second, the original target supplier service remains unchanged to ensure service stability.

[0077] S302, Receive the current health status of the abnormal supplier service detected and sent by the health detection module.

[0078] Optionally, the dynamic routing module can receive the current health status of abnormal supplier services sent by the health detection module at preset intervals.

[0079] S303. If the current health status of the abnormal supplier service is healthy, then the abnormal supplier service and the target supplier service will be used as the new target supplier service, and a new target scheduling scheme will be determined based on the scheduling information of the new target supplier service and the scheduling rules of the target local service.

[0080] As an optional implementation, if the scheduling rule for the target local service is based on a load balancing strategy, after the abnormal provider service recovers, it will form a new target provider service together with the original target provider. Combining the real-time load data and scheduling information of each new target provider service, the new target scheduling scheme is determined to be a load-weighted round-robin strategy to allocate requests, prioritizing traffic to the new target provider service with lower load to balance the overall load.

[0081] Optionally, if the current health status of the abnormal supplier service is healthy, the preset weight can be increased by another gradient to test whether the abnormal supplier service can perform the service again.

[0082] In this embodiment, a preset weight is set for abnormal supplier services so that abnormal supplier services receive call requests and execute corresponding services according to the preset weight. The current health status of abnormal supplier services is detected and sent by the health detection module, thereby ensuring that abnormal supplier services can execute services stably.

[0083] As an optional implementation, the multi-vendor service scheduling method can also perform the following steps: if the health detection module confirms that the health status of each vendor is unhealthy, then it generates text information based on the pre-set local cache information and sends it to the local demander through the local API.

[0084] As an optional implementation, the local cached information inflow can be a preset text template, which may include event time and emergency prompts. The health monitoring module monitors the current health status of each vendor's service in real time. Once it detects that all vendor services have become unhealthy, it triggers an emergency text generation strategy. That is, it reads the preset text template from the local configuration file. The preset text module includes event time, emergency prompts, etc., and fills in dynamic information such as the current timestamp to generate complete text information. This information is then asynchronously pushed to the local requester via the local API to ensure that the requester receives the status notification in a timely manner.

[0085] As an alternative implementation, if the health detection module confirms that the health status of each supplier is unhealthy, it directly reads the local static text file in the local cache information, such as emergency_info.txt, which contains service recovery suggestions, contact information, etc., and responds to the local requester in plain text format through the local HTTP API, making it easier for the requester to identify the emergency scenario.

[0086] In this embodiment, if the health detection module confirms that the health status of each supplier is unhealthy, it generates text information based on the pre-set local cache information and sends it to the local demand party through the local API to ensure that the demand party can identify the emergency scenario in a timely manner and ensure the continuity of service.

[0087] As an optional implementation method, Figure 4 This is a schematic diagram of another multi-vendor service scheduling system provided in an embodiment of this application. For example... Figure 4 As shown, the multi-vendor service scheduling system also includes an adaptation module. Based on this, the multi-vendor service scheduling method further includes the following steps: the adaptation module receives multiple service data sent by each target vendor service, encapsulates each service data, and sends the encapsulated service data to the local API.

[0088] Optionally, for different target vendor services, the adaptation module can encapsulate the service data sent by each target vendor service into unified internal calibration service data, making its format uniform. This allows the target local service requirements to be concerned with the differences in vendor services, thereby greatly simplifying the integration work and laying the foundation for seamless vendor switching in the future.

[0089] Optionally, the adaptation module receives the call request sent by the dynamic routing module, encapsulates the call request, and sends the encapsulated call request to each target vendor service.

[0090] Optionally, the adaptation module accepts the call request sent by the dynamic routing module, and encapsulates the call request according to the format requirements of the target vendor service, and sends the encapsulated call request to the corresponding target vendor service.

[0091] In this embodiment, the system receives a call request from the dynamic routing module, encapsulates the call request, and sends the encapsulated call request to each target vendor service so that each target vendor service can successfully execute the corresponding service.

[0092] This application also provides a multi-vendor service scheduling system, which includes a scheduling strategy configuration module, a health detection module, and a dynamic routing module. The multi-vendor service scheduling system is used to execute the above-described multi-vendor service scheduling method.

[0093] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A multi-vendor service scheduling method, characterized in that, An application is made in a multi-vendor service scheduling system, the system comprising: a scheduling policy configuration module, a health check module, and a dynamic routing module; the method comprises: After the local demander calls the target local service through the local API, the scheduling strategy configuration module determines at least one supplier service corresponding to the target local service, the scheduling information of each supplier service, and the scheduling rules corresponding to the target local service. The health monitoring module determines the health status of each supplier's service based on the historical service data of each supplier's service. The dynamic routing module determines the target scheduling scheme and at least one target supplier service based on the health status of each supplier service, the scheduling information of each supplier service, and the scheduling rules of the target local service. The dynamic routing module sends the call request to each of the target supplier services based on the target scheduling scheme, so that each target supplier service receives the call request and executes the corresponding service.

2. The multi-vendor service scheduling method according to claim 1, characterized in that, The step of determining the health status of each supplier's service based on historical service data includes: The error rate of each supplier's service is determined based on the historical service data of each supplier's service. Iterate through each supplier service. For the first current supplier service encountered, determine whether the error rate of the first current supplier service exceeds a preset error rate threshold. If so, the health status of the first current supplier service is: unhealthy.

3. The multi-vendor service scheduling method according to claim 1, characterized in that, The step of determining the health status of each supplier's service based on historical service data includes: Based on the service quality prediction model, the service quality information of each supplier's service is determined according to the historical service data of each supplier's service. The service quality information includes: latency rate and return speed. Based on the service quality information of each supplier, determine the health status of each supplier's services.

4. The multi-vendor service scheduling method according to claim 1, characterized in that, The step of determining the target scheduling scheme and at least one target supplier service based on the health status of each of the supplier services, the scheduling information of each of the supplier services, and the scheduling rules of the target local service includes: If the scheduling rule for the target local service is to schedule according to weight, then at least one target supplier service is determined based on the health status of each supplier service, and the target weight is determined based on the scheduling information of each target supplier service. The target scheduling scheme is to allocate the call request to each corresponding target supplier according to the target weight of each target supplier. If the scheduling rule for the target local service is to schedule according to the primary / backup strategy, then according to the pre-set order of the supplier services, each supplier service is traversed. For the second current supplier service that is traversed, it is determined whether the health status of the second current supplier service is healthy. If not, the next supplier service is traversed. If yes, the second current supplier service is taken as the target supplier service. The target scheduling scheme is to send the call request to the target supplier service.

5. The multi-vendor service scheduling method according to claim 1, characterized in that, The method further includes: The dynamic routing module obtains real-time monitoring information of each supplier's services from the health detection module, and the real-time monitoring information includes: the current health status of each supplier's services; The dynamic routing module treats a supplier service whose current health status is unhealthy as an abnormal supplier service, and determines whether there is an abnormal supplier service whose current health status has returned to normal. If so, it determines a new target scheduling scheme and a new target supplier based on the current health status of the abnormal supplier service that has returned to normal, the current health status of the target supplier, the scheduling information, and the scheduling rules of the target local service.

6. The multi-vendor service scheduling method according to claim 5, characterized in that, The step of determining a new target scheduling scheme and a new target supplier based on the current health status of the restored abnormal supplier service, the current health status of the target supplier, scheduling information, and the scheduling rules of the target local service includes: A preset weight is set for the abnormal supplier service, so that the abnormal supplier service receives the call request according to the preset weight and executes the corresponding service; Receive the current health status of the abnormal supplier service detected and sent by the health detection module; If the current health status of the abnormal supplier service is healthy, then the abnormal supplier service and the target supplier service are taken as the new target supplier service, and a new target scheduling scheme is determined based on the scheduling information of the new target supplier service and the scheduling rules of the target local service.

7. The multi-vendor service scheduling method according to claim 1, characterized in that, The method further includes: If the health detection module confirms that the health status of each supplier is unhealthy, it will generate text information from the pre-set local cache information and send it to the local demand party through the local API.

8. The multi-vendor service scheduling method according to claim 1, characterized in that, The multi-vendor service scheduling system further includes an adaptation module, and the method further includes: The adaptation module receives multiple service data sent by various vendor services, encapsulates each target service data, and sends the encapsulated data to the local API.

9. The multi-vendor service scheduling method according to claim 8, characterized in that, The method further includes: The adaptation module receives the call request sent by the dynamic routing module, encapsulates the call request, and sends the encapsulated call request to each of the target supplier services.

10. A multi-vendor service scheduling system, characterized in that, The multi-vendor service scheduling system includes a scheduling strategy configuration module, a health detection module, and a dynamic routing module. The multi-vendor service scheduling system is used to execute the multi-vendor service scheduling method as described in any one of claims 1-9.

Images