Micro-service instance routing method and device based on multi-level cache, equipment and medium

Abstract

This application discloses a microservice instance routing method, apparatus, device, and medium based on multi-level caching, belonging to the field of data processing technology. The method includes: when the computing engine module processes a microservice instance call request, parsing the microservice instance call request to obtain a first request feature value; if a version corresponding to the first request feature value is found in the first-level cache, a load balancer is selected, and the target service version corresponding to the request is obtained; a second request feature value is obtained based on the first request feature value and the target service version; if a route corresponding to the second request feature value is found in the first-level cache, a load balancer is selected, and the target service instance corresponding to the request is obtained. This application solves the inherent technical problems of low routing decision efficiency, excessive system resource consumption, and inability to effectively utilize caching while ensuring correctness in existing technologies when handling advanced routing scenarios such as multi-version and canary deployments.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, and specifically relates to a microservice instance routing method, apparatus, device and medium based on multi-level caching. Background Technology

[0002] With the rapid development of internet services, monolithic application architectures can no longer meet the demands of rapid iteration and elastic scaling, making microservice architecture the mainstream. In this architecture, a complex application is broken down into a set of small, autonomous services that collaborate via remote calls (such as RPC or HTTP). In this context, service discovery and load balancing form the cornerstone of microservice communication. The core process is: when service A (the consumer) needs to call service B (the provider), it must select the optimal and most suitable instance from among the many running instances of service B to initiate the request.

[0003] Currently, mainstream implementations generally follow this pattern in their instance selection logic when handling a single request: First, obtain the full list of instances: retrieve all healthy instances of the target service from the locally cached service registry; then, perform real-time filtering and calculation: for each arriving request, traverse the entire instance list in memory in real time. The strategies executed in the filtering and calculation process include: metadata matching: comparing the metadata tags of each instance based on the request context (such as header, user ID) and routing rules to filter out a subset of candidate instances that meet the conditions; weight calculation: in canary scenarios, complex probability calculations need to be performed on the subset of instances that meet the conditions, based on their respective weights, to determine the final instance; health check integration: exclude instances that have been marked as unhealthy or circuit-breaker by the local health checker.

[0004] However, as the scale of enterprise systems continues to expand, the number of service instances may reach tens of thousands, and the routing rules become increasingly complex. The above traditional model exposes the following significant technical defects and performance bottlenecks: (1) Performance overhead and high latency caused by real-time computing: Traversing the full instance list, matching conditions, and calculating weights for each request is a CPU-intensive operation. In high-concurrency scenarios where tens of thousands or even hundreds of thousands of requests are processed per second, this computational overhead becomes unavoidable, directly increasing the overall response time of requests and becoming a performance bottleneck of the system. (2) The inherent contradiction between dynamism and caching efficiency: First, the health status of backend instances changes instantaneously, and outdated cache results in requests being sent to instances that have crashed, causing call failures. Second, canary deployment relies on traffic allocation that meets statistical proportions under a large number of requests. Fixed caching will destroy the accuracy of weights, making canary deployment meaningless.

[0005] Therefore, in order to ensure the correctness and dynamism of routing, existing technical solutions have to sacrifice efficiency and fall into the paradigm of recalculating for each request.

[0006] In summary, existing technologies suffer from inherent technical challenges when handling advanced routing scenarios such as multi-version and canary deployments, including low routing decision efficiency, excessive system resource consumption, and the inability to effectively utilize caching while ensuring correctness. Summary of the Invention

[0007] To address the aforementioned technical issues, this application provides a microservice instance routing method, apparatus, device, and medium based on multi-level caching.

[0008] To achieve the above objectives, this application provides the following technical solution: A microservice instance routing method based on multi-level caching, the method comprising: When the computing engine module processes a microservice instance call request, it parses the microservice instance call request to obtain the first request feature value. If the version selection load balancer corresponding to the first request feature value is hit in the first-level cache of the multi-level caching module, then the version selection load balancer is called to obtain the target service version corresponding to the microservice instance call request. A second request feature value is obtained based on the first request feature value and the target service version; If the routing load balancer corresponding to the second request feature value is hit in the first-level cache of the multi-level caching module, then the routing load balancer is invoked to obtain the target service instance corresponding to the microservice instance call request.

[0009] Further, in one embodiment, before parsing the microservice instance call request to obtain the first request feature value when the computing engine module processes the microservice instance call request, the following steps are included: Establish and maintain the connection between the data listening module of the routing client and the registration center and / or configuration center; Retrieve all service registration information from the registry center, using the service name as the key and the service instance information as the value, and initialize the instance list cache in the second-level cache. Retrieve all service routing rule configurations from the configuration center, using the configuration item name as the key and the configuration item content as the value, and initialize the routing rule cache in the second-level cache. When the service instance information of the registration center and / or the routing rules stored in the configuration center change, the second-level cache in the multi-level caching module is synchronously updated.

