Micro-service test environment optimization routing method and system based on intelligent flow identification

Abstract

The invention discloses a micro-service test environment optimization routing method and system based on intelligent flow identification, and the method comprises the steps: distributing a unique service ID for different versions of each service, and enabling the service ID to be transmitted among a plurality of services along with a request; service versions needing to be modified and tested are deployed in the dynamic environment, and unmodified service versions are deployed in the stable environment; when each service is started, information of the service is registered to a service registration center, and the service registration center maintains a service instance list which is updated in real time; and when the service calling party is started or runs, the latest instance information of the dependent service is inquired from the service registration center through a service discovery mechanism, and a request is forwarded to the instance of the corresponding service version. According to the method and the system, the request is accurately routed to the service version matched with the current test requirement in the micro-service test environment through the service ID transparent transmission and dynamic routing mechanism, so that the test efficiency is optimized, and the resource waste is reduced.

Description

Technical Field

[0001] The present invention relates to the field of microservice testing environment, and in particular to a method and system for optimizing routing of a microservice testing environment based on intelligent traffic identification. Background Art

[0002] In a microservice testing environment, since different development branches work in parallel, the logic on each node is often different, which will cause the following problems:

[0003] (1) The complex dependencies of the microservice architecture make it difficult to accurately route requests.

[0004] Microservice architectures typically split a single application into multiple independent services, each with its own independent logic and functionality. This architecture complicates the dependencies between services. In a test environment, especially when multiple development branches are working in parallel, the service versions running on each node are often different, which makes it difficult for requests to be accurately routed to the target version when passing through the service link. Traditional routing methods often cannot dynamically identify different versions of services, especially when multiple service nodes interact in complex links, which can easily cause requests to be routed to the wrong service version, leading to inaccurate test results.

[0005] (2) Traditional testing environments consume huge resources, resulting in inefficiency and waste.

[0006] Traditional test environments are usually physically separated, that is, a complete set of independent test environments is provided for each test requirement. This means that every time a new version of the test is required, all microservices involved must be redeployed, including those that have not been modified in this test. Although this method can ensure that requests are accurately routed to the target service, it has a serious problem of resource waste, especially in scenarios where a large number of services need to share resources, the cost of repeated deployment is very high. In addition, the deployment time of the entire test environment is also long, and testing must wait until all service nodes are deployed before starting, which greatly reduces the test speed and efficiency.

[0007] (3) The governance of microservice versions is complex, especially in test environments where it is difficult to manage dependencies.

[0008] A key challenge in microservice architecture is service version management and dependency governance. In the test environment, different service branches may depend on different versions of other services. For example, service A may depend on a specific version of service B, and service B may depend on multiple versions of service C. As services are continuously iterated and updated, the version dependencies between these services become more and more complex. Without effective version management and dependency governance mechanisms, service calls in the test environment may fail or even cause unpredictable failures.

[0009] Traditional dependency management usually relies on manual configuration and management, which is not only error-prone, but also increases the complexity and uncertainty of testing. Especially when multiple branches are developed in parallel, manual maintenance of dependencies is almost impossible. Summary of the invention

[0010] In order to solve the complex service dependency and routing problems in multi-branch parallel development, the present invention provides a microservice test environment optimization routing method and system based on intelligent traffic identification. Through service ID transparent transmission and dynamic routing mechanism, requests are accurately routed to the service version that matches the current test requirements in the microservice test environment, thereby optimizing test efficiency, reducing resource waste, and solving the above problems.

[0011] To achieve the above object, the present invention adopts the following technical solutions:

[0012] In one embodiment of the present invention, a method for optimizing routing in a microservice test environment based on intelligent traffic identification is proposed, and the method includes:

[0013] Assign a unique service ID to each version of a service, which is passed between multiple services as requests occur.

[0014] Dynamic environments deploy service versions that need to be modified and tested, and stable environments deploy unchanged service versions;

[0015] When each service is started, it registers its information with the service registration center, which maintains a real-time updated list of service instances.

[0016] When the service caller starts or runs, it initiates a dependency query to the service registry through the service discovery mechanism, obtains the latest version of the dependent service and its instance information, and forwards the request to the instance of the corresponding service version.

[0017] Furthermore, when a request enters the test environment, the traffic router routes the request to a corresponding service version in the dynamic environment or the stable environment according to the service ID.

