A method and system for application programming interface routing

Abstract

This application discloses a method and system for processing application programming interface (API) routing. The method includes: monitoring the lifecycle events of each service in a container orchestration platform; creating independent collection tasks for target services based on the matching results of event types and specified tags; calculating the time offset of the first collection execution time of the target service within a preset collection period relative to the start time of the current collection period, based on the identification information of the target service; determining the scheduling time corresponding to the target service based on the time offset and the collection period; triggering the retrieval of routing information for the target service at the scheduling time to achieve staggered collection among services; and reporting the retrieved routing information to the central platform according to a unified data model. This application achieves distributed collection times by independently calculating the offset within a period for each service and triggering task restarts by filtering with specified tags, thereby optimizing system resources.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a method and system for processing application programming interface routing. Background Technology

[0002] In a microservice architecture, each business service is developed and deployed independently, exposing a large number of application programming interfaces (APIs). This results in scattered interfaces, inconsistent documentation, version chaos, and difficulty in auditing. Therefore, it is necessary to aggregate the routing information of each service to a unified platform for centralized management, so as to detect interface changes in real time and proactively synchronize them to the unified platform, thereby ensuring that API assets are consistent with the actual running status.

[0003] In existing technologies, the current practice typically involves a central node initiating routing queries for all target services at fixed intervals and at a unified time. When the number of services requiring data collection within the cluster is large, a large number of concurrent requests will be generated at the same time, leading to instantaneous load spikes on business services and the central platform. This can easily cause timeouts, rate limiting, or failures, and is strongly correlated with the collection cycle, exhibiting a peak-cumulative phenomenon. Furthermore, existing technologies have significant drawbacks: for example, the collection scope is uncontrollable, and the response to service changes is too coarse. There are also issues such as inconsistent or incompatible routing retrieval and reporting methods. These shortcomings make it difficult to meet the needs of technological development. Summary of the Invention

[0004] To address the aforementioned technical problems, this application discloses a method and system for processing application programming interface (API) routing. By independently calculating the offset within a cycle for each service to distribute the data collection time, and only triggering task restarts for services with specified tags and whose relevant data collection fields have changed, system resource optimization is achieved. Specifically, the technical solution of this application is as follows: In a first aspect, this application discloses a method for processing application programming interface (API) routing, including: Monitor the lifecycle events of each service in the container orchestration platform, and create independent collection tasks for the target service based on the matching results of event type and specified tag; Based on the identification information of the target service, calculate the time offset of the first collection execution time of the target service within the preset collection period relative to the start time of the current collection period; Based on the time offset and the collection period, the scheduling time corresponding to the target service is determined, and the routing information of the target service is pulled at the scheduling time to realize staggered collection among services. The retrieved routing information is reported to the central platform according to a unified data model.

[0005] In some implementations, calculating the time offset of the first data collection execution time of the target service relative to the start time of the current collection period within a preset collection period, based on the identification information of the target service, specifically includes: Obtain the namespace and name of the target service as the identification information; Perform a deterministic hash algorithm on the string of the identification information to obtain a hash integer value; The absolute value of the hash integer is taken and modulo the collection period to obtain the time offset of the target service within the collection period.

[0006] In other embodiments, determining the scheduling time corresponding to the target service based on the time offset and the acquisition period, and triggering the retrieval of routing information for the target service at the scheduling time, specifically includes: Create a separate timer for the target service; The time offset is used as the initial delay time of the current system time to obtain the initial scheduling time, and the routing information retrieval operation of the target service is triggered at the initial scheduling time. The next scheduling time is obtained by superimposing the acquisition period on the previous scheduling time using the timer; the pull operation is triggered again at the next scheduling time.