[0010] Furthermore, in one embodiment, the step of triggering a synchronous update of the second-level cache in the multi-level caching module when the service instance information of the registration center and / or the routing rules stored in the configuration center change includes: When the service instance information of the registry center and / or the routing rules stored in the configuration center change, receive incremental change pushes from the registry center and / or the configuration center, and parse the changed data; If the changed data is successfully parsed, the state snapshot of the registry center in the multi-level cache is updated, and the parsing results of the changed data are analyzed to obtain the analysis results; Based on the analysis results, the second-level cache synchronization update strategy in the corresponding multi-level cache module is triggered.

[0011] Furthermore, in one embodiment, triggering the second-level cache synchronization update strategy in the corresponding multi-level caching module based on the analysis results includes: If the analysis result is: the changed data is a new service, then create a new cache item with the new service name as the key and the list of instances of the new service as the value, and insert it into the instance list cache in the second-level cache; If the analysis result is: the changed data is due to a service instance change, then update the cache in the instance list cache with the service name as the key according to the changed content, and update the service instance list to the latest value; If the analysis result indicates that the changed data is due to the service being deleted, then clear the cache in the instance list cache that uses the service name as the key.

[0012] Further, in one embodiment, the step of parsing the microservice instance call request to obtain the first request feature value includes: The microservice instance call request is parsed. If the parsing is successful, the state snapshots of the registry center and the configuration center are read from the cache. Obtain the source name and target service name of the microservice instance call request from the parsing results; Based on the state snapshots of the registry center, the state snapshots of the configuration center, and the source and target service names of the microservice instance call requests, the first request characteristic value for reading the version to select the load balancer is generated.

[0013] Further, in one embodiment, after parsing the microservice instance call request to obtain the first request feature value, the process includes: If the version of the first request feature value is not selected in the first-level cache of the multi-level caching module, the routing rule of the target service name is obtained from the routing rule cache of the second-level cache using the target service name as the key. A version selection load balancer is constructed based on the version canary release rules and load balancing strategies in the routing rules, and the version selection load balancer is added to the version selection load balancer cache. The load balancer is selected by calling the version to obtain the target service version corresponding to the microservice instance call request.

[0014] Further, in one embodiment, after obtaining the second request feature value based on the first request feature value and the target service version, the process includes: If the routing load balancer corresponding to the second request feature value is not hit in the first-level cache of the multi-level caching module, then the service instance list of the target service name is obtained from the service list cache of the second-level cache using the target service name as the key. Filter the list of service instances with the target service name to select the list of instances that match the target service version, build a route selection load balancer, and add the route selection load balancer to the route selection load balancer cache; The routing load balancer is invoked to obtain the target service instance corresponding to the microservice instance call request.

[0015] Based on the same inventive concept, embodiments of this application also provide a microservice instance routing device based on multi-level caching, the device comprising: The first request feature value acquisition module is configured to parse the microservice instance call request and obtain the first request feature value when the computing engine module processes the microservice instance call request. The target service version acquisition module is configured to call the version selection load balancer if the version selection load balancer corresponding to the first request feature value is hit in the first-level cache of the multi-level caching module, and obtain the target service version corresponding to the microservice instance call request. The second request feature value acquisition module is configured to obtain a second request feature value based on the first request feature value and the target service version; The target service instance acquisition module is configured to call the routing load balancer corresponding to the second request feature value in the first-level cache of the multi-level caching module if the routing load balancer is hit, and then obtain the target service instance corresponding to the microservice instance call request.

[0016] Based on the same inventive concept, embodiments of this application also provide an electronic device, including: a memory and a processor; the processor is used to read and execute a computer program stored in the memory to implement the steps of the aforementioned microservice instance routing method based on multi-level caching.

[0017] Based on the same inventive concept, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, implement the steps of the aforementioned microservice instance routing method based on multi-level caching.

[0018] Compared with the prior art, this application has the following advantages: In the implementation of the routing client, the multi-level caching module not only provides a service instance list and routing rule cache, but also, in conjunction with the data monitoring module, avoids frequent operations between the routing client and the registry and configuration center, reducing system resource consumption. Furthermore, by providing load balancer storage, the computing engine module can retrieve the corresponding load balancer from the first-level cache when processing request routing. The computing engine module directly returns the next selected instance by executing the load balancer's embedded selection method, avoiding complex calculations, shortening request routing processing time, and improving system efficiency. Simultaneously, the key-value pairs corresponding to the load balancer cache entries contain version information representing the current snapshot of the registry and configuration center. In scenarios with frequent dynamic service changes, this ensures the accuracy of cache selection, guaranteeing the efficiency and accuracy of microservice instance routing.

