Method and device for dynamic routing and isolated access supporting multi-tenant heterogeneous data sources

Abstract

This application relates to the field of cloud computing technology and provides a method and apparatus for dynamic routing and isolated access to multi-tenant heterogeneous data sources. The method configures basic and dynamic resources for each tenant in a cloud computing management platform. Upon receiving a tenant's business request, it first dynamically initializes the resources corresponding to the business request, then accesses the client through the initialized resources to execute the business request. When receiving cross-tenant collaborative tasks, it configures a collaborative process including a dual authentication mechanism, a secure sandbox environment for executing tenant data interactions, and the generation of full-link audit logs for all interactive operations. This achieves a unified approach of strict data isolation and controllable sharing in a multi-tenant environment through a dynamic isolation architecture and secure collaboration mechanism. It also supports minute-level tenant deployment and real-time configuration effectiveness, resolving the technical contradictions of traditional solutions in terms of isolation, collaboration, and operational efficiency, and providing a secure and efficient multi-tenant solution for demand management systems.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method and apparatus for dynamic routing and isolation access that supports multi-tenant heterogeneous data sources. Background Technology

[0002] With the rapid development of cloud computing technology, multi-tenant SaaS (Software as a Service) systems have become the mainstream deployment model for enterprise applications. In collaborative application scenarios such as demand management, how to achieve strict isolation, traffic isolation, and secure sharing of tenant data has become a key issue that urgently needs to be addressed in the current technology field.

[0003] Currently, mainstream SaaS systems primarily employ three multi-tenant data isolation schemes: shared database with shared table structure, shared database with independent schema (a blueprint describing the data structure), and dedicated database instances. The shared database with shared table structure scheme achieves logical isolation through specific fields, but it suffers from serious security vulnerabilities. SQL (Structured Query Language) injection vulnerabilities can easily lead to cross-tenant data leaks, and database performance degrades exponentially with the number of tenants. The shared database with independent schema scheme allows each tenant to use the same database instance but have its own independent schema. While achieving some physical isolation, it suffers from resource contention issues such as CPU / IO bottlenecks, and backup and recovery granularity is difficult to control, making single-tenant rollback impossible. The dedicated database instance scheme, while achieving complete physical isolation, requires managing multiple database instances, resulting in extremely high maintenance costs, and often leads to low resource utilization due to small tenant instances remaining idle for extended periods.

[0004] In multi-tenant systems within a hybrid storage environment, the deployment of SaaS systems faces greater challenges. When using relational databases, document databases, object storage, and search engines simultaneously, maintaining multiple heterogeneous tenant isolation strategies necessitates a significant increase in the complexity of the SaaS system. Therefore, how to deploy a SaaS system to achieve secure, efficient, and flexible cross-tenant collaboration while ensuring physical data isolation, and simultaneously supporting unified management in a hybrid storage environment, is a key technical problem that needs to be solved. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method and apparatus for dynamic routing and isolation access to multi-tenant heterogeneous data sources, in order to solve the problem that conventional SaaS deployment methods in the prior art cannot achieve secure and efficient cross-tenant cooperation while ensuring physical data isolation.

[0006] A first aspect of this application provides a method for dynamic routing and isolated access to multi-tenant heterogeneous data sources, including:

[0007] Configure basic resources and dynamic resources for each tenant in the cloud computing management platform; the basic resources include independent data storage space and service instances allocated to each tenant, and the dynamic resources include dynamically allocated storage resources and routing policies;

[0008] In response to receiving a service request from the first tenant, the resource corresponding to the service request is dynamically initialized, and the service request is executed by the client through the initialized resource access.

[0009] In response to receiving a cross-tenant collaboration task, the cross-tenant collaboration process for the first tenant and the second tenant is configured; the cross-tenant collaboration process includes a dual authentication mechanism, a secure sandbox environment for executing tenant data interaction, and the generation of full-link audit logs for all interaction operations.

[0010] A second aspect of this application provides a dynamic routing and isolation access device that supports multi-tenant heterogeneous data sources, including:

[0011] The resource configuration module is configured to configure basic resources and dynamic resources for each tenant in the cloud computing management platform; the basic resources include independent data storage space and service instances allocated to each tenant, and the dynamic resources include dynamically allocated storage resources and routing policies.

[0012] The initialization module is configured to dynamically initialize the resources corresponding to the service request in response to receiving a service request from the first tenant, and then access the client to execute the service request through the initialized resources.

[0013] The collaboration configuration module is configured to, in response to receiving a cross-tenant collaboration task, configure the cross-tenant collaboration process of the first tenant and the second tenant; the cross-tenant collaboration process includes a dual authentication mechanism, a secure sandbox environment for executing tenant data interaction, and the generation of full-link audit logs for all interaction operations.

[0014] A third aspect of this application provides a dynamic routing and isolation access system that supports multi-tenant heterogeneous data sources, including:

[0015] The tenant management platform is configured to store and manage the independent configuration information of each tenant, including dynamic service routing policies and heterogeneous data source mapping relationships.

[0016] The intelligent routing gateway is configured to identify and verify tenants for user requests and perform two-stage routing decisions based on the tenant identifier.

[0017] The distributed storage engine is configured to provide each tenant with independent data storage space using a physically isolated architecture.

[0018] The multi-tenant data isolation system is configured to ensure strict isolation of computing and storage resources among tenants through a dynamic configuration loading mechanism.

[0019] The collaboration strategy management module is configured to establish cross-tenant access authorization rules based on a multi-level approval workflow, and define the scope and timeliness of collaborative resources through a visual configuration interface;

[0020] The dual authentication engine is configured to perform identity and permission verification on collaboration requests, including source tenant identity status verification and target tenant real-time permission checks, while generating time-sensitive access credentials.

[0021] The operation audit module is configured to record and store verifiable traces of the collaboration process in real time;

[0022] The secure collaboration system is configured to enable controlled sharing of data among tenants while ensuring data isolation.

[0023] A fourth aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0024] A fifth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0025] The beneficial effects of this application embodiment compared to the prior art are as follows: This application embodiment configures basic and dynamic resources for each tenant in the cloud computing management platform. When a business request from the first tenant is received, the resources corresponding to the business request are dynamically initialized first. Then, the client is accessed through the initialized resources to execute the business request. Furthermore, when a cross-tenant collaborative task is received, a first-tenant and second-tenant collaborative process is configured, including a dual authentication mechanism, a secure sandbox environment for executing tenant data interaction, and the generation of full-link audit logs for all interactive operations. This achieves a unified approach of strict data isolation and controllable sharing in a multi-tenant environment through a dynamic isolation architecture and secure collaboration mechanism. Simultaneously, this application embodiment supports minute-level tenant deployment and real-time configuration effectiveness, resolving the technical contradictions of traditional solutions in terms of isolation, collaboration, and operational efficiency, and providing a secure and efficient multi-tenant solution for the demand management system. Attached Figure Description

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

[0027] Figure 1 This is a flowchart illustrating a dynamic routing and isolation access method for multi-tenant heterogeneous data sources provided in an embodiment of this application.

[0028] Figure 2 This is a flowchart illustrating the method for configuring basic and dynamic resources for each tenant in the cloud computing management platform provided in this application embodiment.

[0029] Figure 3 This is a schematic diagram of the tenant information creation page provided in an embodiment of this application. For example... Figure 3 As shown, the aforementioned tenant metadata can be configured through this interface.

[0030] Figure 4 This is a flowchart illustrating the method for instantiating and configuring isolated service resources of the first tenant based on subscription information, as provided in this application embodiment.

[0031] Figure 5 This is a schematic diagram of the tenant resource configuration management interface provided in the embodiments of this application.