[0007] In other implementations, the lifecycle events of each service in the monitoring container orchestration platform are used to create independent collection tasks for the target service based on the matching results of event types and specified tags; specifically including: A listening channel is established through the application programming interface of the container orchestration platform to receive new events, update events and deletion events of each of the services. For the newly added event, determine whether the new service has a specified tag; if it has the specified tag, then create the collection task. For the update event, compare whether the data collection-related fields in the metadata of the new service and the old service have changed. If the data collection-related fields have changed, stop the data collection task of the old service and create the data collection task of the new service. For the deletion event, determine whether the deleted old service has the specified tag. If it has the specified tag, stop the corresponding collection task.

[0008] Optionally, the fields related to data collection include the target service's tag set, the target service's port definition set, and the cluster's Internet Protocol address.

[0009] In other embodiments, triggering the retrieval of routing information for the target service specifically includes: A dual-path retrieval strategy is adopted, with a primary path and a backup path pre-configured, and a unified reporting data model and reporting interface agreed upon. The system prioritizes sending a fetch request to the primary path; if the primary path returns a failure status code, it automatically switches to the backup path and sends the fetch request again. If the primary path or the backup path returns a success status code, the response message is parsed according to the agreed data format to obtain the full application programming interface route list of the target service.

[0010] Secondly, this application also discloses an application programming interface (API) routing processing system, which connects a central platform and a container orchestration platform cluster to implement the API routing processing method described in any of the above embodiments, specifically including: The event listening module is used to listen to the lifecycle events of various services in the container orchestration platform and create independent collection tasks for the target service based on the matching results of event type and specified tag. The task management module is used to calculate the time offset of the first collection execution time of the target service relative to the start time of the current collection period within a preset collection period, based on the identification information of the target service. The routing retrieval module is used to determine the scheduling time corresponding to the target service based on the time offset and the collection period, and to trigger the retrieval of routing information for the target service at the scheduling time, so as to realize staggered collection among services. The information reporting module is used to report the retrieved routing information to the central platform according to a unified data model.

[0011] In other embodiments, the event listening module is specifically used for the following operations: A listening channel is established through the application programming interface of the container orchestration platform to receive new events, update events and deletion events of each of the services. For the newly added event, determine whether the new service has a specified tag; if it has the specified tag, then create the collection task. For the update event, compare whether the data collection-related fields in the metadata of the new service and the old service have changed. If the data collection-related fields have changed, stop the data collection task of the old service and create the data collection task of the new service. For the deletion event, determine whether the deleted old service has the specified tag. If it has the specified tag, stop the corresponding collection task.

[0012] Thirdly, this application also discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the application programming interface routing processing method described in any of the above embodiments.

[0013] Fourthly, this application also discloses a computer program product, including a computer program that, when executed by a processor, implements the steps of the application programming interface routing processing method described in any of the above embodiments.

[0014] Compared with the prior art, this application has at least one of the following beneficial effects: 1. This application performs deterministic hash calculations on each service being collected, based on its namespace and name, and takes the hash value modulo the collection period to obtain a fixed time offset for that service within the period. Each service triggers its collection task independently according to its own offset. Since the hash values ​​of different services are likely to be different, their collection times will naturally be distributed across the entire period's timeline. Only a small number of services will execute collection at any given time, thereby significantly reducing instantaneous concurrency pressure, mitigating the impact on business services and the central platform, and improving the overall stability of the system.

[0015] 2. This application achieves precise control and efficient resource utilization of data collection tasks by limiting the collection scope through tags and combining incremental change judgments of collection-related fields. Furthermore, for service update events, this application determines whether collection-related fields in the metadata have changed; only when these fields change will the task be restarted. Other changes, such as annotations or resource version numbers, will not trigger any operation, significantly reducing system jitter and resource consumption.

[0016] 3. This application significantly improves the system's scalability and compatibility through a unified data reporting model. The central platform only needs to interface with one reporting protocol to receive all routing information, achieving unified access across multiple languages ​​and frameworks. Simultaneously, this application employs a dual-path strategy of a primary path plus a backup path, prioritizing requests to the primary path and automatically switching to the backup path if a failure occurs, significantly improving compatibility with different frameworks and versions and increasing the success rate of discovery. Attached Figure Description