[0019] This application solves the inherent technical problems of existing technologies in handling advanced routing scenarios such as multi-version and canary deployment, including low routing decision efficiency, excessive system resource consumption, and inability to effectively utilize caching while ensuring correctness.

[0020] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart illustrating the method provided in the embodiments of this application; Figure 2 A schematic diagram of the overall architecture according to an embodiment of this application is shown; Figure 3 This is a schematic diagram illustrating the interaction process between the data monitoring module and the registration center according to an embodiment of this application; Figure 4 This is a schematic diagram of the routing process of a microservice instance call request in the computing engine module according to an embodiment of this application. Figure 5 This is a schematic diagram of the functional modules of an embodiment of the microservice instance routing device based on multi-level caching in this application; Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0023] 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. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] To address the shortcomings of existing technologies, refer to Figure 1 This application discloses a microservice instance routing method based on multi-level caching, including: Step S10: When the computing engine module processes a microservice instance call request, it parses the microservice instance call request to obtain the first request feature value. Further, in one embodiment, before step S10, the following steps are included: Establish and maintain the connection between the data listening module of the routing client and the registration center and / or configuration center; Retrieve all service registration information from the registry center, using the service name as the key and the service instance information as the value, and initialize the instance list cache in the second-level cache. Retrieve all service routing rule configurations from the configuration center, using the configuration item name as the key and the configuration item content as the value, and initialize the routing rule cache in the second-level cache. When the service instance information of the registration center and / or the routing rules stored in the configuration center change, the second-level cache in the multi-level caching module is synchronously updated.

[0025] In some specific embodiments, the step of triggering a synchronous update of the second-level cache in the multi-level caching module when the service instance information of the registration center and / or the routing rules stored in the configuration center change includes: When the service instance information of the registry center and / or the routing rules stored in the configuration center change, receive incremental change pushes from the registry center and / or the configuration center, and parse the changed data; If the changed data is successfully parsed, the state snapshot of the registry center in the multi-level cache is updated, and the parsing results of the changed data are analyzed to obtain the analysis results; Based on the analysis results, the second-level cache synchronization update strategy in the corresponding multi-level cache module is triggered.

[0026] In this embodiment, when the data monitoring module of the routing client detects changes in the service instance information of the registration center and / or the routing rules stored in the configuration center, it will trigger a synchronous update of the second-level cache in the multi-level caching module.

[0027] The logical structure between the routing client, the registry center, and the configuration center is as follows: Figure 2 As shown. The routing client is internally divided into three core modules: a data monitoring module, a multi-level caching module, and a computing engine. The functional roles of each component and module are as follows: Registration Center: The infrastructure in a microservice architecture, responsible for centrally recording and managing the real-time network addresses, metadata, and health status of all service instances.

[0028] Configuration Center: A unified configuration manager responsible for storing, pushing, and dynamically updating application routing rules, weighting strategies, and other configuration information related to business logic.

[0029] Data monitoring module: Responsible for monitoring changes in data in the registry center and configuration center, such as changes in the service instance list in the registry center (instance online, offline, metadata changes) and changes in routing rules in the configuration center (such as weight adjustments, matching rule updates). When changes occur, it updates the data involved in the second-level cache in the multi-level caching module and evicts old data.

[0030] The multi-level caching module includes instance list caching, routing rule caching, and load balancer caching, and operates in two modes: cache objects and cached iteration logic with specific states. The instance list cache and routing rule cache are second-level caches, belonging to the cache object mode. They store deterministic data and are used to cache the service instance list obtained from the registry center and the service routing rules obtained from the configuration center, respectively. The load balancer cache is a first-level cache, used to store cached load balancer instances with state, specifying key-value pairs. This includes route selection load balancer cache and version selection load balancer cache. Data from the second-level cache is used during the creation of load balancer instances. Specifically, the key value of the route selection load balancer cache is a routing key composed of multiple conditions for matching routing rules (such as combinations of conditions like "orimod=ave", "version=1.0.1", "svcname=echo", "reg_version=2316789"). It stores a load balancer object containing state and routing matching logic; multiple calls to its methods produce dynamic, serialized routing results. The version selection load balancer cache is used to store the version selection load balancer in multi-version release and canary release scenarios, and dynamically returns the version selection result.

