Multi-version gray scale control system and control method of SAAS multi-tenant software system

Abstract

The invention provides a multi-version gray control system and method for an SAAS multi-tenant software system, and the system comprises an agent request dyeing assembly which is used for intercepting the original request flow of a user, carrying out the dyeing according to a multi-version gray rule, generating a first request flow containing dyeing information, and transmitting the first request flow to a front-end service node routing assembly. And the front-end service node routing component is used for receiving the first request flow, routing the first request flow to the front-end service node of the corresponding version for processing according to the dyeing information, and sending an application gateway request dyeing component. And the application gateway request dyeing component is used for receiving the first request traffic, identifying dyeing information, adding the dyeing information to a back-end request context, obtaining second request traffic and sending the second request traffic to the RPC framework multi-version data distribution component. And the RPC framework multi-version data distribution component is used for receiving the second request flow, identifying the dyeing information and distributing the dyeing information to the corresponding version of back-end service node for processing according to the dyeing information. By means of the method, multi-version control of the multi-tenant software system can be achieved, and individual requirements of different clients are met.

Description

Multi-version grayscale control system and control method for SAAS multi-tenant software system Technical Field

[0001] This disclosure relates to the field of software development technology, and in particular to a multi-version grayscale control system and control method for a SaaS multi-tenant software system. Background Technology

[0002] SaaS (Software as a Service) is a service model that delivers software applications via the internet. In this model, the software and related data are hosted in the cloud, and users can access these applications via the internet without needing to install and maintain the software. This service model typically uses a subscription model, with users paying based on usage time or functional modules. SaaS has become a very popular way for businesses and individuals to obtain software services, simplifying technology management and reducing costs while providing flexibility and accessibility.

[0003] However, existing SaaS lacks a parallel version management mechanism for multi-tenancy, making it difficult to simultaneously deploy and manage multiple versions of software systems in a production environment to meet the diverse needs of different customers. This makes it difficult to satisfy customers' personalized requirements. Therefore, how to leverage SaaS to achieve multi-version control of multi-tenant software systems to meet the personalized needs of different customers has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, this disclosure proposes a multi-version grayscale control system and control method for SaaS multi-tenant software systems, which can realize multi-version control of multi-tenant software systems with the help of SaaS to meet the personalized needs of different customers.

[0005] According to a first aspect of this disclosure, a multi-version grayscale control system for a SaaS multi-tenant software system is provided, comprising: a proxy request coloring component, a front-end service node routing component, an application gateway request coloring component, an RPC framework multi-version data distribution component, multi-version front-end service nodes, and multi-version back-end service nodes; the proxy request coloring component is used to intercept the original request traffic sent by the user, color the original request traffic based on pre-built multi-version grayscale rules, generate a first request traffic including coloring information, and send the first request traffic to the front-end service node routing component, wherein the multi-version grayscale rules include at least one of grayscale rule type, rule content, adapted grayscale service information, and grayscale service activation status, and the coloring information includes at least one of whether the grayscale version of the service is enabled and the grayscale version of the service pointed to by the original request traffic; the front-end... A service node routing component is used to receive the first request traffic, identify and route the first request traffic to the corresponding version of the front-end service node for processing based on the coloring information in the first request traffic, and simultaneously route the first request traffic to the application gateway request coloring component; the application gateway request coloring component is used to receive the first request traffic, identify the coloring information in the first request traffic, add the coloring information to the backend request context of the first request traffic to obtain the second request traffic, and send the second request traffic to the RPC framework multi-version data distribution component; the RPC framework multi-version data distribution component is used to receive the second request traffic, identify the coloring information from the backend request context of the second request traffic, and distribute the second request traffic to the corresponding version of the backend service node for processing based on the coloring information.

[0006] In one possible implementation, the proxy request coloring component, when coloring the original request traffic based on pre-built multi-version grayscale rules to generate a first request traffic including coloring information, is specifically configured to: parse the user's user information and the service pointed to by the original request traffic from the original request traffic; match the user information and the pointed-to service section with each of the multi-version grayscale rules to obtain the matching result of the multi-version grayscale rules; and color the original request traffic based on the matching result to generate a first request traffic including coloring information.

[0007] In one possible implementation, the system further includes a message queue multi-version data coloring and distribution component; the message queue multi-version data coloring and distribution component is used to create a corresponding gray-scale message producer for the service node that generates the gray-scale version of the message, and when the service node of the gray-scale version generates the initial message, the gray-scale message producer will color the initial message based on the pre-built multi-version gray-scale rules to generate a colored message including coloring information, and route the colored message to the corresponding message queue.