[0017] The preferred embodiments will now be described in a clear and easy-to-understand manner, in conjunction with the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of this application.

[0018] Figure 1 This is a flowchart illustrating the steps of an embodiment of the application programming interface routing processing method of this application; Figure 2This is a flowchart illustrating the steps of another embodiment of the application programming interface routing processing method of this application; Figure 3 This is a structural block diagram of an embodiment of an application programming interface routing processing system according to this application. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0020] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or sets.

[0021] To keep the drawings concise, each figure only schematically shows the parts relevant to the invention, and these do not represent the actual structure of the product. Furthermore, to facilitate understanding, in some figures, only one of components with the same structure or function is schematically depicted, or only one is labeled. In this document, "one" not only means "only one," but can also mean "more than one."

[0022] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the specific implementation methods of this application will be described below with reference to the accompanying drawings. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without creative effort.

[0025] In a microservices architecture, each business service exposes a large number of API interfaces. To centrally manage API assets, aggregate documentation, govern version control, and conduct compliance audits, it is necessary to aggregate the routing information of each service onto a unified platform.

[0026] Prior to this application, common solutions in the prior art first involve a central node maintaining a list of services to be collected. This list can be obtained through a configuration file or from the full service list of a container orchestration platform. Subsequently, the system starts a global timer with a fixed collection period. At the end of each period, the central node sequentially or concurrently initiates Hypertext Transfer Protocol (HTTP) requests to all services in the list, obtains full application programming interface (API) routing information from the routing discovery endpoints of each service, parses the responses, and reports them to the central platform.

[0027] However, the above solutions result in a concentrated surge of collection requests, with the collection time for all services perfectly aligned with the start of the global cycle. Simultaneous requests to all services at the same time can easily create instantaneous load spikes, causing significant concurrent pressure on business services and the central platform, potentially leading to timeouts, rate limiting, or service failures. Furthermore, if the service list adopts a full service approach, the collection scope becomes uncontrollable, potentially including a large number of services unrelated to application programming interface governance in the collection, resulting in invalid requests and wasted storage.

[0028] To overcome the technical deficiencies in the existing technology, this application proposes a method and system for processing application programming interface (API) routing. While maintaining periodic data collection, the collection times of each service are distributed throughout the period, reducing instantaneous concurrency and smoothing the load.

[0029] Reference manual attached Figure 1 As shown, one embodiment of the application programming interface routing processing method of this application specifically includes the following steps: S1 listens to the lifecycle events of each service in the container orchestration platform and creates independent collection tasks for the target service based on the matching results of the event type and the specified tag.

[0030] Specifically, a container orchestration platform refers to a platform used for the automated deployment, scaling, and management of containerized applications. This embodiment uses Kubernetes as an example. It provides an application programming interface (API) service interface, allowing external programs to monitor lifecycle events such as service creation, updates, and deletions.

[0031] Multiple services run within a Kubernetes cluster, and the services to be collected are labeled with a predefined tag (e.g., api.collect=true). The service discovery module of the collection program listens for service lifecycle events through the ListWatch / Informer interface of the Kubernetes application programming interface, and only issues start or stop collection orders to the collection task management module for services with the specified tag. These lifecycle events include three types: service addition, attribute update, and deletion (Add / Update / Delete), corresponding to service going online, changing, and going offline, respectively.

[0032] S2, based on the identification information of the target service, calculate the time offset of the first collection execution time of the target service within the preset collection period relative to the starting time of the current collection period.

[0033] Optionally, within the container orchestration platform cluster, each target service corresponds to a unique identifier, enabling accurate differentiation between the target service and all other services. Furthermore, this identifier remains unchanged throughout the target service's entire lifecycle; the result calculated based on the identifier for the same service is always the same at any time and under any computing environment. Based on this characteristic, this application, through deterministic calculations based on identifier information, allows different services to obtain distinct offsets due to their different identifiers, thereby naturally distributing the collection trigger times of each service across the entire timeline.

