Low-intrusion multi-tenant support method and system

Abstract

The invention discloses a low-intrusion multi-tenant support method and system, and relates to the technical field of data engines, and the method comprises the following steps: S1, defining a global tenant context for storing a tenant identifier of a current request, and controlling the enabling of a multi-tenant function through a context thread switch; s2, setting different technical components according to different data storage modes; s3, the technical component automatically writes a tenant identifier into a request header, and performs multi-tenant isolation processing according to different middleware and data storage modes; s4, the technical component injects the tenant identifier into the request header through the Feign interceptor, and the called service repeats the steps S1-S3; and S5, after the request processing is completed, clearing the tenant context information of the current thread so as to avoid thread leakage. According to the low-intrusion multi-tenant supporting method and system, modification of existing codes can be reduced while multiple tenants are supported, the development and maintenance difficulty is lowered, and practicability is improved.

Description

Technical Field

[0001] This invention relates to the field of data engine technology, and specifically to a low-intrusion multi-tenant support method and system. Background Technology

[0002] With the rapid development of cloud computing technology, Software as a Service (SaaS) has become the mainstream software delivery method. Its core requirement is to provide services to multiple independent tenants through a single software system, while ensuring that the data, configurations, and resources of each tenant are isolated and do not interfere with each other. For the above situation, traditional implementation methods usually require deploying a separate system for each tenant, or making extensive modifications to the existing system. This approach not only has high development and maintenance costs, but may also introduce performance and security risks to the system.

[0003] To address the aforementioned issues, several solutions for multi-tenancy have emerged in existing technologies. For example, some SaaS platforms provide multi-tenant database access components that allow different tenants to use different database instances or schemas through dynamic data source switching. The dynamic data source is typically the Baomidou Dynamic-Datasource component, which supports dynamically adding and deleting data sources. Other approaches achieve logical isolation by adding tenant ID filtering at the data access layer.

[0004] However, the existing solutions often suffer from problems such as high invasiveness, complex integration, and poor scalability. For example, some solutions require modifications to a large amount of business code or SQL statements to add tenant conditions. Different modifications are usually required for different tenants. Since different tenants correspond to different data sources, it is necessary to add data source selection, logical judgment, and tenant ID information for different tenants to each business code. SQL needs to add filtering conditions for different tenants, for example, the data source for tenant 1 is xxxx_scpg, and the data source for tenant 2 is xxxx_bgbu, thus increasing the difficulty of development and maintenance. Other solutions lack unified support for multiple middleware and data storage, making it difficult to handle tenant isolation of different components in a single system, such as relational databases, NoSQL databases, caches, and message queues. Therefore, to overcome the above defects, a multi-tenant support solution that can achieve low invasiveness and easy scalability is needed. This invention addresses this technical problem. Summary of the Invention

[0005] This invention provides a low-intrusion multi-tenancy support method and system that can support multi-tenancy while reducing modifications to existing code, lowering development and maintenance difficulty, and simultaneously handling tenant isolation of different components, thus improving practicality.

[0006] A low-intrusion multi-tenancy support method includes the following steps:

[0007] Define a global tenant context to store the tenant identifier of the current request, and control the enabling of multi-tenancy functionality through a context thread switch;

[0008] Different technical components are set up for different data storage methods, and each of the technical components automatically obtains the current tenant identifier from the tenant context;

[0009] The technical components automatically write the tenant identifier into the request header. Each technical component calls the tenant service interface to obtain the data corresponding to the tenant according to the preset isolation strategy. Multi-tenant isolation processing is performed according to different middleware and data storage methods.

[0010] When microservice calls are involved, the technical component injects the tenant identifier into the request header through the Feign interceptor. The called service repeats steps S1-S3 to ensure that the tenant identifier is not lost in the call chain.

[0011] After the request is processed, the tenant context information of the current thread is cleared to prevent thread leaks.

[0012] Furthermore, the steps for defining a global tenant context and controlling the enabling of multi-tenancy functionality through a context thread switch are as follows:

[0013] Configure the TenantContextHolder interface;

[0014] After a tenant initiates a business request, the tenant ID is extracted from the HTTP request header through the SDK's built-in filter, and the tenant ID is set to the context through the TenantContextHolder interface to achieve automatic transmission of the tenant identifier.

[0015] The context thread switch controls the activation of each of the technical components through the TenantContextHolder interface.

[0016] Furthermore, the technical components include at least one of the following components:

[0017] MyBatis multi-tenant component: used to implement multi-tenant isolation support for relational databases, including physical isolation strategies based on multiple data sources and logical isolation strategies based on tenant fields;

[0018] MQ multi-tenant component: used to implement multi-tenant isolation support for message queues, providing physical isolation strategies and logical isolation strategies;

[0019] MongoDB multi-tenancy component: used to implement multi-tenancy isolation support for the NoSQL database MongoDB, with different tenants corresponding to different databases;

[0020] Redis multi-tenant component: Used to implement multi-tenant isolation support for caching, achieving logical isolation by automatically adding a tenant ID prefix to the cache key;

[0021] Web multi-tenant component: Used to pass tenant context in microservice call chains, ensuring that cross-service requests carry the correct tenant identifier.

[0022] Furthermore, when the technical component includes the MyBatis multi-tenant component, the isolation processing steps are as follows:

[0023] When configuring a physical isolation strategy, the MyBatis multi-tenant component integrates the Baomidou Dynamic-Datasource component to dynamically switch to the tenant's dedicated database based on the current tenant identifier.

[0024] When configuring a logical isolation strategy, a tenant identifier filter condition is automatically injected into the business SQL through an SQL parsing interceptor to achieve row-level isolation.

[0025] Furthermore, when the technical components include an MQ multi-tenant component, the isolation processing steps are as follows:

[0026] When configuring a physical isolation policy, different tenants use different message topics, and automatic routing is achieved by automatically appending the tenant code to the message topic name;

[0027] When configuring a logical isolation policy, add a tenant identifier to the message header. All tenants share the same topic, and different tenants are distinguished by the tenant identifier in the message header.

[0028] The consumer listens to all tenant messages using a regular expression Topic pattern and filters messages from other tenants besides the target tenant based on the tenant identifier.

[0029] Furthermore, when the technical components include the Redis multi-tenant component, the isolation processing steps are as follows:

[0030] Encapsulate RedisTemplate to automatically append the current tenant identifier when storing cache keys, and use the appended tenant identifier as a prefix. Automatically remove the prefix when reading.

[0031] This distributed lock service is implemented based on Redisson, with the lock name automatically prefixed with a tenant identifier to achieve lock isolation across tenants.

[0032] Furthermore, when the technical component includes a Web multi-tenant component, the pass-through steps are as follows:

[0033] Encapsulate the Feign client interceptor to automatically extract the tenant identifier from the tenant context and add it to the request header when making cross-service calls;

[0034] The called service extracts the tenant identifier from the request header through a filter and sets it to the local context so that microservices can share the same tenant context.

[0035] A low-intrusion multi-tenancy support system, based on the above-mentioned low-intrusion multi-tenancy support method, includes:

[0036] The multi-tenant context management module is used to define the global tenant context, provide interfaces for setting, getting, and clearing tenant identifiers, and context thread switches, and realize the binding of tenant identifiers to threads;

[0037] The modular technology component layer includes MyBatis multi-tenant components, MQ multi-tenant components, Redis multi-tenant components, MongoDB multi-tenant components, and Web multi-tenant components. Each component independently encapsulates the multi-tenant isolation logic of the corresponding middleware for on-demand activation.

[0038] The configuration management module adopts a configuration-driven design, providing global configuration and component-specific configuration.

[0039] The tenant business component module is used to encapsulate the tenant service interface and query the current tenant's detailed information and configuration.

[0040] Furthermore, the system adopts a Maven multi-module project structure, with each technical component being independently encapsulated as a SpringBootStarter for referencing the corresponding technical component as needed.

[0041] One or more technical solutions proposed in this application have at least the following technical effects:

[0042] (1) This solution adopts a low-intrusion design. Different technical components can be used to process different data sources. Staff can refer to the corresponding technical components as needed, so that the corresponding technical components can obtain the tenant identifier and obtain the data source corresponding to the tenant. This allows the tenant to obtain only its own data and not the data of other tenants, thus realizing the tenant isolation function. Moreover, this function is implemented through the corresponding technical components without making major modifications to the original business code, thereby reducing the difficulty of development and maintenance and achieving the effect of low intrusion.

[0043] (2) In this solution, staff can reference technical components as needed without referencing all technical components. Therefore, unreferenced technical components will not affect the system, making the system safer and more convenient to use. It can be flexibly applied to different business scenarios. Furthermore, each technical component is independently encapsulated as SpringBootStarter, which facilitates the extension of new technical components through the above methods, enabling the system to achieve scalable functionality and further improving its practicality.

[0044] (3) Each technical component in this solution can implement different isolation strategies for different resources. At the data level, physical isolation and logical isolation are supported. At the cache level, tenants are distinguished by prefix. At the message queue level, topic isolation and tenant identifier filtering are supported. At the service call level, the tenant identifier is not lost by passing through context. Thus, the above methods cover a variety of different isolation strategies, which helps to achieve effective isolation of multiple tenants. Attached Figure Description

[0045] Figure 1 This is a diagram of the distributed multi-tenant service architecture for SaaS scenarios in this invention;

[0046] Figure 2 This is a flowchart illustrating the SQL execution process of MyBatis combined with the multi-tenant plugin in this invention.

[0047] Figure 3 This is a flowchart of the multi-tenant message isolation processing of the message queue in this invention;

[0048] Figure 4 This is a flowchart of the remote call initiated by the Feign client in this invention. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0050] It should be noted that if the embodiments of the present invention involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a specific posture. If the specific posture changes, the directional indicators will also change accordingly.

[0051] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the use of "and / or" or "and / or" throughout the text includes three parallel solutions. For example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0052] See Figures 1-4 This invention proposes a low-intrusion multi-tenancy support method, comprising the following steps:

[0053] Define a global tenant context to store the tenant identifier of the current request, and control the enabling of multi-tenancy functionality through a context thread switch;

[0054] Different technical components are set up for different data storage methods, and each technical component automatically obtains the current tenant identifier from the tenant context;

[0055] The technical components automatically write the tenant identifier into the request header. Each technical component calls the tenant service interface to obtain the data corresponding to the tenant according to the preset isolation strategy, and performs multi-tenant isolation processing according to different middleware and data storage methods.

[0056] When microservice calls are involved, the technical components inject the tenant identifier into the request header through the Feign interceptor. The called service repeats steps S1-S3 to ensure that the tenant identifier is not lost in the call chain.

[0057] After the request is processed, the tenant context information of the current thread is cleared to prevent thread leaks.

[0058] In this solution, the tenant identifier serves as the tenant's identity credential, with the core carrier being the tenant ID. The tenant context is an extended storage method for the tenant identifier, containing the tenant ID and other additional information.

[0059] Furthermore, the steps for defining a global tenant context and controlling the enabling of multi-tenancy functionality through a context thread switch are as follows:

[0060] Configure the TenantContextHolder interface;

[0061] After a tenant initiates a business request, the tenant ID is extracted from the HTTP request header through the SDK's built-in filter, and then set to the context through the TenantContextHolder interface to enable the automatic transmission of tenant identification.

[0062] The context thread switch controls the activation of various technical components through the TenantContextHolder interface. It can achieve global activation for all technical components, as well as component-level activation for individual technical components, which can be controlled according to actual needs.

[0063] Furthermore, the technical components include at least one of the following components:

[0064] MyBatis multi-tenant component: used to implement multi-tenant isolation support for relational databases, including physical isolation strategies based on multiple data sources and logical isolation strategies based on tenant fields;

[0065] MQ multi-tenant component: used to implement multi-tenant isolation support for message queues, providing physical isolation strategies and logical isolation strategies;

[0066] MongoDB multi-tenancy component: used to implement multi-tenancy isolation support for the NoSQL database MongoDB, with different tenants corresponding to different databases;

[0067] Redis multi-tenant component: Used to implement multi-tenant isolation support for caching, achieving logical isolation by automatically adding a tenant ID prefix to the cache key;

[0068] Web multi-tenant component: Used to pass tenant context in microservice call chains, ensuring that cross-service requests carry the correct tenant identifier.

[0069] Furthermore, when the technical components include MyBatis multi-tenant components, the isolation processing steps are as follows:

[0070] When configuring a physical isolation strategy, the MyBatis multi-tenant component integrates the Baomidou Dynamic-Datasource component to dynamically switch to the tenant's dedicated database based on the current tenant identifier.

[0071] When configuring a logical isolation strategy, a tenant identifier filter condition is automatically injected into the business SQL through an SQL parsing interceptor to achieve row-level isolation.

[0072] Furthermore, when the technical components include MQ multi-tenant components, the isolation processing steps are as follows:

[0073] When configuring a physical isolation policy, different tenants use different message topics, and automatic routing is achieved by automatically appending the tenant code to the message topic name;

[0074] When configuring a logical isolation policy, add a tenant identifier to the message header. All tenants share the same topic, and different tenants are distinguished by the tenant identifier in the message header.

[0075] The consumer listens to all tenant messages using regular expression Topic patterns and filters messages from other tenants besides the target tenant based on the tenant identifier.

[0076] Furthermore, when the technical components include Redis multi-tenant components, the isolation processing steps are as follows:

[0077] Encapsulate RedisTemplate to automatically append the current tenant identifier when storing cache keys, and use the appended tenant identifier as a prefix. Automatically remove the prefix when reading.

[0078] This distributed lock service is implemented based on Redisson, with the lock name automatically prefixed with a tenant identifier to achieve lock isolation across tenants.

[0079] For automatic data concatenation, a corresponding SDK component is introduced. When data enters the Redis cache, the SDK component automatically concatenates the data and tenant ID. This step is completed automatically by the SDK component. For example, when the cache key is "abc" and the tenant ID is "scpg", the corresponding SDK component will add "scpg" before "abc", and the final key stored in Redis will be "scpg-abc".

[0080] Regarding automatic retrieval, given the tenant ID as scpg and the key as abc, when data is retrieved from Redis by scpg-abc and returned to the caller, the corresponding SDK component will automatically remove the tenant ID. After that, the key will be returned to the caller as abc, thus achieving automatic removal of the prefix.

[0081] Furthermore, when the technical components include Web multi-tenant components, the pass-through steps are as follows:

[0082] Encapsulate the Feign client interceptor to automatically extract the tenant identifier from the tenant context and add it to the request header when making cross-service calls;

[0083] The called service extracts the tenant identifier from the request header through a filter and sets it to the local context so that microservices can share the same tenant context.

[0084] A low-intrusion multi-tenancy support system, based on the above-mentioned low-intrusion multi-tenancy support method, includes:

[0085] The multi-tenant context management module is used to define the global tenant context, provide interfaces for setting, getting, and clearing tenant identifiers, and context thread switches, and realize the binding of tenant identifiers to threads;

[0086] The modular technology component layer includes MyBatis multi-tenant components, MQ multi-tenant components, Redis multi-tenant components, MongoDB multi-tenant components, and Web multi-tenant components. Each component independently encapsulates the multi-tenant isolation logic of the corresponding middleware for on-demand activation.

[0087] The configuration management module adopts a configuration-driven design, providing global configuration and component-specific configuration.

[0088] The tenant business component module is used to encapsulate the tenant service interface and query the current tenant's detailed information and configuration.

[0089] The system in this solution is specifically a software development kit (SDK).

[0090] Furthermore, the system adopts a Maven multi-module project structure, with each technical component being independently encapsulated as a SpringBootStarter, allowing relevant personnel to reference the corresponding technical components as needed.

[0091] See Figure 1 , Figure 1 The paper illustrates the layered architecture and module collaboration relationships of this invention, including a multi-tenant context module, technical component modules (database, message queue, cache, NoSQL, Web components, etc.), tenant business component modules, and a configuration management module. Each module collaborates through a common context and configuration center. Modular decomposition facilitates middleware adaptation and tenant isolation, and simplifies integration and configuration, thereby enabling the system to achieve low-intrusion and modular functionality.

[0092] See Figure 2 This demonstrates the implementation process of dynamic data source switching and SQL tenant filtering. When the system executes database operations, the component selects the corresponding data source based on the current tenant ID and automatically adds the tenant ID condition before SQL execution, achieving isolated access to tenant data.

[0093] See Figure 3 This demonstrates how topics are handled under both physical and logical isolation modes. During sending, the component automatically modifies the topic name or adds tenant header information based on the strategy; during consumption, it matches the topic using regular expressions and filters messages from the current tenant based on the header information.

[0094] See Figure 4When service A calls service B via Feign, the web component adds the tenant ID to the request header; after receiving the request, service B extracts the tenant ID from the header and sets it to the local context to ensure that the processing logic uses the correct tenant information.

[0095] Example 1

[0096] This example demonstrates the module structure and dependencies of the multi-tenant SDK. The SDK is built using Maven multi-modules and includes:

[0097] Parent module: scpg-saas-pro-master, used for unified management of sub-modules.

[0098] Submodules include the following two types:

[0099] 1. scpg-saas-dependencies: Used to uniformly manage the version numbers of all dependency libraries, ensuring that the versions of third-party libraries are consistent.

[0100] 2. scpg-saas-framework: The core SDK framework, further divided into 7 functional sub-modules (all SpringBootStarter). It uses `spring.factories` to declare auto-configuration classes, enabling automatic configuration during application startup. The application mentioned here is specifically a microservice application built on the Spring Boot framework. This solution introduces scpg-saas-framework into the original microservice application, enabling it to handle multi-tenancy.

[0101] Usage: Applications enable the corresponding multi-tenant component (MyBatis multi-tenant component) by introducing the required Starter dependency (such as scpg-saas-starter-mybatis:1.0.1). The modular design of each multi-tenant component allows developers to flexibly choose the corresponding technology component while ensuring that the dependency relationship is clear and controllable.

[0102] The seven functional sub-modules mentioned above correspond to the MyBatis multi-tenant component, MQ multi-tenant component, Redis multi-tenant component, MongoDB multi-tenant component, Web multi-tenant component, context management module, and configuration management module, respectively.

[0103] Example 2

[0104] This embodiment describes how to pass and obtain tenant identifiers through a multi-tenant context, where the core relies on the TenantContextHolder utility class of the scpg-saas-common module.

[0105] The core method is as follows:

[0106] setTenantId(ObjecttenantId): Sets the tenant ID of the current thread;

[0107] getTenantId(): Gets the current tenant ID;

[0108] clearTenantId(): Clears the tenant ID;