[0008] In one possible implementation, the message queue multi-version data coloring distribution component is further configured to: create ordinary consumers and gray-scale consumers for service nodes that process messages in the message queue, wherein the ordinary consumers are used to pull uncolored messages from the message queue for processing, and the gray-scale consumers are used to pull colored messages from the message queue for processing.

[0009] In one possible implementation, the system further includes: a scheduled task multi-version data coloring and distribution component; the scheduled task multi-version data coloring and distribution component is used to monitor scheduled task request traffic in service nodes of multiple versions, and when the scheduled task request traffic is detected, it colors the scheduled task request traffic based on pre-built multi-version grayscale rules, and distributes the colored scheduled task request traffic to the corresponding version service nodes for processing.

[0010] In one possible implementation, the system further includes a multi-version scheduled task management module; the multi-version scheduled task management module is used to configure and manage the versions of each scheduled task.

[0011] In one possible implementation, the system further includes: a multi-version grayscale rule management module; the multi-version grayscale rule management module is used to receive multi-version grayscale rule information input by the user, and create corresponding multi-version grayscale rules based on the multi-version grayscale rule information.

[0012] In one possible implementation, the system further includes: a multi-version application service management module; the multi-version application service management module is used to configure and manage the version information of each application service.

[0013] According to a second aspect of this disclosure, a multi-version canary control method for a SaaS multi-tenant software system is provided, comprising: intercepting original request traffic sent by a user by a proxy request coloring component; coloring the original request traffic based on pre-built multi-version canary rules to generate a first request traffic including coloring information; and sending the first request traffic to a front-end service node routing component, wherein the multi-version canary rules include at least one of canary rule type, rule content, adapted canary service information, and canary service activation status; the coloring information includes at least one of whether a canary version of the service is enabled and the canary version of the service pointed to by the original request traffic; the front-end service node routing component receives the first request traffic, identifies and controls the canary traffic based on the first request traffic. The first request traffic is routed to the corresponding version of the front-end service node for processing, and simultaneously routed to the application gateway request coloring component. The application gateway request coloring component receives the first request traffic, identifies the coloring information from the first request traffic, adds the coloring information to the back-end request context of the first request traffic to obtain the second request traffic, and sends the second request traffic to the RPC framework multi-version data distribution component. The RPC framework multi-version data distribution component receives the second request traffic, identifies the coloring information from the back-end request context in the second request traffic, and distributes the second request traffic to the corresponding version of the back-end service node for processing based on the coloring information.

[0014] In one possible implementation, the proxy request coloring component, when coloring the original request traffic based on pre-built multi-version grayscale rules to generate a first request traffic including coloring information, includes: parsing the user's user information and the service node required to respond to the original request traffic from the original request traffic; matching the user information and the service node with each of the multi-version grayscale rules to obtain the matching result of the multi-version grayscale rules; and coloring the original request traffic based on the matching result to generate a first request traffic including coloring information.

[0015] This disclosure provides a multi-version canary release control system for a SaaS multi-tenant software system, including: a proxy request coloring component, a front-end service node routing component, an application gateway request coloring component, an RPC framework multi-version data distribution component, multi-version front-end service nodes, and multi-version back-end service nodes; the proxy request coloring component is used to intercept the original request traffic sent by the user, color the original request traffic based on pre-built multi-version canary release rules, generate a first request traffic including coloring information, and send the first request traffic to the front-end service node routing component; the front-end service node routing component is used to receive the first request traffic, identify and process the coloring information in the first request traffic, The first request traffic is routed to the corresponding version of the front-end service node for processing. Simultaneously, the first request traffic is also routed to the application gateway request coloring component. The application gateway request coloring component receives the first request traffic, identifies the coloring information within it, and adds this information to the back-end request context of the first request traffic to obtain the second request traffic. This second request traffic is then sent to the RPC framework multi-version data distribution component. The RPC framework multi-version data distribution component receives the second request traffic, identifies the coloring information from its back-end request context, and distributes the second request traffic to the corresponding version of the back-end service node for processing based on this coloring information. This disclosure utilizes pre-built multi-version grayscale rules to perform rule matching and coloring operations at each processing node of the request traffic (including load balancers, gateways, etc.), and routes the request traffic to the corresponding version of the service node without the user noticing the coloring information. Thus, multi-version control of a multi-tenant software system is achieved through Software as a Service (SaaS), thereby meeting the personalized needs of different customers.