[0031] The computation engine module is responsible for processing requests. Based on the feature values ​​carried in the request, it constructs a version selection key, selects the version selection load balancer corresponding to this request from the version selection load balancer cache, and determines the target service version for this request. Next, it constructs a routing selection key, selects the routing selection load balancer corresponding to this request from the routing selection load balancer cache, determines the specific target service instance selected for this request, and completes the request transmission.

[0032] In the microservice instance routing implementation scheme, the registry and configuration center, as two independent infrastructure components, together form the data foundation for service routing decisions. Through separation of responsibilities, they decouple and manage the physical information of service instances from the business routing logic. Specifically, the registry stores information such as the version, metadata, and real-time network address of all instances of a service at the service level; similarly, the configuration center stores the routing policy configurations for each service at the service level, using the service name as the name of each configuration item. The routing client utilizes the incremental change push or client-side long polling mechanisms of the registry and configuration center to promptly detect changes in the service instance list or service routing rules and trigger a refresh of the local second-level cache.

[0033] The specific implementation steps for the interaction between the client's data monitoring module and the registration center are as follows: Figure 3 As shown. (Refer to...) Figure 3 Step 1.1: Establish and maintain a connection with the registry center; Step 2.1: Retrieve all service registration information from the registry center, using the service name as the key and the service instance information as the value, and initialize the instance list cache in the second-level cache; Step 3.1: Receive incremental change pushes from the registry center and parse the changed data. If parsing fails, disconnect from the registry center and skip to step 1.1. If successful, update the registry center's state snapshot (revision:R1) in the multi-level cache as the snapshot version of the registry center when the computing engine module creates the first-level cache. Simultaneously, analyze the parsing results to obtain the analysis results. If the analysis result is: the changed data is a newly added service, proceed to step 4.1. If the analysis result is: the changed data is a service instance change, skip to step 5.1. If the analysis result is: the changed data is a service deletion, skip to step 6.1.

[0034] Step 4.1: Create a new cache item with the new service name as the key and the list of new service instances as the value, and insert it into the instance list cache in the second-level cache. Skip to step 7.1. Step 5.1: Update the cache in the instance list cache with the service name as the key according to the changes, update the service instance list to the latest value, and skip to step 7.1; Step 6.1: Clear the cache entries in the instance list cache that use the service name as the key; Step 7.1, skip to step 3.1.

[0035] The specific implementation steps for the interaction between the client's data monitoring module and the configuration center are as follows.

[0036] Step 1.2: Establish and maintain the connection with the configuration center; Step 2.2: Retrieve all service routing rule configurations from the configuration center, using the configuration item name as the key and the configuration item content as the value, and initialize the routing rule cache in the second-level cache; Step 3.2: Receive incremental change pushes from the configuration center and parse the change data. If parsing fails, disconnect from the configuration center and skip to step 1.2. If successful, update the status snapshot of the configuration center in the multi-level cache to revision:C1, which serves as the snapshot version of the configuration center when the computing engine module creates the first-level cache. Simultaneously, analyze the parsing results to obtain the analysis results. If the analysis result is: the changed data is a newly added configuration item, proceed to step 4.2. If the analysis result is: the changed data is a change in configuration content, skip to step 5.2. If the analysis result is: the changed data is a deleted configuration item, skip to step 6.2. Step 4.2: Using the newly added configuration item name as the key and its content as the value, create a new cache item and insert it into the routing rule cache in the second-level cache. Skip to step 7.2. Step 5.2: Update the cache in the routing rule cache with the configuration item name as the key according to the changed content, update its content to the latest value, and skip to step 7.2; Step 6.2: Clear the cache in the routing rule cache that uses the configuration item name as the key.

[0037] Step 7.2, skip to step 3.2.

[0038] In some specific embodiments, step S10 includes: The microservice instance call request is parsed. If the parsing is successful, the state snapshots of the registry center and the configuration center are read from the cache. Obtain the source name and target service name of the microservice instance call request from the parsing results; Based on the state snapshots of the registry center, the state snapshots of the configuration center, and the source and target service names of the microservice instance call requests, the first request characteristic value for reading the version to select the load balancer is generated.

[0039] In this embodiment, refer to Figure 4 The system reads the microservice instance call request, parses and verifies it. If it fails, it records the error and waits for the next request. If it succeeds, it reads the registry center state snapshot (revision R1) and configuration center state snapshot (revision C1) from the cache. Then, it executes the target service version selection logic for this microservice instance call request, obtaining the microservice instance call request source name S1 and target service name D1 from the parsing results.