[0018] Furthermore, in the service registry, when multiple versions of the same service exist at the same time, the appropriate dependent service version is dynamically selected by carrying the version number of the dependent service in the request, the version selection strategy predefined by the service registry, the label mechanism, and the version routing of the API gateway.

[0019] Furthermore, when the version of a dependent service changes, the dependency chain is dynamically adjusted through the following steps to ensure that new calls point to the correct service version:

[0020] The service registration center monitors the registration status of service version instances in real time;

[0021] When the service caller initiates a dependency query, the appropriate version is automatically selected based on the request content or the preset version selection strategy;

[0022] Through the service discovery mechanism, the dependency chain is automatically adjusted according to the version selection strategy;

[0023] The service registration center automatically detects the status of service version instances through a health check mechanism and automatically switches to a healthy service version instance when a failure occurs.

[0024] In one embodiment of the present invention, a microservice test environment optimization routing system based on intelligent traffic identification is also proposed, and the system includes:

[0025] A service ID allocation module is used to allocate a unique service ID to each different version of a service. The service ID is passed between multiple services along with the request.

[0026] The test environment module is used to deploy service versions that need to be modified and tested in dynamic environments, and to deploy unchanged service versions in stable environments;

[0027] The automated dependency management module is used for each service to register its own information with the service registration center when it is started. The service registration center maintains a real-time updated list of service instances. When the service caller is started or running, it initiates a dependency query to the service registration center through the service discovery mechanism to obtain the latest version of the dependent service and its instance information, and forwards the request to the instance of the corresponding service version.

[0028] Furthermore, when a request enters the test environment, the traffic router routes the request to a corresponding service version in the dynamic environment or the stable environment according to the service ID.

[0029] Furthermore, in the service registry, when multiple versions of the same service exist at the same time, the appropriate dependent service version is dynamically selected by carrying the version number of the dependent service in the request, the version selection strategy predefined by the service registry, the label mechanism, and the version routing of the API gateway.

[0030] Furthermore, when the version of a dependent service changes, the dependency chain is dynamically adjusted through the following steps to ensure that new calls point to the correct service version:

[0031] The service registration center monitors the registration status of service version instances in real time;

[0032] When the service caller initiates a dependency query, the appropriate version is automatically selected based on the request content or the preset version selection strategy;

[0033] Through the service discovery mechanism, the dependency chain is automatically adjusted according to the version selection strategy;

[0034] The service registration center automatically detects the status of service version instances through a health check mechanism and automatically switches to a healthy service version instance when a failure occurs.

[0035] In one embodiment of the present invention, a computer device is also proposed, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the aforementioned microservice test environment optimized routing based on intelligent traffic identification is implemented.

[0036] In one embodiment of the present invention, a computer-readable storage medium is further proposed, which stores a computer program for executing optimized routing in a microservice test environment based on intelligent traffic identification.

[0037] Beneficial effects:

[0038] 1. The present invention realizes the automation of dependency management between services through service discovery mechanism and dynamic routing strategy. The service caller does not need to manually configure the version and address of the dependent service, and the system can dynamically discover and call the correct service version.

[0039] 2. The present invention supports the coexistence of multiple versions of services, and uses multiple methods such as version number, label mechanism, version routing of API gateway, etc. to dynamically select the appropriate service version to ensure flexible calling and version compatibility of services in different environments.

[0040] 3. Through the health check mechanism of the service registration center, the system of the present invention can automatically detect the status of the service instance and automatically switch to the healthy instance when the service fails, thereby achieving high availability and self-healing capability. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 It is a schematic diagram of the process of optimizing routing in a microservice test environment based on intelligent traffic identification of the present invention;

[0042] Figure 2 It is a schematic diagram of the structure of the microservice test environment optimization routing system based on intelligent traffic identification of the present invention;

[0043] Figure 3 It is a schematic diagram of the computer device structure of the present invention. DETAILED DESCRIPTION

[0044] The principles and spirit of the present invention will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0045] Those skilled in the art will appreciate that the embodiments of the present invention may be implemented as a system, system, device, method or computer program product. Therefore, the present disclosure may be implemented in the following forms, namely: complete hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0046] According to an implementation of the present invention, a method for optimizing routing in a microservice test environment based on intelligent traffic identification is proposed. Through service ID pass-through and a dynamic routing mechanism, requests are accurately routed to a service version that matches the current test requirements in a microservice test environment, thereby optimizing test efficiency, reducing resource waste, and solving complex service dependencies and routing problems in multi-branch parallel development.