[0016] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0017] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0018] Figure 1 shows a schematic block diagram of a multi-version grayscale control system of a SaaS multi-tenant software system according to an embodiment of the present disclosure; Figure 2 shows a schematic block diagram of an example of a multi-version grayscale control system of a SaaS multi-tenant software system according to an embodiment of the present disclosure; Figure 3 shows an example message management diagram corresponding to a message queue multi-version data coloring and distribution component according to an embodiment of the present disclosure; Figure 4 shows a display diagram of a grayscale rule management interface according to an embodiment of the present disclosure; Figure 5 shows a schematic flowchart of a multi-version grayscale control method of a SaaS multi-tenant software system according to an embodiment of the present disclosure. Detailed Implementation

[0019] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0020] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0021] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0022] <Method Embodiments> Figure 1 shows a schematic block diagram of a multi-version grayscale control system for a SaaS multi-tenant software system according to an embodiment of the present disclosure. As shown in Figure 1, the system 100 includes: a proxy request coloring component 110, a front-end service node routing component 120, an application gateway request coloring component 130, an RPC framework multi-version data distribution component 140, multi-version front-end service nodes 150, and multi-version back-end service nodes 160.

[0023] The proxy request coloring component 110 is used to intercept the original request traffic sent by the user, color the original request traffic based on the pre-built multi-version grayscale rules, generate the first request traffic including coloring information, and send the first request traffic to the front-end service node routing component 120.

[0024] The multi-version gray-scale rule includes at least one of the following: rule type, rule content, adapted gray-scale service information, and gray-scale service activation status. The rule type includes at least one of the following: domain name (i.e., rules are set based on a domain name), tenant ID (i.e., rules are set based on a tenant ID), and user ID (i.e., rules are set based on a user ID). The rule content is the specific domain name, tenant ID, or user ID that the multi-version gray-scale rule adapts to. For example, when the rule type of the multi-version gray-scale rule is a domain name, its corresponding rule content is a specific domain name, such as www.xxx.com. Similarly, when the rule type of the multi-version gray-scale rule is a tenant ID, its corresponding rule content is a specific tenant ID, such as tenant123". And again, when the rule type of the multi-version gray-scale rule is a user ID, its corresponding rule content is a specific user ID, such as user456. The adapted gray-scale service information clarifies the service to which the multi-version gray-scale rule points and the gray-scale version of the service. The gray-scale service activation status indicates whether the multi-version gray-scale rule is available, such as enabled or disabled.

[0025] The coloring information includes at least one of whether the grayscale version of the service is enabled and whether the original request traffic points to the grayscale version of the service. Specifically, it includes whether the grayscale version of the service is enabled.

[0026] In one possible implementation, the proxy request coloring component 110, when coloring the original request traffic based on pre-built multi-version grayscale rules to generate a first request traffic including coloring information, is specifically used for: First, parsing the user's user information and the service to which the original request traffic points from the original request traffic. The user information includes at least one of the domain name of the user initiating the request traffic, the user ID, and the tenant ID.

[0027] Second, the user information and the service it points to are matched against multiple pre-built multi-version grayscale rules to obtain the matching results. The specific matching process is as follows: First, the user information is matched against multiple pre-built multi-version grayscale rules to obtain multi-version grayscale rules that match the user information, which are then used as candidate multi-version grayscale rules. Specifically, the domain name, user ID, and tenant ID in the user information have pre-set matching priorities, with the matching priorities decreasing sequentially from domain name to user ID to tenant ID. During the matching process, the domain name, user ID, and tenant ID are matched against multi-version grayscale rules in descending order of matching priority. Multi-version grayscale rules whose rule content matches the user information being matched are selected as candidate multi-version grayscale rules that match the user information.

[0028] It's important to note that when a candidate multi-version grayscale rule is matched for high-priority user information, subsequent rule matching will stop. If no candidate multi-version grayscale rule is matched for high-priority user information, the rule matching process will continue for the next higher priority user information, and so on. The number of matched candidate multi-version grayscale rules can be zero or more; there is no specific limitation here. If the final number of matched candidate multi-version grayscale rules is zero, it means that no candidate multi-version grayscale rule was matched for any priority user information, and the request traffic is actually normal traffic. If the final number of matched candidate multi-version grayscale rules is one or more, it means that the request traffic is potential grayscale traffic.

[0029] Secondly, the service targeted by the original request traffic is matched with candidate multi-version canary release rules to obtain the multi-version canary release rules that match the service targeted by the original request traffic, and these are used as the matching results of the multi-version canary release rules. Specifically, when the service involved in the canary release service information adapted in the candidate multi-version canary release rules is consistent with the service targeted by the original request traffic, it is used as the service targeted by the original request traffic to match the multi-version canary release rules, and this is used as the matching result of the multi-version canary release rules.