[0109] setIgnore(Booleanignore) and component-level ignore switches (such as setIgnoreMybatis(true)): control whether to ignore multi-tenant isolation (the default is false).

[0110] Tenant ID Transfer Process:

[0111] In web applications: The SDK has a built-in filter / interceptor that extracts the tenant ID from the HTTP request header (such as X-Tenant-ID) and sets it to the thread context using TenantContextHolder.setTenantId(tenantId). The specific code is as follows:

[0112] Java

[0113] / / Filter example code

[0114] String tenantId = request.getHeader("X-Tenant-ID");

[0115] if (tenantId != null) {

[0116] TenantContextHolder.setTenantId(tenantId);

[0117] }

[0118] Using the above method, the filter / interceptor can automatically inject and clean up tenant identifiers without requiring manual intervention from the developer.

[0119] Cross-service calls: The Feign interceptor of the web component automatically adds TenantContextHolder.getTenantId() to the request header (i.e., the tenant identifier). The called service extracts and sets the tenant identifier to the local context through the filter, realizing the pass-through of the tenant identifier in a distributed environment.

[0120] Note: After the request is processed, you need to call TenantContextHolder.clear() to clear the context to avoid thread leaks and help prevent tenant data leaks.

[0121] Example 3

[0122] This example illustrates multi-tenancy support for relational databases and requires the inclusion of scpg-saas-starter-mybatis:1.0.1.

[0123] Dynamic data source configuration (physical isolation): Configure data source parameters in application.properties:

[0124] properties

[0125] #Basic Configuration

[0126] spring.datasource.dynamic.primary=master

[0127] spring.datasource.dynamic.strict=false

[0128] spring.datasource.dynamic.task.enable=true # Refresh the data source periodically (default 60 seconds)

[0129] #Example of tenant data source

[0130] spring.datasource.dynamic.datasource.master.url=jdbc:mysql: / / xxx:3306 / master_db

[0131] spring.datasource.dynamic.datasource.tenant1.url=jdbc:mysql: / / xxx:3306 / tenant1_db

[0132] Supports encrypted password storage (format ENC(encrypted string)), which is automatically decrypted when the SDK starts.

[0133] Data source switching methods:

[0134] Annotation method: @DS("tenant1") or SpEL expression @DS("#{tenantId}");

[0135] Programming method: DynamicDataSourceContextHolder.push("tenant1") (requires pop() to restore the original data source).

[0136] Logical isolation configuration: Within the same database, isolation can be achieved through the tenant field, configured as follows:

[0137] properties

[0138] mybatis.tenant.config.enable=true

[0139] mybatis.tenant.config.tenantIdColumn=tenant_id#tenant field name

[0140] mybatis.tenant.config.ignoreTableNames=role,user_role # Tables that do not need to be isolated.

[0141] The SDK's SQL interceptor will automatically add the condition WHERE tenant_id = current tenant ID to non-ignore tables.

[0142] Transaction support:

[0143] Local multi-data source transactions: Use the @DSTransactional annotation;

[0144] Distributed transactions: Configure spring.datasource.dynamic.seata=true and integrate the Seata framework.

[0145] Thus, multi-tenancy support is achieved through the above methods.

[0146] Example 4

[0147] This embodiment implements multi-tenant isolation of Kafka messages, which requires the introduction of scpg-saas-starter-mq:1.0.1.

[0148] Basic configuration:

[0149] properties

[0150] spring.kafka.bootstrap-servers=xxx:9092

[0151] spring.kafka.listener.type=single # Must be a single-threaded listener

[0152] Multi-tenant isolation strategy configuration:

[0153] properties

[0154] spring.kafka.properties.tenant.enable=true

[0155] spring.kafka.properties.tenant.topic.logical.list=topicA, topicB #Logically isolated topics

[0156] spring.kafka.properties.tenant.topic.physical.list=topicC,topicD#Physically isolated topics

[0157] Logical isolation: The topic name is appended with a suffix (default is SHARE, such as topicA-SHARE), and the tenant ID is carried in the message header;

[0158] Physical isolation: The topic name is concatenated with the tenant ID (e.g., topicC-tenant1), and each tenant uses the topic independently.

[0159] Message sending and consumption:

[0160] Sending: Use the SDK's KafkaTemplate to automatically handle topic names and message headers:

[0161] Java

[0162] kafkaTemplate.send("topicA", message); / / Automatically route to logical / physical topics

[0163] Consumption: By matching topics using regular expressions, the SDK automatically parses the tenant ID and sets it to the context.

[0164] Java

[0165] @KafkaListener(topicPattern="topicA.*")

[0166] publicvoidlisten(Stringmessage){

[0167] String tenantId = TenantContextHolder.getTenantId(); / / Directly retrieve the tenant ID

[0168] }

[0169] Dynamic control: Temporarily disable multi-tenancy processing by using TenantContextHolder.setIgnoreMq(true).

[0170] Example 5

[0171] This embodiment implements tenant isolation for caching, which requires the introduction of scpg-saas-starter-redis:1.0.1.

[0172] Configuration items:

[0173] properties

[0174] spring.redis.host=127.0.0.1

[0175] `redis.tenant.config.enable=true` # Enable multi-tenant caching

[0176] redis.tenant.config.separator=_ # Tenant prefix separator (default _)

[0177] Cache operations: The SDK's RedisTemplate automatically adds a tenant prefix to the key (e.g., tenant1_user:123), eliminating the need for manual handling by developers.

[0178] Java

[0179] redisTemplate.opsForValue().set("user:123","userInfo"); / / The actual key is tenant1_user:123

[0180] Distributed lock: Implemented based on Redisson, the lock name is automatically prefixed with the tenant to avoid cross-tenant conflicts.

[0181] Java

[0182] RLocklock=redissonClientService.getLock("order:lock"); / / The lock name is automatically concatenated with the tenant ID.

[0183] Example 6

[0184] To implement the pass-through of tenant context in microservice calls, the example requires the inclusion of scpg-saas-starter-web:1.0.1.

[0185] Configuration:

[0186] properties

[0187] web.tenant.config.tenant-header-name=x-tenant-id#Tenant header name

[0188] Tenant delivery mechanism:

[0189] Feign call: The interceptor automatically adds the tenant ID to the request header;

[0190] Service reception: The filter extracts the tenant ID from the request header and sets it into the context to ensure tenant consistency across service calls.