[0040] Using the state snapshot (R1) from the registry center, the state snapshot (C1) from the configuration center, the source name (S1) and the target service name (D1) of the microservice instance call request, the read version selection load balancer key value K1 is generated, which is also the first request characteristic value.

[0041] Furthermore, in one embodiment, after step S10, the method further includes: If the version of the first request feature value is not selected in the first-level cache of the multi-level caching module, the routing rule of the target service name is obtained from the routing rule cache of the second-level cache using the target service name as the key. A version selection load balancer is constructed based on the version canary release rules and load balancing strategies in the routing rules, and the version selection load balancer is added to the version selection load balancer cache. The version selection load balancer is invoked to obtain the target service version corresponding to the microservice instance call request. In this embodiment, the version selection load balancer corresponding to the first request feature value K1 is obtained from the version load balancer cache in the first-level cache. If the version selection load balancer corresponding to the first request feature value K1 is not successfully obtained, the version selection load balancer is constructed.

[0042] Specifically, using the target service name D1 as the key, the routing rule Rt1 for the target service name D1 is retrieved from the routing rule cache of the second-level cache. If the routing rule Rt1 for the target service name D1 is not successfully retrieved, an error message is constructed and returned to the calling end, and the system waits for the next microservice instance call request.

[0043] If the routing rule Rt1 for the target service name D1 is successfully obtained, a version selection load balancer L1 is constructed based on the version canary release rule and load balancing strategy (round-robin or consistent hashing) in the routing rule Rt1, and the constructed version selection load balancer L1 is added to the version selection load balancer cache. The constructed version selection load balancer is called to obtain the target service version V1 corresponding to this microservice instance call request, thus completing the target service version selection logic.

[0044] Step S20: If the version selection load balancer corresponding to the first request feature value is hit in the first-level cache of the multi-level caching module, then the version selection load balancer is called to obtain the target service version corresponding to the microservice instance call request. In this embodiment, the version selection load balancer corresponding to the first request feature value K1 is obtained from the version load balancer cache of the first-level cache. If the version selection load balancer corresponding to the first request feature value K1 is successfully obtained, the version selection load balancer is called to obtain the target service version V1 corresponding to this microservice instance call request, and the target service version selection logic is completed.

[0045] Step S30: Obtain a second request feature value based on the first request feature value and the target service version; In this embodiment, the target service routing instance selection logic used in this request is executed. The first request feature value K1 and the target service version V1 are combined to generate the read routing selection load balancer key value K2, which is also the second request feature value.

[0046] Furthermore, in one embodiment, after step S30, the method further includes: If the routing load balancer corresponding to the second request feature value is not hit in the first-level cache of the multi-level caching module, then the service instance list of the target service name is obtained from the service list cache of the second-level cache using the target service name as the key. Filter the list of service instances with the target service name to select the list of instances that match the target service version, build a route selection load balancer, and add the route selection load balancer to the route selection load balancer cache; The routing load balancer is invoked to obtain the target service instance corresponding to the microservice instance call request.

[0047] In this embodiment, the routing load balancer corresponding to the second request feature value K2 is obtained from the routing load balancer cache of the first-level cache. If the routing load balancer corresponding to the second request feature value K2 is not successfully obtained, the routing load balancer is constructed.

[0048] The specific process for building a load balancer for routing selection is as follows.

[0049] Using the target service name D1 as the key, retrieve the list of service instances for the target service name D1 from the service list cache in the second-level cache. If the list of service instances for the target service name D1 is not successfully retrieved, construct an error message and return it to the calling end, waiting for the next microservice instance call request.

[0050] If the list of service instances for the target service name D1 is successfully obtained, the list of instances matching the target service version V1 is filtered out, and a routing load balancer L2 is constructed and added to the routing load balancer cache.

[0051] The constructed routing load balancer is invoked to obtain the target service instance corresponding to this microservice instance call request, and the target service routing instance selection logic is completed, thereby completing the request forwarding.

[0052] It should be noted that the load balancers constructed in this application embodiment will all exist in the first-level cache.

[0053] Step S40: If the routing load balancer corresponding to the second request feature value is hit in the first-level cache of the multi-level caching module, then the routing load balancer is invoked to obtain the target service instance corresponding to the microservice instance call request.

[0054] In this embodiment, the routing load balancer corresponding to the second request feature value K2 is retrieved from the routing load balancer cache of the first-level cache. If the routing load balancer corresponding to the second request feature value K2 is successfully retrieved, the routing load balancer is invoked to obtain the target service instance corresponding to this microservice instance call request, and the target service routing instance selection logic is completed, thereby completing the request forwarding.