[0030] It's important to note that the rule matching operation for the service to which the original request traffic points is only performed when more than one candidate multi-version grayscale rule is matched. Of course, the matching result of the multi-version grayscale rule may or may not be empty. If the matching result is empty, it means that the request traffic is actually normal traffic; if the matching result is not empty, it means that the request traffic is potential grayscale traffic.

[0031] Third, based on the matching results, the original request traffic is colored to generate a first request traffic that includes the colored information.

[0032] When the matching result is not empty, the specific coloring process can be as follows: First, identify the multi-version grayscale rule in the matching result and determine it as the target multi-version grayscale rule.

[0033] Secondly, based on the gray-scale service activation status and adapted gray-scale service information parsed from the target multi-version gray-scale rules, the gray-scale version activation status of the service in the coloring information and the gray-scale version of the service to which the original request traffic points are clarified. Specifically, when the gray-scale service activation status in the target multi-version gray-scale rules is "enabled," the corresponding gray-scale version in the coloring information is the one where the service is enabled; when the gray-scale service activation status is "disabled," the corresponding gray-scale version in the coloring information is the one where the service is disabled. The adapted gray-scale service information in the target multi-version gray-scale rules is parsed to obtain the service and its gray-scale version pointed to by the target multi-version gray-scale rules, and the gray-scale version of the service pointed to by the target multi-version gray-scale rules is used as the gray-scale version of the same service to which the original request traffic in the coloring information points.

[0034] When the matching result is empty, the specific coloring process can be as follows: set the coloring information to the grayscale version of the service that is not enabled, and at the same time set the service that the original request traffic points to and the grayscale version of that service to empty.

[0035] It should be further clarified that when the coloring information indicates a grayscale version where the service is disabled, it means that regardless of whether the service pointed to by the original request traffic and the grayscale version of that service are empty, the first traffic is considered normal traffic. Only when the coloring information indicates a grayscale version where the service is enabled, and both the service pointed to by the original request traffic and the grayscale version of that service are not empty, is the first traffic considered grayscale traffic. In other words, the coloring information can be used to distinguish between normal traffic and grayscale traffic.

[0036] It should be further noted that if the original request traffic points to multiple services, the coloring information will record each service and its corresponding grayscale version in the order of the responses from the multiple services, so as to achieve request traffic distribution across the entire backend chain.

[0037] Finally, combining the generated coloring information with the original request traffic yields the first request traffic, which includes the coloring information.

[0038] In one possible implementation, the proxy request coloring component 110 is the load balancing component Nginx in Figure 2. Nginx can read the pre-built multi-version canary rules through the Redis middleware via an embedded Lua script, and then color the original request traffic based on these multi-version canary rules.

[0039] The front-end service node routing component 120 receives the first request traffic, identifies and routes the first request traffic to the corresponding version of the front-end service node for processing based on the coloring information in the first request traffic, and simultaneously routes the first request traffic to the application gateway request coloring component 130. Specifically, as shown in Figure 2, the coloring information is extracted from the first request traffic. Based on the extracted coloring information, it is determined whether the first request traffic is normal traffic or grayscale traffic: if the first request traffic is normal traffic, it is routed to the front-end service node where the standard front-end service version (i.e., the FE Release version in Figure 2) is located for processing, so as to push and display the standard front-end page; if the first request traffic is grayscale traffic, it is processed by the front-end service node where the grayscale version of the front-end service (i.e., the FEGray version in Figure 2) is located, so as to push and display the corresponding grayscale version front-end page.

[0040] It's important to note that if the original request traffic only involves accessing the front-end page, the response to the original request traffic ends after the corresponding version of the front-end page is displayed, and the subsequent operation of routing the first request traffic to the application gateway request coloring component 130 is not performed. If the original request traffic involves accessing both the front-end page and the back-end service, after the corresponding version of the front-end page is displayed, the service node routing component 120 will simultaneously route the first request traffic to the application gateway request coloring component 130 for further processing. If the original request traffic only involves accessing the back-end service and not the front-end page, the proxy request coloring component 110 can directly send the first request traffic to the application gateway request coloring component 130, eliminating the need for data processing operations by the front-end service node routing component 120. This configuration ensures that the original request traffic can be accurately and efficiently routed to the corresponding processing components or service nodes when different service access scenarios are involved (front-end page access only, front-end page and back-end service access only, and back-end service access only). This enables accurate push display of different versions of the front-end page and smooth connection of subsequent back-end service access, avoids unnecessary process redundancy, and improves the flexibility of gray-scale traffic processing and the overall system response efficiency.

[0041] The application gateway request coloring component 130 receives the first request traffic, identifies the coloring information in the first request traffic, adds the coloring information to the backend request context of the first request traffic to obtain the second request traffic, and sends the second request traffic to the RPC framework multi-version data distribution component 140. In one possible implementation, the application gateway request coloring component 130 can be the Gateway in Figure 2.