[0032] Figure 6 This is a topology diagram of the various resource configuration relationships provided in the embodiments of this application.

[0033] Figure 7 This is a flowchart illustrating the method for configuring fine-grained access control policies for a first tenant, as provided in an embodiment of this application.

[0034] Figure 8 This is a flowchart illustrating the method for configuring the service endpoint binding rules and traffic distribution strategy of the first tenant based on feature attributes, as provided in the embodiments of this application.

[0035] Figure 9 This is a request sequence diagram under the multi-tenant, multi-cluster deployment architecture provided in the embodiments of this application.

[0036] Figure 10 This is a multi-cluster traffic distribution topology diagram provided in the embodiments of this application.

[0037] Figure 11 This is a flowchart illustrating the method for dynamically initializing resources corresponding to business requests provided in this application embodiment.

[0038] Figure 12This is a schematic diagram illustrating the process of business requests triggering dynamic instantiation of connection resources, as provided in the embodiments of this application.

[0039] Figure 13 This is a flowchart illustrating the method for configuring cross-tenant collaboration between the first tenant and the second tenant, as provided in this application embodiment.

[0040] Figure 14 This is a flowchart illustrating the method for controlled collaboration between organizations provided in an embodiment of this application.

[0041] Figure 15 This is the cross-tenant resource sharing configuration interface provided in the embodiments of this application.

[0042] Figure 16 This is a flowchart illustrating a method for changing collaborative role permissions through a distributed notification mechanism, as provided in an embodiment of this application.

[0043] Figure 17 This is a schematic diagram of the synchronization process of cross-tenant shadow accounts provided in the embodiments of this application.

[0044] Figure 18 This is a schematic diagram of the process for a collaborative user to switch tenants, provided in an embodiment of this application.

[0045] Figure 19 This is a schematic diagram of the recording format of the cross-tenant operation audit log provided in the embodiments of this application.

[0046] Figure 20 This is a schematic diagram of the overall architecture of the socialized collaborative multi-tenant demand management system provided in this application embodiment.

[0047] Figure 21 This is a schematic diagram of the multi-tenant data isolation device architecture provided in the embodiments of this application.

[0048] Figure 22 This is a schematic diagram of the cross-tenant secure collaboration device architecture provided in the embodiments of this application.

[0049] Figure 23 This is a schematic diagram of a dynamic routing and isolation access device that supports multi-tenant heterogeneous data sources, provided in an embodiment of this application.

[0050] Figure 24 This is a schematic diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0051] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0052] The following describes in detail, with reference to the accompanying drawings, a method and apparatus for dynamic routing and isolation access supporting multi-tenant heterogeneous data sources according to embodiments of this application.

[0053] As mentioned above, how to deploy a SaaS system to achieve secure, efficient, and flexible cross-tenant collaboration while ensuring physical data isolation, and to support unified management in a hybrid storage environment, is a technical problem that needs to be solved.

[0054] In view of this, this application provides a dynamic routing and isolated access method for multi-tenant heterogeneous data sources. It configures basic and dynamic resources for each tenant in the cloud computing management platform. Upon receiving a business request from the first tenant, it first dynamically initializes the resources corresponding to the business request, and then accesses the client through the initialized resources to execute the business request. Furthermore, upon receiving a cross-tenant collaborative task, it configures a first-tenant and second-tenant collaboration process including a dual authentication mechanism, a secure sandbox environment for executing tenant data interactions, and the generation of full-link audit logs for all interaction operations. This achieves a unified approach of strict data isolation and controllable sharing in a multi-tenant environment through a dynamic isolation architecture and secure collaboration mechanism. Simultaneously, this application supports minute-level tenant deployment and real-time configuration effectiveness, resolving the technical contradictions of traditional solutions in terms of isolation, collaboration, and operational efficiency, and providing a secure and efficient multi-tenant solution for demand management systems.

[0055] Figure 1 This is a flowchart illustrating a dynamic routing and isolated access method for multi-tenant heterogeneous data sources provided in an embodiment of this application. Figure 1 As shown, the method includes the following steps:

[0056] In step S101, basic resources and dynamic resources are configured for each tenant in the cloud computing management platform.

[0057] Basic resources include independent data storage space and service instances allocated to each tenant, while dynamic resources include dynamically allocated storage resources and routing policies.

[0058] In step S102, in response to receiving the service request from the first tenant, the resource corresponding to the service request is dynamically initialized, and the service request is executed by accessing the client through the initialized resource.

[0059] In step S103, in response to receiving a cross-tenant collaboration task, the cross-tenant collaboration process of the first tenant and the second tenant is configured.

[0060] The cross-tenant collaboration process includes a dual authentication mechanism, a secure sandbox environment for executing tenant data interactions, and the generation of full-link audit logs for all interaction operations.

[0061] In some embodiments of this application, the method may be executed by a cloud computing platform, which includes at least a cloud computing management platform.

[0062] In some embodiments of this application, basic resources and dynamic resources can be configured for each tenant in the cloud computing management platform. Basic resources include independent data storage space and service instances allocated to each tenant, while dynamic resources include dynamically allocated storage resources and routing policies.

[0063] Upon receiving a business request from the first tenant, the resources corresponding to the business request can be dynamically initialized, and the client can be accessed to execute the business request through the initialized resources. The specific implementation methods for dynamically initializing resources and accessing the client through the initialized resources will be described in detail later and will not be repeated here.

[0064] When a cross-tenant collaboration task is received, a cross-tenant collaboration process can be configured for the first and second tenants. This cross-tenant collaboration process includes a dual authentication mechanism, a secure sandbox environment for executing tenant data interactions, and the generation of full-link audit logs for all interactions.

[0065] According to the technical solution provided in this application, by configuring basic and dynamic resources for each tenant in the cloud computing management platform, upon receiving a business request from the first tenant, the resources corresponding to the business request are first dynamically initialized. Then, the client is accessed through the initialized resources to execute the business request. Furthermore, upon receiving a cross-tenant collaborative task, a first-tenant and second-tenant collaboration process is configured, including a dual authentication mechanism, a secure sandbox environment for executing tenant data interaction, and the generation of full-link audit logs for all interaction operations. This achieves a unified approach of strict data isolation and controllable sharing in a multi-tenant environment through a dynamic isolation architecture and secure collaboration mechanism. Simultaneously, this application supports minute-level tenant deployment and real-time configuration effectiveness, resolving the technical contradictions in isolation, collaboration, and operational efficiency inherent in traditional solutions, and providing a secure and efficient multi-tenant solution for the demand management system.

[0066] Figure 2 This is a flowchart illustrating the method for configuring basic and dynamic resources for each tenant in the cloud computing management platform provided in this application embodiment. Figure 2 As shown, the method includes the following steps:

[0067] In step S201, in response to receiving the first tenant registration request, a unique identifier for the first tenant is generated, and a basic configuration profile is generated based on the first tenant's metadata.

[0068] In step S202, the subscription information of the first tenant is obtained, and the isolated service resource instantiation configuration of the first tenant is associated with the subscription information.

[0069] In step S203, the fine-grained access control policy for the first tenant is configured.

[0070] In step S204, the characteristic attributes of the first tenant are obtained, and the service endpoint binding rules and traffic distribution strategies of the first tenant are configured based on the characteristic attributes.

[0071] In some embodiments of this application, upon receiving a first tenant registration request, a unique identifier for the first tenant can be generated, and a basic configuration profile can be generated based on the first tenant's metadata. Then, the first tenant's subscription information is obtained, and the isolated service resource instantiation configuration for the first tenant is associated with the subscription information, and fine-grained access control policies for the first tenant are configured. Finally, the first tenant's characteristic attributes are obtained, and service endpoint binding rules and traffic distribution policies for the first tenant are configured based on these characteristic attributes.