[0047] The principle and spirit of the present invention are explained in detail below with reference to several representative embodiments of the present invention.

[0048] Figure 1 This is a schematic diagram of the process flow of the microservice test environment optimization routing method based on intelligent traffic identification of the present invention. Figure 1 As shown, the method includes:

[0049] (1) The client initiates a request, which includes a Service-ID, indicating that it is requesting a specific service.

[0050] (2) The traffic router performs routing based on the Service-ID and determines whether the service exists in the dynamic environment.

[0051] (3) If the service exists in the dynamic environment, enter version v1.1 of the order service. The service registry is used to register services and perform automatic discovery of dependency management. Version management determines whether to select the service version in the dynamic environment or the service version in the stable environment. The service health check monitors the health of the service. If the service is unhealthy, it switches to the service version in the stable environment.

[0052] (4) Once the service is determined, it enters the order service processing phase. The order service will process the request. If the service in the dynamic environment is not available or the service cannot be found in the dynamic environment, the traffic will be routed to the stable environment.

[0053] (5) The order service calls the payment service and inventory service.

[0054] (6) Payment services will use payment services v1.0 in the stable environment for payment processing.

[0055] (7) The order service calls the inventory service to perform inventory checks and obtains inventory data from the inventory service v1.0 in the stable environment.

[0056] (8) Through the service discovery mechanism, dependency management will automatically discover and register the necessary dependencies.

[0057] We will make changes in the following aspects to solve the complex service dependency and routing problems in multi-branch parallel development:

[0058] (1) Automated traffic routing based on service ID.

[0059] Each service branch is assigned a unique service ID, which is passed between microservices along with the request. The traffic router dynamically identifies the versions of different services based on the service ID and accurately routes the request to the corresponding service version. No matter how complex the service link is, the system can ensure that the request flows to the correct version.

[0060] (2) Combining dynamic environment with stable environment.

[0061] The test environment only deploys services that need to be modified and tested, and the unmodified services rely on the public stable environment. This approach reduces resource consumption, avoids the situation of repeatedly deploying the entire service set in the traditional physically isolated environment, and significantly improves testing efficiency.

[0062] (3) Service ID transmission and automatic dependency management.

[0063] The system automatically tracks and manages the dependencies between different services through service IDs. The dependencies of each service are parsed and managed based on the service ID, ensuring that when a request calls a dependent service, it can automatically match the correct service version without manually configuring complex dependencies.

[0064] It should be noted that, although the operations of the method of the present invention are described in a specific order in the above embodiments and the accompanying drawings, this does not require or imply that the operations must be performed in the specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0065] In order to explain the above-mentioned microservice test environment optimization routing method based on intelligent traffic identification more clearly, a specific embodiment is used for illustration below. However, it is worth noting that this embodiment is only for better illustrating the present invention and does not constitute an improper limitation to the present invention.

[0066] The process of implementing the microservice test environment optimization routing method based on intelligent traffic identification is as follows:

[0067] 1. Automated traffic routing based on service ID

[0068] Implementation process:

[0069] (1) Definition and allocation of service ID

[0070] Each different version of a service is assigned a unique service ID. This service ID includes not only the name of the service, but also a version number to distinguish different versions. The purpose of this is to let the system know which version of the service the current request needs to access.

[0071] For example:

[0072] Service ID of Order Service v1.0: order-service-v1.0

[0073] Service ID of Order Service v1.1: order-service-v1.1

[0074] Inventory Service v1.0 service ID: inventory-service-v1.0

[0075] (2) Service ID transparent transmission in the request

[0076] In a microservice architecture, requests are usually passed between multiple services. To ensure that the request can always access the correct service version in the call chain, the message header of each request needs to carry this service ID.

[0077] When the client sends a request, the service ID will be included as part of the request message (usually in the HTTP request header), such as:

[0078]

[0079]

[0080] The Service-ID in this request header tells the system and traffic routers that this request should be routed to OrderService v1.1.

[0081] (3) The role of traffic routers

[0082] A traffic router (usually an API gateway or a specialized traffic management tool such as NGINX, Kong, or Envoy) is a component in the network that is specifically responsible for forwarding requests. Its main function is to decide which service instance to forward the request to based on the content of the request (such as the service ID in the request header).