[0042] The RPC framework multi-version data distribution component 140 receives second request traffic, identifies coloring information from the backend request context of the second request traffic, and distributes the second request traffic to the corresponding version of the backend service node for processing based on the coloring information. In one possible implementation, the RPC framework multi-version data distribution component 140 can be the Dubbo Router shown in Figure 2.

[0043] When the multi-version data distribution component 140 of the RPC framework distributes the second request traffic to the corresponding version of the backend service node for processing based on the coloring information, it may include the following steps: After identifying the coloring information from the backend request context of the second request traffic, it determines whether the second request traffic is normal traffic or gray traffic based on the extracted coloring information: If the second request traffic is normal traffic, it is routed to the backend service node where the backend standard service version (S1Release version in Figure 2) is located for processing, so as to perform backend data response operations based on the backend standard service version; If the second request traffic is gray traffic, it extracts the backend service node where the gray version of the backend service (S1 Gray version in Figure 2) is located from its coloring information for processing, so as to perform the backend data response operations provided by the corresponding gray version.

[0044] In one possible implementation, the system may also include a message queue multi-version data coloring and distribution component. This component creates corresponding gray-scale message producers (as shown in Figure 3) for service nodes that generate gray-scale versions of messages. When a gray-scale version service node generates an initial message, the gray-scale message producer colors the initial message based on pre-built multi-version gray-scale rules, generating a colored message containing coloring information, and routes the colored message to the corresponding message queue (as shown in Figure 3, TOPIC-V-USER). The specific coloring process is described above and will not be repeated here.

[0045] In one possible implementation, the message queue multi-version data coloring distribution component is also used to create consumers (Cunsumer shown in Figure 3) for service nodes that process messages in the message queue. These consumers are divided into regular consumers and grayscale consumers. Regular consumers are used to pull uncolored messages from the message queue for processing, while grayscale consumers are used to pull colored messages from the message queue for processing. By creating regular and grayscale consumers for a single service node, lossless isolation of business traffic can be guaranteed: regular and grayscale consumers process different types of messages respectively, ensuring that grayscale test traffic does not interfere with the processing of normal business traffic, thus guaranteeing the stability of online business. Resource reuse is possible, reducing deployment costs: the same service node can simultaneously handle normal business and grayscale tasks, eliminating the need to deploy a separate complete cluster for grayscale testing, saving system resources and operational costs; test coverage and release security are improved: grayscale messages can represent real traffic from specific scenarios or user groups, helping to verify the functionality and compatibility of new versions in a real environment and reducing the risk of full release.

[0046] For example, for an initial request to a backend service, the Gray version of backend service S1 in Figure 2 first generates a response message and sends it to a message queue for processing. Then, the Release version of backend service S2 retrieves the message from the message queue for processing. In this embodiment, the node where the Gray version of backend service S1 resides is the producer of the grayscale message, and the node where the Release version of backend service S2 resides is the consumer. At this time, the message queue multi-version data coloring and distribution component creates a corresponding grayscale message producer for the node where the Gray version of backend service S1 resides. When the node generates an initial message, it colors the initial message based on pre-built multi-version grayscale rules, generating a colored message including coloring information, and routes the colored message to the corresponding message queue. Simultaneously, the message queue multi-version data coloring and distribution component also creates ordinary consumers and grayscale consumers for the node where the Release version of backend service S2 resides. This allows the grayscale consumers to retrieve the colored messages sent by the Gray version service node of S1 from the corresponding message queue for processing. The created ordinary consumers can then pull uncolored messages from the message queue for processing during subsequent request-response processes.

[0047] In one possible implementation, the system further includes a multi-version data coloring and distribution component for scheduled tasks. This component monitors scheduled task request traffic across multiple versions of service nodes. Upon detecting such traffic, it colors the traffic based on pre-built multi-version grayscale rules and distributes the colored traffic to the corresponding version of the service node for processing. The specific coloring process is described above and will not be repeated here.

[0048] In one possible implementation, the system further includes a multi-version scheduled task management module. This module is used to configure and manage the versions of each scheduled task. Specifically, the multi-version scheduled task management module can provide a scheduled task management interface for users, allowing them to query, add, modify, and delete scheduled task versions. The version of a scheduled task includes at least one of the following: scheduled task namespace, scheduled task name, scheduled task version number, responsible person, creation time, creator, modification time, and modifier.