[0055] In this embodiment, based on the lifecycle management of the service list cache and routing rule cache in the second-level cache completed by the data monitoring module of the routing client, the computing engine module of the routing client, when processing a single request, directly retrieves information from the second-level cache when constructing the route selection load balancer cache and version selection load balancer cache in the first-level cache according to the registration information and routing rules of the target service. This avoids frequent operations with the registration center and configuration center, reducing system resource consumption. Simultaneously, for continuous requests to the same request source and destination service, this embodiment directly retrieves the load balancer corresponding to the request from the first-level cache through the computing engine module of the routing client, executes the selection method embedded in the load balancer, and directly returns the next selected instance. This avoids complex calculation processes, shortens the request routing processing time, and improves system efficiency.

[0056] In other words, the routing client internally monitors changes in service instance information in the registry center and routing rules stored in the configuration center through a data listening module. Upon detecting a change, it triggers a synchronous update of the second-level cache in the multi-level caching module, providing basic data for the computing engine module when building the load balancer. The computing engine is responsible for the initialization and use of the load balancer in the first-level cache of the multi-level caching module. During request processing, it first retrieves the load balancer from the cache based on a specific key-value pair. If the load balancer is not found, it initializes the load balancer using the service instance list and service routing rules stored in the second-level cache and places it in the first-level cache of the multi-level caching module.

[0057] Under the same judgment conditions (no change in the registered instance list, no change in service routing rules), subsequent request processing can directly obtain the corresponding load balancer through the first-level cache, execute the load balancer's embedded selection method to directly return the next selected instance, avoiding complex calculation processes. By pre-emptively and cached the time-consuming calculations, the corresponding load balancer instance method is directly called during request processing, thereby achieving efficient routing processing.

[0058] It should be noted that this embodiment uses a two-level cache (instance list cache and routing rule cache) to cache the original instance list obtained from the registry center and the routing rules obtained from the configuration center, and a first-level cache (load balancer cache) to map request feature values ​​to load balancers, achieving efficient service routing. Compared with the prior art, this application directly stores the load balancer used in routing decisions in the first-level cache. During request processing, only the load balancer matching the request feature values ​​needs to be executed, eliminating the need for repeated rule calculation and matching, thereby improving the efficiency of system routing decisions and reducing system resource consumption.

[0059] In this embodiment, when the computing engine module processes a microservice instance call request, it parses the request to obtain a first request feature value. If the version selection load balancer corresponding to the first request feature value is found in the first-level cache of the multi-level caching module, the version selection load balancer is invoked to obtain the target service version corresponding to the microservice instance call request. A second request feature value is obtained based on the first request feature value and the target service version. If the routing selection load balancer corresponding to the second request feature value is found in the first-level cache of the multi-level caching module, the routing selection load balancer is invoked to obtain the target service instance corresponding to the microservice instance call request. In the implementation of the routing client, the multi-level caching module not only provides a service instance list and routing rule cache, but also, combined with the operation of the data monitoring module, avoids frequent operations between the routing client and the registration center and configuration center, reducing system resource consumption. Furthermore, by providing load balancer storage, the computing engine module can retrieve the corresponding load balancer from the first-level cache when processing request routing. The computing engine module directly returns the next selected instance by executing the selection method embedded in the load balancer, avoiding complex calculation processes, shortening the request routing processing time, and improving system efficiency. Meanwhile, the key-value pairs corresponding to the load balancer cache entries contain version information representing the current snapshots of the registry center and configuration center. In scenarios where services change frequently, this ensures the accuracy of cache selection and guarantees the efficiency and accuracy of microservice instance routing.

[0060] This embodiment solves the inherent technical problems of low routing decision efficiency, excessive system resource consumption, and inability to effectively utilize cache while ensuring correctness when dealing with advanced routing scenarios such as multi-version and canary deployments.

[0061] Based on the same inventive concept, embodiments of this application also provide a microservice instance routing device based on multi-level caching.

[0062] In one embodiment, reference is made to Figure 5 , Figure 5 This is a functional module diagram of an embodiment of the microservice instance routing device based on multi-level caching in this application. Figure 5 As shown, the microservice instance routing device based on multi-level caching includes: The first request feature value acquisition module 10 is configured to parse the microservice instance call request and obtain the first request feature value when the computing engine module processes the microservice instance call request. The target service version acquisition module 20 is configured to call the version selection load balancer to obtain the target service version corresponding to the microservice instance call request if the version selection load balancer corresponding to the first request feature value is hit in the first-level cache of the multi-level cache module. The second request feature value acquisition module 30 is configured to obtain a second request feature value based on the first request feature value and the target service version; The target service instance acquisition module 40 is configured to call the routing load balancer to obtain the target service instance corresponding to the microservice instance call request if the second request feature value is hit in the first-level cache of the multi-level caching module.