[0083] How it works: When a traffic router receives a request, it reads the Service-ID in the request header and looks up the instance of the corresponding service version based on the Service-ID. The traffic router forwards the request to the service version instance running on the correct server.

[0084] 2. Combination of dynamic environment and stable environment

[0085] In order to improve the efficiency of the test environment and reduce resource waste, the solution introduces a combination of dynamic environment and stable environment. Specifically, the dynamic environment deploys the new version of the service that needs to be tested, while the unchanged services rely on the public stable environment. This mechanism allows the test to verify only the new version of the service without redeploying all unchanged services, greatly reducing resource consumption and deployment time.

[0086] (1) Concept and configuration of stable environment

[0087] The stable environment deploys service versions that have passed testing and have not changed. These services are shared by multiple test tasks and are not frequently updated or redeployed. The stable environment ensures the stability of regular services and reduces repeated deployment and maintenance.

[0088] Function:

[0089] Run stable, unmodified versions of services.

[0090] Shared among multiple test tasks to avoid resource waste.

[0091] Provides basic service dependencies and supports new services in dynamic environments.

[0092] Configuration method:

[0093] Services in a stable environment are deployed persistently, such as Order Service v1.0, Inventory Service v1.0, and Payment Service v1.0.

[0094] These service versions usually do not need to be changed during multiple testing processes, so they can run for a long time without having to be redeployed every time.

[0095] Example data:

[0096] Services in a stable environment

[0097] Order Service v1.0 (running on server 10.0.0.2:8080)

[0098] Inventory Service v1.0 (running on server 10.0.0.3:8080)

[0099] Payment Service v1.0 (running on server 10.0.0.4:8080)

[0100] (2) Concept and configuration of dynamic environment

[0101] The dynamic environment is used to deploy new versions of services that are being developed or need to be tested. These services are the targets that testers or developers need to verify, so they are dynamically loaded, run, and tested in the test environment. The dynamic environment only contains services that need to be modified and tested, and other unchanged services rely on the stable environment.

[0102] Function:

[0103] Services in a dynamic environment are started or stopped dynamically based on current testing requirements.

[0104] The dynamic environment is used to verify whether the latest service version is compatible with the existing system or whether it can achieve the expected functions.

[0105] Avoid repeated deployment of unchanged services, saving resources and time.

[0106] Configuration method:

[0107] Deploy only the service versions that need to be tested, such as Order Service v1.1.

[0108] Dynamic environments are created dynamically based on demand at the beginning of each test and release resources after the test is completed.

[0109] Example data:

[0110] Services in a dynamic environment

[0111] Order Service v1.1 (running on server 10.0.0.5:8080).

[0112] (3) Concept and configuration of dynamic environment

[0113] During the test, the traffic router is responsible for distributing requests to the correct service version in the dynamic environment or stable environment based on the service ID. The following is the specific routing strategy:

[0114] Requests are routed to the dynamic environment first: When a request enters the test environment, the traffic router will first check whether the corresponding service version is running in the dynamic environment. If the test version of the service exists in the dynamic environment, the request will be routed to the service version in the dynamic environment.

[0115] If there is no test version of the service in the dynamic environment, route to the stable environment: For service versions that have not been modified or are not running in the dynamic environment, the traffic router forwards requests to the corresponding service version in the stable environment.

[0116] This combination of dynamic and stable environments ensures that only new versions of services are tested, while unchanged service versions continue to rely on the stable environment, avoiding unnecessary redeployment.

[0117] Example data:

[0118] Use of dynamic environment during testing:

[0119] Assume that Order Service v1.1 is being tested and it is running in a dynamic environment.

[0120] The traffic router receives a request to create an order. It first reads the Service-ID in the request header and finds that the request points to order-service-v1.1.

[0121] The traffic router will preferentially route the request to Order Service v1.1 in the dynamic environment, with the server address being http: / / 10.0.0.5:8080.

[0122] Service dependencies for a stable environment:

[0123] After Order Service v1.1 processes the order, it needs to check the inventory, which requires calling InventoryService.

[0124] Because the Inventory Service has not been modified and is not running in a dynamic environment, the traffic router forwards the call request to Inventory Service v1.0 in the stable environment at http: / / 10.0.0.3:8080.

[0125] Payment service call:

[0126] Next, after the order is completed, the payment request needs to be processed, and Order Service v1.1 will initiate a call to PaymentService.