[0049] In one possible implementation, the system further includes a multi-version gray-scale rule management module. This module receives multi-version gray-scale rule information input by the user and creates corresponding multi-version gray-scale rules based on this information. Specifically, the multi-version gray-scale rule management module can provide users with a gray-scale rule management interface (as shown in Figure 4), through which users can query, add, modify, and delete multi-version gray-scale rules. In addition to the rule type, rule content, adapted gray-scale service information, and gray-scale service activation status mentioned above, the multi-version gray-scale rule may also include information such as the responsible person, creation time, creator, modification time, and modifier. Through the multi-version gray-scale rule management module of this embodiment, developers can quickly configure multi-version gray-scale deployments of SaaS software systems.

[0050] In one possible implementation, the system further includes a multi-version application service management module; this module is used to configure and manage the version information of each application service. Specifically, the multi-version application service management module provides users with an application service management interface through which users can query, add, modify, and delete versions of each application service. The application service version information includes at least one of the following: service name, service version number, responsible person, creation time, creator, modification time, and modifier. It should be noted that the "service" in this disclosure is the same concept as the "application service" described herein.

[0051] It's important to note that each time a user creates a gray-scale version of an application service through the multi-version application service management module, a corresponding multi-version gray-scale management rule is created based on the user information served by that gray-scale application service through the multi-version gray-scale rule management module. This allows for precise gray-scale release and control of the application service. This multi-version gray-scale management rule is automatically associated with the newly created gray-scale application service, ensuring that during subsequent gray-scale releases, the system can accurately identify the target user group based on this rule and push the corresponding gray-scale application service to these users. Simultaneously, the system monitors and flexibly adjusts the push process in real time to ensure the stability and controllability of the gray-scale release.

[0052] To support the accurate operation of the message queue multi-version data coloring and distribution component described above, the system also includes a multi-version message queue management module. This module is used for centralized management of multi-version configurations for message queue producers and consumers. The configuration information defined in this module will serve as the basis for the message queue multi-version data coloring and distribution component to create grayscale message producers and consumers, and to define the routing paths for messages.

[0053] This multi-version message queue management module includes a producer multi-version configuration management sub-module and a consumer multi-version configuration management sub-module.

[0054] The producer multi-version configuration management submodule provides a dedicated configuration management interface for operations and development personnel to manage the versioned routing rules of message producers. Through this interface, users can query, add, modify, or delete producer configurations. A typical producer configuration record may include fields such as: target queue name, queue version number, responsible person, creation information, and modification information. This configuration defines which version of the message queue a specific grayscale version of the service should deliver its colored messages to when sending messages.

[0055] The consumer multi-version configuration management submodule also provides a configuration management interface for managing message consumer version subscription rules. Users can maintain consumer configurations through this interface. A consumer configuration record typically includes: the name of the queue to be consumed, the name of the consumer group, the person in charge, and related creation and modification information. This configuration specifies which version of the message queue a particular service node (or its specific version) should pull and process messages from when acting as a consumer.

[0056] This module enables centralized and visualized version rule configuration for both producers and consumers, ensuring that the message queue's multi-version data coloring and distribution component operates on a rule-based basis. When sending messages, producers can accurately deliver colored messages to the corresponding version's queue according to preset configurations; similarly, when consuming messages, consumers can precisely subscribe to messages in a specified version's queue based on their own configurations. This achieves logical isolation and precise routing between different version services at the asynchronous message transmission level, effectively preventing cross-interference between multiple version messages and ensuring the reliability and consistency of message communication throughout the entire canary release process.

[0057] This disclosure provides a multi-version canary release control system for a SaaS multi-tenant software system, including: a proxy request coloring component, a front-end service node routing component, an application gateway request coloring component, an RPC framework multi-version data distribution component, multi-version front-end service nodes, and multi-version back-end service nodes; the proxy request coloring component is used to intercept the original request traffic sent by the user, color the original request traffic based on pre-built multi-version canary release rules, generate a first request traffic including coloring information, and send the first request traffic to the front-end service node routing component; the front-end service node routing component is used to receive the first request traffic, identify and process the coloring information in the first request traffic, The first request traffic is routed to the corresponding version of the front-end service node for processing. Simultaneously, the first request traffic is also routed to the application gateway request coloring component. The application gateway request coloring component receives the first request traffic, identifies the coloring information within it, and adds this information to the back-end request context of the first request traffic to obtain the second request traffic. This second request traffic is then sent to the RPC framework multi-version data distribution component. The RPC framework multi-version data distribution component receives the second request traffic, identifies the coloring information from its back-end request context, and distributes the second request traffic to the corresponding version of the back-end service node for processing based on this coloring information. This disclosure utilizes pre-built multi-version grayscale rules to perform rule matching and coloring operations at each processing node of the request traffic (including load balancers, gateways, etc.), and routes the request traffic to the corresponding version of the service node without the user noticing the coloring information. Thus, multi-version control of a multi-tenant software system is achieved through Software as a Service (SaaS), thereby meeting the personalized needs of different customers.