[0191] Verification example: Print the tenant ID in the controller of service B to verify the validity of the transmitted ID:

[0192] Java

[0193] @GetMapping(" / api / data")

[0194] publicString getData(){

[0195] return"Datafortenant:"+TenantContextHolder.getTenantId();

[0196] }

[0197] Example 7

[0198] This example demonstrates how tenant information is obtained through the tenant business component (scpg-saas-starter-biz-tenant).

[0199] Core interface: TenantService, providing tenant information query capabilities:

[0200] Java

[0201] @Service

[0202] public class MyService{

[0203] @Autowired

[0204] privateTenantServicetenantService;

[0205] public void doSomething(){

[0206] / / Get current tenant information

[0207] Tenanttenant=tenantService.getCurrentTenant();

[0208] / / Get tenant configuration

[0209] Stringtheme=tenantService.getTenantConfig("ui.theme");

[0210] }

[0211] }

[0212] The component internally retrieves the tenant ID from the context, calls the tenant service interface to obtain data, and supports personalized business logic.

[0213] Example 8

[0214] This example illustrates the SDK's configuration system and extensibility.

[0215] Layered configuration model:

[0216] Global configuration: Global parameters in application.properties;

[0217] Component configuration: Specific configurations for each component (e.g., mybatis.tenant.config.*);

[0218] Thread-level configuration: Dynamically override via TenantContextHolder (e.g., temporarily disable multi-tenancy with setIgnore(true)).

[0219] Dynamic configuration refresh: Supports dynamic updates of configurations such as data sources and isolation policies without restarting the application (refreshes every 60 seconds by default).

[0220] Extension method:

[0221] Custom Starter: Develop new components according to specifications (such as Elasticsearch multi-tenancy support);

[0222] Interface extension: Implement interfaces such as DynamicDataSourceProvider to customize data source loading logic;

[0223] Event Listening: Listen for events such as tenant context changes and data source switching through the Spring event mechanism. Log or monitoring functions can be extended according to actual needs.

[0224] The following is a further explanation of this scheme with reference to the accompanying drawings:

[0225] See Figure 1

[0226] 1. User Access Layer

[0227] The user access layer is located at Figure 1 The leftmost element is the tenant-side access point, covering the following aspects:

[0228] Terminal types: Mini Program, PC, Web, and mobile, covering access scenarios for multiple terminal tenants;

[0229] Pre-processing acceleration: CDN+LB (used for load balancing) is used to distribute and cache tenant requests, accelerating their delivery and serving as the first point of contact for incoming traffic. CDN is responsible for caching and accelerating tenant requests, reducing latency for cross-regional access; LB performs initial request distribution, avoiding single-node overload and providing stable traffic input for subsequent services.

[0230] 2. Entry and Authentication / Authorization Layer

[0231] The entry point and authentication / authorization layer is located in the middle of the left side of the diagram. It is the core front-end layer for tenant identification and access control, and includes the following components:

[0232] Nginx (used for load balancing): As the next level of traffic entry after CDN, it takes over the traffic of CDN and forwards the received requests to the Gateway.

[0233] Gateway (orange module): Its core functions are mainly reflected in the following three aspects:

[0234] Tenant identification: Extract tenant identifiers (such as tenant ID) from requests, supporting multiple extraction methods such as request headers and domain suffixes;

[0235] Permission verification: Verify the current tenant's access permissions to determine whether the tenant has permission to call the target service;

[0236] Request filtering: Blocks illegal / unauthorized tenant requests to ensure service security.

[0237] 3. Service Registration and Configuration Layer

[0238] The service registration and configuration layer is located in the upper middle part of the diagram. It supports multi-tenant configuration and service management, and includes the following components:

[0239] Service Registry (Eureka / Nacos): Manages instance information for all backend services. Multi-tenant components can obtain the deployment nodes of each service through this registry to enable service routing for tenant requests.

[0240] Configuration Center (Nacos): Stores personalized configurations for multiple tenants, including data source addresses and isolation policies for different tenants. The multi-tenant component dynamically pulls tenant configurations from here to achieve "unified management and dynamic distribution of tenant configurations".

[0241] 4. Core Service Cluster Layer

[0242] The core service cluster layer, represented by the green and red modules in the middle of the diagram, is the layer that carries business capabilities and multi-tenant logic. It is divided into "Business Services" and "Multi-tenant Core Components":

[0243] Business services (green modules): These include business function modules such as permission services, traffic control services, and notification services. Each service needs to rely on "multi-tenant components" to achieve tenant-level isolation and avoid interference between business data of different tenants.

[0244] Multi-tenant component (red box, i.e., the multi-tenant base in the diagram): The core engine of the entire multi-tenant architecture, its function is:

[0245] (1) Inject "tenant context" (such as the tenant ID of the current request) into each business service;

[0246] (2) Coordinate the "tenant isolation rules" (such as data isolation and resource isolation) of various services;

[0247] (3) Connect to the configuration center and service registration center to synchronize the tenant's service / configuration information.

[0248] 5. Data storage layer

[0249] The data storage layer, located in the lower middle part of the diagram, is the core carrier of multi-tenant data isolation, achieving tenant data isolation through a combination of physical and logical isolation.

[0250] (1) Cache layer (Redis cluster): Stores frequently accessed data of tenants (such as sessions and configurations), and achieves logical isolation by "key prefix concatenated with tenant ID";

[0251] (2) Database layer (MySQL master-slave / multi-instance):

[0252] Physical isolation: By using "multiple instances (MySQL Master / Slave + multiple databases in the diagram)" to correspond to independent databases for different tenants, that is, by allocating independent databases to different tenants, physical isolation of data is achieved;

[0253] Logical isolation: When some tenants share an instance, data differentiation is achieved by "carrying the tenant ID in the table field";

[0254] (3) Log storage (ELK): Stores the operation / service logs of each tenant, and enables independent querying of tenant logs through "log tags carrying tenant IDs";

[0255] (4) Task scheduling (xxl-job): Supports "tenant-level scheduled tasks", such as scheduled data synchronization tasks for different tenants, and independent scheduled tasks can be configured for different tenants;

[0256] (5) File storage (OSS): Physical isolation of tenant files is achieved by using "bucket prefix / directory to distinguish tenant ID".

[0257] 6. Middleware Service Layer