[0072] In other words, tenant metadata can be extracted from standard specifications, project experience, and historical data. The creation process of new tenants can be completed through the tenant management platform. The system automatically generates a globally unique tenant identifier (Tenant ID) that conforms to the UUIDv4 specification and records a complete tenant basic information file.

[0073] In one example, the set of common attributes abstracted from the business practices of the industry in which the current system operates should include, but is not limited to, the following core data elements:

[0074] 1) Basic identification information: including tenant name and tenant code. The tenant name can be the legal registered name of an enterprise or organization, and the tenant code can adopt a standardized coding structure with specific rules.

[0075] 2) Contact Information: This includes contact person, contact information, email address, etc. The contact person can be a system administrator who has been verified with their real name. The contact information can be, for example, a phone number that conforms to the E.164 standard. The email address can be, for example, a corporate email address that has been verified through the RFC 5322 standard.

[0076] 3) Status management information: including tenant status and service period. Tenant status can be an enumerated value, such as trial, official, deactivated, etc. The service period is the start and end time of the tenant service.

[0077] Figure 3This is a schematic diagram of the tenant information creation page provided in an embodiment of this application. For example... Figure 3 As shown, the aforementioned tenant metadata can be configured through this interface.

[0078] Figure 4 This is a flowchart illustrating the method for instantiating and configuring isolated service resources based on subscription information associated with the first tenant, as provided in this application embodiment. Figure 4 As shown, the method includes the following steps:

[0079] In step S401, an independent relational database or a non-relational database is configured for the first tenant.

[0080] The connection configuration items for relational databases include the database instance connection address, a dedicated database account with CRUD (Create, Read, Update, Delete) permissions, and encrypted access credentials. The connection configuration items for non-relational databases include: the system-preset MongoDB replica set connection string, the sharded access account, and its corresponding encrypted access credentials.

[0081] In step S402, a dedicated microservice cluster entry point is allocated to the first tenant, and the following storage configuration is set for the first tenant: regional access endpoint, access key, key credentials, and a dedicated storage space name for the first tenant.

[0082] In step S403, the search engine service is configured for the first tenant.

[0083] The search engine service includes Elasticsearch cluster REST access endpoints, index-level access accounts, dynamically generated access tokens, and a dedicated index namespace for the first tenant.

[0084] In some embodiments of this application, when configuring the isolated service resources of the first tenant based on subscription information, an independent relational database or a non-relational database can be configured for the first tenant. The connection configuration items of the relational database include the database instance connection address, a dedicated database account with CRUD permissions for adding, reading, updating, deleting, and storing encrypted access credentials. The connection configuration items of the non-relational database include: a system-preset open-source document database MongoDB replica set connection string, a database sharding access account and its corresponding encrypted access credentials.

[0085] Then, a dedicated microservice cluster entry point is assigned to the first tenant, and the following storage configuration is set for the first tenant: a regionalized access endpoint, access key, key credentials, and a dedicated storage space name for the first tenant. Finally, a search engine service is configured for the first tenant, which may include an Elasticsearch cluster REST access endpoint, an index-level access account, dynamically generated access tokens, and a dedicated index namespace for the first tenant.

[0086] Figure 5 This is a schematic diagram of the tenant resource configuration management interface provided in an embodiment of this application. Figure 5 As shown, the system can provide an extensible resource configuration model on this interface, supporting tenant-level personalized customization, specifically including the following core elements:

[0087] At the database connection configuration level, the system allocates an independent relational database instance to each tenant. Configuration items include: the database instance connection address (uniform resource locator, URL), a dedicated database account with create, read, update, and delete (CRUD) permissions, and access credentials encrypted using the SM4 national cryptographic algorithm. For NoSQL database configurations, the system pre-sets MongoDB replica set connection strings (containing master-slave node information), shard-level access accounts, and their corresponding encrypted access credentials to ensure tenant-level isolation of the document database.

[0088] In terms of business service configuration, the system assigns a dedicated microservice cluster entry URL to each tenant to achieve physical isolation of computing resources. Object storage configuration includes a regional access endpoint (OSS EndPoint), access key, key credentials, and a tenant-specific storage space name (Bucket), ensuring tenant-level security isolation of object storage.

[0089] For the search engine service, the system configures the Elasticsearch cluster's Representational State Transfer Interface (REST) ​​access endpoint, index-level access accounts, dynamically generated access tokens, and tenant-specific index namespaces to achieve tenant isolation for the search service. All configuration items are transmitted through encrypted channels and stored in a secure configuration center to ensure the security of configuration information.

[0090] All the above configuration items are dynamically managed through the tenant management platform, supporting change auditing, sensitive information encryption, hot updates, and tenant-differentiated configurations. A topology diagram showing the relationships between various resource configurations is shown below. Figure 6As shown, the physical resource tenant metadata is associated with the virtual tenant resource through a mapping relationship, and the tenant metadata can select different databases through the business selection module. For example, a relational database can be selected to store the database URL and username / password, or a document database can be selected to store the MongoURL and access credentials.

[0091] Figure 7 This is a flowchart illustrating the method for configuring fine-grained access control policies for a first tenant, as provided in an embodiment of this application. Figure 7 As shown, the method includes the following steps:

[0092] In step S701, the organizational structure tree relationship of the first tenant is configured.

[0093] The organizational structure should include at least the department nodes of the first tenant, hierarchical relationships, control attributes, and extended attributes.

[0094] In step S702, a user account system is established based on a tree structure so that user accounts are associated with target department nodes in the organizational structure tree, and fine-grained access control policies for the first tenant are configured.

[0095] In step S703, the fine-grained access control policy is implemented based on the user-role-permission model, including data-level permissions, function-level permissions, and field-level permissions, which are verified in real time with each request through a dynamic permission decision engine.

[0096] In some embodiments of this application, when configuring fine-grained access control policies for the first tenant, the organizational structure tree relationship of the first tenant can be configured first. The organizational structure includes at least the department nodes, hierarchical relationships, control attributes, and extended attributes of the first tenant. Department nodes may include, for example, a department unique identifier (ID), department name, and department code; hierarchical relationships may include, for example, a parent department ID, hierarchical depth (e.g., level 1 is the root department), and full path (e.g., " / headquarters / R&D center"); control attributes may include, for example, a sequence number and status (enabled / disabled); extended attributes may include, for example, contact information, etc.

[0097] Organizational tree structures can be generated in two ways:

[0098] 1) Manual configuration: Generated through a visual interface, the system automatically maintains the hierarchical relationship and full path.

[0099] 2) Batch import: Import via Excel file, the system automatically checks circular dependencies and generates a tree structure.

[0100] Establishing an account system based on a tree structure means that user accounts must be associated with a specific department node in the organizational tree when they are created. The account system refers to a complete user identity management system based on a Role-Based Access Control (RBAC) model, which includes: basic user information (username, employee ID, department), authentication credentials (password policy, multi-factor authentication), role membership relationships, and permission sets.

[0101] Fine-grained access control policies can be implemented based on a "user-role-permission" model, specifically including: data-level permissions (restricting the range of accessible data), function-level permissions (controlling access to menus and operation buttons), and field-level permissions (controlling the display and editing of sensitive fields), and are validated in real time with each request through a dynamic permission decision engine.

[0102] Figure 8 This is a flowchart illustrating the method for configuring service endpoint binding rules and traffic distribution strategies for a first tenant based on feature attributes, as provided in an embodiment of this application. Figure 8 As shown, the method includes the following steps:

[0103] In step S801, the business cluster bound to the first tenant is configured based on the feature attributes.