[0034] This application calculates time offsets instead of scheduling the first collection of all services at the beginning of the cycle to avoid generating a large number of concurrent requests at the same time. In a microservice architecture, the number of services that need to be collected may reach hundreds or thousands. If all services trigger collection at the beginning of the cycle simultaneously, business services and the central platform will be subjected to instantaneous load spikes, which may lead to timeouts, rate limiting, or even service failures.

[0035] S3. Based on the time offset and the collection period, determine the scheduling time corresponding to the target service, and trigger the retrieval of routing information for the target service at the scheduling time to achieve staggered collection among services.

[0036] Specifically, this application adopts an independent task plus offset scheduling design. Each service has its own independent timer, and each timer is triggered according to its calculated offset, without interfering with each other. This design avoids the period start alignment problem caused by global timers. At the same time, since the offset is deterministically generated based on service identification information, even if the collection program restarts or the service is rediscovered, the scheduling time of the same service remains consistent, ensuring the stability and traceability of the collection behavior.

[0037] In some implementations, for the first fetch, the scheduling time is equal to the start time of the service collection task plus a time offset. For subsequent fetches, the scheduling time is equal to the completion time of the previous fetch plus the collection period, or equal to the first scheduling time plus an integer multiple of the collection period.

[0038] S4. The retrieved routing information is reported to the central platform according to a unified data model.

[0039] Specifically, routing information is application programming interface-related data parsed from the target service response message. It includes at least the project name or service name, route list, and development language. The route list further includes the request method, path, parameter description, and function description of each interface.

[0040] By agreeing on a unified data model, all collected services are required to report data in the same format. The central platform only needs to connect to one reporting protocol to receive routing information from all services, which greatly reduces the complexity and cost of the system.

[0041] Based on the above embodiments, this application discloses another embodiment of an application programming interface routing processing method, as detailed in the appendix. Figure 2 As shown, step S1 involves listening to the lifecycle events of each service in the container orchestration platform and creating an independent collection task for the target service based on the matching results of the event type and the specified tag. Specifically, this includes the following sub-steps: S11, a listening channel is established through the application programming interface of the container orchestration platform to receive new events, update events and deletion events of each service.

[0042] Specifically, after receiving a Kubernetes service event, the data collection program needs to decide whether to start, stop, or maintain the current data collection task. The entry point is the receipt of a service event, followed by branching based on event type. These type branches include three types: service addition, attribute update, and deletion (Add / Update / Delete).

[0043] For the three types, further determination is needed based on the matching results of specified tags to decide whether to create independent collection tasks for each service. Specified tags are a set of key-value pairs pre-set for each service, used to distinguish which services should be included in the collection scope of the application programming interface (API) routing. Limiting the collection scope by tags avoids initiating invalid pull requests to irrelevant services, reducing system resource waste and storage pressure on the central platform. Simultaneously, creating independent, rather than shared, collection tasks for each service ensures that the collection lifecycles of each service are isolated, facilitating the setting of differentiated scheduling strategies for different services and providing flexible start / stop control capabilities for dynamic service deployment and shutdown.

[0044] S12, for the newly added event, determine whether the new service has a specified tag; if it has the specified tag, then create the collection task.

[0045] S13, for the update event, compare whether the data collection-related fields in the metadata of the new service and the old service have changed. If the data collection-related fields have changed, stop the data collection task of the old service and create the data collection task of the new service.

[0046] S14, for the deletion event, determine whether the deleted old service has the specified tag; if it has the specified tag, stop the corresponding collection task.

[0047] Specifically, for the newly added event (Add): if the service does not have a specified tag, it is ignored. If it has a tag, the data collection is started (a data collection task is created for the service and added to the off-peak scheduling).