[0127] Again, the payment service has not been modified, so the request is forwarded to Payment Service v1.0 in the stable environment at http: / / 10.0.0.4:8080.

[0128] (4) Resource conservation and efficient testing

[0129] By combining this dynamic environment with a stable environment, the system can avoid redeploying unchanged services during testing, thus significantly saving resources and shortening test preparation time. Testers only need to focus on testing the currently modified services without having to worry about other already stable services, which improves testing efficiency.

[0130] Resource conservation: Because only services in the dynamic environment are temporarily started, other unchanged services continue to run in the stable environment, avoiding repeated redeployment.

[0131] Improve test speed: Since the test environment only needs to load the changed services, the test starts faster and reduces the environment preparation time.

[0132] Reduce conflicts: Different test tasks can share a stable environment, ensuring that when multiple teams test in parallel in different dynamic environments, unmodified services remain stable and do not interfere with each other.

[0133] 3. Automated dependency management

[0134] Automated dependency management aims to ensure that each microservice can dynamically and automatically find other services it depends on at runtime, especially when multiple versions of service instances exist at the same time. Through dynamic dependency resolution, service version management, automatic rollback and other strategies, the system can automatically select the correct dependent service and automatically adjust the call chain according to changes in service versions to ensure the stability and flexibility of the service.

[0135] (1) Dynamic service registration and automatic dependency discovery

[0136] Automatic service registration: Each microservice will automatically register with the service registry (such as Eureka, Consul, Zookeeper, etc.) when it starts. The service will register its service name, version number, IP address, port number and other information with the service registry. The service registry maintains a real-time updated list of service instances.

[0137] Dynamic service discovery: When a service caller (such as Order Service) is started or running, it will query the service registry for the latest instance information of the dependent service (such as Inventory Service) through the service discovery mechanism, including its version number and address. In this way, Order Service does not need to manually configure the dependent service version or address in advance, but dynamically discovers the dependent services based on the service name or label at runtime.

[0138] The service registry can know the dependent service version and instance information. The service registry maintains a real-time service instance list. Each service will register its own information to the service registry when it starts. The Order Service can obtain all available Inventory Service instances and their version numbers and addresses by querying the service name.

[0139] Example data:

[0140] When Order Service v1.1 is started, it automatically registers its own information (such as order-service-v1.1) with the service discovery center, and obtains the latest instance information of Inventory Service v1.0 and Payment Service v1.0 on which it depends through the query mechanism.

[0141] The service discovery center returns the query results:

[0142] Inventory Service v1.0: Running at http: / / 10.0.0.3:8080

[0143] Payment Service v1.0: running at http: / / 10.0.0.4:8080

[0144] This mechanism ensures that each service can dynamically discover and resolve the services it depends on at runtime without the need to hard-code dependency information in advance.

[0145] (2) Selection and management of multi-version services

[0146] In the service registry, there may be multiple versions of the same service (such as Inventory Service v1.0 and Inventory Service v1.1). The system dynamically selects the appropriate version of the dependent service in the following ways:

[0147] There are several ways to achieve this:

[0148] A. Request to carry version number

[0149] The service caller (referring to the service that initiates the request, for example, when processing an order, the order service may need to call the inventory service, then the order service is the caller because it initiates the request to the inventory service, such as Order Service) can carry the version number of the dependent service in the request, and the service discovery mechanism will query and return the appropriate service version instance based on the version number. This is an explicit version call to ensure that the specified service version is called.

[0150] B. Version selection strategy of the service registry

[0151] If the request does not specify a version number, the service registry can automatically select the appropriate version based on predefined strategies. Common strategies include:

[0152] Return to the latest stable version: Give priority to the latest stable version (such as Inventory Service v1.1).

[0153] Compatibility priority strategy: Automatically match compatible dependent service versions (such as Inventory Service v1.0) based on the version of the service caller (such as Order Service v1.1).

[0154] C. Service discovery combined with tagging mechanism

[0155] The tagging mechanism is to distinguish service instances of different versions, environments, and specific functions by tagging service version instances. This mechanism can help callers accurately query, locate, and call the appropriate service version based on tags, especially in different environments (such as production environment, test environment) or different versions (such as v1.0, v1.1).

[0156] Implementation process:

[0157] a. Tag the service instance when registering it:

[0158] When a service starts, it registers its own information (such as service name, version number, IP address, port number, etc.) to the service registration center.