[0104] In step S802, in response to determining that the first tenant is bound to a dedicated service cluster, the traffic distribution strategy is determined to accurately route the first tenant's service requests to the dedicated service cluster, and the dedicated service cluster determines the computing node to process the first tenant's service requests based on a preset load balancing strategy.

[0105] The compute node returns a response message after completing the business processing by accessing the first tenant's dedicated database.

[0106] In step S803, in response to determining that the first tenant is bound to the shared service cluster, the traffic distribution strategy is determined to be the computing node for the first tenant's service request based on resource quota.

[0107] In step S804, in response to determining that the first tenant is bound to a dedicated high-performance service cluster, the traffic distribution strategy is to determine the computing node in the dedicated high-performance service cluster that handles the first tenant's business requests, and to ensure the service quality of the first tenant through fixed session binding and a dedicated thread pool.

[0108] In some embodiments of this application, when configuring the service endpoint binding rules and traffic distribution strategy for the first tenant based on feature attributes, the first tenant can first be configured with a bound service cluster based on the feature attributes. If it is determined that the first tenant is bound to a dedicated service cluster, the traffic distribution strategy can be determined to accurately route the first tenant's service requests to the dedicated service cluster, and the dedicated service cluster can determine the computing node to process the first tenant's service requests based on a preset load balancing strategy.

[0109] On the other hand, if it is determined that the first tenant is bound to a shared business cluster, then the traffic distribution strategy can be determined as determining the computing node for the first tenant's business requests based on resource quotas.

[0110] On the other hand, if it is determined that the first tenant is bound to a dedicated high-performance service cluster, the traffic distribution strategy can be determined to identify the computing node in the dedicated high-performance service cluster that handles the first tenant's business requests, and the service quality of the first tenant can be guaranteed through fixed session binding and a dedicated thread pool.

[0111] In other words, by dynamically configuring and routing strategies for tenant-specific "business service addresses," accurate distribution and load balancing of request traffic from different tenants can be achieved.

[0112] Request timing in a multi-tenant, multi-cluster deployment architecture is as follows Figure 9 As shown, when tenant A initiates a request, the gateway parses its tenant ID and precisely routes the request to the pre-configured tenant A dedicated cluster (svc-business-a.example.com). This cluster selects the optimal node to process the request based on a preset load balancing strategy (such as round-robin or least connections), accesses the tenant's dedicated database to complete the business processing, and then returns a response. For tenant B, the gateway directs its request to the business shared cluster (svc-shard.example.com), which allocates computing nodes for processing according to resource quotas. Tenant C's request will be prioritized and scheduled to the dedicated high-performance cluster (svc-vip.example.com). Service quality is guaranteed through fixed session binding and a dedicated thread pool. Ultimately, all tenant requests are automatically distributed to the corresponding business clusters according to their business characteristics, service level, and resource configuration to complete closed-loop processing. The multi-cluster traffic distribution topology is as follows: Figure 10 As shown.

[0113] Figure 11 This is a flowchart illustrating the method for dynamically initializing resources corresponding to business requests provided in an embodiment of this application. For example... Figure 11 As shown, the method includes the following steps:

[0114] In step S1101, the business request of the first tenant is intercepted, and the business request is preprocessed to obtain the context object of the first tenant.

[0115] In step S1102, the resources corresponding to the business request are initialized based on the context object, the validity of the resource configuration of the first tenant is verified, and the tenant-level resource isolation is maintained through the connection pool manager to generate a data access component carrying the context tag of the first tenant.

[0116] In some embodiments of this application, when dynamically initializing the resources corresponding to a business request, the business request of the first tenant can be intercepted first, the business request can be preprocessed to obtain the context object of the first tenant, and then the resources corresponding to the business request can be initialized based on the context object to complete the validity verification of the resource configuration of the first tenant. The connection pool manager can maintain tenant-level resource isolation and generate a data access component carrying the context tag of the first tenant.

[0117] The resources corresponding to the business request initialized based on the context object include:

[0118] Create tenant-specific JDBCTemplate instances for relational databases to configure isolated data source connection pools;

[0119] Initialize a MongoTemplate object with permissions for the specified database name for the document database;

[0120] Build a storage client that restricts access permissions to OSS Buckets;

[0121] Configure the Elasticsearch cluster's Representational State Transfer Interface (REST) ​​access endpoint, index-level access accounts, dynamically generated access tokens, and tenant-specific index namespaces to achieve tenant isolation for the search service.

[0122] The data access component is an abstract encapsulation of the underlying resource connections and operations, instantiating an independent resource access object for each tenant. This object provides secure and isolated resource access capabilities to a specific tenant through pre-configured connection parameters and access rules. Specifically:

[0123] 1) The component itself: It encapsulates standardized interfaces for resource connection pools, authentication mechanisms, and operation methods.

[0124] 2) Instantiation feature: Each tenant obtains a unique component instance, which contains tenant-specific connection configurations (such as database connection strings and OSS endpoints) and access credentials (tenant-specific authentication keys).

[0125] 3) Access mechanism: Through this instantiated access object, tenants can access their dedicated database instance / schema, object storage bucket, and search service index.

[0126] All requests arriving at the business interface are intercepted by the interceptor. The tenant ID is retrieved from the request, and based on this tenant ID, relevant isolation rules are obtained from the tenant management platform. Subsequently, the relevant resource connection client is initialized. In other words, the system can intercept business service requests, parse the tenant context, and dynamically initialize data access component instances. Through the initialized resource access client, specific business data processing and logical operations are completed.

[0127] Figure 12 This is a schematic diagram illustrating the process of a business request triggering the dynamic instantiation of connection resources, as provided in an embodiment of this application. For example... Figure 12 As shown, when a request reaches the business service, the business service preprocesses the received Application Programming Interface (API) request through a request interceptor. First, it extracts the tenant ID from the request header or authentication token, queries the tenant management platform to obtain the data source configuration, and constructs a complete tenant context object (containing metadata such as tenant identifier and data isolation policy) after the configuration verification passes. If the verification fails, the request is rejected.

[0128] Subsequently, the system dynamically initializes data access component instances based on the tenant context to initialize resource connection clients. This includes: creating tenant-specific JDBCTemplate instances for relational databases (configuring isolated data source connection pools), initializing MongoTemplate objects with permissions for the specified database name for document databases, and building storage clients with limited OSSBucket access permissions. During initialization, these component instances actively verify the validity of the tenant resource configuration and inject them into the connection pool manager after creation to maintain tenant-level resource isolation through the connection pool manager.

[0129] Furthermore, for the search engine service, the system can also configure the Elasticsearch cluster REST access endpoint, index-level access accounts, dynamically generated access tokens, and tenant-specific index namespaces to achieve tenant isolation for the search service. All configuration items are transmitted through encrypted channels and stored in a secure configuration center to ensure the security of configuration information.

[0130] The final generated data access component will carry a tenant context tag to ensure that all subsequent data operations strictly adhere to the preset isolation rules. This process employs a dual verification mechanism: verifying the tenant status (enabled / disabled) during component initialization and reconfirming permission boundaries during each data access, thereby achieving physical isolation of tenant data while ensuring system throughput.

[0131] Figure 13 This is a flowchart illustrating the method for configuring cross-tenant collaboration between the first tenant and the second tenant, as provided in an embodiment of this application. Figure 13 As shown, the method includes the following steps:

[0132] In step S1301, during the collaboration space initialization phase, the first tenant creates a dedicated collaboration project, configures data sharing boundaries, designates the second tenant as a participant, and initiates a multi-level approval workflow.

[0133] In step S1302, during the cross-tenant role definition phase, the first tenant creates a collaboration role as the administrator and sets fine-grained permissions.

[0134] In step S1303, during the cross-tenant shadow account synchronization phase, a shadow account is created in the space of the first tenant for a designated member account in the second tenant, so that the shadow account works as a collaborative role.