[0063] Optionally, in one embodiment, the microservice instance routing device based on multi-level caching further includes a data acquisition module, configured to: Establish and maintain the connection between the data listening module of the routing client and the registration center and / or configuration center; Retrieve all service registration information from the registry center, using the service name as the key and the service instance information as the value, and initialize the instance list cache in the second-level cache. Retrieve all service routing rule configurations from the configuration center, using the configuration item name as the key and the configuration item content as the value, and initialize the routing rule cache in the second-level cache. The data update module is configured to: When the service instance information of the registration center and / or the routing rules stored in the configuration center change, the second-level cache in the multi-level caching module is synchronously updated.

[0064] Optionally, in one embodiment, the data update module is specifically configured to: When the service instance information of the registry center and / or the routing rules stored in the configuration center change, receive incremental change pushes from the registry center and / or the configuration center, and parse the changed data; If the changed data is successfully parsed, the state snapshot of the registry center in the multi-level cache is updated, and the parsing results of the changed data are analyzed to obtain the analysis results; Based on the analysis results, the second-level cache synchronization update strategy in the corresponding multi-level cache module is triggered.

[0065] Optionally, in one embodiment, the data update module is specifically configured to: If the analysis result is: the changed data is a new service, then create a new cache item with the new service name as the key and the list of instances of the new service as the value, and insert it into the instance list cache in the second-level cache; If the analysis result is: the changed data is due to a service instance change, then update the cache in the instance list cache with the service name as the key according to the changed content, and update the service instance list to the latest value; If the analysis result indicates that the changed data is due to the service being deleted, then clear the cache in the instance list cache that uses the service name as the key.

[0066] Optionally, in one embodiment, the first request feature value acquisition module 10 is configured to: The microservice instance call request is parsed. If the parsing is successful, the state snapshots of the registry center and the configuration center are read from the cache. Obtain the source name and target service name of the microservice instance call request from the parsing results; Based on the state snapshots of the registry center, the state snapshots of the configuration center, and the source and target service names of the microservice instance call requests, the first request characteristic value for reading the version to select the load balancer is generated.

[0067] Optionally, in one embodiment, the target service version acquisition module 20 is further configured to: If the version of the first request feature value is not selected in the first-level cache of the multi-level caching module, the routing rule of the target service name is obtained from the routing rule cache of the second-level cache using the target service name as the key. A version selection load balancer is constructed based on the version canary release rules and load balancing strategies in the routing rules, and the version selection load balancer is added to the version selection load balancer cache. The load balancer is selected by calling the version to obtain the target service version corresponding to the microservice instance call request.

[0068] Optionally, in one embodiment, the target service instance acquisition module 40 is further configured to: If the routing load balancer corresponding to the second request feature value is not hit in the first-level cache of the multi-level caching module, then the service instance list of the target service name is obtained from the service list cache of the second-level cache using the target service name as the key. Filter the list of service instances with the target service name to select the list of instances that match the target service version, build a route selection load balancer, and add the route selection load balancer to the route selection load balancer cache; The routing load balancer is invoked to obtain the target service instance corresponding to the microservice instance call request.

[0069] The functions of each module in the above-mentioned microservice instance routing device based on multi-level caching correspond to the steps in the above-mentioned microservice instance routing method embodiment based on multi-level caching, and their functions and implementation processes will not be described in detail here.

[0070] Based on the same inventive concept, embodiments of this application also provide an electronic device, the structure of which is as follows: Figure 6As shown, it includes: a memory and a processor, wherein the processor is used to read and execute the computer program stored in the memory to implement the aforementioned microservice instance routing method based on multi-level caching.

[0071] Based on the same inventive concept, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, implement the aforementioned microservice instance routing method based on multi-level caching.

[0072] Finally, it should be noted that while some processes described in the embodiments of this application include multiple operations or steps that appear in a specific order, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0073] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A microservice instance routing method based on multi-level caching, characterized in that, The method includes: When the computing engine module processes a microservice instance call request, it parses the microservice instance call request to obtain the first request feature value. If the version selection load balancer corresponding to the first request feature value is hit in the first-level cache of the multi-level caching module, then the version selection load balancer is called to obtain the target service version corresponding to the microservice instance call request. A second request feature value is obtained based on the first request feature value and the target service version; If the routing load balancer corresponding to the second request feature value is hit in the first-level cache of the multi-level caching module, then the routing load balancer is invoked to obtain the target service instance corresponding to the microservice instance call request.