[0048] In this case, specifying a label can be achieved by checking if service.Labels[key]==value, and the key / value pair can be configured.

[0049] In some implementations, for update events, the process is stopped and restarted only if the field related to the data collection changes; otherwise, no action is taken.

[0050] Reference manual attached Figure 2 In other implementations, for the update event, it is also necessary to determine in advance whether the old service object and the new service object have a specified tag. If the old service object does not have a tag, then only the new service object is checked for a tag. If it has a tag, data collection is started; otherwise, it is ignored. If the old service object has a tag and the new service object does not have a tag, then data collection is stopped (logical deletion). If both the old and new service objects have tags, then it is determined whether the fields related to data collection have changed. If they have not changed, no operation is performed; if they have changed, the old task is stopped first, and then the new data collection is started for the new service.

[0051] Specifically, the fields related to data collection are limited to those affecting the target and results of the data retrieval. Optionally, these fields include, but are not limited to, the target service's label set (Labels), the target service's port definition set (Spec.Ports), and the cluster internet protocol address (Spec.Cluster IP). Changes to other fields will not trigger a restart.

[0052] Determining whether fields related to data collection have changed can be done by performing a deep comparison of the relevant fields, optionally, for example, using `reflect.DeepEqual`. A restart should only be performed if these fields have changed.

[0053] For the deletion event: if the deleted service object has a specified tag, data collection stops; otherwise, it is ignored. By checking whether relevant fields have changed, meaningless restarts due to changes in irrelevant fields are avoided.

[0054] This embodiment employs deterministic offset based on service identifiers and staggered scheduling within a period to distribute the collection times of each service within a period, significantly reducing instantaneous concurrent pressure.

[0055] Based on the above embodiments, this application discloses another embodiment of an application programming interface (API) routing processing method. Step S2 involves calculating the time offset of the first data collection execution time of the target service within a preset collection period relative to the start time of the current collection period, based on the identification information of the target service. Specifically, this includes the following sub-steps: S21, Obtain the namespace and name of the target service as the identification information.

[0056] In some alternative implementations, the "namespace / name" service key of the Kubernetes service is used as the service identification information.

[0057] S22, Perform a deterministic hash algorithm on the string of the identification information to obtain a hash integer value.

[0058] Specifically, a deterministic hash is performed on the service key string (e.g., djb2: initial value 5381, hash=(hash<<5)+hash+char for each character), the absolute value of the integer obtained is taken, and then modulo the collection period T (e.g. 300 seconds) to obtain the offset of the service within the period (unit is consistent with T).

[0059] S23, take the absolute value of the hash integer value and then take the modulo of the collection period to obtain the time offset of the target service within the collection period.

[0060] Specifically, taking the absolute value of the hash integer is intended to eliminate negative results that the hash algorithm may produce, ensuring that subsequent modulo operations yield non-negative integers.

[0061] The hash value, after taking its absolute value, is moduloed by the collection period. This means the remainder is the time offset of the target service within the collection period. Since the remainder ranges from 0 to one (the collection period minus one), the time offset is naturally mapped to the time window of the collection period.

[0062] Using the above method, the time offset for the same service remains constant in each calculation, while different services obtain different time offsets due to their different hash values, thereby achieving a distributed distribution of the collection times of each target service within the period. Simultaneously, since the calculation is deterministic, the offset obtained for the same service remains unchanged each time, ensuring the stability and predictability of the scheduling behavior.

[0063] Based on the above embodiments, this application discloses another embodiment of an application programming interface (API) routing processing method. Step S3 involves determining the scheduling time corresponding to the target service based on the time offset and the acquisition period, and triggering the retrieval of routing information for the target service at the scheduling time. Specifically, it includes the following sub-steps: S31, Create an independent timer for the target service.

[0064] Specifically, independent timed threads are created for the target service, ensuring that the data collection tasks of each service are not shared or interfered with. Independent timers allow each service to time independently according to its calculated time offset, distributing the data collection trigger times across different points in the data collection cycle. This also facilitates fine-grained lifecycle management of the data collection tasks for individual services.

