Tenant request processing method and device under micro-service architecture
By using a data plane container in a microservice architecture to modify tenant request headers on demand, the high cost of multi-domain deployment and microservice client methods is solved, achieving low-cost tenant request processing and isolation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HAINAN SHANGHU INFORMATION TECH CO LTD
- Filing Date
- 2026-01-15
- Publication Date
- 2026-04-28
AI Technical Summary
In a microservice architecture, existing technologies struggle to effectively handle tenant requests at low cost. Multi-domain deployment methods are costly to maintain, while microservice client-based methods are also costly to manage and have strong code intrusion.
By modifying request headers on demand in upstream services and using data plane containers, tenant requests are forwarded to the service instances corresponding to the target groups, thus achieving multi-tenant request traffic isolation and avoiding the need for additional microservice clients and domain name modifications.
It reduces domain name and service maintenance costs, avoids client version compatibility and upgrade costs, and achieves efficient isolation of tenant requests.
Smart Images
Figure CN121940397A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of microservice architecture technology, and in particular to a tenant request processing method and apparatus under a microservice architecture. Background Technology
[0002] Microservice architecture is an architectural style that, compared to traditional monolithic applications, breaks down an application into a set of loosely coupled services. Because each service is relatively small, it is called a microservice (or simply service). Business functionality is implemented by combining these microservices. Typically, one microservice accesses another through remote procedure calls (RPCs), usually with the callee as the upstream service and the caller as the downstream service. For example, if service A calls the interface of service B to retrieve data, then service B is the upstream service of service A.
[0003] In a microservice architecture, HTTP calls between services are routed and forwarded using domain names and ports. This process requires distinguishing request traffic from different tenants and determining the corresponding forwarding paths. Currently, there are two methods for distinguishing request traffic from different tenants: multi-domain deployment and microservice client-based methods. Multi-domain deployment requires maintaining multiple domains and updating multiple services with each deployment, resulting in high domain management and service maintenance costs. Microservice client-based methods require users to access the corresponding microservice client, leading to strong code intrusion and high management costs for the microservice client.
[0004] Therefore, further research is needed on how to handle tenant requests in a low-cost and efficient manner under a microservice architecture. Summary of the Invention
[0005] This application provides a tenant request processing method and apparatus under a microservice architecture. The upstream service makes minor modifications to the request header of the tenant request as needed, and forwards the tenant request to the service instance corresponding to the target group through the data plane container. This reduces maintenance costs and achieves multi-tenant request traffic isolation.
[0006] In a first aspect, embodiments of this application provide a tenant request processing method under a microservice architecture, the method comprising: Based on the tenant request, the upstream service determines whether it needs to add a grouping field value to indicate the target group of the downstream service. If so, it adds a grouping field value representing the target group to the request header of the tenant request to obtain an updated tenant request. The updated tenant request is forwarded to the service instance corresponding to the target group through the data plane container of the upstream service. The service instances of the group corresponding to the downstream service belong to the same domain name. The data plane container is a container created by the microservice governance platform for forwarding tenant requests.
[0007] Using the above approach, upstream services make minor modifications to the request headers of tenant requests as needed, and forward tenant requests to the service instances corresponding to the target group through a data plane container. This achieves multi-tenant request traffic isolation while reducing maintenance costs. Compared to multi-domain deployment methods, it eliminates the need to maintain multiple services corresponding to multiple domains. Downstream services only need to maintain a pool of instances with a unified domain name and grouping tags. Multiple service groups do not need to be updated during deployment, significantly reducing domain and service maintenance costs. Compared to microservice client-based methods, it eliminates the need to add a specific microservice client, avoiding client version compatibility and upgrade costs.
[0008] In one optional implementation, the updated tenant request is forwarded to the service instance corresponding to the target group via the data plane container of the upstream service, including: The upstream service's data plane container determines the target group corresponding to the group field value according to the group forwarding rules; the group forwarding rules are sent to the data plane container through the control plane of the microservice governance platform; the group forwarding rules are obtained based on multiple groups set by the downstream service; the updated tenant request is forwarded to the service instance corresponding to the target group through the upstream service's data plane container.
[0009] By using the above method, the request header of the tenant request is parsed by the data plane container of the upstream service, and the tenant request is forwarded to the corresponding target group according to the forwarding rules, thereby achieving tenant isolation at low cost.
[0010] In one optional implementation, the packet forwarding rule is obtained based on multiple packets set by downstream services, including: Downstream services group their own service instances to obtain a group label for each group and a corresponding service instance for each group; based on the group labels of multiple groups of the downstream services, group forwarding rules are set on the microservice governance platform; wherein, the group label represents the group field value, and the group forwarding rules include the correspondence between the group label and the service instance.
[0011] Using the above method, downstream services only need to group their own service instances without modifying the code logic, achieving "zero code intrusion" tenant isolation.
[0012] In one alternative implementation, the upstream service determines, based on a tenant request, whether it needs to add a grouping field value indicating the target group of the downstream service, including: The upstream service determines the service type requested by the tenant; if the service type is the set service type of the downstream service, the grouping field value of the target group of the downstream service corresponding to the tenant request is determined according to the grouping requirements of the set service type; the downstream service sets multiple groups for the set service type, and each group includes at least one service instance.
[0013] Using the above method, the upstream service does not need to modify the domain name in the tenant request; it only needs to update the tenant request according to the business type. The update only includes updating the value of the grouping field representing the target group, resulting in low transformation costs.
[0014] In an optional implementation, the method further includes: If it is not necessary to add the group field value to indicate the target group of the downstream service, the tenant request is sent to the service instance of the downstream service through the data plane container of the upstream service according to the load balancing forwarding principle.
[0015] Using the above method, for tenant requests that have not yet been modified, the upstream service's data plane container sends the tenant request to the service instance of the downstream service according to the load balancing forwarding principle, thus avoiding the risk of full-scale modification.
[0016] In one alternative implementation, the data plane container is automatically injected when the upstream service is launched as a container via a container orchestration engine mechanism.
[0017] Using the above method, the data plane container is automatically injected when the upstream service starts as a container through the container orchestration engine mechanism, without the need to modify the deployment script of the business service, and the traffic interception and parsing are transparent throughout the process.
[0018] Secondly, embodiments of this application provide a tenant request processing method under a microservice architecture, which is applied to a microservice governance platform. The method includes: The microservice governance platform obtains packet forwarding rules for downstream services; the service instances of the packets corresponding to the downstream services correspond to the same domain name; the microservice governance platform sends the packet forwarding rules to the data plane container of the upstream service corresponding to the downstream service through the control plane; the data plane container is created by the microservice governance platform for the upstream service and is used to forward the tenant request to the service instance of the target packet indicated by the packet field value according to the packet forwarding rules based on the packet field value in the request header of the tenant request.
[0019] Using the above approach, the control plane is mainly responsible for distributing the packet forwarding rules to the data plane container, without directly forwarding requests. The data plane container of the upstream service is responsible for transparently intercepting the call traffic (i.e., tenant requests) between the upstream and downstream services, parsing the content in the request body, and forwarding the requests according to the packet forwarding rules, thereby achieving isolation of multi-tenant request traffic.
[0020] In one optional implementation, the microservice governance platform further includes a configuration platform, which is used to configure the packet forwarding rules and distribute the packet forwarding rules to the control plane.
[0021] Using the above method, the packet forwarding rules can be configured through the configuration platform in the microservice governance platform, which enables the visualization of the packet forwarding rules and distributes the packet forwarding rules to the control plane.
[0022] In one alternative implementation, the data plane container is created for the upstream service through the microservice governance platform, including: The microservice governance platform automatically injects the data plane container of the upstream service when the upstream service is started as a container through the container orchestration engine mechanism.
[0023] Thirdly, embodiments of this application provide a tenant request processing apparatus under a microservice architecture, the apparatus comprising: The determination module is used by upstream services to determine, based on tenant requests, whether it is necessary to add a grouping field value that indicates the target group of downstream services. The update module is used to add a grouping field value representing the target group to the request header of the tenant request if necessary, so as to obtain an updated tenant request. The processing module is used to forward the updated tenant request to the service instance corresponding to the target group through the data plane container of the upstream service; the service instances of the downstream service group correspond to the same domain name; the data plane container is a container created by the microservice governance platform for forwarding tenant requests.
[0024] In one optional implementation, the processing module is specifically used to determine the target group corresponding to the group field value according to the group forwarding rule through the data plane container of the upstream service; the group forwarding rule is sent to the data plane container through the control plane of the microservice governance platform; the group forwarding rule is obtained based on multiple groups set by the downstream service; and the updated tenant request is forwarded to the service instance corresponding to the target group through the data plane container of the upstream service.
[0025] In one optional implementation, the group forwarding rule is obtained based on multiple groups set by downstream services, including: downstream services grouping their own service instances to obtain a group label for each group and a service instance corresponding to each group; and setting group forwarding rules on the microservice governance platform based on the group labels of the multiple groups of the downstream services; wherein, the group label represents the group field value, and the group forwarding rule includes the correspondence between the group label and the service instance.
[0026] In one optional implementation, the determining module is specifically used by the upstream service to determine the service type requested by the tenant; if the service type is a set service type of the downstream service, then the grouping field value of the target group of the downstream service corresponding to the tenant request is determined according to the grouping requirements of the set service type; the downstream service has set up multiple groups for the set service type, and each group includes at least one service instance.
[0027] In an optional implementation, the processing module is further configured to, if it is not necessary to add the grouping field value indicating the target group of the downstream service, send the tenant request to the service instance of the downstream service through the data plane container of the upstream service in accordance with the load balancing forwarding principle.
[0028] In one alternative implementation, the data plane container is automatically injected when the upstream service is launched as a container via a container orchestration engine mechanism.
[0029] Fourthly, this application embodiment provides a tenant request processing device under a microservice architecture. This device is a microservice governance platform, and includes: The acquisition module is used by the microservice governance platform to acquire the group forwarding rules for downstream services; the service instances of the groups corresponding to the downstream services correspond to the same domain name; The processing module is used by the microservice governance platform to send the packet forwarding rules to the data plane container of the upstream service corresponding to the downstream service through the control plane; the data plane container is created by the microservice governance platform for the upstream service and is used to forward the tenant request to the service instance of the target packet indicated by the packet field value according to the packet forwarding rules based on the packet field value in the request header of the tenant request.
[0030] In one optional implementation, the microservice governance platform further includes a configuration platform, which is used to configure the packet forwarding rules and distribute the packet forwarding rules to the control plane.
[0031] In one alternative implementation, the microservice governance platform automatically injects the data plane container of the upstream service when the upstream service is started as a container through a container orchestration engine mechanism.
[0032] Fifthly, embodiments of this application provide a device for processing tenant requests under a microservice architecture, comprising: a memory for storing computer programs; and a processor for executing the method described in the first or second aspect according to the obtained program when executing the computer program stored in the memory.
[0033] Sixthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when read and executed by a computer, causes the methods described in the first or second aspect to be performed.
[0034] In a seventh aspect, embodiments of this application provide a computer program product that, when read and executed by a computer, causes the methods described in the first or second aspect above to be performed. Attached Figure Description
[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0036] Figure 1 This application provides an architectural diagram of a tenant request processing system under a microservice architecture. Figure 2 A flowchart corresponding to a tenant request processing method under a microservice architecture provided in this application embodiment; Figure 3 A schematic diagram illustrating the process of forwarding tenant requests provided in an embodiment of this application; Figure 4 A flowchart illustrating a tenant request processing method under a microservice architecture provided in this application embodiment; Figure 5 A schematic diagram of a tenant request processing device under a microservice architecture provided in this application embodiment; Figure 6 A schematic diagram of a tenant request processing device under a microservice architecture provided in this application embodiment; Figure 7 This is a schematic diagram of the structure of a tenant request processing device under a microservice architecture, provided in an embodiment of this application. Detailed Implementation
[0037] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0038] Based on the exemplary embodiments shown in this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application. Furthermore, although the disclosures in this application are presented by way of one or more exemplary examples, it should be understood that each aspect of these disclosures can constitute a complete technical solution on its own.
[0039] Before introducing the tenant request processing method under the microservice architecture provided in the embodiments of this application, the background technology of the embodiments of this application will be introduced in detail for ease of understanding.
[0040] In a microservice architecture, HTTP calls between services are routed and forwarded using domain names and ports. In this process, it is necessary to distinguish the request traffic of different tenants and determine the corresponding forwarding path. Currently, there are two ways to distinguish the request traffic of different tenants, namely Method 1 and Method 2. The following sections will introduce Method 1 and Method 2 in detail.
[0041] (1) Implementation method one
[0042] The multi-domain deployment method involves configuring independent domains for different tenants. This requires upstream services to modify the domain names in each tenant's request, distinguishing which domain a tenant's request belongs to based on business attributes. Each tenant's request corresponds to a separate domain. For example, domain 1: service-v1.example.com corresponds to the service instance of tenant 1, and domain 2: service-v2.example.com corresponds to the service instance of tenant 2. Therefore, multiple domains need to be maintained, each requiring the deployment of a corresponding service. This high management cost, coupled with the fact that deployments are typically performed service-by-service, requires multiple executions, further increasing service maintenance costs. Secondly, if all requests are forwarded through Nginx, the Nginx cluster will bear a heavy traffic load. If the cluster fails, all systems will be affected; traffic from upstream services calling downstream services will also be routed to Nginx, creating a significant single point of failure for the cluster. Therefore, most companies currently avoid using Nginx for inter-service calls, instead managing entry point traffic.
[0043] (1) Implementation Method Two
[0044] The microservice-based client approach requires tenants to integrate with corresponding microservice clients. This integration involves significant modifications, as the code implementation differs depending on the microservice client used. For example, service B might need to integrate functionality from services A and C (e.g., service A provides Baidu Maps functionality, and service C provides Gaode Maps functionality). This necessitates writing corresponding code for each service using different clients. For sites using Java, a unified client implementation is required across all sites, either by converting all services to Baidu Maps or Gaode Maps. This raises the issue of adapting existing systems. Furthermore, companies may use multiple programming languages, such as Java, Go, and Python, requiring the provision of microservice clients for different languages, thus introducing multi-language compatibility issues. Therefore, the microservice-based client approach has extremely high management costs, potentially leading to multiple versions running concurrently. Each client and service modification requires consideration of compatibility with historical versions. Additionally, significant feature updates or major bug fixes to the microservice client necessitate pushing for client upgrades across all services.
[0045] Based on this, this application provides a tenant request processing method under a microservice architecture. Without adding an additional microservice client and without modifying the domain name, the upstream service makes minor modifications to the request header of the tenant request as needed, and forwards the tenant request to the service instance corresponding to the target group through the data plane container. This reduces maintenance costs and achieves multi-tenant request traffic isolation.
[0046] The following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application are applicable. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.
[0047] Figure 1 This application provides an architectural diagram of a tenant request processing system under a microservice architecture, as illustrated in the embodiments of this application. Figure 1 As shown, the system architecture includes upstream service 101, control plane 102, data plane container 103, and downstream service 104. Upstream service 101 and downstream service 104 are relative concepts. If service A calls the interface of service B to obtain data, then service B is the upstream service of service A; conversely, service A is the downstream service of service B. For example, in an e-commerce system, the order service needs to call the user service to obtain buyer information and the product service to obtain product details. In this case, the user service and product service are the upstream services of the order service. In a multi-tenant microservice architecture, the processing of a tenant request is essentially a chain-like process of multiple microservices collaboratively calling, data flow, and permission verification. Taking a tenant order request from a SaaS e-commerce platform as an example, the tenant is a clothing brand merchant (tenant ID: Tenant_001) on the SaaS e-commerce platform. The core microservice cluster includes: tenant authentication service, product service, inventory service, order service, payment service, and log auditing service. Invocation relationships: The order service is the core downstream service, relying on tenant authentication, product, and inventory services. In other words, the order service is a downstream service of tenant authentication, product, and inventory services, while tenant authentication, product, and inventory services are upstream services of the order service. The payment service depends on the order service; that is, the payment service is a downstream service of the order service. Upstream service 101 communicates with data plane container 103, control plane 102 communicates with data plane 103, and data plane container 103 communicates with downstream service 104.
[0048] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the device executes the method, it may be executed in the order shown in the embodiments or drawings, or in combination.
[0049] Figure 2 The flowchart corresponding to a tenant request processing method under a microservice architecture provided in this application embodiment is as follows: Figure 2 As shown, the process includes the following steps: Step 201: Based on the tenant's request, the upstream service determines whether it is necessary to add a grouping field value to indicate the target group of the downstream service.
[0050] For example, the upstream service determines the business type requested by the tenant. If the business type is the same as the business type set by the downstream service, the grouping field value of the target group of the downstream service corresponding to the tenant's request is determined according to the grouping requirements of the set business type. The downstream service sets multiple groups for the set business type, and each group includes at least one service instance. For example, suppose there are three business types: business type 1, business type 2, and business type 3. The downstream service includes 12 service instances. In this case, the downstream service sets multiple groups for business type 1, business type 2, and business type 3: group 1, group 2, and group 3. Business type 1 corresponds to group 1, business type 2 corresponds to group 2, and business type 3 corresponds to group 3. Each group includes at least one service instance. The number of service instances included in each group can be the same or different. For example, each group may include 4 service instances, or group 1 may include 2 service instances, group 2 may include 4 service instances, and group 3 may include 6 service instances. The upstream service determines the business type requested by the tenant based on the tenant's request. If the business type requested by the tenant belongs to the business type set by the downstream service, it determines that a grouping field value needs to be added to indicate the target group of the downstream service. For example, if the business type requested by the tenant is business type 1, then the grouping field value of the target group of the downstream service corresponding to the tenant's request is determined according to the grouping requirements set for the business type. For example, the field value of group 1 corresponding to business type 1 is group1.
[0051] In some embodiments, if the service type requested by the tenant does not belong to any of the service types defined by the downstream service, it is determined that it is not necessary to add the grouping field value indicating the target group of the downstream service. If it is not necessary to add the grouping field value indicating the target group of the downstream service, the tenant request is sent to the service instance of the downstream service through the data plane container of the upstream service according to the load balancing forwarding principle. For example, suppose the downstream service is divided into group 1, group 2, and group 3 according to the service type, and each group includes 4 service instances. Suppose that one service instance in group 1 is occupied, and two service instances in groups 2 and 3 are occupied. In this case, the data plane container of the upstream service will forward the tenant request to the remaining service instance in group 1 according to the load balancing forwarding principle.
[0052] Step 202: If necessary, add the grouping field value representing the target group to the request header of the tenant request to obtain the updated tenant request.
[0053] For example, if it is determined that a grouping field value indicating the target group of the downstream service needs to be added, the grouping field value representing the target group is added to the request header of the tenant request to obtain an updated tenant request. For example, if the service type of the tenant request is service type 1, then the grouping field value indicating the target group of the downstream service, i.e., group1, is added to the X-Traffic-Group field corresponding to the request header of the tenant request. At this time, the request header in the updated tenant request is X-Traffic-Group = group1.
[0054] Step 203: The updated tenant request is forwarded to the service instance corresponding to the target group through the data plane container of the upstream service.
[0055] For example, the service instances of the downstream service group correspond to the same domain name. For instance, taking the above-mentioned downstream service as an example, the 12 service instances are all under the same domain name; the data plane container is a container created by the microservice governance platform for forwarding tenant requests.
[0056] Specifically, the upstream service's data plane container determines the target group corresponding to the group field value based on the group forwarding rules. The updated tenant request is then forwarded to the service instance corresponding to the target group via the upstream service's data plane container. The group forwarding rules are sent to the data plane container through the control plane of the microservice governance platform. These rules are derived from multiple groups set by downstream services. Each downstream service groups its own service instances, obtaining a group label for each group and a corresponding service instance. Based on the group labels of the downstream services' multiple groups, group forwarding rules are set on the microservice governance platform. The group label represents the group field value, and the group forwarding rules include the correspondence between the group label and the service instance. For example, rule 1 in the group forwarding rules is: X-Traffic-Group=group1=group1, binding an instance in group1. Figure 3 As shown, assuming the downstream service includes group 1 and group 2, the upstream service's data plane container determines whether the updated tenant request header includes a group field value indicating the target group of the downstream service. The field name is X-Traffic-Group. If the value of X-Traffic-Group is empty, the upstream service's data plane container sends the tenant request to the service instance of the downstream service according to the load balancing forwarding principle. If the value of X-Traffic-Group is not empty, and the group field value indicating the target group of the downstream service is group1, then according to group forwarding rule 1: X-Traffic-Group=group1=group1, the updated tenant request is forwarded to the service instance corresponding to group1. If the group field value indicating the target group of the downstream service is group2, then according to group forwarding rule 2: X-Traffic-Group=group2=group2, the updated tenant request is forwarded to the service instance corresponding to group2.
[0057] In some embodiments, the data plane container is automatically injected when the upstream service starts as a container via a container orchestration engine mechanism, which can be a Kubernetes mechanism. This eliminates the need to modify the deployment scripts of the business services, and traffic interception and parsing are transparent throughout the entire process.
[0058] In some embodiments, a monitoring center can collect traffic metrics for each group in the downstream service in real time. When an abnormal traffic metric is detected for a group, an alarm is triggered, and stable group forwarding rules are used to forward tenant requests. The traffic metrics include at least one of the following: request volume, success rate, and latency. This avoids interruption of all services. For example, if the downstream service includes three groups, and the monitoring center detects an abnormal traffic metric in group 1, an alarm is triggered, and the original forwarding rules specifying forwarding to group 1 are reassigned to service instances in group 2 or group 3 according to a load balancing strategy.
[0059] Using the above method, upstream services make minor modifications to the request headers of tenant requests as needed, and forward tenant requests to the service instances corresponding to the target group through a data plane container. This achieves multi-tenant request traffic isolation while reducing maintenance costs. Compared with existing multi-domain deployment methods, it eliminates the need to maintain multiple services corresponding to multiple domains. Downstream services only need to maintain a pool of instances with a unified domain name and grouping labels. Multiple service groups do not need to be updated during deployment, significantly reducing domain and service maintenance costs. Compared with microservice client-based methods, it eliminates the need to add specific microservice clients, avoiding client version compatibility and upgrade costs. Furthermore, upstream services do not need to modify the domain name in the request; they only need to add a grouping field value indicating the target group of the downstream service in the tenant-differentiated request. Unmodified tenant requests can be routed normally through the default strategy, avoiding the risk of full-scale modification.
[0060] Figure 4 This application provides a flowchart illustrating a tenant request processing method under a microservice architecture. The method is applied to a microservice governance platform, which includes a control plane, a data plane container, and a configuration platform. The process includes: Step S401: Automatically inject the data plane container of the upstream service when the upstream service starts as a container through the container orchestration engine mechanism.
[0061] In step S402, the downstream service groups its own service instances to obtain a group label for each group and the corresponding service instance for each group.
[0062] Among them, the service instances of the groups corresponding to the downstream services correspond to the same domain name.
[0063] Step S403: Configure and obtain packet forwarding rules for downstream services, and configure packet forwarding rules.
[0064] The data plane container is created for upstream services through the microservice governance platform. The upstream service's data plane container, centered around the edge vehicle container, is responsible for transparently intercepting call traffic (i.e., tenant requests) between upstream and downstream services, parsing the request body, and forwarding the requests according to grouping and forwarding rules.
[0065] Step S404: Configure the platform to send the packet forwarding rules to the control plane.
[0066] In step S405, the control plane sends the packet forwarding rules to the data plane container of the upstream service corresponding to the downstream service.
[0067] For example, the control plane includes a rules engine and a configuration synchronization module, which convert the packet forwarding rules of the configuration platform into packet forwarding rules that can be executed by the data plane container, and push them to the data plane container in real time.
[0068] Step S406: The upstream service forwards the tenant request to the service instance of the target group indicated by the group field value according to the group forwarding rules based on the group field value in the request header of the tenant request.
[0069] Using the above method, the packet forwarding rules can be configured through the configuration platform in the microservice governance platform, which enables the visualization of the packet forwarding rules and distributes them to the control plane. The control plane is mainly responsible for distributing the packet forwarding rules to the data plane container, without directly forwarding requests. The data plane container of the upstream service is responsible for transparently intercepting the call traffic (i.e., tenant requests) between the upstream and downstream services, parsing the content in the request body, and forwarding the requests according to the packet forwarding rules, thereby achieving isolation of multi-tenant request traffic.
[0070] Based on the same technical concept described above, this application provides a tenant request processing apparatus under a microservice architecture, which can execute the methods described in the above embodiments. Figure 5 This application provides a schematic diagram of the structure of a tenant request processing device under a microservice architecture, as shown in the embodiments of this application. Figure 5 As shown, the device 5000 includes: Module 501 is used by the upstream service to determine, based on a tenant request, whether it is necessary to add a grouping field value that indicates the target group of the downstream service. The update module 502 is used to add a grouping field value representing the target group to the request header of the tenant request if necessary, so as to obtain an updated tenant request. The processing module 503 is used to forward the updated tenant request to the service instance corresponding to the target group through the data plane container of the upstream service; the service instances of the downstream service group correspond to the same domain name; the data plane container is a container created by the microservice governance platform for forwarding tenant requests.
[0071] In one optional implementation, the processing module 503 is specifically used to determine the target group corresponding to the group field value according to the group forwarding rule through the data plane container of the upstream service; the group forwarding rule is sent to the data plane container through the control plane of the microservice governance platform; the group forwarding rule is obtained based on multiple groups set by the downstream service; and the updated tenant request is forwarded to the service instance corresponding to the target group through the data plane container of the upstream service.
[0072] In one optional implementation, the group forwarding rule is obtained based on multiple groups set by downstream services, including: downstream services grouping their own service instances to obtain a group label for each group and a service instance corresponding to each group; and setting group forwarding rules on the microservice governance platform based on the group labels of the multiple groups of the downstream services; wherein, the group label represents the group field value, and the group forwarding rule includes the correspondence between the group label and the service instance.
[0073] In one optional implementation, the determining module 501 is specifically used by the upstream service to determine the service type requested by the tenant; if the service type is a set service type of the downstream service, then the grouping field value of the target group of the downstream service corresponding to the tenant request is determined according to the grouping requirements of the set service type; the downstream service has set up multiple groups for the set service type, and each group includes at least one service instance.
[0074] In an optional implementation, the processing module 503 is further configured to, if it is not necessary to add the grouping field value indicating the target group of the downstream service, send the tenant request to the service instance of the downstream service through the data plane container of the upstream service in accordance with the load balancing forwarding principle.
[0075] In one alternative implementation, the data plane container is automatically injected when the upstream service is launched as a container via a container orchestration engine mechanism.
[0076] Based on the same technical concept described above, this application also provides a tenant request processing device under a microservice architecture. This device is a microservice governance platform and can execute the methods described in the above embodiments. Figure 6 This application provides a schematic diagram of the structure of a tenant request processing device under a microservice architecture, as shown in the embodiments of this application. Figure 6 As shown, the device 6000 includes: The acquisition module 601 is used by the microservice governance platform to acquire the group forwarding rules for downstream services; the service instances of the groups corresponding to the downstream services correspond to the same domain name; The processing module 602 is used by the microservice governance platform to send the packet forwarding rules to the data plane container of the upstream service corresponding to the downstream service through the control plane; the data plane container is created by the microservice governance platform for the upstream service and is used to forward the tenant request to the service instance of the target packet indicated by the packet field value according to the packet forwarding rules based on the packet field value in the request header of the tenant request.
[0077] In one optional implementation, the microservice governance platform further includes a configuration platform, which is used to configure the packet forwarding rules and distribute the packet forwarding rules to the control plane.
[0078] In one alternative implementation, the microservice governance platform automatically injects the data plane container of the upstream service when the upstream service is started as a container through a container orchestration engine mechanism.
[0079] Based on the same technological concept Figure 7 This application provides a schematic diagram of the structure of a tenant request processing device 7000 under a microservice architecture, as shown in the embodiment of the present application. Figure 7 As shown, the device 7000 includes at least one processor 701 and a memory 702 connected to the at least one processor 701. In this embodiment, the specific connection medium between the processor 701 and the memory 702 is not limited. Figure 7 Taking the connection between processor 701 and memory 702 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc. In this embodiment of the invention, memory 702 stores instructions that can be executed by at least one processor 701. By executing the instructions stored in memory 702, at least one processor 701 can implement the steps of the tenant request processing method under the above-mentioned microservice architecture.
[0080] The processor 701 is the control center of the computer device, capable of connecting various parts of the computer device via various interfaces and lines. It performs resource configuration by running or executing instructions stored in the memory 702 and accessing data stored in the memory 702. Optionally, the processor 701 may include one or more processing units. The processor 701 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 701. In some embodiments, the processor 701 and the memory 702 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.
[0081] The processor 701 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.
[0082] Memory 702, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 702 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 702 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 702 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.
[0083] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the tenant request processing methods under a microservice architecture discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the tenant request processing method under a microservice architecture, the implementation of the above-described computer-readable storage medium can be referred to the implementation of the method, and repeated details will not be elaborated further.
[0084] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the tenant request processing methods under a microservice architecture discussed above. Since the principle by which the above computer program product solves the problem is similar to that of the tenant request processing method under a microservice architecture, the implementation of the above computer program product can refer to the implementation of the method, and repeated details will not be described again.
[0085] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0086] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0087] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0088] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0089] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A tenant request processing method under a microservice architecture, characterized in that, include: Based on tenant requests, the upstream service determines whether it needs to add a grouping field value to indicate the target group for the downstream service; If necessary, the grouping field value representing the target group is added to the request header of the tenant request to obtain an updated tenant request; The updated tenant request is forwarded to the service instance corresponding to the target group through the data plane container of the upstream service; the service instances of the downstream service group correspond to the same domain name; the data plane container is a container created by the microservice governance platform for forwarding tenant requests.
2. The method according to claim 1, characterized in that, The updated tenant request is forwarded to the service instance corresponding to the target group via the data plane container of the upstream service, including: The upstream service's data plane container determines the target packet corresponding to the packet field value based on the packet forwarding rules; the packet forwarding rules are sent to the data plane container through the control plane of the microservice governance platform; the packet forwarding rules are obtained based on multiple packets set by the downstream service. The updated tenant request is forwarded to the service instance corresponding to the target group through the data plane container of the upstream service.
3. The method according to claim 2, characterized in that, The packet forwarding rules are derived from multiple packets set by downstream services, including: Downstream services group their own service instances to obtain a group label for each group and the corresponding service instance for each group; Based on the group labels of multiple groups of the downstream services, group forwarding rules are set in the microservice governance platform; wherein, the group label represents the group field value, and the group forwarding rules include the correspondence between the group label and the service instance.
4. The method according to claim 1, characterized in that, Based on tenant requests, the upstream service determines whether it needs to add a grouping field value to indicate the target group for downstream services, including: The upstream service determines the type of service requested by the tenant; If the business type is the set business type of the downstream service, then the grouping field value of the target group of the downstream service corresponding to the tenant request is determined according to the grouping requirements of the set business type; the downstream service has multiple groups set for the set business type, and each group includes at least one service instance.
5. The method according to claim 1, characterized in that, The method further includes: If it is not necessary to add the group field value to indicate the target group of the downstream service, the tenant request is sent to the service instance of the downstream service through the data plane container of the upstream service according to the load balancing forwarding principle.
6. The method according to any one of claims 1-5, characterized in that, The data plane container is automatically injected when the upstream service is started as a container through a container orchestration engine mechanism.
7. A tenant request processing method under a microservice architecture, characterized in that, The method is applied to a microservice governance platform, and the method includes: The microservice governance platform obtains the packet forwarding rules for downstream services; the service instances of the packets corresponding to the downstream services correspond to the same domain name; The microservice governance platform sends the packet forwarding rules to the data plane container of the upstream service corresponding to the downstream service through the control plane; the data plane container is created by the microservice governance platform for the upstream service and is used to forward the tenant request to the service instance of the target group indicated by the packet field value according to the packet forwarding rules based on the packet field value in the request header of the tenant request.
8. The method according to claim 7, characterized in that, The microservice governance platform also includes a configuration platform, which is used to configure the packet forwarding rules and distribute the packet forwarding rules to the control plane.
9. The method according to claim 7, characterized in that, The data plane container is created for the upstream service through the microservice governance platform, and includes: The microservice governance platform automatically injects the data plane container of the upstream service when the upstream service is started as a container through the container orchestration engine mechanism.
10. A tenant request processing device under a microservice architecture, characterized in that, The device includes: The determination module is used by upstream services to determine, based on tenant requests, whether it is necessary to add a grouping field value that indicates the target group of downstream services. The update module is used to add a grouping field value representing the target group to the request header of the tenant request if necessary, so as to obtain an updated tenant request. The processing module is used to forward the updated tenant request to the service instance corresponding to the target group through the data plane container of the upstream service; the service instances of the downstream service group correspond to the same domain name; the data plane container is a container created by the microservice governance platform for forwarding tenant requests.
11. A tenant request processing device under a microservice architecture, characterized in that, The device is a microservice governance platform, and the device includes: The acquisition module is used by the microservice governance platform to acquire the group forwarding rules for downstream services; the service instances of the groups corresponding to the downstream services correspond to the same domain name; The processing module is used by the microservice governance platform to send the packet forwarding rules to the data plane container of the upstream service corresponding to the downstream service through the control plane; the data plane container is created by the microservice governance platform for the upstream service and is used to forward the tenant request to the service instance of the target packet indicated by the packet field value according to the packet forwarding rules based on the packet field value in the request header of the tenant request.
12. An electronic device, characterized in that, The device includes: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method according to any one of claims 1-9.
13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a computer, cause the method as described in any one of claims 1-9 to be performed.
14. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a computer, causes any one of claims 1-9 to be executed.