[0159] When registering, you can add tags to the service instance. These tags can include:

[0160] Environment labels: such as prod (production environment), dev (development environment), test (test environment), etc.

[0161] Version label: such as v1.0, v1.1.

[0162] Feature tags: such as fast-response, high-priority, etc.

[0163] b. The caller uses tags when querying:

[0164] When the Order Service needs to call the Inventory Service, it can use tags to accurately query the required version and environment. For example, the Order Service can specify tags when querying:

[0165] Environment: prod;

[0166] Version: v1.0;

[0167] The service registration center returns the Inventory Service instance that meets the conditions based on the passed-in tags.

[0168] c. Tag matching mechanism of service registration center:

[0169] The service registry maintains the label information of each service instance. When the Order Service issues a query with a label, the service registry will filter all registered service instances and match the most appropriate service instance based on the label. For example, if the Order Service needs to call the v1.0 version of the Inventory Service in the prod environment, the service registry will return the Inventory Service v1.0 instance that meets the condition.

[0170] d. Dynamic label support:

[0171] In some scenarios, service labels may need to be adjusted dynamically. For example, in a test environment, a new version of a service may be gradually promoted to a production environment. With the dynamic label update mechanism, service instance labels can be changed at runtime to adapt to different business scenarios.

[0172] Example data:

[0173] Tags during registration:

[0174] The label when registering Inventory Service v1.0 is

[0175] {

[0176] "environment":"prod",

[0177] "version":"v1.0"

[0178] }

[0179] Inventory Service v1.1 registration label is

[0180] {

[0181] "environment":"prod",

[0182] "version":"v1.1"

[0183] }

[0184] Tags when querying:

[0185] When the Order Service queries the Inventory Service, it can specify tags:

[0186] {

[0187] "environment":"prod",

[0188] "version":"v1.0"

[0189] }

[0190] The service registry returns the service instance that meets the conditions based on the label: http: / / 10.0.0.3:8080 (Inventory Service v1.0).

[0191] D. Version routing of API gateway

[0192] The API gateway acts as the entry point in the microservice architecture. All external requests first reach the API gateway for routing. The API gateway can dynamically forward requests to different service versions based on the request content (e.g., request header, URL path, parameters, etc.). It allows different requests to be routed to different service instances, thereby achieving coexistence of multiple versions and flexible switching.

[0193] Sample data for selecting and managing multi-version services:

[0194] Order Service v1.1 queries Inventory Service, and the service registry returns the v1.0 version instance at http: / / 10.0.0.3:8080.

[0195] Order Service v2.0 has no version number specified, and the system returns the latest version Inventory Service v1.1 by default, at http: / / 10.0.0.6:8080.

[0196] (3) Dynamic dependency resolution and service invocation

[0197] Automatic dependency resolution: The service caller (such as Order Service) initiates a dependency query to the service registry at runtime to obtain the latest version of the dependent service and its instance information. Through the service discovery mechanism, the service can automatically resolve the dependency chain and dynamically select the correct dependent service for invocation.

[0198] Service call and routing: Once the address of the dependent service is obtained, the Order Service will forward the request to the corresponding service instance. The system uses automated dependency management to ensure that the call chain always points to the correct service version at runtime.

[0199] Example data:

[0200] When Order Service v1.1 initiates an inventory check request, it queries the Inventory Service instance and forwards the request to http: / / 10.0.0.3:8080.

[0201] If the Inventory Service has multiple instances, the service registry can select the appropriate instance to handle the request based on load balancing and other strategies.

[0202] (4) Management and update of dynamic dependency versions

[0203] When the version of a dependent service changes (such as Inventory Service is upgraded to v1.1), the automated dependency management module dynamically adjusts the dependency chain through the following steps to ensure that new calls point to the correct version.

[0204] A. Automatic detection of service version changes

[0205] The service registry will monitor the registration status of service instances in real time. When Inventory Service v1.1 goes online, it is automatically registered to the service registry, while v1.0 remains in the service registry. This enables the service registry to manage multiple versions at the same time.

[0206] B. Dynamic Selection Strategy

[0207] When a service caller (such as Order Service) initiates a dependency query, the system can automatically select the appropriate version based on the caller's request content or preset strategy:

[0208] Explicit version number call: If the Order Service specifies a version number (such as v1.0), the service registry will return an instance of the corresponding version.