[0058] In other words, this disclosure allows for the simultaneous online deployment of multiple versions of the same application service based on the needs of different customers, with each version deployed on a different service node. Simultaneously, corresponding multi-version grayscale rules are preset for different customers based on their needs. Thus, when a user sends a request for the application service, the request traffic can be colored using the pre-defined multi-version grayscale rules, and the colored information can be used to route the request traffic to the corresponding version of the service node for processing. This allows for the satisfaction of the personalized service needs of different customers through different versions of the service node.

[0059] Furthermore, current SaaS systems provide a single version of application service to all users. When some customers report problems, it is necessary to force all customers to upgrade the application service version. However, the SaaS system disclosed here can deploy multiple versions of application services online simultaneously, and by building corresponding multi-version canary rules, it can achieve targeted version upgrades for some customers, enabling fine-grained management of application service versions and reducing version iteration risks.

[0060] Furthermore, since the SaaS system disclosed herein supports the parallel deployment of multiple versions of application services, new versions of application services can be tested on a small scale online. After verification, the release scope can be gradually expanded, thereby realizing a low-cost and high-efficiency A / B testing and canary release process.

[0061] Furthermore, the SaaS system disclosed herein allows multiple versions of application services to run simultaneously in an online environment and be tested independently, without the need for additional pre-release environment setup and maintenance, thereby saving hardware resources and R&D manpower, and reducing the overall cost of system development and deployment.

[0062] Furthermore, the SaaS system disclosed herein provides a centralized interface for managing canary release rules and service versions, enabling developers to quickly complete configurations such as multi-version routing, coloring, and traffic splitting, thereby improving the efficiency and operability of canary releases.

[0063] The above technologies achieve progressive effects, from basic multi-version control to supporting flexible release strategies, then to reducing system costs, and finally to facilitating the management of the R&D process. Together, they constitute a complete solution for multi-version canary release of SaaS multi-tenant software systems.

[0064] <Method Embodiment> Figure 5 shows a schematic flowchart of a multi-version grayscale control method for a SaaS multi-tenant software system according to an embodiment of the present disclosure. As shown in Figure 5, the method includes steps S1100-S1400.

[0065] S1100, the proxy request coloring component intercepts the original request traffic sent by the user, colors the original request traffic based on pre-built multi-version grayscale rules, generates a first request traffic including coloring information, and sends the first request traffic to the front-end service node routing component. The multi-version grayscale rules include at least one of grayscale rule type, rule content, adapted grayscale service information, and grayscale service activation status. The coloring information includes at least one of whether the grayscale version of the service is enabled and the grayscale version of the service pointed to by the original request traffic. S1200, the front-end service node routing component receives the first request traffic, identifies and, based on the coloring information in the first request traffic, routes the first request traffic to the front-end service node routing component. Traffic is routed to the corresponding version of the front-end service node for processing. At the same time, the first request traffic is routed to the application gateway request coloring component. In S1300, the application gateway request coloring component receives the first request traffic, identifies the coloring information from the first request traffic, and adds the coloring information to the back-end request context of the first request traffic to obtain the second request traffic. The second request traffic is then sent to the RPC framework multi-version data distribution component. In S1400, the RPC framework multi-version data distribution component receives the second request traffic, identifies the coloring information from the back-end request context in the second request traffic, and distributes the second request traffic to the corresponding version of the back-end service node for processing based on the coloring information.

[0066] In one possible implementation, the proxy request coloring component, when coloring the original request traffic based on pre-built multi-version grayscale rules to generate a first request traffic including coloring information, includes: parsing user information and service nodes required to respond to the original request traffic from the original request traffic; matching the user information and service nodes with each multi-version grayscale rule to obtain the matching result of the multi-version grayscale rule; and coloring the original request traffic based on the matching result to generate a first request traffic including coloring information.