[0258] The middleware service layer, located on the right side of the diagram, is the distributed foundation supporting business operations and is also adaptable to multi-tenant scenarios.

[0259] Component types include MQ (Message Queues), ES (Search Engine), and Redis (Cache).

[0260] Multi-tenant adaptation logic: For example, MQ achieves physical isolation of tenant messages by "concatenating tenant ID with topic name", and ES achieves independent retrieval of tenant data by "carrying tenant ID with index prefix".

[0261] 7. Monitoring and Governance Layer

[0262] The monitoring and governance layer, located in the upper right corner of the diagram, enables "observability and stability control" of multi-tenant services and includes the following components:

[0263] Skywalking: Enables full-link tracing of tenant requests, allowing you to locate the service call chain of a single tenant request, making it easier to detect tenant anomalies in a timely manner;

[0264] APM monitoring (Prometheus + Grafana): Monitors resource usage and service performance of each tenant (such as interface response time and QPS for a tenant).

[0265] Distributed transactions (Seata): Ensure data transaction consistency when the same tenant makes cross-service calls, avoiding data inconsistency issues caused by distributed calls.

[0266] 8. Infrastructure Layer

[0267] The infrastructure layer, located at the bottom of the diagram, is the deployment platform for the architecture, supporting elastic scaling across multiple tenants. It includes the following components:

[0268] Components: cloud servers, container services (TKE), Kubernetes+Docker, image repositories (TCR), etc.

[0269] Multi-tenant value: Through containerization and elastic scaling (HPA), the service instance corresponding to a tenant ID can be scaled up individually based on the traffic fluctuations of a tenant (e.g., if the traffic of tenant 1 doubles due to the activity of tenant 1, only the service node associated with tenant 1 is scaled up), thus achieving "tenant-level resource elasticity".

[0270] The working process of the above architecture is as follows:

[0271] The user access layer's request, after the entry and authentication / authorization layer identifies the tenant ID, is passed to the multi-tenant component. The multi-tenant component writes the tenant ID into the global context and synchronously pulls the tenant's isolation policy from the configuration center. The multi-tenant component distributes the tenant ID and isolation policy to the technical components of the data storage layer / middleware service layer, triggering the corresponding isolation logic. The monitoring and governance layer obtains the tenant context from the multi-tenant component to achieve tenant-level tracing and performance monitoring. The infrastructure layer performs elastic scaling based on the tenant resource usage data of the multi-tenant component.

[0272] The core logic of the entire architecture is: using "multi-tenant components" as the engine, and through "identifier transmission, configuration control, and data isolation", all services / middleware / storage have the ability to "operate independently and be managed in a unified manner at the tenant level".

[0273] See Figure 2

[0274] Figure 2 This describes the entire SQL execution process using MyBatis combined with a custom multi-tenant plugin. The core functionality is achieved through the MyBatisMultiTenantPlugin (a custom multi-tenant plugin) to implement "tenant data isolation at the SQL level." The functions and multi-tenant logic of each stage are as follows:

[0275] Step 1: Obtain the MyBatis configuration file (mybatis-config.xml)

[0276] This is the core configuration file for MyBatis, and its main functions include the following three aspects:

[0277] (1) Configure the MyBatis runtime environment, including database connection pool, transaction manager, etc.;

[0278] (2) Register plugins, such as MyBatisMultiTenantPlugin in this process, which will be configured in MyBatis in this step;

[0279] (3) Specify basic configurations such as the storage location of the SQL mapping file so that MyBatis can load the SQL logic corresponding to the business.

[0280] Step 2: Load the mapping files (Mapper1.xml, Mapper2.xml, etc.)

[0281] Load the SQL mapping file corresponding to the business logic, which is an XML file containing select / insert / update / delete statements. These files define the original SQL logic corresponding to the business operations.

[0282] Step 3: Construct the session factory (SqlSessionFactory)

[0283] MyBatis uses the configuration information in mybatis-config.xml to construct the SqlSessionFactory (session factory). This is the "factory class" for creating database interaction sessions, responsible for creating session instances for database interaction, and is the core artifact of MyBatis initialization.

[0284] Step 4: Create a session object (SqlSession)

[0285] A SqlSession is created through SqlSessionFactory. It is a session instance for MyBatis to interact with the database, encapsulating capabilities such as database connection and transaction control. Business code initiates database operations through SqlSession.

[0286] Step 5: Executor (Multi-tenant plugin intervention point)

[0287] The Executor is the core component of MyBatis for executing SQL, responsible for SQL execution scheduling, cache management, etc.

[0288] The red arrow points here, indicating that the interception logic of MyBatisMultiTenantPlugin (a custom multi-tenant plugin) operates at this stage: before the Executor executes the SQL, the plugin obtains the tenant ID from the tenant context of the current thread and performs "tenant condition injection" on the original SQL (such as appending AND tenant_id = 『current tenant ID』 after WHERE), thereby achieving logical isolation of multi-tenant data.

[0289] Step 6: MappedStatement object

[0290] It encapsulates the complete information of a single SQL statement in the mapping file (Mapper.xml), including the SQL content, parameter mapping rules, result mapping rules, etc. It is the "data source" for the Executor to execute SQL, ensuring that the modified SQL can complete the matching of parameters and results according to preset rules.

[0291] Step 7: Input Parameter Mapping

[0292] Convert Java type parameters (such as Map, List, String, POJO, etc.) passed in from business code into a parameter format that the database can recognize. For example, map the attribute values ​​of POJO to placeholder parameters in SQL to ensure the correct transmission of SQL parameters.

[0293] Step 8: Output Result Mapping

[0294] The result set returned by the database (such as ResultSet) is converted into the Java type (such as Map, List, POJO, etc.) required by the business code, completing the "reverse mapping" of data and the transformation from database data to business objects, forming a complete database interaction loop.

[0295] The core of the above content is the role of MyBatisMultiTenantPlugin. This custom plugin is key to multi-tenant data isolation: based on MyBatis' plugin mechanism (intercepting the SQL execution method of the Executor), it automatically injects "tenant identifier filtering conditions" before SQL execution, allowing different tenants to only query / operate on their own business data. This eliminates the need for developers to manually write tenant filtering logic in each SQL statement, achieving "non-intrusive" integration for multi-tenant isolation.

[0296] See Figure 3