[0065] Optionally, the acquisition period T and offset are configurable. The timer uses time.Timer or time.NewTicker, and is properly closed and released when the task stops.

[0066] S32, the time offset is used as the initial delay time of the current system time to obtain the initial scheduling time, and the routing information retrieval operation of the target service is triggered at the initial scheduling time.

[0067] Specifically, the initial data collection is performed after the initial delay time from the current time. The initial delay time refers to the length of time required from the current system time to the first execution of the routing information retrieval operation, and its value is equal to the time offset calculated in the aforementioned steps.

[0068] In some implementations, the initial delay time can be between 0 and the collection period T. By using the time offset obtained through deterministic calculation as the initial delay, the same service can still trigger fetching at the same relative time point under different startup scenarios, while different services are naturally staggered due to their different offsets, thus achieving deterministic peak-shifting scheduling.

[0069] S33, the next scheduling time is obtained by superimposing the acquisition period on the previous scheduling time using the timer. The pull operation is triggered again at the next scheduling time.

[0070] Specifically, subsequent data collection uses a timer. Each time a data collection is completed, a full period T is waited before the next data collection is executed. Alternatively, the timer is set to period T with the service offset as the initial trigger delay, and then reset to T after each trigger.

[0071] In this way, the collection times of different services fall at different time points within the period T, and only a small number of services are collecting data at the same time, thus achieving load smoothing.

[0072] In some alternative implementations, the triggering of the retrieval of routing information for the target service specifically includes the following retrieval steps: S301 adopts a dual-path retrieval strategy, pre-configuring the primary path and backup path, and agreeing on a unified reporting data model and reporting interface.

[0073] Specifically, a Uniform Resource Locator (URL) is constructed based on the service's ClusterIP and port (such as a port named http-80 or the first port).

[0074] Route retrieval also needs to adhere to the following pre-defined conventions: each service being collected exposes a route discovery interface (such as GET / routes), and a single request returns all API interface information for that service (such as project_name, route_list, language), using a pre-defined JSON structure.

[0075] S302, a fetch request is initiated first to the primary path. If the primary path returns a failure status code, the system automatically switches to the backup path and initiates the fetch request again.

[0076] Specifically, the system first initiates a Hypertext Transfer Protocol (HTTP) request to the constructed Uniform Resource Locator (URL) concatenated with the main path. That is, it first requests the main path: http: / / {ClusterIP}:{port} / routes.

[0077] Optionally, if the primary path request returns a status code of "404" or "not found", then switch to the backup path and re-initiate the request to the Uniform Resource Locator (URL) appended to the backup path, i.e., request the backup path: http: / / {ClusterIP}:{port} / xxx).

[0078] S303, if the primary path or the backup path returns a success status code, then parse the response message according to the agreed data format to obtain the full application programming interface route list of the target service.

[0079] Specifically, when the primary path or the backup path returns a "success" status code, the response message body is parsed according to the agreed JavaScript service object notation format to extract the project name (project_name), route list (route_list), and language field (language), and these fields are encapsulated into a unified reporting data structure. Through this dual-path fetching strategy, the same parsing logic is compatible with both the primary and backup paths, improving compatibility and success rate for different frameworks or versions of route discovery endpoint exposure methods.

[0080] This application provides another embodiment of an application programming interface (API) routing processing method. Based on any of the above embodiments, step S4 involves reporting the retrieved routing information to the central platform according to a unified data model. The following technical details are also included.

[0081] In some implementations, the reported data model includes at least project_name (project / service identifier), route_list (route list), and language (development language).

[0082] The reporting method involves submitting the JSONbody via the same HTTP endpoint (e.g., POST / private / v1 / devhub / project / report). The central platform can then interface with this protocol to receive routing data from all collected services, facilitating unified database entry, display, and multi-language support.