[0135] In step S1304, a two-factor access control policy is used to simultaneously verify the identity credentials of the second tenant and the collaboration permissions granted by the first tenant when accessing the first tenant's collaborative data.

[0136] In some embodiments of this application, when configuring the cross-tenant collaboration process between the first tenant and the second tenant, the first tenant can first create a dedicated collaboration project, configure data sharing boundaries, and designate the second tenant as a participant during the collaboration space initialization phase, initiating a multi-level approval workflow. Simultaneously, during the cross-tenant role definition phase, the first tenant can create a collaboration role as an administrator and set fine-grained permissions.

[0137] During the cross-tenant shadow account synchronization phase, shadow accounts can be created in the space of the first tenant for designated member accounts in the second tenant, so that the shadow accounts can work as collaboration roles. In other words, the collaboration role is a role created by the administrator of the first tenant, which can create shadow accounts for designated member accounts in the second tenant in the first tenant. Subsequently, when the designated members in the second tenant participate in collaborative tasks, they will operate through these shadow accounts in the first tenant as collaboration roles.

[0138] Finally, a two-factor access control strategy is used to simultaneously verify the identity credentials of the second tenant and the collaboration permissions granted by the first tenant when accessing the first tenant's collaborative data, thereby enabling cross-tenant collaboration.

[0139] In this context, shadow accounts can perform cross-tenant collaborative tasks within the space of the first tenant, acting as a collaborative role. All operations performed by shadow accounts in cross-tenant collaborative tasks are executed within a secure sandbox environment, and all operations performed by shadow accounts in cross-tenant collaborative tasks are recorded in the audit log; the audit log includes at least the shadow account's identity identifier, operation timestamp, accessed target resource path, and corresponding operation record.

[0140] In other words, the first tenant can explicitly grant the second tenant specific access permissions (such as read-only, edit, etc.) to the "Project 1" resource within it, and the system persists this authorization relationship to the access policy library.

[0141] When a second tenant attempts to access "Project 1" of the first tenant, the system performs dual security verification, including identity legitimacy verification and permission validity verification. Identity legitimacy verification includes verifying the validity and authenticity of the identity credentials (such as an Access Token) provided by the second tenant, verifying the signature of the request to prevent tampering, and confirming that the request indeed originates from a legitimate user of the second tenant. Permission validity verification includes querying the access policy library to confirm whether the second tenant has been granted access to "Project 1" by the first tenant, and checking whether the authorization is valid and whether the operation type conforms to the authorized scope (e.g., no unauthorized write operation attempt).

[0142] If we denote the first tenant as tenant A and the second tenant as tenant B, assuming tenant A is the OEM and tenant B is the collaborator, the flowchart illustrating the method for controlled inter-organizational collaboration between tenant A and tenant B through refined role mapping and a data sandbox mechanism in this application scenario is as follows: Figure 14 As shown:

[0143] During the initialization of the collaborative space, tenant A creates a dedicated collaborative project, configures data sharing boundaries (e.g., only open specific data such as BOM tables and process requirements), and initiates a multi-level approval workflow by requesting access to tenant B's data and specifying tenant B's participants (e.g., quality engineer Zhang San).

[0144] It also allows for cross-tenant role definition. Tenant A administrator can create collaborative roles (such as "external designer") and set fine-grained permissions.

[0145] Next, cross-tenant shadow account synchronization can be performed. The system generates a shadow account (labeled B-Zhang San) in tenant A's space. Then, two-factor authentication is implemented. At this point, tenant B, as a collaborator, accesses the data of host A. Tenant B can click the collaboration button or link on their own interface. The backend performs two verifications: firstly, it verifies whether tenant B's token in their own tenant is valid; secondly, it verifies whether tenant B's action of accessing tenant A's data is legal, including whether the accessed resources are valid and whether the access permissions are correct. After both verifications pass, a B->A token is generated.

[0146] When performing collaborative tasks, end-to-end auditing and tracing can be implemented. All cross-tenant data interactions are executed through a security sandbox, with complete access control and recording of operation content, process, and context information. Related operations are synchronized to the log management system in real time. Meanwhile, tenant B can call the interface to retrieve tenant A's data when needed.

[0147] Tenant A creates a cross-tenant collaboration project through the collaboration management platform and completes the following operations based on the visual policy configuration interface: 1) Data entity-level authorization: Select core business data that can be shared; 2) Collaboration item permission control: Set temporary access validity period and set different access permissions for each data entity (e.g., data A in a certain project has read-only permission, and data B has read-write permission); 3) Collaboration member configuration: Select designated personnel from the organizational structure of tenant B; 4) Secure approval process: Automatically generate an approval form containing configuration details and trigger a multi-level approval workflow (requiring multiple approvals from tenant A's data manager and relevant specialists). The cross-tenant resource sharing configuration interface is shown below. Figure 15 As shown.

[0148] Meanwhile, the administrator of Tenant A can create collaborative roles (such as "External Designer"), set fine-grained access policies based on the visual permission configuration interface, and synchronize the permission configuration to the access control engine in real time to ensure that the policies take effect dynamically. In other words, permission changes for collaborative roles can be implemented through a distributed notification mechanism.

[0149] Figure 16 This is a flowchart illustrating a method for changing collaborative role permissions using a distributed notification mechanism, as provided in an embodiment of this application. Figure 16As shown, after the administrator of tenant A submits the configuration to the permission management module and completes the permission configuration, the system can persistently store the policy version in the Redis cluster, and then broadcast the change event to the entire cluster through the publish / subscribe (PUB / SUB) mechanism. The access control engine receives the event in real time and immediately updates the in-memory policy tree to ensure strong consistency authentication, while each business service node adopts an eventual consistency scheme, only marking the local cache as invalid and pulling the latest policy on demand for subsequent requests.

[0150] On the one hand, when the published cache is updated to the business service node, the cache expiration time can be marked and cached using a local policy, and then lazy-loaded to the Redis cluster. On the other hand, when the published cache is updated to the access control engine, the latest policy acknowledgment character (ACK) and version verification can be pulled from the Redis cluster. The memory policy can also be updated to the engine policy cache. Then, requests are intercepted through real-time authentication. If authentication is successful, the business logic is executed; if authentication is rejected, a 403 alert is returned.

[0151] Figure 17 This is a schematic diagram of the synchronization process for cross-tenant shadow accounts provided in an embodiment of this application. For example... Figure 17 As shown, after the approval workflow is completed, the system generates a unique shadow account identifier in tenant A space according to the specifications, synchronizes the basic attribute information of user Zhang San in source tenant B, and configures the preset access policy according to the approval result; then, user information (storing basic account information) and permission rules (storing fine-grained access control rules) are written through distributed transaction atomicity, and finally a security audit log containing complete operation records is generated, realizing the secure mapping of cross-tenant identities and precise control of permissions.

[0152] In other words, once the approval workflow is completed, the system will automatically create a shadow account ID for tenant B in tenant A's space. For example, a shadow account will be created for collaborator Zhang San. The entire process is completed automatically at the system level, transparent to users and ensuring data isolation.

[0153] The system can synchronize user attributes for the generated shadow accounts, configure permission policies, and write them to a distributed transaction. This includes tenant A's user directory, which contains basic account information, and tenant A's permission services, which contain storage policy rules. Upon completion of synchronization, a completion notification is generated and sent to the operation audit log.

[0154] When accessing tenant A's collaborative data, the system simultaneously verifies the validity of tenant B's original identity credentials and the fine-grained collaborative permissions granted by tenant A, and implements two-factor access control through dynamic token binding; at the same time, all cross-tenant data interaction operations are executed in a secure sandbox environment, recording the operation content, context metadata and the complete permission verification process in real time, and generating tamper-proof audit logs that are synchronized to the centralized log management system.

[0155] Figure 18 This is a schematic diagram illustrating the process of a collaborative user switching tenants, as provided in an embodiment of this application. Figure 18 As shown, tenant B user Zhang San (identified as B-Zhang San) achieves cross-tenant access through a multi-tenant identity switching mechanism. The specific process includes the following technical implementations: 1) When the front-end interface triggers a tenant switching request, the system verifies the validity of the user's original identity credentials through the security token service; 2) After successful identity verification, the authorization service generates a temporary access token based on a preset cross-tenant collaboration strategy; 3) The system automatically loads the workspace configuration of tenant A and injects a tenant identifier watermark into the front-end interface; 4) All subsequent API requests carry the tenant and user context identifier (X-Tenant-Id: A, X-Access-Token: A tenant's temporary token). The business middle platform achieves fine-grained data isolation and access control by parsing this header.

