A multi-tenant data processing method, device and medium based on distributed deployment
Patent Information
- Application Number
- CN202311189262.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-14
- Publication Date
- 2026-11-03
- Estimated Expiration
- 2043-09-14
AI Technical Summary
Existing multi-tenant data isolation methods cannot ensure data security and scalability, and the installation, deployment, expansion, and maintenance costs of software splitting into microservices are high.
By using a multi-tenant data processing method based on distributed deployment, thread binding is performed using session information in the software-deployed microservices to obtain tenant context information, and database connection configuration is performed through the configuration center to realize data source switching and tenant's multi-type business expansion calls.
It achieves secure isolation and elastic scalability of multi-tenant data, reduces the installation, deployment and maintenance costs of software splitting into microservices, and can provide personalized and customized services.
Smart Images

Figure CN117112266B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of distributed deployment, and in particular to a multi-tenant data processing method, device and medium based on distributed deployment. Background Technology
[0002] With the rapid development of the software industry and the widespread adoption of cloud computing and the internet, the number of software users is increasing dramatically, while industry segmentation is becoming more pronounced. Software vendors need to provide more personalized and customized services based on the different dimensions of various industries and users. Furthermore, vendors must ensure that each user can securely access their own data. As a result, the time and cost of installing, deploying, and maintaining enterprises and applications will increase significantly.
[0003] The main challenges and issues to address in multi-tenant data isolation include: Single point of failure: Because tenants need to operate independently, this multi-tenant architecture is prone to single points of failure. This is because if one tenant's resources fail, only that tenant is affected. Security: Security is paramount when managing multiple tenants. It's essential to ensure that each tenant's data and applications are isolated and secure across different tenants. System scalability: System scalability is crucial in multi-tenant architectures. Since each tenant has its own data and applications, system scalability must be considered, and each tenant must be able to operate relatively independently. Performance: In a multi-tenant environment, data storage and processing must consider the actual needs of each tenant. If one tenant requires a large amount of data processing or storage, it may impact the performance of other tenants. Data backup and recovery: Backing up and recovering data becomes more complex in a multi-tenant environment. It's essential to ensure that each tenant's data can be backed up and recovered without interference from other tenants. Summary of the Invention
[0004] This application provides a multi-tenant data processing method, device, and medium based on distributed deployment to solve the following technical problems: existing multi-tenant data isolation is difficult to ensure data security and scalability, and the corresponding software splitting microservices has high installation, deployment, expansion, and maintenance costs.
[0005] The embodiments of this application adopt the following technical solutions:
[0006] On one hand, embodiments of this application provide a multi-tenant data processing method based on distributed deployment, including: binding tenant attribute information to threads based on session information in a software-deployed microservice to obtain tenant context information; configuring database connections for the tenant context information through a configuration center in the software-deployed microservice to obtain tenant configuration information; switching data sources for data access information based on the tenant context information and the tenant configuration information to obtain data source connection information; connecting the tenant's data information to a data source based on the data source connection information; and performing various types of business extension calls on the tenant based on the tenant configuration information and the data source connection information to achieve multi-functional extension of the tenant.
[0007] This application's embodiments, through the storage of tenant and user information, the implementation of tenant configuration storage and retrieval interfaces and databases, data source switching during data access, and scalable tenant calls, are beneficial for applications in scenarios involving large-scale software decomposition into microservices or distributed deployments. When dealing with a large number of users, different organizations, and different roles, it ensures data security and elastic scalability by storing and processing data from different tenants separately, i.e., multi-tenant data isolation. This facilitates the reduction of costs associated with the installation, deployment, expansion, and maintenance of software decomposition into microservices, enabling software vendors to provide more personalized and customized services based on the different dimensions of various industries and users.
[0008] In one feasible implementation, tenant attribute information is bound to a thread based on session information in the software-deployed microservice to obtain tenant context information. Specifically, this includes: associating the tenant attribute information with user information to obtain tenant association information; and storing the tenant association information in the session information of the software-deployed microservice. The session information includes at least tenant keyword information and user personal information. Based on the session information, the tenant association information is bound to the tenant context thread to obtain the tenant context information. The tenant context information includes at least the current thread tenant ID, the current thread's microservice information, and other dimension information required by the tenant.
[0009] In one feasible implementation, the configuration center in the software-deployed microservice is used to configure the connection of the tenant context information to the database to obtain tenant configuration information. Specifically, this includes: connecting multiple tenant context information sets to the database through the configuration center to determine the connection information under distributed deployment; associating the tenant context information with the configuration list in the database one by one based on the connection information to obtain relevant configuration information; wherein, the configuration list in the database includes: a Tenant configuration table, a DbConnection configuration table, and a DbMapping configuration table; and configuring the tenant according to the relevant configuration information to obtain the tenant configuration information.
[0010] In one feasible implementation, the Tenant configuration table includes: tenant ID, tenant number, and tenant name; the DbConnection configuration table includes: connection information ID, database connection URL, and database type; and the DbMapping configuration table includes: user ID, the tenant ID, microservice extension dimension, and database connection ID.
[0011] In one feasible implementation, the data access information is switched based on the tenant context information and tenant configuration information to obtain data source connection information. Specifically, this includes: determining the access type of the data access information to obtain the data access type; wherein the data access type includes: entity operation access and default direct access; if the data access type is entity operation access, then the tenant context information and corresponding session information are obtained; the tenant context information and the session information are integrated and identified to obtain identification information based on the entity operation access; through the identification information, the tenant configuration information in the configuration center is correlated with the corresponding data to obtain the tenant information and microservice information to which the current thread belongs; based on the identification information, the data source information corresponding to the identification is determined; the data source information and the tenant information are connected and configured to determine the data source connection information based on the entity operation access.
[0012] In one feasible implementation, if the data access type is the default direct access, then the default data source information is directly obtained through the database of the configuration center, and the data source connection information corresponding to the default data source information access is determined; wherein, the default data source information is the preset data source information when there is no tenant context information.
[0013] In one feasible implementation, the connection of the tenant's data information to the data source based on the data source connection information specifically includes: generating a corresponding data source based on the data source connection information, the tenant context information, and the tenant configuration information; and performing one-to-one configuration connection processing on the tenant's data information through the data source to achieve data isolation between multiple tenants.
[0014] In one feasible implementation, based on the tenant configuration information and the data source connection information, the tenant is subjected to various types of business extension calls, specifically including: performing REST cross-tenant extension calls on the tenant based on the tenant configuration information and the data source connection information, and by passing the TenantId in the front-end HTTP request; temporarily switching the tenant's routing based on the tenant configuration information and the data source connection information, and by using the RPC service interface in Remote Procedure Call, to achieve remote procedure extension calls on the tenant; performing tenant-level extension calls on the tenant based on the tenant configuration information and the data source connection information, and by using microservice-level dimension information; and performing integrable extension calls on the tenant based on the tenant configuration information and the data source connection information, and according to the integration requirements of external applications, involving tenant information parsing and mapping.
[0015] Secondly, embodiments of this application also provide a multi-tenant data processing device based on distributed deployment, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to execute a multi-tenant data processing method based on distributed deployment as described in any of the above embodiments.
[0016] Thirdly, embodiments of this application also provide a non-volatile computer storage medium, characterized in that the storage medium is a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium stores at least one program, each program including instructions, and when the instructions are executed by a terminal, the terminal executes a multi-tenant data processing method based on distributed deployment as described in any of the above embodiments.
[0017] This application provides a multi-tenant data processing method, device, and medium based on distributed deployment. Compared with the prior art, this application has the following beneficial technical effects:
[0018] This application's embodiments, through the storage of tenant and user information, the implementation of tenant configuration storage and retrieval interfaces and databases, data source switching during data access, and scalable tenant calls, are beneficial for applications in scenarios involving large-scale software decomposition into microservices or distributed deployments. When dealing with a large number of users, different organizations, and different roles, it ensures data security and elastic scalability by storing and processing data from different tenants separately, i.e., multi-tenant data isolation. This facilitates the reduction of costs associated with the installation, deployment, expansion, and maintenance of software decomposition into microservices, enabling software vendors to provide more personalized and customized services based on the different dimensions of various industries and users. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, 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 recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:
[0020] Figure 1 A flowchart illustrating a multi-tenant data method based on distributed deployment, as provided in this application embodiment;
[0021] Figure 2 A schematic diagram of thread binding based on microservice splitting is provided for an embodiment of this application;
[0022] Figure 3 A schematic diagram illustrating data source switching based on data access, provided for an embodiment of this application;
[0023] Figure 4 This application provides a schematic diagram of a cross-tenant extended call in an embodiment;
[0024] Figure 5 A schematic diagram of a remote procedure call provided in an embodiment of this application;
[0025] Figure 6 This is a schematic diagram of the structure of a multi-tenant data device based on distributed deployment, provided as an embodiment of this application. Detailed Implementation
[0026] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.
[0027] This application provides a multi-tenant data method based on distributed deployment, such as... Figure 1 As shown, the multi-tenant data method based on distributed deployment specifically includes steps S101-S104:
[0028] S101. Based on the session information in the software-deployed microservice, bind the tenant attribute information to the thread to obtain the tenant context information.
[0029] Specifically, tenant attribute information is associated and bound with user information to obtain tenant association information. This tenant association information is then stored in the session information of the microservice deployed in the software. The session information includes at least: tenant keyword information and user personal information.
[0030] Furthermore, based on session information, tenant association information is bound to the tenant context thread to obtain tenant context information. This tenant context information includes at least: the current thread's tenant ID, the current thread's microservice information, and other dimensional information required by the tenant.
[0031] As a feasible implementation method, tenant attributes are associated and bound to user information. Since users select their tenant upon login or after logging in, the design inherently stores tenant and user-related information in a session. Session information is unique and thread-bound; all user operations after login occur within the same session's thread context. The session's lifecycle coincides with the user's activity lifecycle, created upon login and destroyed upon logout or timeout. Session information must include, but is not limited to, the tenant's keyword (ID) and the user's personal information.
[0032] In one embodiment, Figure 2 This diagram illustrates a thread binding method based on microservice decomposition, as provided in an embodiment of this application. Figure 2As shown, in a microservice-based deployment, data isolation is supported across multiple dimensions, including tenants and microservices, meaning a tenant context is bound to a thread. When there are multiple tenants, they are first uniformly connected to a portal, and then the basic services in the Web Server cluster and the microservice gateway (API Gateway) are used to bind and associate them with the main database and the service database (T1-DB). Tenant context information typically includes the tenant ID of the current thread, the microservice information of the current thread, and other dimensions required by the tenant. This information is usually obtained through a session or the microservice context.
[0033] S102. By deploying the configuration center in the microservice through software, configure the connection to the database for the tenant context information to obtain the tenant configuration information.
[0034] Specifically, the configuration center connects the context information of multiple tenants to the database to determine the connection information under the distributed deployment.
[0035] Furthermore, based on the connection information, the tenant context information is associated one-to-one with the configuration list in the database to obtain the relevant configuration information. The configuration list in the database includes: the Tenant configuration table, the DbConnection configuration table, and the DbMapping configuration table. The Tenant configuration table includes: tenant ID, tenant number, and tenant name. The DbConnection configuration table includes: connection information ID, database connection URL, and database type. The DbMapping configuration table includes: user ID, tenant ID, microservice extension dimension, and database connection ID.
[0036] Furthermore, based on the relevant configuration information, the tenant is configured accordingly to obtain the tenant configuration information.
[0037] As a feasible implementation, an application product needs to support multiple tenants and multiple data sources, which requires certain configuration of the relationship between tenants and data sources. Since the application product may be deployed in a cluster, such configurations must be configured in a unified configuration center. The configuration center's interface includes methods for obtaining tenant information, obtaining connection information based on tenants, and obtaining connection information based on tenants and other extended dimensions. The implementation of the interface involves obtaining the relevant configuration list through the configuration center, which allows for the association of tenant context information with the configuration list in the database to obtain the relevant configuration information. Taking database configuration as an example, when the application server interacts with the database service, it first accesses the tenant configuration service. In a distributed deployment scenario, multiple application servers connect to the same master database to provide tenant-related configurations. Then, based on the tenant context information and related extended information, it obtains the database that needs to be accessed through the tenant configuration information.
[0038] S103. Based on the tenant context information and tenant configuration information, switch the data source for the data access information to obtain the data source connection information. Then, based on the data source connection information, connect the tenant's data information to the data source.
[0039] Specifically, the access type of the data access information is determined. Data set access types include entity operation access and default direct access. If the data access type is entity operation access, then the tenant context information and corresponding session information are obtained.
[0040] Furthermore, the tenant context information and session information are integrated and identified to obtain identification information based on entity operation access.
[0041] Furthermore, by using the identification information, the tenant configuration information in the configuration center is correlated with the data to obtain the tenant information and microservice information to which the current thread belongs. Based on the identification information, the data source information corresponding to the identification is determined.
[0042] Furthermore, the data source information and tenant information are configured to connect and determine the data source connection information based on entity operation access.
[0043] If the data access type is the default direct access, the default data source information is directly obtained from the database in the configuration center, and the data source connection information corresponding to the default data source information access is determined. The default data source information is the preset data source information when there is no tenant context information.
[0044] Furthermore, based on the data source connection information, and according to the tenant context information and tenant configuration information, a corresponding data source is generated. Through the data source, the tenant's data information is configured and connected one-to-one to achieve data isolation between multiple tenants.
[0045] As a feasible implementation method, to achieve tenant data isolation and improve database performance, tenant data isolation employs database isolation or schema isolation. Data isolation refers to the data source switching that occurs when the application server accesses the database. Data access typically takes two forms: access via entity framework operations or direct access through a database connection. Therefore, the tenant service also provides both methods. When using entity frameworks, taking JPA as an example, JPA interceptors can be configured to switch tenant databases. Database switching mainly involves two steps: resolving the connection identifier of the current tenant context and obtaining the corresponding data source and connection based on the identifier.
[0046] As a feasible implementation, the first step is to obtain an identifier based on the current tenant context information: by acquiring session information and tenant context information, information such as the tenant to which the current user and thread belong, and microservice information can be obtained. This information is then aggregated into an identifier for subsequent use. Next, based on the previously obtained identifier information, the corresponding tenant configuration information is retrieved. Based on the identifier information, the data source information configured in the configuration center can also be obtained, thus obtaining the data source connection information based on entity operation access corresponding to the tenant identifier information. The corresponding data source can be constructed based on the data source connection information, and the corresponding data source connection can be obtained through the data source. In addition to the tenant data source, a method for obtaining a default data source is also provided to provide a default data source when no tenant information is available.
[0047] In one implementation, Figure 3 This application provides a schematic diagram of a data source switching method based on data access, as shown in the embodiment. Figure 3 As shown, in a public cloud, tenant information is input into the shared application server instance via LoadBalancer, followed by tenant access control, tenant context information processing, and tenant mapping service processing to complete the switching and access to single / multi-Schema (object collection) databases. In a managed cloud, tenant information is input into the managed application server instance via APP Server routing and LoadBalancer, followed by tenant access control, tenant context information processing, and tenant mapping service processing to complete the switching and access to the Schema (object collection) database. This implements the access and corresponding switching between the tenant service API and the tenant configuration library during data access.
[0048] S104. Based on tenant configuration information and data source connection information, perform various types of business extension calls on the tenant to achieve multi-functional extension of the tenant.
[0049] Specifically, based on tenant configuration information and data source connection information, and by passing the TenantId in the front-end HTTP request, the tenant is made a REST cross-tenant extended call.
[0050] In one embodiment, Figure 4 This application provides a schematic diagram of a cross-tenant extended call, as shown in the embodiment. Figure 4 As shown, cross-tenant REST calls mainly refer to the way TenantId (tenant information) is passed in front-end HTTP (response protocol) requests. Passing tenant information via headers or parameter values offers advantages over passing it via domain names or request paths, such as eliminating the need for dynamic domains on the front-end, separate main domain registration, and back-end conversions like nginx. Furthermore, tenant information can be parsed based on parameter routing, retrieving dimension values according to agreed-upon parameter names and checking for their existence. If not found, the dimension values are calculated using route parameter parsing extensions; if found, the tenant information is retrieved from the routing table, ultimately enabling extended cross-tenant REST calls.
[0051] Preferably, based on tenant configuration information and data source connection information, and through the RPC (RpcClient, responsible for importing the proxy implementation of the remote interface) service interface in remote procedure calls, the tenant's tenant route can be temporarily switched to realize remote procedure extended calls to the tenant.
[0052] In one implementation, Figure 5 A schematic diagram of a remote procedure call provided in an embodiment of this application is shown below. Figure 5 As shown, when business needs require cross-tenant calls, directly modifying the thread's session or tenant context carries significant risks. In such cases, temporary tenant switching can be achieved through Remote Procedure Call (RPC). The RPC service interface adds two types of overloaded methods supporting tenant routing: It adds a routing parameter: TenantId (tenant information) target. It adds two parameters: the caller's or callee's route identifier and the tenant or route dimension value parameter.
[0053] Priority can also be given to extending tenant-level calls based on tenant configuration information and data source connection information, and through microservice-level information.
[0054] Preferably, based on tenant configuration information and data source connection information, and according to the integration requirements of external applications, tenants can also be subject to integrable extended calls for tenant information parsing and mapping. Tenant routing integrable extended calls refer to the need for tenant information to be interfaced when the current application has integration requirements with external applications, for parsing and mapping external tenant information and mapping internal dimensions to tenant information.
[0055] In addition, embodiments of this application also provide a multi-tenant data processing device based on distributed deployment, such as... Figure 6 As shown, the multi-tenant data processing device 600 based on distributed deployment specifically includes:
[0056] At least one processor 600. And a memory 602 communicatively connected to at least one processor 601. The memory 602 stores instructions executable by at least one processor 601, enabling at least one processor 601 to execute:
[0057] Based on session information in software-deployed microservices, tenant attribute information is bound to threads to obtain tenant context information;
[0058] By deploying a configuration center within a microservice in software, the tenant context information is configured to connect to the database and obtain the tenant configuration information.
[0059] Based on the tenant context information and tenant configuration information, the data access information is switched to obtain the data source connection information; and based on the data source connection information, the tenant's data information is connected to the data source.
[0060] Based on tenant configuration information and data source connection information, various types of business extension calls are made to the tenant to achieve multi-functional extension of the tenant.
[0061] This application provides a multi-tenant data processing method, device, and medium based on distributed deployment. Through the storage of tenant and user information, tenant configuration storage and retrieval interfaces and database implementation, data source switching during data access, and scalable tenant calls, it is beneficial for applications in scenarios involving large-scale software decomposition into microservices or distributed deployment. When dealing with a large number of users, different organizations, and different roles, it ensures data security and elastic scalability by storing and processing data from different tenants separately, i.e., multi-tenant data isolation. This helps reduce the costs of installation, deployment, expansion, and maintenance of software decomposition into microservices, enabling software vendors to provide more personalized and customized services based on different industries and user dimensions.
[0062] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for devices and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0063] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.
[0064] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0065] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0066] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0067] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0068] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0069] The above description is merely an embodiment of this application and is not intended to limit this application. For those skilled in the art, various modifications and variations can be made to the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of this application should be included within the scope of the claims of this application.
Claims
1. A multi-tenant data processing method based on distributed deployment, characterized in that, The method includes: Based on session information in software-deployed microservices, tenant attribute information is bound to threads to obtain tenant context information; The configuration center in the microservice is deployed through the software to configure the database connection for the tenant context information, thereby obtaining the tenant configuration information. Based on the tenant context information and tenant configuration information, the data access information is switched to obtain data source connection information, specifically including: The data access information is analyzed to determine the data access type; wherein, the data access type includes: entity operation access and default direct access; If the data access type is entity operation access, then obtain the tenant context information and the corresponding session information; The tenant context information and the session information are integrated and identified to obtain identification information based on the entity's operation access; Using the identification information, the tenant configuration information in the configuration center is associated with corresponding data to obtain the tenant information and microservice information to which the current thread belongs; Based on the identification information, the data source information corresponding to the identification is determined; Configure the connection between the data source information and the tenant information to determine the data source connection information accessed based on the entity operation; If the data access type is the default direct access, then the default data source information is directly obtained from the database of the configuration center, and the data source connection information corresponding to the default data source information access is determined; wherein, the default data source information is the preset data source information when there is no tenant context information; and based on the data source connection information, the tenant's data information is connected to the data source, specifically including: Based on the data source connection information, and using the tenant context information and tenant configuration information, a corresponding data source is generated; Through the data source, the data information of the tenant is configured and connected one-to-one to achieve data isolation between multiple tenants; Based on the tenant configuration information and the data source connection information, the tenant is subjected to various types of business extension calls to achieve multi-functional extension of the tenant.
2. The multi-tenant data processing method based on distributed deployment according to claim 1, characterized in that, Based on session information in software-deployed microservices, tenant attribute information is thread-bound to obtain tenant context information, specifically including: The tenant attribute information is associated and bound with the user information to obtain tenant association information; and the tenant association information is stored in the session information of the software deployment microservice; wherein, the session information includes at least: tenant keyword information and user personal information; Based on the session information, the tenant association information is bound to the tenant context thread to obtain the tenant context information; wherein, the tenant context information includes at least: the current thread tenant ID, the current thread's microservice information, and other dimension information required by the tenant.
3. The multi-tenant data processing method based on distributed deployment according to claim 1, characterized in that, By deploying a configuration center within the microservices in the software, the tenant context information is configured with database connections to obtain tenant configuration information, specifically including: The configuration center connects the context information of multiple tenants to the database to determine the connection information under the distributed deployment. Based on the connection information, the tenant context information is associated with the configuration list in the database one by one to obtain the relevant configuration information; wherein, the configuration list in the database includes: Tenant configuration table, DbConnection configuration table and DbMapping configuration table; Based on the relevant configuration information, the tenant is configured accordingly to obtain the tenant configuration information.
4. The multi-tenant data processing method based on distributed deployment according to claim 3, characterized in that, The Tenant configuration table includes: tenant ID, tenant number, and tenant name; The DbConnection configuration table includes: connection information ID, database connection URL, and database type; The DbMapping configuration table includes: user ID, tenant ID, microservice extension dimension, and database connection ID.
5. The multi-tenant data processing method based on distributed deployment according to claim 1, characterized in that, Based on the tenant configuration information and the data source connection information, the tenant will be subject to various types of extended business calls, specifically including: Based on the tenant configuration information and the data source connection information, and through the TenantId transmission method in the front-end HTTP request, the tenant is extended by REST cross-tenant call; Based on the tenant configuration information and the data source connection information, and through the RPC service interface in the remote procedure call, the tenant's tenant routing is temporarily switched to realize the remote procedure extended call to the tenant. Based on the tenant configuration information and the data source connection information, and through the microservice dimension information, the tenant is extended to make tenant dimension calls; Based on the tenant configuration information and the data source connection information, and according to the integration requirements of external applications, the tenant information is parsed and mapped in an integrable and extensible manner.
6. A multi-tenant data processing device based on distributed deployment, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor to enable the at least one processor to perform a multi-tenant data processing method based on distributed deployment according to any one of claims 1-5.
7. A non-volatile computer storage medium, characterized in that, The storage medium is a non-volatile computer-readable storage medium that stores at least one program, each program including instructions that, when executed by a terminal, cause the terminal to perform a multi-tenant data processing method based on distributed deployment according to any one of claims 1-5.
Citation Information
Patent Citations
Method and system suitable for cloud service multi-tenant isolation
CN115842674A