[0083] Based on the same concept, this application also discloses an application programming interface (API) routing processing system. The system connects a central platform and a container orchestration platform cluster to implement the steps described in any of the above method embodiments. Specifically, an embodiment of the API routing processing system of this application is provided in the appendix to the specification. Figure 3 As shown, it specifically includes: The event listening module is used to listen to the lifecycle events of various services in the container orchestration platform and create independent collection tasks for the target service based on the matching results of event type and specified tag.

[0084] The task management module is used to calculate the time offset of the first collection execution time of the target service relative to the start time of the current collection period within a preset collection period, based on the identification information of the target service.

[0085] The routing retrieval module is used to determine the scheduling time corresponding to the target service based on the time offset and the collection period, and to trigger the retrieval of routing information for the target service at the scheduling time, so as to realize the staggered collection between services.

[0086] The information reporting module is used to report the retrieved routing information to the central platform according to a unified data model.

[0087] Based on the above embodiments, this application discloses another embodiment of an application programming interface routing processing system, wherein the event listening module is specifically used to implement the following operations: A listening channel is established through the application programming interface of the container orchestration platform to receive new events, update events, and deletion events from each of the services.

[0088] For the newly added event, determine whether the new service has a specified tag. If it has the specified tag, then create the collection task.

[0089] For the update event, compare whether the data collection-related fields in the metadata of the new service and the old service have changed. If the data collection-related fields have changed, stop the data collection task of the old service and create the data collection task of the new service.

[0090] For the deletion event, determine whether the deleted old service has the specified tag. If it has the specified tag, stop the corresponding collection task.

[0091] This application provides another embodiment of an application programming interface routing processing system. Based on any embodiment of the above system, the task management module further includes the following units: The identifier acquisition unit acquires the namespace and name of the target service as the identifier information.

[0092] The hash operation unit is used to perform a deterministic hash algorithm on the string of the identification information to obtain a hash integer value.

[0093] An offset calculation unit is used to take the absolute value of the hash integer value and then take the modulo of the collection period to obtain the time offset of the target service within the collection period.

[0094] In some implementations, the route fetching module further includes the following units: A timer unit is used to create an independent timer for the target service.

[0095] The time calculation unit is used to take the time offset as the initial delay time of the current system time to obtain the initial scheduling time.

[0096] The information retrieval unit is used to trigger the retrieval operation of routing information for the target service at the initial scheduling time.

[0097] The time calculation unit is also used to obtain the next scheduling time by superimposing the acquisition period on the previous scheduling time using the timer.

[0098] The information retrieval unit is also used to trigger the retrieval operation again at the next scheduling time.

[0099] Based on the same technical concept, this application also discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the application programming interface routing processing method described in any of the above embodiments.

[0100] This application also discloses a computer program product, including a computer program that, when executed by a processor, implements the steps of the application programming interface routing processing method described in any of the above embodiments.

[0101] The application programming interface routing processing method, system, readable storage medium, and computer program product of this application have the same technical concept, and the technical details of the embodiments of the four are applicable to each other. In order to reduce repetition, they will not be described again here.

[0102] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of program modules is merely an example. In practical applications, the above functions can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program units or modules to complete all or part of the functions described above. The program modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software program unit. Furthermore, the specific names of the program modules are only for easy differentiation and are not intended to limit the scope of protection of this application.

[0103] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for processing application programming interface (API) routing, characterized in that, include: Monitor the lifecycle events of each service in the container orchestration platform, and create independent collection tasks for the target service based on the matching results of event type and specified tag; Based on the identification information of the target service, calculate the time offset of the first collection execution time of the target service within the preset collection period relative to the start time of the current collection period; Based on the time offset and the collection period, the scheduling time corresponding to the target service is determined, and the routing information of the target service is pulled at the scheduling time to enable staggered collection among multiple services. The retrieved routing information is reported to the central platform according to a unified data model.