[0156] In other words, when tenant B, user Zhang San (identified as B-Zhang San), clicks the switch tenant button, the switch request carrying the current tenant's token (JSON Web Token, JWT) undergoes dual verification: firstly, the source tenant's identity is verified and user status is checked; secondly, the target tenant's permissions are checked to verify collaboration permissions. After successful verification, the configuration is dynamically loaded, including initializing the DB connection pool, creating storage clients, and allocating container resources. Once the configuration is loaded, a new token is generated and the security context is updated, thus completing the switch.

[0157] When tenant B user Zhang San (identified as B-Zhang San) accesses tenant A's resources through the multi-tenant identity switching mechanism, the system will automatically generate audit logs to record the full-link tracking information of cross-tenant operations. Figure 19 This is a schematic diagram of the recording format of the cross-tenant operation audit log provided in an embodiment of this application. For example... Figure 19 As shown, the log includes: explicitly marked identity identifiers, operation timestamps accurate to the second, accessed target resource paths and corresponding operation records, ensuring the traceability and non-repudiation of cross-tenant operations.

[0158] Figure 20 This is a schematic diagram of the overall architecture of the socialized collaborative multi-tenant demand management system provided in this application embodiment. For example... Figure 20As shown, this architecture can include a configuration layer, a control layer, an execution layer, a data layer, and an audit layer. The configuration layer can include a tenant management platform, which can configure and distribute requests to the intelligent routing gateway in the control layer. The intelligent routing gateway can either isolate and route requests to the dedicated service cluster in the execution layer, or collaboratively request requests to the dual-authentication engine in the execution layer. The dedicated service cluster can access tenant DB instances, tenant document libraries, and tenant buckets in the data layer through data access. After successful authentication, the dual-authentication engine can access the security sandbox in the data layer to execute the request. The entire process of request execution is audited by the audit layer.

[0159] This architecture can be used to implement the dynamic routing and isolated access method for supporting multi-tenant heterogeneous data sources provided in the embodiments of this application. In one example, the registration of new tenants can be completed first on the tenant management platform, generating a unique tenant identifier and establishing a basic configuration file; then, based on the business function modules subscribed by the tenant, the instantiation configuration of associated service resources can be completed; next, the tenant organizational structure tree relationship can be configured, a user account system can be established, and fine-grained access control policies can be set; then, based on the tenant characteristic attributes, service endpoint binding rules and traffic distribution policies can be configured; then, business service requests can be intercepted, the tenant context can be parsed, and data access component instances can be dynamically initialized; finally, through the initialized resource access client, specific business data processing and logical operations can be completed.

[0160] Furthermore, during cross-tenant collaboration, the collaboration space can be initialized first. Tenant A creates a dedicated collaboration project, configures data sharing boundaries, designates participants from Tenant B, and initiates a multi-level approval workflow. Then, cross-tenant roles are defined. Tenant A's administrator creates collaboration roles and sets fine-grained permissions. Next, cross-tenant shadow account synchronization is performed. The system generates shadow accounts for designated member accounts in Tenant B within Tenant A's space. Then, two-factor access control is implemented. When accessing collaborative data in Tenant A, Tenant B's identity credentials and the collaboration permissions granted by Tenant A are verified simultaneously. After access control is passed, the shadow account executes the collaboration task in Tenant A. At the same time, full-link auditing and tracing are implemented. All cross-tenant data interactions are executed through a security sandbox, ensuring complete access control and recording the operation content, process, and context information. Related operations are synchronized to the log management system in real time.

[0161] Figure 21 This is a schematic diagram of the multi-tenant data isolation device architecture provided in the embodiments of this application. For example... Figure 21 As shown, this multi-tenant data isolation device may include a tenant management platform, an intelligent routing gateway, and a distributed storage engine. The tenant management platform issues routing policies to the intelligent routing gateway, which then forwards requests carrying tenant IDs to the distributed storage engine. Furthermore, the tenant management platform can also synchronize data source mappings to the distributed storage engine.

[0162] Distributed storage engines can access different tenant data spaces, and these different tenant data spaces reside in physically isolated storage clusters. For example, tenant A's data space could be a PolarDB instance: polardb-tenantA; or a MongoDB shard: db_tenantA; or an OSS Bucket: bucket-tenantA. Similarly, tenant B's data space could be a PolarDB instance: polardb-tenantB; or a MongoDB shard: db_tenantV; or an OSS Bucket: bucket-tenantB. And so on.

[0163] Figure 22 This is a schematic diagram of the cross-tenant secure collaboration device architecture provided in an embodiment of this application. For example... Figure 22 As shown, the device includes core components such as a collaboration strategy management module, a dual authentication engine, a security sandbox environment, and an operation audit module, as well as their interactions.

[0164] The collaboration strategy management module is used to establish cross-tenant access authorization rules based on a multi-level approval workflow, defining the scope and timeliness of collaborative resources through a visual configuration interface. The dual-authentication engine performs strict identity and permission verification on collaboration requests, including source tenant identity status review and target tenant real-time permission checks, while generating time-sensitive access credentials. The operation auditing module records and stores verifiable traces of the collaboration process in real time. The secure collaboration system enables controlled data sharing between tenants while ensuring data isolation.

[0165] The technical solution provided in this application adopts dynamic credential management and instance-level physical isolation mechanisms at the data security level. Each tenant has an independent PolarDB instance, MongoDB document repository, OSS storage bucket, and ElasticSearch index.

[0166] In terms of cross-tenant collaboration, secure and controllable data sharing is achieved through an approval workflow engine and a dual verification mechanism (source tenant identity verification + target tenant permission check).

[0167] In terms of system performance, a dynamic configuration interface is used to enable small tenants to share database instances while maintaining schema isolation, while large tenants use dedicated clusters. Combined with connection pool management technology, this allows more users to complete business operations under the same hardware conditions.

[0168] In terms of service stability, adjustable tenant configuration enables different tenants to access different business software clusters, ensuring stable response times for high-priority tenant requests and effectively solving the "noisy neighbor" problem.

[0169] In terms of operation and maintenance management, the centralized tenant management platform enables real-time synchronization and activation of configurations. The deployment time for new tenants has been reduced from several hours in the traditional solution to minutes, which greatly reduces downtime for system upgrades and maintenance and lowers the cost of operation and maintenance manpower.

[0170] The technical solution provided in this application embodiment achieves user authentication through centralized authentication service, ensures security through multi-factor authentication mechanism, and binds successfully authenticated users with their tenant information to generate encrypted access tokens containing tenant identifiers.

[0171] By parsing the tenant identifier in the request, the configuration information of the tenant management platform can be queried in real time, a connection with the dedicated service cluster can be dynamically established, and the corresponding data source configuration can be loaded to achieve tenant-level isolated access to computing and storage resources.