[0297] Figure 3 This demonstrates a multi-tenant message isolation processing flow in a message queue (using Kafka as an example) scenario. The core of this flow is achieved through "topic splitting + tenant identifier interception + isolation strategy routing" to enable independent consumption of messages from different tenants. The functions and flow logic of each stage are as follows:

[0298] Process Components and Steps Description

[0299] 1. Producer: The message initiator

[0300] The producer generates business messages and carries a tenant identifier context in the message. The tenant identifier context is specifically "producer identifier + context token: tenant" in the diagram. This is the foundation of multi-tenant isolation, and subsequent processes use this identifier to distinguish the tenant to which the message belongs.

[0301] 2. Main topic (topic001): Message entry point

[0302] Messages sent by the producer are first routed to the main topic topic001, which is the "decision entry point" for message isolation and will perform routing judgment based on the business attributes of the message:

[0303] If the message belongs to tenant-specific data (which needs to be isolated): enter the topic001.tenant branch, which is the tenant-specific processing link;

[0304] If the message belongs to multi-tenant shared data (no isolation required): enter the topic001.SHARE branch, which is the shared processing link.

[0305] 3. ProcessorInterceptor: The core of tenant identification processing.

[0306] This is a key node for multi-tenant identifier pass-through, and its function is as follows:

[0307] Identifier Injection and Reading: Intercept the incoming messages and read / inject the tenant identifier (tenant_id) from the message header, i.e., "header: tenant_id: tenant" in the diagram; if there is no tenant ID in the message header, it is automatically injected from the context; if a tenant ID already exists, it is validated to ensure the accuracy of the tenant identifier.

[0308] Isolation attribute marking: Mark the message of the tenant branch (topic001.tenant) with the "tenant-specific" attribute, and mark the message of the shared branch (topic001.SHARE) with the "multi-tenant shared" attribute, thereby marking the corresponding isolation attribute.

[0309] 4. RecordIsolateStrategy: Message isolation execution layer

[0310] Based on the "tenant identifier / isolation attribute" marked by the interceptor, execute the specific isolation logic:

[0311] For messages in the topic001.tenant branch: route them to the corresponding tenant's "dedicated consumption path" by tenant ID (tenant_id);

[0312] Messages for the topic001.SHARE branch: routed to "Multi-tenant Shared Consumption Link", available for all tenants' consumers to subscribe to.

[0313] 5. Kafka Consumer: The final message consumer.

[0314] Different consumers correspond to different isolation links:

[0315] Consumers subscribing to the topic001.tenant branch can only consume messages specific to the corresponding tenant_id and cannot obtain messages from other tenants;

[0316] Consumers subscribing to the topic001.SHARE branch can consume multi-tenant shared messages.

[0317] Summary of core logic

[0318] This process achieves "physical isolation (branch topics) + identifier differentiation" for multi-tenant messages in the message queue by using the method of "main topic splitting (requires isolation / sharing) → interceptor processing tenant identifiers → isolation policy routing". This ensures that messages from different tenants are not consumed by other tenants, while also supporting unified processing of shared messages.

[0319] See Figure 4

[0320] Figure 4 This demonstrates the complete process of a Feign client initiating a remote call (Feign is a commonly used declarative HTTP client in microservices). The core is the conversion of an "interface method call" into an "HTTP remote request," which is the core process for cross-service tenant context collaboration in a microservice architecture. The functions and flow logic of each layer are as follows:

[0321] Process hierarchy and function description (from call initiation to response return)

[0322] 1. Starting point: @FeignClient annotation method

[0323] This is a Feign interface defined by the developer (e.g., @FeignClient(name = "user-service") public interface UserFeign { @GetMapping(" / user / {id}") UserDTO getById(Longid);}), which is the entry point for initiating remote calls in the business code. The business code can directly call the getById method of this interface without having to worry about the construction and sending of the underlying HTTP request.

[0324] 2. JDK Proxy dynamic proxy class example

[0325] Feign dynamically generates proxy classes for interfaces annotated with `@FeignClient`. When business code calls Feign interface methods, the logic of this proxy class is actually executed. Its core logic is to receive method call requests through an `InvocationHandler` and forward them as subsequent remote HTTP requests.

[0326] 3. Contract

[0327] It is Feign's "annotation parser," responsible for parsing the definition of interface methods according to Feign's annotation rules (such as @FeignClient, @GetMapping, @RequestParam, etc.), and converting the parsing results into a MethodHandler (method processor) to provide a rule basis for the construction of subsequent HTTP requests.

[0328] 4. MethodHandler

[0329] Feign's "method executor" consists of a MethodHandler for each Feign interface method, which is divided into two types:

[0330] The MethodHandler on the left is responsible for the request-side logic, receiving calls from the proxy class and triggering the construction process of the HTTP request.

[0331] The MethodHandler on the right is responsible for the response logic, receiving the HTTP response returned by the remote service and triggering the result decoding process.

[0332] 5. RequestTemplate

[0333] It is an HTTP request builder used to construct the core elements of an HTTP request (URL, request headers, request body, request method, etc.) based on the parameters of the interface method (such as id in getById(Long id)) and the annotation rules of Contract parsing, and generate a standardized Request instance.

[0334] 6. Encoder / Decoder

[0335] Encoder (request encoder): Encodes request parameters (such as Java objects) passed in by business code into a format supported by HTTP requests (such as JSON, Form), adapting to the receiving format of remote services;

[0336] Decoder: Decodes the HTTP response (such as a JSON string) returned by a remote service into a Java object (i.e., the final returned Response Bean) needed by the business code, completing the reverse conversion of data format.

[0337] 7. Interceptors, Logger

[0338] Interceptors are key nodes for the cross-service pass-through of multi-tenant identifiers. They are used to perform unified processing on HTTP requests / responses (such as adding request headers, printing logs, and verifying permissions). Corresponding to the previous multi-tenant scenario, the injection logic of tenant identifiers (such as X-Tenant-ID) is usually implemented here.

[0339] For example, when adding a request header: before the HTTP request is sent, the tenant ID is obtained from the tenant context of the current thread and automatically added to the request header;

[0340] Logger: Records key information about requests / responses, including URL, parameters, response status codes, etc., for troubleshooting.

[0341] 8. Feign.Client

[0342] Feign's "HTTP Request Sender" is the component that actually initiates the remote request, and includes the following:

[0343] Underlying dependencies (configurable): The underlying framework is compatible with different HTTP client frameworks such as OkHttp and HttpClient;