2. The method for processing application programming interface routing as described in claim 1, characterized in that, The step of calculating the time offset of the first collection execution time of the target service relative to the start time of the current collection period within a preset collection period, based on the identification information of the target service, includes: Obtain the namespace and / or name of the target service as the identification information; Perform a deterministic hash algorithm on the string of the identification information to obtain a hash integer value; The absolute value of the hash integer is taken and modulo the collection period to obtain the time offset of the target service within the collection period.

3. The method for processing application programming interface routing as described in claim 1, characterized in that, The method of determining the scheduling time corresponding to the target service based on the time offset and the collection period, and triggering the retrieval of routing information for the target service at the scheduling time, includes: Create a separate timer for the target service; The time offset is used as the initial delay time of the current system time to obtain the initial scheduling time, and the routing information retrieval operation of the target service is triggered at the initial scheduling time. The next scheduling time is obtained by superimposing the acquisition period on the previous scheduling time using the timer; the pull operation is triggered again at the next scheduling time.

4. The method for processing application programming interface routing as described in claim 1, characterized in that, The aforementioned monitoring of lifecycle events for each service in the container orchestration platform, based on the matching results of event types and specified tags, creates independent collection tasks for target services, including: A listening channel is established through the application programming interface of the container orchestration platform to receive new events, update events and deletion events of each of the services. For the newly added event, determine whether the new service has a specified tag; if it has the specified tag, then create the collection task. For the update event, compare whether the data collection-related fields in the metadata of the new service and the old service have changed. If the data collection-related fields have changed, stop the data collection task of the old service and create the data collection task of the new service. For the deletion event, determine whether the deleted old service has the specified tag. If it has the specified tag, stop the corresponding collection task.

5. The method for processing application programming interface routing as described in claim 4, characterized in that, The fields related to data collection include: the target service's tag set, the target service's port definition set, and the cluster's Internet Protocol address.

6. A method for processing application programming interface routing as described in any one of claims 1-5, characterized in that, The triggering of the retrieval of routing information for the target service includes: A dual-path retrieval strategy is adopted, with a primary path and a backup path pre-configured, and a unified reporting data model and reporting interface agreed upon. The system prioritizes sending a fetch request to the primary path; if the primary path returns a failure status code, it automatically switches to the backup path and sends the fetch request again. If the primary path or the backup path returns a success status code, the response message is parsed according to the agreed data format to obtain the full application programming interface route list of the target service.

7. A processing system for application programming interface (API) routing, characterized in that, The system connects the central platform and the container orchestration platform cluster to implement the application programming interface routing processing method according to any one of claims 1-6, specifically including: The event listening module is used to listen to the lifecycle events of various services in the container orchestration platform and create independent collection tasks for the target service based on the matching results of event type and specified tag. The task management module is used to calculate the time offset of the first collection execution time of the target service relative to the start time of the current collection period within a preset collection period, based on the identification information of the target service. The routing retrieval module is used to determine the scheduling time corresponding to the target service based on the time offset and the collection period, and to trigger the retrieval of routing information for the target service at the scheduling time, so as to realize staggered collection among services. The information reporting module is used to report the retrieved routing information to the central platform according to a unified data model.

8. The application programming interface routing processing system as described in claim 7, characterized in that, The event listening module is specifically used to implement the following operations: A listening channel is established through the application programming interface of the container orchestration platform to receive new events, update events and deletion events of each of the services. For the newly added event, determine whether the new service has a specified tag; if it has the specified tag, then create the collection task. For the update event, compare whether the data collection-related fields in the metadata of the new service and the old service have changed. If the data collection-related fields have changed, stop the data collection task of the old service and create the data collection task of the new service. For the deletion event, determine whether the deleted old service has the specified tag. If it has the specified tag, stop the corresponding collection task.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the processing method for routing application programming interfaces as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the processing method for routing application programming interfaces as described in any one of claims 1-6.

Images