[0172] When a cross-tenant access request is detected, the system first verifies the requester's valid identity status in the source tenant, then checks the scope of collaborative permissions granted by the target tenant, and finally performs data interaction operations in a controlled and secure environment.

[0173] After the request is processed, the occupied connection resources are automatically released, and a complete audit log containing key information such as operation time, operation user, accessed resources and permission basis is generated to ensure the traceability of the operation process.

[0174] Compared with existing technologies, the technical solution provided in this application brings significant technological advancements and substantial improvements in data isolation, cross-tenant collaboration, service governance, and operation management of multi-tenant SaaS systems. Through tenant ID dynamic routing technology and a secure collaboration mechanism, it fundamentally solves the long-standing technical bottlenecks in data isolation, cross-tenant collaboration, system performance, and operation management inherent in traditional solutions.

[0175] The technical solution provided in this application, through systematic architectural innovation, effectively solves the technical defects of existing technologies in data isolation, innovatively realizes the security, controllability, integrity and traceability of cross-tenant collaboration processes, redefines the design paradigm of multi-tenant SaaS systems, and provides a practical engineering practice solution for secure data sharing in a cloud computing environment.

[0176] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0177] The following are embodiments of the apparatus of this application, which can be used to execute the embodiments of the method of this application. For details not disclosed in the embodiments of the apparatus of this application, please refer to the embodiments of the method of this application.

[0178] Figure 23 This is a schematic diagram of a dynamic routing and isolation access device supporting multi-tenant heterogeneous data sources provided in an embodiment of this application. Figure 23 As shown, the device includes:

[0179] The resource configuration module 2301 is configured to configure basic resources and dynamic resources for each tenant in the cloud computing management platform; the basic resources include independent data storage space and service instances allocated to each tenant, and the dynamic resources include dynamically allocated storage resources and routing policies.

[0180] The initialization module 2302 is configured to dynamically initialize the resources corresponding to the service request in response to receiving a service request from the first tenant, and then access the client to execute the service request through the initialized resources.

[0181] The collaboration configuration module 2303 is configured to, in response to receiving a cross-tenant collaboration task, configure the cross-tenant collaboration process of the first tenant and the second tenant; the cross-tenant collaboration process includes a dual authentication mechanism, execution of tenant data interaction in a secure sandbox environment, and generation of full-link audit logs for all interaction operations.

[0182] According to the technical solution provided in this application, by configuring basic and dynamic resources for each tenant in the cloud computing management platform, upon receiving a business request from the first tenant, the resources corresponding to the business request are first dynamically initialized. Then, the client is accessed through the initialized resources to execute the business request. Furthermore, upon receiving a cross-tenant collaborative task, a first-tenant and second-tenant collaboration process is configured, including a dual authentication mechanism, a secure sandbox environment for executing tenant data interaction, and the generation of full-link audit logs for all interaction operations. This achieves a unified approach of strict data isolation and controllable sharing in a multi-tenant environment through a dynamic isolation architecture and secure collaboration mechanism. Simultaneously, this application supports minute-level tenant deployment and real-time configuration effectiveness, resolving the technical contradictions in isolation, collaboration, and operational efficiency inherent in traditional solutions, and providing a secure and efficient multi-tenant solution for the demand management system.

[0183] On the other hand, this application embodiment also provides a dynamic routing and isolation access system that supports multi-tenant heterogeneous data sources, which includes a tenant management platform configured to store and manage the independent configuration information of each tenant, the independent configuration information including dynamic service routing policies and heterogeneous data source mapping relationships;

[0184] The intelligent routing gateway is configured to identify and verify tenants for user requests and perform two-stage routing decisions based on the tenant identifier.

[0185] The distributed storage engine is configured to provide each tenant with independent data storage space using a physically isolated architecture.

[0186] The multi-tenant data isolation system is configured to ensure strict isolation of computing and storage resources among tenants through a dynamic configuration loading mechanism.

[0187] The collaboration strategy management module is configured to establish cross-tenant access authorization rules based on a multi-level approval workflow, and define the scope and timeliness of collaborative resources through a visual configuration interface;

[0188] The dual authentication engine is configured to perform identity and permission verification on collaboration requests, including source tenant identity status verification and target tenant real-time permission checks, while generating time-sensitive access credentials.

[0189] The operation audit module is configured to record and store verifiable traces of the collaboration process in real time;

[0190] The secure collaboration system is configured to enable controlled sharing of data among tenants while ensuring data isolation.

[0191] Heterogeneous data source mapping refers to the targeted association rules established between different types of data storage resources and tenants, ensuring that each tenant can accurately access its dedicated data storage resources. This includes the content of the mapping relationship, the technical implementation mechanism, and the runtime execution flow.

[0192] The mapping relationships include physical resource mapping and logical structure mapping. Physical resource mapping is used to determine the correspondence between tenants and specific data instances, for example: tenant A → PolarDB instance-123 + OSS bucket-bucket-a; tenant B → MongoDB cluster-456 + ES index-tenant-b. Logical structure mapping is used to achieve isolation through logical identifiers in shared data sources, for example, tenant D uses the key prefix tenant_d in shared Redis.

[0193] The technical implementation mechanism includes a metadata configuration library and a dynamic routing engine. The former uses the configuration library to store mapping rules, while the latter resolves the target resource in real time based on the tenant identifier.

[0194] The runtime execution process includes receiving data access requests carrying tenant identifiers, querying mapping rules to determine the location of the target data source, establishing a connection channel with the dedicated data source, accessing specific resources, and returning a tenant-specific data result set.

[0195] Two-stage routing decision is a mechanism that divides request processing into two consecutive stages for routing decisions. The first stage determines which business service cluster the request should be forwarded to, and the second stage determines how to access the correct data source within that cluster.

[0196] The first phase is the service routing phase, which determines which business service cluster or instance the request should be distributed to. The process can be as follows: first, receive the request and parse the tenant identity; then, query the service routing configuration based on the tenant ID; next, forward the request to the corresponding dedicated service cluster; and finally, inject the tenant context information into the request header.

[0197] The second phase involves the data routing node, which, within the target service cluster, determines how to access the tenant's dedicated data source. The process can be as follows: first, the business service receives the request and extracts the tenant context; then, it obtains a dedicated data connection through the data source router based on the tenant ID; and finally, it uses this dedicated connection to perform data operations.

[0198] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0199] Figure 24 This is a schematic diagram of the electronic device provided in an embodiment of this application. For example... Figure 24 As shown, the electronic device 24 of this embodiment includes: a processor 2401, a memory 2402, and a computer program 2403 stored in the memory 2402 and executable on the processor 2401. When the processor 2401 executes the computer program 2403, it implements the steps in the various method embodiments described above. Alternatively, when the processor 2401 executes the computer program 2403, it implements the functions of each module / unit in the various device embodiments described above.

[0200] Electronic device 24 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 24 may include, but is not limited to, processor 2401 and memory 2402. Those skilled in the art will understand that... Figure 24 This is merely an example of electronic device 24 and does not constitute a limitation on electronic device 24. It may include more or fewer components than shown, or different components.

[0201] The processor 2401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0202] The memory 2402 can be an internal storage unit of the electronic device 24, such as a hard disk or RAM of the electronic device 24. The memory 2402 can also be an external storage device of the electronic device 24, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, FlashCard, etc., equipped on the electronic device 24. The memory 2402 can also include both internal and external storage units of the electronic device 24. The memory 2402 is used to store computer programs and other programs and data required by the electronic device.