[0209] Version selection strategy: If the version number is not specified, the service registry can return the latest stable version or a compatible older version (such as returning Inventory Service v1.1) based on the strategy.

[0210] C. Dynamic dependency chain update

[0211] The system automatically adjusts the dependency chain through the service discovery mechanism. When the Inventory Service is upgraded, the system will select the strategy based on the service version and forward the calls of the old version dependencies to the new version to ensure the continuity of the call chain.

[0212] D. Health Check and Version Adaptation

[0213] The service registry ensures the availability of the selected service version through health checks. If Inventory Service v1.1 is in a faulty state, the automated dependency management module will automatically switch the call back to v1.0.

[0214] Example data:

[0215] When calling Order Service v1.1, it depends on Inventory Service v1.0 by default. When InventoryService v1.1 is launched, the dependency of Order Service v2.0 is automatically updated to v1.1, and the call request is routed to http: / / 10.0.0.6:8080.

[0216] If a problem occurs with v1.1, the system will automatically roll back to v1.0 and forward the request to http: / / 10.0.0.3:8080.

[0217] Based on the same inventive concept, the present invention also proposes a microservice test environment optimization routing system based on intelligent traffic identification. The implementation of the system can refer to the implementation of the above method, and the repeated parts will not be repeated. The term "module" used below can be a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceived.

[0218] Figure 2 Schematic diagram of the structure of the microservice test environment optimization routing system based on intelligent traffic identification of the present invention. Figure 2 As shown, the system includes:

[0219] The service ID allocation module 101 is used to allocate a unique service ID to different versions of each service. The service ID is transmitted between multiple services along with the request.

[0220] The test environment module 102 is used to deploy the service version that needs to be modified and tested in the dynamic environment, and the unchanged service version in the stable environment; when a request enters the test environment, the traffic router routes the request to the corresponding service version in the dynamic environment or the stable environment according to the service ID.

[0221] The automated dependency management module 103 is used for each service to register its own information with the service registration center when it is started. The service registration center maintains a real-time updated service instance list. When the service caller is started or running, it initiates a dependency query to the service registration center through the service discovery mechanism to obtain the latest version of the dependent service and its instance information, and forwards the request to the instance of the corresponding service version.

[0222] When multiple versions of the same service exist in the service registry, the appropriate version of the dependent service is dynamically selected by carrying the version number of the dependent service in the request, the version selection strategy predefined by the service registry, the label mechanism, and the version routing of the API gateway.

[0223] When the version of a dependent service changes, dynamically adjust the dependency chain through the following steps to ensure that new calls point to the correct service version:

[0224] The service registration center monitors the registration status of service version instances in real time;

[0225] When the service caller initiates a dependency query, the appropriate version is automatically selected based on the request content or the preset version selection strategy;

[0226] Through the service discovery mechanism, the dependency chain is automatically adjusted according to the version selection strategy;

[0227] The service registration center automatically detects the status of service version instances through a health check mechanism and automatically switches to a healthy service version instance when a failure occurs.

[0228] It should be noted that although several modules of the microservice test environment optimization routing system based on intelligent traffic identification are mentioned in the above detailed description, this division is only exemplary and not mandatory. In fact, according to an embodiment of the present invention, the features and functions of two or more modules described above can be concretized in one module. Conversely, the features and functions of one module described above can be further divided into multiple modules for concretization.

[0229] Based on the above invention concept, Figure 3 As shown, the present invention also proposes a computer device 200, including a memory 210, a processor 220, and a computer program 230 stored in the memory 210 and executable on the processor 220. When the processor 220 executes the computer program 230, the aforementioned microservice test environment optimized routing based on intelligent traffic identification is implemented.

[0230] Based on the aforementioned inventive concept, the present invention also proposes a computer-readable storage medium, which stores a computer program for executing the aforementioned microservice test environment optimized routing based on intelligent traffic identification.

[0231] The microservice test environment optimization routing method and system based on intelligent traffic identification proposed in the present invention have the following highlights:

[0232] 1. Through the service discovery mechanism and dynamic routing strategy, the dependency management between services is automated. The service caller does not need to manually configure the version and address of the dependent service. The system can dynamically discover and call the correct service version.

[0233] 2. Support the coexistence of multiple versions of services, and use multiple methods such as version number, label mechanism, API gateway version routing, etc. to dynamically select the appropriate service version to ensure flexible calling and version compatibility of services in different environments.