2. The method according to claim 1, characterized in that, Before parsing the microservice instance call request and obtaining the first request feature value when the computing engine module processes the microservice instance call request, the process includes: Establish and maintain the connection between the data listening module of the routing client and the registration center and / or configuration center; Retrieve all service registration information from the registry center, using the service name as the key and the service instance information as the value, and initialize the instance list cache in the second-level cache. Retrieve all service routing rule configurations from the configuration center, using the configuration item name as the key and the configuration item content as the value, and initialize the routing rule cache in the second-level cache. When the service instance information of the registration center and / or the routing rules stored in the configuration center change, the second-level cache in the multi-level caching module is synchronously updated.

3. The method according to claim 2, characterized in that, When the service instance information of the registration center and / or the routing rules stored in the configuration center change, the second-level cache in the multi-level caching module is triggered to synchronize and update, including: When the service instance information of the registry center and / or the routing rules stored in the configuration center change, receive incremental change pushes from the registry center and / or the configuration center, and parse the changed data; If the changed data is successfully parsed, the state snapshot of the registry center in the multi-level cache is updated, and the parsing results of the changed data are analyzed to obtain the analysis results; Based on the analysis results, the second-level cache synchronization update strategy in the corresponding multi-level cache module is triggered.

4. The method according to claim 3, characterized in that, Based on the analysis results, the strategy for triggering the second-level cache synchronization update in the corresponding multi-level caching module includes: If the analysis result is: the changed data is a new service, then create a new cache item with the new service name as the key and the list of instances of the new service as the value, and insert it into the instance list cache in the second-level cache; If the analysis result is that the changed data is due to a service instance change, then update the cache in the instance list cache with the service name as the key according to the changed content, and update the service instance list to the latest value. If the analysis result indicates that the changed data is due to the service being deleted, then clear the cache in the instance list cache that uses the service name as the key.

5. The method according to claim 1, characterized in that, The parsing of the microservice instance call request yields the first request feature value, including: The microservice instance call request is parsed. If the parsing is successful, the state snapshots of the registry center and the configuration center are read from the cache. Obtain the source name and target service name of the microservice instance call request from the parsing results; Based on the state snapshots of the registry center, the state snapshots of the configuration center, and the source and target service names of the microservice instance call requests, the first request characteristic value for reading the version to select the load balancer is generated.

6. The method according to claim 4 or 5, characterized in that, After parsing the microservice instance call request to obtain the first request feature value, the process includes: If the version of the first request feature value is not selected in the first-level cache of the multi-level caching module, the routing rule of the target service name is obtained from the routing rule cache of the second-level cache using the target service name as the key. A version selection load balancer is constructed based on the version canary release rules and load balancing strategies in the routing rules, and the version selection load balancer is added to the version selection load balancer cache. The load balancer is selected by calling the version to obtain the target service version corresponding to the microservice instance call request.

7. The method according to claim 4 or 5, characterized in that, After obtaining the second request feature value based on the first request feature value and the target service version, the process includes: If the routing load balancer corresponding to the second request feature value is not hit in the first-level cache of the multi-level caching module, then the service instance list of the target service name is obtained from the service list cache of the second-level cache using the target service name as the key. Filter the list of service instances with the target service name to select the list of instances that match the target service version, build a route selection load balancer, and add the route selection load balancer to the route selection load balancer cache; The routing load balancer is invoked to obtain the target service instance corresponding to the microservice instance call request.

8. A microservice instance routing device based on multi-level caching, characterized in that, The device includes: The first request feature value acquisition module is configured to parse the microservice instance call request and obtain the first request feature value when the computing engine module processes the microservice instance call request. The target service version acquisition module is configured to call the version selection load balancer if the version selection load balancer corresponding to the first request feature value is hit in the first-level cache of the multi-level caching module, and obtain the target service version corresponding to the microservice instance call request. The second request feature value acquisition module is configured to obtain a second request feature value based on the first request feature value and the target service version; The target service instance acquisition module is configured to call the routing load balancer corresponding to the second request feature value in the first-level cache of the multi-level caching module if the routing load balancer is hit, and then obtain the target service instance corresponding to the microservice instance call request.

9. An electronic device, characterized in that, include: Memory, processor; The processor is configured to read and execute the computer program stored in the memory to implement the steps of the microservice instance routing method based on multi-level caching as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed, implement the steps of the microservice instance routing method based on multi-level caching as described in any one of claims 1-7.

Images