[0344] Additional capabilities: Combined with load balancing (such as Ribbon), it can obtain target service instances from the service registry to achieve load distribution of requests; it also supports fault tolerance mechanisms such as retries and timeout control.

[0345] 9. Interaction Object: Remote Server

[0346] It is the target of the Feign client (i.e., a service instance in the microservice cluster), responsible for receiving HTTP requests sent by the Feign client, executing the corresponding business logic, and returning response data.

[0347] 10. Destination: Response Bean

[0348] The response data from the remote service is decoded by the decoder, converted into a Java object (such as UserDTO) required by the business code, and finally passed back to the business code, completing the entire remote call loop.

[0349] The core logic of the above can be summarized as follows: business code calls Feign interface methods → proxy class receives the call → Contract parses annotations to generate an executor → constructs an HTTP request → encodes / intercepts / logs → sends the request to the remote service → receives the response → decodes → returns the business object.

[0350] In this process, Interceptors are the key nodes for implementing "multi-tenant identity pass-through" (such as adding a tenant ID to the request header), enabling seamless pass-through of tenant context in cross-service calls and ensuring end-to-end consistency of tenant isolation in a distributed architecture.

[0351] The above description is merely an exemplary embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural transformations made using the contents of the present invention specification and drawings under the technical concept of the present invention, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A low-invasive multi-tenant support method, characterized in that, The method comprises the following steps: defining a global tenant context for saving a tenant identifier of a current request, and controlling enabling of a multi-tenant function through a context thread switch; setting different technical components for different data storage modes, and each of the technical components automatically acquires a current tenant identifier from the tenant context; the technical component automatically writes the tenant identifier into a request header, each of the technical components calls a tenant service interface to acquire data corresponding to the tenant according to a preset isolation strategy, and performs multi-tenant isolation processing according to different middleware and data storage modes; when a microservice call is involved, the technical component injects the tenant identifier into the request header through a Feign interceptor, and the called service repeats steps S1-S3 to ensure that the tenant identifier is not lost in the call chain; after the request processing is completed, the tenant context information of the current thread is cleared to avoid thread leakage.

2. The low intrusion multi-tenancy support method of claim 1, wherein, The step of defining a global tenant context and controlling enabling of a multi-tenant function through a context thread switch comprises the following steps: setting a TenantContextHolder interface; after a tenant initiates a business request, a tenant ID is extracted from an HTTP request header through an SDK built-in filter, and the tenant ID is set to the context through the TenantContextHolder interface to realize automatic transmission of the tenant identifier; the context thread switch controls enabling of each of the technical components through the TenantContextHolder interface.

3. The low intrusion multi-tenancy support method of claim 1, wherein, The technical component at least comprises one of the following components: a MyBatis multi-tenant component for realizing multi-tenant isolation support of a relational database, including a physical isolation strategy based on a multi-data source and a logical isolation strategy based on a tenant field; an MQ multi-tenant component for realizing multi-tenant isolation support of a message queue, and providing a physical isolation strategy and a logical isolation strategy; a MongoDB multi-tenant component for realizing multi-tenant isolation support of a NoSQL database MongoDB, and different tenants corresponding to different databases; a Redis multi-tenant component for realizing multi-tenant isolation support of a cache, and realizing logical isolation through automatic addition of a tenant ID prefix to a cache key; a web multi-tenant component for transmitting a tenant context in a microservice call chain to ensure that a correct tenant identifier is carried in a cross-service request.

4. The low intrusion multi-tenancy support method of claim 3, wherein, When the technical component comprises the MyBatis multi-tenant component, the isolation processing steps are as follows: when the physical isolation strategy is configured, the MyBatis multi-tenant component integrates a Dynamic-Datasource dynamic data source component, and dynamically switches to a database dedicated to the tenant according to the current tenant identifier; when the logical isolation strategy is configured, a SQL analysis interceptor automatically injects a filtering condition of the tenant identifier into business SQL to realize row-level isolation.

5. The low intrusion multi-tenancy support method of claim 3, wherein, When the technical component comprises the MQ multi-tenant component, the isolation processing steps are as follows: When the physical isolation strategy is configured, different tenants use different message topics, and automatic routing is achieved by automatically splicing the tenant code after the message topic name; When the logical isolation strategy is configured, tenant identification is added in the message header, all tenants share the same topic, and different tenants are distinguished by the tenant identification in the message header; The consumer end listens to all tenant messages through the regular Topic mode, and filters other tenant messages outside the target tenant based on the tenant identification.

6. The low intrusion multi-tenancy support method of claim 3, wherein, When the technical component includes a Redis multi-tenant component, the isolation processing steps are as follows: Encapsulate RedisTemplate, automatically splice the current tenant identification when storing the cache key, and use the spliced tenant identification as the prefix, and automatically remove the prefix when reading; Based on Redisson, realize distributed lock service, and automatically add tenant identification prefix to the lock name, which is used to realize lock isolation across tenants.

7. The low intrusion multi-tenancy support method of claim 3, wherein, When the technical component includes a Web multi-tenant component, the transparent step is as follows: Encapsulate the Feign client interceptor, automatically extract the tenant identification from the tenant context and add it to the request header when cross-service calling; The called service extracts the tenant identification from the request header through the filter and sets it to the local context, which is used to make each microservice share the same tenant context.

8. A low-invasive multi-tenant support system based on the low-invasive multi-tenant support method according to any one of claims 1 to 7, characterized in that, It includes: A multi-tenant context management module is used to define a global tenant context, provide interfaces for setting, obtaining, and clearing tenant identification, and context thread switches, and realize the binding of tenant identification and threads; A modular technical component layer includes MyBatis multi-tenant components, MQ multi-tenant components, Redis multi-tenant components, MongoDB multi-tenant components, and Web multi-tenant components, each component independently encapsulates the multi-tenant isolation logic of the corresponding middleware, and is used for on-demand activation; A configuration management module is designed using a configuration driver, which provides global configuration and component-specific configuration; A tenant business component module is used to encapsulate tenant service interfaces to query detailed information and configurations of the current tenant.

9. The low intrusion multi-tenancy support system of claim 8, wherein, The system uses a Maven multi-module engineering structure, and each technical component is independently encapsulated as a SpringBootStarter for on-demand reference of the corresponding technical component.

Images