[0234] 3. Through the health check mechanism of the service registration center, the system can automatically detect the status of the service instance and automatically switch to the healthy instance when the service fails, achieving high availability and self-healing capabilities.

[0235] Although the spirit and principle of the present invention have been described with reference to several specific embodiments, it should be understood that the present invention is not limited to the disclosed specific embodiments, and the division of various aspects does not mean that the features in these aspects cannot be combined to benefit, and such division is only for the convenience of expression. The present invention is intended to cover various modifications and equivalent arrangements contained in the spirit and scope of the attached claims.

[0236] Regarding the limitation of the protection scope of the present invention, those skilled in the art should understand that, based on the technical solution of the present invention, various modifications or variations that can be made by those skilled in the art without creative work are still within the protection scope of the present invention.

Claims

1. A microservice test environment optimization routing method based on intelligent traffic identification, characterized in that: The method includes: Assign a unique service ID to each version of a service, which is passed between multiple services as requests occur. Dynamic environments deploy service versions that need to be modified and tested, and stable environments deploy unchanged service versions; When each service is started, it registers its information with the service registration center, which maintains a real-time updated list of service instances. When the service caller starts or runs, it initiates a dependency query to the service registry through the service discovery mechanism, obtains the latest version of the dependent service and its instance information, and forwards the request to the instance of the corresponding service version.

2. According to the method for optimizing routing in a microservice test environment based on intelligent traffic identification according to claim 1, it is characterized in that: When a request enters the test environment, the traffic router routes the request to the corresponding service version in the dynamic environment or the stable environment based on the service ID.

3. According to the method for optimizing routing in a microservice test environment based on intelligent traffic identification according to claim 1, it is characterized in that: When multiple versions of the same service exist in the service registry, the appropriate version of the dependent service is dynamically selected by carrying the version number of the dependent service in the request, the version selection strategy predefined by the service registry, the label mechanism, and the version routing of the API gateway.

4. According to the method for optimizing routing in a microservice test environment based on intelligent traffic identification according to claim 1, it is characterized in that: When the version of a dependent service changes, dynamically adjust the dependency chain through the following steps to ensure that new calls point to the correct service version: The service registration center monitors the registration status of service version instances in real time; When the service caller initiates a dependency query, the appropriate version is automatically selected based on the request content or the preset version selection strategy; Through the service discovery mechanism, the dependency chain is automatically adjusted according to the version selection strategy; The service registration center automatically detects the status of service version instances through a health check mechanism and automatically switches to a healthy service version instance when a failure occurs.

5. A microservice test environment optimization routing system based on intelligent traffic identification, characterized in that: The system includes: A service ID allocation module is used to allocate a unique service ID to each different version of a service. The service ID is passed between multiple services along with the request. The test environment module is used to deploy service versions that need to be modified and tested in dynamic environments, and to deploy unchanged service versions in stable environments; The automated dependency management module is used for each service to register its own information with the service registration center when it is started. The service registration center maintains a real-time updated list of service instances. When the service caller is started or running, it initiates a dependency query to the service registration center through the service discovery mechanism to obtain the latest version of the dependent service and its instance information, and forwards the request to the instance of the corresponding service version.

6. The microservice test environment optimization routing system based on intelligent traffic identification according to claim 5 is characterized in that: When a request enters the test environment, the traffic router routes the request to the corresponding service version in the dynamic environment or the stable environment based on the service ID.

7. The microservice test environment optimization routing system based on intelligent traffic identification according to claim 5 is characterized in that: When multiple versions of the same service exist in the service registry, the appropriate version of the dependent service is dynamically selected by carrying the version number of the dependent service in the request, the version selection strategy predefined by the service registry, the label mechanism, and the version routing of the API gateway.

8. The microservice test environment optimization routing system based on intelligent traffic identification according to claim 5 is characterized in that: When the version of a dependent service changes, dynamically adjust the dependency chain through the following steps to ensure that new calls point to the correct service version: The service registration center monitors the registration status of service version instances in real time; When the service caller initiates a dependency query, the appropriate version is automatically selected based on the request content or the preset version selection strategy; Through the service discovery mechanism, the dependency chain is automatically adjusted according to the version selection strategy; The service registration center automatically detects the status of service version instances through a health check mechanism and automatically switches to a healthy service version instance when a failure occurs.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 4 is implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program for executing the method according to any one of claims 1 to 4.

Images