[0067] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A multi-version grayscale control system for a SaaS multi-tenant software system, characterized in that, include: The system comprises a proxy request coloring component, a front-end service node routing component, an application gateway request coloring component, an RPC framework multi-version data distribution component, multi-version front-end service nodes, and multi-version back-end service nodes. The proxy request coloring component intercepts raw request traffic sent by users, colores the raw request traffic based on pre-built multi-version grayscale rules, generates a first request traffic including coloring information, and sends the first request traffic to the front-end service node routing component. The multi-version grayscale rules include at least one of grayscale rule type, rule content, adapted grayscale service information, and grayscale service activation status. The coloring information includes at least one of whether a grayscale version of the service is enabled and the grayscale version of the service pointed to by the raw request traffic. The front-end service node routing component receives the first request traffic. The system identifies and routes the first request traffic to the corresponding version of the front-end service node for processing based on the coloring information in the first request traffic. Simultaneously, it routes the first request traffic to the application gateway request coloring component. The application gateway request coloring component receives the first request traffic, identifies the coloring information in the first request traffic, adds the coloring information to the back-end request context of the first request traffic to obtain the second request traffic, and sends the second request traffic to the RPC framework multi-version data distribution component. The RPC framework multi-version data distribution component receives the second request traffic, identifies the coloring information from the back-end request context of the second request traffic, and distributes the second request traffic to the corresponding version of the back-end service node for processing based on the coloring information.

2. The system according to claim 1, characterized in that, The proxy request coloring component, when coloring the original request traffic based on pre-built multi-version grayscale rules to generate a first request traffic including coloring information, is specifically used for: parsing the user's user information and the service pointed to by the original request traffic from the original request traffic; matching the user information and the pointed-to service section with each of the multi-version grayscale rules to obtain the matching result of the multi-version grayscale rules; and coloring the original request traffic based on the matching result to generate a first request traffic including coloring information.

3. The system according to claim 1, characterized in that, It also includes a message queue multi-version data coloring and distribution component; the message queue multi-version data coloring and distribution component is used to create a corresponding gray-scale message producer for the service node that generates the gray-scale version of the message. When the service node of the gray-scale version generates the initial message, the gray-scale message producer will color the initial message based on the pre-built multi-version gray-scale rules to generate a colored message including coloring information, and route the colored message to the corresponding message queue.

4. The system according to claim 3, characterized in that, The message queue multi-version data coloring distribution component is also used to: create ordinary consumers and gray consumers for service nodes that process messages in the message queue. The ordinary consumers are used to pull uncolored messages in the message queue for processing, and the gray consumers are used to pull colored messages in the message queue for processing.

5. The system according to claim 1, characterized in that, Also includes: A multi-version data coloring and distribution component for scheduled tasks; the multi-version data coloring and distribution component for scheduled tasks is used to monitor the scheduled task request traffic in service nodes of multiple versions. When the scheduled task request traffic is detected, the component colors the scheduled task request traffic based on pre-built multi-version grayscale rules and distributes the colored scheduled task request traffic to the corresponding version service nodes for processing.

6. The system according to claim 5, characterized in that, Also includes: Multi-version scheduled task management module; the multi-version scheduled task management module is used to configure and manage the versions of each scheduled task.

7. The system according to claim 1, characterized in that, Also includes: A multi-version grayscale rule management module; the multi-version grayscale rule management module is used to receive multi-version grayscale rule information input by the user, and create corresponding multi-version grayscale rules based on the multi-version grayscale rule information.

8. The system according to claim 1, characterized in that, Also includes: Multi-version application service management module; the multi-version application service management module is used to configure and manage the version information of each application service.

9. A method for controlling the grayscale release of multiple versions in a SaaS multi-tenant software system, characterized in that, include: The proxy request coloring component intercepts the original request traffic sent by the user, colors the original request traffic based on pre-built multi-version grayscale rules, generates a first request traffic including coloring information, and sends the first request traffic to the front-end service node routing component. The multi-version grayscale rules include at least one of grayscale rule type, rule content, adapted grayscale service information, and grayscale service activation status. The coloring information includes at least one of whether the grayscale version of the service is enabled and the grayscale version of the service pointed to by the original request traffic. The front-end service node routing component receives the first request traffic, identifies and routes the first request traffic to the appropriate service based on the coloring information in the first request traffic. The front-end service node of the corresponding version processes the first request traffic, and simultaneously routes the first request traffic to the application gateway request coloring component. The application gateway request coloring component receives the first request traffic, identifies the coloring information from the first request traffic, adds the coloring information to the back-end request context of the first request traffic to obtain the second request traffic, and sends the second request traffic to the RPC framework multi-version data distribution component. The RPC framework multi-version data distribution component receives the second request traffic, identifies the coloring information from the back-end request context in the second request traffic, and distributes the second request traffic to the corresponding version of the back-end service node for processing based on the coloring information.

10. The method according to claim 9, characterized in that, The proxy request coloring component, when coloring the original request traffic based on pre-built multi-version grayscale rules to generate a first request traffic including coloring information, includes: parsing the user's user information and the service node required to respond to the original request traffic from the original request traffic; matching the user information and the service node with each of the multi-version grayscale rules to obtain the matching result of the multi-version grayscale rules; and coloring the original request traffic based on the matching result to generate a first request traffic including coloring information.

Images