[0203] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0204] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0205] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for dynamic routing and isolated access to multi-tenant heterogeneous data sources, characterized in that, include: Configure basic and dynamic resources for each tenant in the cloud computing management platform; The basic resources include independent data storage space and service instances allocated to each tenant, and the dynamic resources include dynamically allocated storage resources and routing policies. In response to receiving a service request from the first tenant, the resource corresponding to the service request is dynamically initialized, and the client is accessed to execute the service request through the initialized resource. In response to receiving a cross-tenant collaboration task, configure the cross-tenant collaboration process for the first tenant and the second tenant; The cross-tenant collaboration process includes a dual authentication mechanism, a secure sandbox environment for executing tenant data interactions, and the generation of full-link audit logs for all interaction operations. This includes configuring basic and dynamic resources for each tenant in the cloud computing management platform, including: In response to receiving the first tenant's registration request, a unique identifier for the first tenant is generated, and a basic configuration profile is generated based on the first tenant's metadata; Obtain the subscription information of the first tenant, and instantiate and configure the isolated service resources of the first tenant based on the subscription information; Configure fine-grained access control policies for the first tenant; Obtain the characteristic attributes of the first tenant, and configure the service endpoint binding rules and traffic distribution strategy of the first tenant based on the characteristic attributes; Based on the subscription information, the isolated service resource instantiation configuration of the first tenant is associated with the following: Configure an independent relational database or a non-relational database for the first tenant; wherein the connection configuration items for the relational database include the database instance connection address, a dedicated database account with CRUD permissions for adding, reading, updating, deleting, and storing encrypted access credentials; the connection configuration items for the non-relational database include: the system-preset MongoDB replica set connection string, the database sharding access account and its corresponding encrypted access credentials. Assign a dedicated microservice cluster entry point to the first tenant and set the following storage configuration for the first tenant: regional access endpoint, access key, key credentials, and a dedicated storage space name for the first tenant; Configure a search engine service for the first tenant; the search engine service includes an Elasticsearch cluster REST access endpoint, an index-level access account, a dynamically generated access token, and an index namespace exclusive to the first tenant.

2. The method according to claim 1, characterized in that, Configure the fine-grained access control policy for the first tenant, including: Configure the organizational structure tree relationship of the first tenant; the organizational structure includes at least the department nodes, hierarchical relationship, control attributes and extended attributes of the first tenant; A user account system is established based on the tree relationship, so that the user account is associated with the target department node in the organizational structure tree, and the fine-grained access control policy of the first tenant is configured. The fine-grained access control policy is implemented based on the user-role-permission model, including data-level permissions, function-level permissions, and field-level permissions, which are verified in real time with each request through a dynamic permission decision engine.

3. The method according to claim 1, characterized in that, Configure the service endpoint binding rules and traffic distribution strategy for the first tenant based on the aforementioned characteristic attributes, including: Configure the bound business cluster for the first tenant based on the aforementioned characteristic attributes; In response to determining that the first tenant is bound to a dedicated service cluster, the traffic distribution strategy is determined to accurately route the first tenant's service requests to the dedicated service cluster. The dedicated service cluster then determines the computing node to process the first tenant's service requests based on a preset load balancing strategy. The computing node returns a response message after accessing the first tenant's dedicated database to complete the service processing. In response to determining that the first tenant is bound to a shared service cluster, the traffic distribution strategy is determined to be based on resource quotas to determine the computing nodes for the first tenant's service requests; In response to determining that the first tenant is bound to a dedicated high-performance service cluster, the traffic distribution strategy is to determine the computing node in the dedicated high-performance service cluster that processes the first tenant's service requests, and to ensure the service quality of the first tenant through fixed session binding and a dedicated thread pool.

4. The method according to claim 1, characterized in that, Dynamically initialize the resources corresponding to the business request, including: Intercept the first tenant's business request, and preprocess the business request to obtain the first tenant's context object; The resources corresponding to the business request are initialized based on the context object, the resource configuration validity of the first tenant is verified, and the tenant-level resource isolation is maintained through the connection pool manager to generate a data access component carrying the context tag of the first tenant. The initialization of the resources corresponding to the business request based on the context object includes: Create tenant-specific JDBCTemplate instances for relational databases to configure isolated data source connection pools; Initialize a MongoTemplate object with permissions for the specified database name for the document database; Build a storage client that restricts access permissions to OSS Buckets; It also configures the Elasticsearch cluster's expressive state transition interface (REST) ​​endpoint, index-level access accounts, dynamically generated access tokens, and tenant-specific index namespaces to achieve tenant isolation for the search service.

5. The method according to claim 1, characterized in that, Configure the cross-tenant collaboration process for the first tenant and the second tenant, including: During the initialization phase of the collaboration space, the first tenant creates a dedicated collaboration project, configures data sharing boundaries, designates the second tenant as a participant, and initiates a multi-level approval workflow. During the cross-tenant role definition phase, the first tenant, acting as the administrator, creates the collaboration role and sets fine-grained permissions; During the cross-tenant shadow account synchronization phase, a shadow account is created in the space of the first tenant for a designated member account in the second tenant, so that the shadow account works as the collaborative role. The two-factor access control policy simultaneously verifies the identity credentials of the second tenant and the collaboration permissions granted by the first tenant when accessing the first tenant's collaborative data.

6. The method according to claim 5, characterized in that, The shadow account performs the cross-tenant collaborative task in the space of the first tenant in the identity of the collaborative role; All operations performed by the shadow account to execute the cross-tenant collaboration task are performed in a secure sandbox environment; All operations performed by the shadow account in the cross-tenant collaboration task are recorded in the audit log; the audit log includes at least the shadow account's identity identifier, operation timestamp, accessed target resource path, and corresponding operation record.

7. A dynamic routing and isolation access device supporting multi-tenant heterogeneous data sources, characterized in that, include: The resource configuration module is configured to configure basic and dynamic resources for each tenant in the cloud computing management platform. The basic resources include independent data storage space and service instances allocated to each tenant, and the dynamic resources include dynamically allocated storage resources and routing policies. The initialization module is configured to dynamically initialize the resources corresponding to the service request in response to receiving a service request from the first tenant, and then access the client to execute the service request through the initialized resources. The collaboration configuration module is configured to configure the cross-tenant collaboration process of the first tenant and the second tenant in response to receiving a cross-tenant collaboration task; The cross-tenant collaboration process includes a dual authentication mechanism, a secure sandbox environment for executing tenant data interactions, and the generation of full-link audit logs for all interaction operations. This includes configuring basic and dynamic resources for each tenant in the cloud computing management platform, including: In response to receiving the first tenant's registration request, a unique identifier for the first tenant is generated, and a basic configuration profile is generated based on the first tenant's metadata; Obtain the subscription information of the first tenant, and instantiate and configure the isolated service resources of the first tenant based on the subscription information; Configure fine-grained access control policies for the first tenant; Obtain the characteristic attributes of the first tenant, and configure the service endpoint binding rules and traffic distribution strategy of the first tenant based on the characteristic attributes; Based on the subscription information, the isolated service resource instantiation configuration of the first tenant is associated with the following: Configure an independent relational database or a non-relational database for the first tenant; wherein the connection configuration items for the relational database include the database instance connection address, a dedicated database account with CRUD permissions for adding, reading, updating, deleting, and storing encrypted access credentials; the connection configuration items for the non-relational database include: the system-preset MongoDB replica set connection string, the database sharding access account and its corresponding encrypted access credentials. Assign a dedicated microservice cluster entry point to the first tenant and set the following storage configuration for the first tenant: regional access endpoint, access key, key credentials, and a dedicated storage space name for the first tenant; Configure a search engine service for the first tenant; the search engine service includes an Elasticsearch cluster REST access endpoint, an index-level access account, a dynamically generated access token, and an index namespace exclusive to the first tenant.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

Images