CN115480914A

CN115480914A - Method and system for realizing multi-tenant service

Info

Publication number: CN115480914A
Application number: CN202211068613.XA
Authority: CN
Inventors: 不公告发明人
Original assignee: Jiangsu Anchao Cloud Software Co Ltd
Current assignee: Jiangsu Anchao Cloud Software Co Ltd
Priority date: 2022-09-02
Filing date: 2022-09-02
Publication date: 2022-12-16
Anticipated expiration: 2042-09-02
Also published as: CN115480914B

Abstract

The invention provides a method and a system for realizing multi-tenant service, wherein the method comprises the following steps: acquiring tenant information respectively corresponding to single tenants in the multi-tenant application to determine a target tenant based on the tenant information; creating a mirror image corresponding to the multi-tenant application to serve as the multi-tenant application mirror image, and extracting a mirror image of a target tenant from the multi-tenant application mirror image to serve as a single-tenant application mirror image; and creating a single-tenant application corresponding to the target tenant based on the single-tenant application mirror image, and synchronizing tenant data matched with the target tenant in the multi-tenant application to the single-tenant application so as to independently provide tenant service for the target tenant through the synchronized single-tenant application. By the method and the system, the purpose of decoupling the tenant data, the tenant service and the tenant resources is realized.

Description

Method and system for realizing multi-tenant service

Technical Field

The invention relates to the technical field of computers, in particular to a method and a system for realizing multi-tenant service.

Background

Multi-tenant refers to a software architecture supporting one instance service multiple users (i.e., customers), each of which is called a tenant (i.e., tent). Software gives tenants the ability to make partial customizations to the system (e.g., user interface colors or business rules), but they cannot customize the code that modifies the software.

The implementation methods of the multi-tenant service in the prior art can be summarized as two types as a whole. The method is used for providing different services for each user by configuring metadata for a single-instance multi-tenant service, namely, one application instance is deployed to meet the requirements of a plurality of users. The other is a shared database multi-tenant service, and the implementation method is specifically divided into two types. The method specifically comprises the following steps: first, the physical database is shared among tenants, and each tenant is divided into banks. The database partitioning refers to splitting data originally stored in one database into a plurality of databases, and each tenant corresponds to one database respectively to distinguish the data of the tenant. Second, tenants share a physical database but do not perform database partitioning. And distinguishing the data of the tenants in a database table through the IDs respectively corresponding to the tenants.

However, the solution of the customer when proposing the personalized demand is to make the expansion compatibility in the service code and the database to realize the personalized demand proposed by each customer. As time goes on, the complexity of the personalized requirements is continuously improved, and the problem of recession is easily caused by the coupling of codes and data; at the same time, the problem of mutual influence in the aspects of performance, stability and the like is caused.

In addition, parameters such as access volume and use frequency of different tenants are different, and the actual resource requirements of different tenants are different. In a traditional single-instance multi-tenant service mode, resources are coupled together, and each tenant cannot monopolize the resource specification of the personalized demand of the tenant. Even if the multi-instance load balancing mode is adopted, the resources are essentially shared. Expanding the resource specification to a state greater than the peak value may result in a defect of resource waste.

In addition, in the shared database multi-tenant service mode, a "tenant ID" is usually added to a table to distinguish data of tenants, and this method has a problem of data security. Once the service code has defects, the problems of data unauthorized and data misoperation are easily caused. Moreover, once the system encounters security attack, all tenants are reached; meanwhile, if one tenant generates a database slow query, all tenants will be affected.

In view of the above, there is a need to improve the multi-tenant service implementation method in the prior art to solve the above problems.

Disclosure of Invention

The invention aims to solve the problems of performance degradation, insufficient stability and the like caused by data coupling existing in the prior art that one application instance is provided for multiple tenants and the multiple tenants share one database in the multi-tenant service, and the problem of unsafe data caused by sharing one database.

In order to achieve the above object, the present invention provides a method for implementing a multi-tenant service, including:

acquiring tenant information respectively corresponding to single tenants in multi-tenant application, and determining a target tenant based on the tenant information;

creating a mirror image corresponding to the multi-tenant application to serve as a multi-tenant application mirror image, and extracting a mirror image of a target tenant from the multi-tenant application mirror image to serve as a single-tenant application mirror image;

and creating a single-tenant application corresponding to the target tenant based on the single-tenant application mirror image, and synchronizing tenant data matched with the target tenant in the multi-tenant application to the single-tenant application so as to independently provide tenant service for the target tenant through the synchronized single-tenant application.

As a further improvement of the present invention, before obtaining tenant information corresponding to each of a single tenant in the multi-tenant application, the method further includes:

acquiring application load information corresponding to the multi-tenant application, and determining whether to execute the step of acquiring tenant information respectively corresponding to a single tenant in the multi-tenant application based on the application load information.

As a further improvement of the present invention, the application load information is determined by giving preset weight coefficients to different system parameters of the multi-tenant application and calculating scores;

wherein the system parameters include: and one or any combination of CPU utilization rate, memory utilization rate, disk IO occupancy rate and network IO occupancy rate corresponding to the multi-tenant application.

As a further improvement of the present invention, the tenant information includes: the activity of each tenant and the service volume of each tenant are respectively corresponding to a single tenant;

the tenant liveness is determined through the API request quantity corresponding to a single tenant, and the tenant service quantity is realized through the database data quantity corresponding to the single tenant.

As a further improvement of the present invention, the API request amount includes: one or any combination of API request quantity percentile, API request time consumption percentile and API request response data quantity percentile corresponding to a single tenant;

the tenant traffic comprises: and one or any combination of several of the percentile of the accumulated data amount corresponding to a single tenant and the average of the percentile of the SQL slow query times.

As a further improvement of the present invention, the synchronization of tenant data matched with a target tenant in a multi-tenant application to a single-tenant application is implemented based on a synchronization policy;

wherein the synchronization policy comprises:

determining whether to execute a synchronization step contained in a first synchronization strategy based on whether full data matched with a target tenant is generated in the multi-tenant application;

determining whether to execute a synchronization step included in a second synchronization policy based on whether incremental data matched with a target tenant is generated in the multi-tenant application;

and determining whether to execute the synchronization step contained in the third synchronization strategy based on whether trace data matched with the target tenant is generated in the multi-tenant application.

As a further improvement of the present invention, the full-scale data includes: data matched with the target tenant in a database corresponding to the multi-tenant application;

the incremental data includes: the last time synchronization step is executed, and operation records which are generated by the multi-tenant application and matched with the target tenant are executed within the starting time point of the current synchronization step;

the trace data includes: and requesting an API matched with the target tenant in the multi-tenant application.

As a further improvement of the synchronization steps included in the first-time synchronization policy of the present invention, the following steps are specifically included:

establishing a master-slave relationship between a database corresponding to the multi-tenant application and a database corresponding to the single-tenant application so as to synchronize data in the database corresponding to the multi-tenant application to the database corresponding to the single-tenant application;

and when the data in the database corresponding to the single-tenant application is consistent with the data in the database corresponding to the multi-tenant application, canceling the master-slave relationship, and only reserving the data matched with the target tenant in the database corresponding to the single-tenant application.

As a further improvement of the present invention, the synchronization step included in the second synchronization policy includes:

and repeatedly executing the steps of processing the operation records matched with the target tenant and generated by the multi-tenant application within the last synchronization step ending time point and the current synchronization step starting time point and importing the operation records into the database corresponding to the single-tenant application until the time difference formed by the last synchronization step ending time point and the current synchronization step starting time point is less than the preset time.

As a further improvement of the present invention, the synchronization step included in the third synchronization policy includes:

copying an API request matched with a target tenant in the multi-tenant application to a cache queue, forwarding the API request in the cache queue to the single-tenant application, sequentially responding to the API request matched with the target tenant through the single-tenant application until the cache queue is empty, and switching a gateway route to directly forward the API request matched with the target tenant to the single-tenant application.

As a further improvement of the present invention, after independently providing tenant services to a target tenant through a synchronized single tenant application, the method further includes:

and deleting the tenant data matched with the target tenant in the multi-tenant application.

Based on the same invention idea, the invention also discloses a system for realizing the multi-tenant service, which comprises the following steps:

the determining module is used for acquiring tenant information respectively corresponding to single tenants in the multi-tenant application so as to determine target tenants based on the tenant information;

the system comprises a creating module, a judging module and a judging module, wherein the creating module creates a mirror image corresponding to a multi-tenant application as a multi-tenant application mirror image, and extracts a mirror image of a target tenant from the multi-tenant application mirror image as a single-tenant application mirror image;

the synchronization module creates a single-tenant application corresponding to the target tenant based on the single-tenant application mirror image, synchronizes tenant data matched with the target tenant in the multi-tenant application to the single-tenant application, and independently provides tenant service for the target tenant through the synchronized single-tenant application.

Compared with the prior art, the invention has the beneficial effects that:

the method comprises the steps of creating a single-tenant application for a target tenant, and providing independent tenant service for the single tenant (namely the target tenant) through the single-tenant application, so that the purpose of tenant service decoupling is achieved, the single tenant is guaranteed not to be interfered by other tenants, and the experience degree of the tenant is guaranteed. The single-tenant application independently deploys the single-tenant database to store tenant data corresponding to a target tenant, so that the purpose of decoupling the tenant data of the target tenant from the multi-tenant application is achieved, decoupling of the data is achieved, the problem that coupling of codes and the data easily causes decline in the prior art is solved, and the problem that the performance, stability and other aspects are affected mutually due to coupling of the codes and the data is solved.

Drawings

FIG. 1 is a topology diagram of a computer system to which the method for implementing a multi-tenant service according to the present invention is applied;

FIG. 2 is a schematic diagram illustrating steps of a method for implementing a multi-tenant service according to the present invention;

FIG. 3 is a schematic diagram of coordinates for dividing tenants based on traffic and liveness;

FIG. 4 is a flow chart of a synchronization strategy;

FIG. 5 is a diagram illustrating the steps involved in executing a first synchronization policy;

FIG. 6 is a topology diagram of a system for implementing a multi-tenant service based on the system shown in FIG. 1;

FIG. 7 is a topology diagram of a synchronization module 403;

FIG. 8 is a topology diagram of the logic included in the first synchronization module 4031;

FIG. 9 is a topology diagram of a second synchronization module 4032;

fig. 10 is a topology diagram of a third synchronization module 4033.

Detailed Description

The present invention is described in detail with reference to the embodiments shown in the drawings, but it should be understood that these embodiments are not intended to limit the present invention, and those skilled in the art should understand that functional, methodological, or structural equivalents or substitutions made by these embodiments are within the scope of the present invention.

Referring to fig. 1 to 5, the present invention shows a specific embodiment of a method for implementing a multi-tenant service.

The application scenario of the method for realizing the multi-tenant service disclosed by the invention is to realize the purpose that a single tenant independently provides the tenant service under a multi-tenant architecture, so that the problems of performance degradation, insufficient stability and the like caused by data coupling in the prior art and the problem of unsafe data caused by sharing one database are solved. The implementation method of the multi-tenant service can run in a kubernets platform, and achieves the purpose of providing the tenant service for the tenant through containerized tenant applications (such as the multi-tenant application and the single-tenant application disclosed below). The kubernets may also be deployed in other platforms, which may be understood as a service or system formed by a super-converged all-in-one machine, a computer, a server, a data center, or a portable terminal through virtualization technology. In the present embodiment, the kubernets 100 is exemplarily illustrated as being deployed in the computer system 1000.

Referring to fig. 2, in the present embodiment, a method for implementing a multi-tenant service includes the following steps S1 to S3.

S1, acquiring tenant information respectively corresponding to a single tenant in the multi-tenant application, and determining a target tenant based on the tenant information.

Illustratively, referring to fig. 1, a kubernets 100 is deployed within a computer system 1000, and a multi-tenant application 10 and a single-tenant application 20 are deployed within the kubernets 100. The multi-tenant microservices 101 and the multi-tenant database 102 are deployed in the multi-tenant application 10, and similarly, the single-tenant microservices 201 and the single-tenant database 202 are deployed in the single-tenant application 20. The multi-tenant application 10 is an application formed by providing tenant services to a plurality of tenants, and the plurality of tenants provide the tenant services through one multi-tenant application 10; the single tenant application 20 refers to an application formed to independently provide a tenant service to a single tenant (i.e., a target tenant described below). And a single tenant independently provides tenant services through a single tenant application. The multi-tenant application 10 achieves the purpose of providing the tenant services of the multiple tenants included in the multi-tenant application 10 through the multi-tenant micro service 101, and achieves the purpose of storing the tenant data of the multiple tenants included in the multi-tenant application 10 through the multi-tenant database 102 (the tenant data at this time is only data generated by the multi-tenant application 10 executing the API service corresponding to the received API request). The single-tenant application 20 achieves the purpose of providing the tenant service for the single tenant corresponding to the single-tenant application 20 through the single-tenant microservice 201, and achieves the purpose of storing the tenant data of the single tenant corresponding to the single-tenant application 20 through the single-tenant database 202 (the tenant data at this time only refers to data generated by the single-tenant application 20 executing the API service corresponding to the disclosed API request). The multi-tenant application 10 and the single-tenant application 20 are independent and do not interfere with each other.

It should be noted that kubernets 100 is a portable, extensible, open source platform for managing containerized workloads and services that facilitates declarative configuration and automation. Containers are similar to virtual machines, but have a relaxed isolation feature, and can share operating systems among applications, so containers are lightweight. The aforementioned multi-tenant application 10 and single-tenant application 20 are both packaged in a container form.

Specifically, first, the application load information corresponding to the multi-tenant application 10 is obtained to determine whether to obtain the tenant information respectively corresponding to the single tenants in the tenant application based on the application load information, and it can also be understood that whether to perform the subsequent slicing step is determined based on the application load information of the multi-tenant application 10 (that is, obtaining the tenant information respectively corresponding to the single tenants in the multi-tenant application is performed to determine the target tenant and the subsequent step based on the tenant information). The application load information is determined by giving preset weight coefficients to different system parameters of the multi-tenant application and calculating scores. Wherein, the system parameters include: within a predetermined time, the CPU usage rate, the memory usage rate, the disk IO occupancy rate, and the network IO occupancy rate of the multi-tenant application 10 may be one or any combination of these.

For example, if the predetermined time is 1 day, scores of four indexes of the CPU usage rate (i.e., CPU _ usage) of the multi-tenant application 10 in the last day, the memory usage rate (i.e., memory _ usage) in the last day, the disk IO occupancy rate (i.e., disk IO _ usage) in the last day, and the network IO occupancy rate (i.e., network IO _ usage) in the last day are obtained, and the score range is 1 to 100. The preset weight coefficient of each index is defined as 25%, so that the total score of the four indexes is calculated according to the preset weight coefficient, thereby determining the application load information of the multi-tenant application 10. If the calculated total score of the four indexes is greater than 50, it is determined that the application load information of the multi-tenant application 10 is under a high load pressure, and the subsequent fragmentation step is triggered to be executed (i.e., the target tenant is determined and the single-tenant application 20 is created for the target tenant). The code for calculating the total score of the four indexes can be referred to

Table 1 shows:

table 1 code example of application load information

If the CPU usage score of the multi-tenant application 10 in the last day is 80, the memory usage score of the last day is 70, the disk IO usage score of the last day is 60, and the network IO usage score of the last day is 50. The total score of the four indexes is: 80 × 25% +70 × 25% +60 × 25% +50 × 25%, i.e. 60. If 60 is greater than 50, it is determined that the application load information of the multi-tenant application 10 is under a high load pressure, and the execution of the subsequent fragmentation steps (i.e., the steps included in steps S1 to S3 disclosed below) is triggered.

It should be noted that the predetermined time may be a day as disclosed above, or may be other times, such as an hour or two days, etc. The specific preset time can be adjusted according to actual conditions, and if the number of customers is large (i.e., more tenants), the application load information of the multi-tenant application 10 can be known by presetting a shorter time; if the customer volume is small (i.e., there are fewer tenants), a longer time can be scheduled to learn the application load information of the multi-tenant application 10. The purpose of predetermining the time and calculating the score of the multi-tenant application 10 is to know application load information (i.e., load pressure of the multi-tenant application 10) of the multi-tenant application 10 for a certain period of time or in a current state. Of course, in addition to the aforementioned way of calculating scores of different system parameters within a predetermined time to achieve the purpose of knowing the application load information of the multi-tenant application 10, so as to determine whether to execute the subsequent steps of subsequently determining the target tenant and creating the single-tenant application 20 for the target tenant, other ways may also be used, for example, the tenant manually feeds back that the page loading of the multi-tenant application 10 is slow, so that the load pressure of the multi-tenant application 10 can be directly obtained to be large, and thus the steps included in the subsequent steps S1 to S3 are executed. Of course, any other manner may be adopted, and the present embodiment does not specifically limit the manner of deriving the load pressure of the multi-tenant application 10. In addition, in order to maintain user experience of some customers (for example, high-quality customers), a single-tenant application can be directly and independently created for the tenant, so that tenant service is provided for the tenant through the single-tenant application, a step of creating the single-tenant application when load pressure of the multi-tenant application is high is omitted, and meanwhile, the experience degree of the customer is also maintained.

In addition, by acquiring the application load information of the multi-tenant application 10 to determine whether to execute the subsequent steps, the subsequent steps are guaranteed to be executed when the load pressure of the multi-tenant application 10 is large, so as to prevent resource waste caused by executing the subsequent steps due to the fact that the load pressure is not large.

When the load pressure of the multi-tenant application 10 is determined to be large, acquiring tenant information corresponding to each of the single tenants in the multi-tenant application 10; the tenant information comprises tenant liveness and tenant traffic corresponding to the single tenant respectively. The tenant liveness is determined through the API request quantity corresponding to a single tenant, and the tenant service quantity is determined through the database data quantity corresponding to the single tenant. The API request amount comprises: and the method comprises one or any combination of an API request quantity percentile, an API request time consumption percentile and an API request response data quantity percentile corresponding to a single tenant. The tenant traffic comprises: one or any combination of the percentile of the accumulated data amount corresponding to a single tenant and the percentile of the SQL slow query times. Similarly to the application load information, the tenant information is realized by calculating scores based on the weight coefficients for the tenant liveness and the tenant traffic corresponding to a single tenant.

Referring to fig. 3, tenants a, B, C, and D shown in the figure represent not only one tenant, but also a general term of tenants located in the quadrant. The abscissa represents traffic (i.e., the aforementioned tenant traffic), the ordinate represents liveness (i.e., the aforementioned tenant liveness), and both the abscissa and the ordinate are from low to high from the origin outward. The tenant A in the first quadrant represents a class of tenants with high activity and low traffic; the tenant B in the second quadrant represents a class of tenants with low activity and low traffic; the tenant C in the third quadrant has low activity and high traffic; the tenant D in the fourth quadrant has high activity and high traffic. Therefore, a class of tenants with high tenant liveness and tenant traffic ranges (i.e., tenant D in the fourth quadrant) is defined as a high-quality customer, and such customers often have high requirements on stability and security of applications, so it is necessary to provide better tenant service for such customers. The user is defined as a target tenant, a single tenant application is created for the user to independently provide tenant service for the target tenant, and the target tenant is guaranteed not to be interfered by other tenants, so that the purpose of reducing the load pressure of the multi-tenant application 10 is achieved while the experience degree of the user is guaranteed.

For example, scores of three indexes, namely, an API _ request _ count _ percentage of the average daily API request amount for the last 30 days (i.e., API _ request _ count _ percentage), an API _ request _ latency _ percentage of the average daily API request consumption for the last 7 days (i.e., API _ request _ latency _ percentage), and an API _ response _ data _ size _ percentage of the average daily API request amount for the last 7 days (i.e., API _ response _ data _ size _ percentage), corresponding to each single tenant in the multi-tenant application 10 are obtained. Meanwhile, scores of two indexes, namely db _ data _ size _ percentage of accumulated data amount and db _ slow _ query _ percentage of daily slow query times, which correspond to each tenant in the multi-tenant application 10, are obtained. And summing up scores of five indexes respectively corresponding to a single tenant, defining the weight coefficient of each index as 20%, calculating the total score of the five indexes according to the weight coefficient, and determining the tenant information respectively corresponding to the single tenant according to the obtained total score. And if the total score of the five calculated indexes is more than 50, judging the tenant as a target tenant. The percentile refers to the ranking number of tenants in the multi-tenant application 10, and the ranking is 100 at the highest and 1 at the lowest. The rank of each tenant in the multi-tenant application 10 is determined by percentile to finally determine the target tenant. The code for calculating the total score of the five indicators can be referred to the following table 2:

table 2 code examples for tenant information

If the daily average API request quantity percentile of the single tenant in the last 30 days is 50, the daily average API request time consumption percentile in the last 7 days is 60, the daily average API request response data quantity percentile in the last 7 days is 70, the cumulative data quantity percentile is 70, and the daily average SQL slow query frequency percentile in the last 7 days is 80. The total score of the five indexes is 50 × 20% +60 × 20% +70 × 20% +80 × 20%, that is 66, and 66 is greater than 50, and the single tenant is determined to be the target tenant. Whether the tenant is the target tenant is determined through the tenant information, and whether the user is the user in the fourth quadrant (namely, the high-quality user) is determined through the tenant information, so that the aim of subsequently creating a single-tenant application for the target tenant and independently providing tenant service for the single user through the single-tenant application is fulfilled. The foregoing steps may also be understood as selecting a high-quality customer according to the tenant information, so as to achieve the purpose of creating a single-tenant application for the high-quality customer to independently provide tenant services for the high-quality customer, and finally achieve the purpose of reducing the load pressure of the multi-tenant application 10 while ensuring the high-quality customer experience.

And S2, creating a mirror image corresponding to the multi-tenant application to serve as the multi-tenant application mirror image, and extracting the mirror image of the target tenant from the multi-tenant application mirror image to serve as the single-tenant application mirror image.

Illustratively, referring to fig. 1, an image repository 30 is deployed independently of the multi-tenant application 10 and the single-tenant application 20 for storing images. Mirror repository 30 may be deployed within kubernets 100, or may be deployed in computer system 1000 and logically independent of kubernets 100, and the present embodiment does not specifically limit the deployment location of mirror repository 30. Preferably, the mirror repository 30 is deployed within kubernets 100 and is independent of the multi-tenant application 10 and the single-tenant application 20.

Specifically, a multi-tenant application image is created in a container form based on the multi-tenant application 10, and the multi-tenant application image is uploaded into the image repository 30. And downloading the image corresponding to the target tenant from the image warehouse 30 to serve as the single tenant image corresponding to the target tenant. After the single-tenant mirror image is downloaded, the container application is started, and therefore the single-tenant application which is corresponding to the target tenant and independently provides the tenant service can be conveniently established on the basis of the single-tenant mirror image.

It should be noted that the manner of creating the multi-tenant application image may be any method in the prior art, and this embodiment does not limit this. Meanwhile, the single-tenant application 20 is created according to the mirror image, so that the resource specification of the single-tenant application 20 is ensured to be consistent with the original specification, and the situation that the resource specification is not matched with a target tenant is prevented; meanwhile, the target tenant monopolizes the resource specification in the single-tenant application 20 to achieve the purpose of monopolizing the individualized requirement resource specification and finally achieve the purpose of resource decoupling, so that the problem of resource waste caused by the fact that the resource specification is expanded to a state larger than the peak value in the prior art is solved.

And S3, creating a single-tenant application corresponding to the target tenant based on the single-tenant application mirror image, and synchronizing tenant data matched with the target tenant in the multi-tenant application to the single-tenant application so as to independently provide tenant services through the synchronized single-tenant application.

After the image corresponding to the target tenant is downloaded to be used as the single-tenant application image, the single-tenant application 20 corresponding to the target tenant is created based on the single-tenant application image. At this time, the single-tenant application 20 created based on the single-tenant application image does not have any data matching the target tenant, and cannot provide tenant service to the target tenant, and is only one application. After the subsequent steps of tenant data synchronization and gateway switching traffic forwarding rule configuration, a single tenant application 20 independently providing tenant services to the target tenant can be formed.

Illustratively, after the single-tenant application 20 is created, tenant data matched with the target tenant in the multi-tenant application 10 is synchronized to the single-tenant application 20, so that the target tenant is independently provided with tenant services through the synchronized single-tenant application 20. And synchronizing the tenant data matched with the target tenant in the multi-tenant application to the single-tenant application based on a synchronization strategy. The synchronization strategy comprises the following steps: determining whether to execute the synchronization policy included in the first synchronization step based on whether the full amount of data matching the target tenant is generated in the multi-tenant application 10; determining whether to execute a synchronization step contained in a second synchronization strategy based on whether incremental data matched with a target tenant is generated in the multi-tenant application; whether to execute the synchronization steps included in the third synchronization policy is determined based on whether trace data matching the target tenant is generated in the multi-tenant application 10.

As shown in fig. 4, the synchronization policy specifically includes the following steps S31 to S36.

S31, judging whether incremental data matched with a target tenant are generated in the multi-tenant application; if yes, go to step S32; if not, step S33 is executed.

And S32, executing a synchronization step contained in a first-time synchronization strategy on the full data matched with the target tenant in the database corresponding to the multi-tenant application.

S33, judging whether incremental data matched with a target tenant are generated in the multi-tenant application; if yes, go to step S34; if not, step S35 is executed.

And S34, executing a synchronization step included in a second synchronization strategy on the incremental data which is generated in the multi-tenant application and matched with the target tenant.

Step S35, judging whether trace data matched with a target tenant is generated in the multi-tenant application; if yes, go to step S36; if not, step S37 is executed.

And S36, executing a synchronization step contained in a third synchronization strategy on whether trace data matched with the target tenant is generated in the multi-tenant application.

And S37, completing the tenant data synchronization, and independently providing tenant service for the target tenant through the single tenant application after the synchronization is completed.

The full data refers to data matching the target tenant in the database (i.e., the multi-tenant database 102) corresponding to the multi-tenant application 10, and is synchronized in a full form at the time of the first synchronization. The incremental data refers to the operation records matched with the target tenant generated by the multi-tenant application 10 at the end time point of the last synchronization step and the start time point of the synchronization step executed this time. Trace data refers to API requests in the multi-tenant application 10 that match the target tenant. The third synchronization policy (i.e., the first synchronization policy, the second synchronization policy, and the third synchronization policy) determines whether to execute the synchronization steps included in the third synchronization policy based on the third determinations (i.e., whether the first determination indicates that the full amount of data exists, whether the second determination indicates that the incremental data exists, and whether the third determination indicates that the trace amount of data exists), so that there may be a step of executing only the synchronization steps included in the first synchronization policy (e.g., executing only the synchronization steps included in the first synchronization policy, executing only the synchronization steps included in the second synchronization policy, or executing only the synchronization steps included in the third synchronization policy), a step of executing two synchronization policies (e.g., executing the synchronization steps included in the first synchronization policy and the synchronization steps included in the second synchronization policy, etc.), and a step of executing the third synchronization policy, where the specific execution condition is specifically defined according to the third determinations.

As shown in fig. 5, the foregoing synchronization steps included in executing the first-time synchronization policy on the full amount of data matching the target tenant in the database corresponding to the multi-tenant application specifically include the following steps S51 to S52.

And S51, establishing a master-slave relationship between the database corresponding to the multi-tenant application and the database corresponding to the single-tenant application so as to synchronize the data in the database corresponding to the multi-tenant application to the database corresponding to the single-tenant application.

Specifically, a master-slave relationship of a database corresponding to the multi-tenant application 10 (i.e., the multi-tenant database 102 illustrated in fig. 1) and a database corresponding to the single-tenant application 20 (i.e., the single-tenant database 202 illustrated in fig. 1) is established. After the master-slave relationship is established, the data in the multi-tenant database 102 is synchronized to the single-tenant database 202, so as to ensure the consistency of the data stored in the two (i.e., the aforementioned multi-tenant database 102 and the single-tenant database 202).

Note that the master-slave relationship of the databases refers to a relationship formed between the master database and the slave database. Master-slave replication to create a database environment identical to the master database and refer to it (i.e., the aforementioned one-to-one database environment) as the slave database. And the master database and the slave database are synchronized through a log synchronization mechanism. The data corresponding to the aforementioned multi-tenant application 10 (i.e., the multi-tenant database 102 shown in fig. 1) is a master database, and the database corresponding to the single-tenant application 20 (i.e., the single-tenant database 202 shown in fig. 1) is a slave database. The master-slave relationship may be established by accessing the database corresponding to the single-tenant application 20 into the database corresponding to the multi-tenant application 10 in a node manner, or directly accessing the database corresponding to the single-tenant application 20 into the database corresponding to the multi-tenant application 10, or accessing the database in a container manner, and the master-slave relationship is not specifically limited in this embodiment.

In addition, the aforementioned manner of synchronizing data in the multi-tenant database 102 to the single-tenant database 202 may be that the slave database (i.e., the single-tenant database 202) actively synchronizes data of the master database from the master database (i.e., the multi-tenant database 102) through a log synchronization mechanism for the purpose of data synchronization, or that the master database actively synchronizes data of itself (i.e., the master database) to the slave database through the log synchronization mechanism for the purpose of data synchronization. The embodiment does not limit the specific synchronization method.

And S52, when the data in the database corresponding to the single-tenant application is consistent with the data in the database corresponding to the multi-tenant application, canceling the master-slave relationship, and only reserving the data matched with the target tenant in the database corresponding to the single-tenant application.

Specifically, when the data in the database corresponding to the single-tenant application 20 (i.e., the single-tenant database 202 shown in fig. 1) is consistent with the data in the database corresponding to the multi-tenant application 10 (i.e., the multi-tenant database 102 shown in fig. 1) (it can also be understood that the data in the single-tenant database 202 is the same as the data in the multi-tenant database 102), the master-slave relationship formed between the multi-tenant database 102 and the single-tenant database 202 is cancelled. At this time, the single-tenant database 202 stores data consistent with that in the multi-tenant database 102, i.e., the single-tenant database 202 stores not only data matching the target tenant. Therefore, a deletion operation is performed on data that does not match the target tenant in the database corresponding to the single-tenant application 20 (i.e., the single-tenant database 202) to delete the data that does not match the target tenant in the single-tenant database 202, so that only the data that matches the target tenant is retained to delete unnecessary data, thereby achieving the purpose of saving the space of the single-tenant database 202.

The determining whether to execute the synchronization step included in the second synchronization policy based on whether incremental data matched with the target tenant is generated in the multi-tenant application specifically includes: and repeatedly executing the steps of processing the operation records matched with the target tenant and generated by the multi-tenant application within the last synchronization step ending time point and the current synchronization step starting time point and importing the operation records into the database corresponding to the single-tenant application until the time difference formed between the last synchronization step ending time point and the current synchronization step starting time point is less than the preset time.

The operation record can be understood as binlog, which refers to SQL statement information for recording user operations on the database, including addition, deletion, and modification operations of data tables and contents, while query operations are not recorded. The code for intercepting the operation record may be referred to the following table 3:

table 3 intercepting code instances of operational records

For example, if the end time point of the first synchronization step (i.e., the time point corresponding to the time point when the data in the single-tenant database 202 is identical to the data in the multi-tenant database 102) is denoted as T1, and the start time point of the current synchronization step is denoted as T2, the step of processing the operation record matching the target tenant generated by the multi-tenant database 10 in the time period from T1 to T2 and importing the operation record into the database corresponding to the single-tenant application 20 is performed. The method specifically comprises the following steps: analyzing an operation record (namely binlog) which is generated by multiple tenants within a time period from T1 to T2 and is matched with a target tenant, converting the analyzed operation record into a DML database operation language, replaying DML import data in a single-tenant application 20, and simultaneously recording the time of importing completion as T3. Then, the step of processing the operation records which are generated by the multi-tenant application 10 and matched with the target tenant in the time period from T2 to T3 and importing the operation records into the database corresponding to the single-tenant application 20 is executed, and the time for completing importing is recorded as T4. And analogizing in turn, executing the steps of processing the operation records which are generated by the multi-tenant application 10 and matched with the target tenant in the Tn-1-Tn time period and importing the operation records into the database corresponding to the single-tenant application 20. Until the time period (time difference) between Tn-1 and Tn is less than the preset time. And defining the preset time as 1 second, and stopping until the time period of Tn-1-Tn is less than 1 second, so that the execution of the steps contained in the second synchronization strategy is finished.

The preset time may be defined as 1 second, or may be defined as another time length. While the definition of 1 second is based on the general experience requirement in the industry of "2-5-8 principles". The "2-5-8 principle" is specifically: the principle of response time 2-5-8, if the user can get the response within 2 seconds, the user will feel the response speed of the system is very fast. If the user gets a response within 2-5 seconds, the user feels the response speed of the system is moderate. If the user gets a response within 5 seconds to 8 seconds, the user feels that the response speed of the system is slow, but it is acceptable. If the user still fails to respond after 8 seconds, the user may perceive the system to be slow to respond, or may choose to leave the secondary Web site or initiate a secondary request in the belief that the system has lost response. The aforementioned example based on the above "2-5-8 principle" defines the preset time as 1 second, and can be defined as other time lengths, however, the preset time is preferably 1 second.

In addition, a synchronization step is also performed on the operation record before the aforementioned processing of the operation record, so as to synchronize the operation record to the single-tenant application 20, thereby achieving the purpose of preserving the integrity of the operation record at the single-tenant application 20.

The determining whether to execute the synchronization step included in the third synchronization policy based on whether trace data matched with the target tenant is generated in the multi-tenant application specifically includes: the API requests matched with the target tenants in the multi-tenant application 10 are copied to the cache queue, and the API requests in the cache queue are forwarded to the single-tenant application 20, so that the API requests matched with the target tenants are sequentially responded by the single-tenant application until the cache queue is empty, and the gateway route is switched to directly forward the API requests matched with the target tenants to the single-tenant application.

Specifically, a gateway API request mirror copy function is started, and API requests matched with the target tenant in the multi-tenant application 10 are copied to the cache queue. At the same time, the API replay listens to the cache queue to forward API requests in the cache queue to the single-tenant application 20. When the buffer queue is empty (i.e. all API requests in the buffer queue have been forwarded), the gateway route is cut off so as to forward the API request issued by the target tenant directly to the single-tenant application 20 without turning on the aforementioned mirror copy function. At this time, the execution of the step of synchronizing the tenant data matching the target tenant in the multi-tenant application to the single-tenant application is ended, so that the target tenant can be independently provided with the tenant service through the synchronized single-tenant application 20 (i.e., after the tenant data is synchronized). The tenant data may be understood as a general term of the aforementioned full data, incremental data, and trace data.

By synchronizing the tenant data matched with the target tenant in the multi-tenant application to the single-tenant application independently providing tenant service based on the synchronization strategy, the problem of poor user experience caused by stopping service to complete data migration in the prior art is solved, and the tenant data can be synchronized without stopping service under the condition of continuous flow, so that the purpose of no perception of the user is achieved, and the user experience is guaranteed.

After the target tenant independently provides tenant services through the synchronized single-tenant application, tenant data matched with the target tenant in the multi-tenant application 10 is deleted, so that the purpose of saving resources in the multi-tenant application 10 is achieved.

The implementation method of the multi-tenant service, which is disclosed by the invention, judges whether the load pressure of the multi-tenant application 10 is larger at the current time by acquiring the application load information of the multi-tenant application 10. When the load pressure of the multi-tenant application 10 is large, tenant information respectively corresponding to a single tenant in the multi-tenant application 10 is acquired, and thus a target tenant is selected. The target tenant can be understood as a premium customer, i.e., a customer with high tenant service requirements. The number of target customers may be several, and may be determined by the tenant liveness and the tenant traffic, or may be determined in other manners, which are specifically referred to above and will not be described herein again.

After the target customer is determined, a single-tenant application 20 is created for the target tenant in a mirroring manner, and the tenant data of the target tenant is synchronized to the single-tenant application 20, so that the tenant service is independently provided for the target tenant through the synchronized single-tenant application. Compared with the prior art in which multiple tenants correspond to one multi-tenant application 10 to provide tenant services for the multiple tenants through the multi-tenant application 10, the single-tenant application 20 is created for the target tenant to provide independent tenant services for the single tenant (namely, the target tenant) through the single-tenant application 20, so that the purpose of tenant service decoupling is achieved, the single tenant is guaranteed not to be interfered by other tenants, and the experience degree of the tenant is guaranteed. The single-tenant application 20 deploys the single-tenant database 202 independently to store tenant data corresponding to a target tenant, so as to achieve the purpose of decoupling the tenant data of the target tenant from the multi-tenant application 10, achieve decoupling of data, solve the problem that in the prior art, coupling of codes and data easily causes degradation, and solve the problem that coupling of codes and data causes mutual influence in the aspects of performance, stability and the like. And determining the target tenant through the tenant information, so as to independently create the single-tenant application 20 corresponding to the target tenant for the target tenant to independently provide tenant service for the target tenant, and the target tenant exclusively occupies resources contained in the single-tenant application 20. The tenant information represents the requirements of tenants, and the actual resource requirements corresponding to tenants with different requirements are also different, but in the prior art, resource coupling causes that each tenant cannot monopolize the resource specification of the personalized requirements. Even if a multi-instance load balancing mode is adopted, the resource is essentially shared, and the problem of resource sharing is as follows: the resource specification is expanded to a state larger than the peak value so as to satisfy each tenant as much as possible, and the problem of resource waste is inevitably caused at this time. Therefore, the single-tenant application 20 is created for the target tenant, so that the target tenant is provided with the independent resource specification, the monopolization of the resource specification by the target tenant is realized, the purpose of resource decoupling is realized, and the problem of resource waste in the prior art for sharing resources is finally solved. In addition, the tenant data of the target tenant is independently stored in the single tenant application 20, so that the security of the tenant data is ensured, and the problem of data security of a shared database in a multi-tenant service mode in the prior art is solved. In summary, the implementation method of the multi-tenant service provided by the present invention implements the implementation of the target tenant (i.e., the high-quality customer), and provides the independent tenant service with both stability and security. Meanwhile, in the operation mode of independently providing the tenant service of the single-tenant application 20 corresponding to the target tenant, the purpose of reducing the load pressure of the multi-tenant application 10 is also achieved.

Based on the same inventive concept, the present embodiment also discloses an implementation system (simply referred to as "implementation system", i.e., the implementation system 400 shown in fig. 6) of the multi-tenant service. Referring to fig. 6, an implementation system 400 includes: a determination module 401, a creation module 402, and a synchronization module 403.

Referring to fig. 6, the implementation system 400 is a system that is wholly composed of computer code included in the determination module 401, the creation module 402, and the synchronization module 403, and may be not only deployed locally but also logically composed. As for the deployment positions of the three modules (i.e., the determination module 401, the creation module 402, and the synchronization module 403), the three modules may be deployed in the kubernets 100 in an integrated manner, or deployed in the computer system 1000 and logically independent from the kubernets 100, or separately deployed in the kubernets 100 and the computer system 1000 (e.g., the determination module 401 is deployed inside the kubernets 100, the creation module 402 and the synchronization module 403 are both deployed outside the kubernets 100 and inside the computer system 1000, etc.), and the three modules form the implementation system 400 in an integrated manner.

The confirmation module 401 obtains tenant information corresponding to each of the tenants in the multi-tenant application, so as to determine the target tenant based on the tenant information.

Specifically, the confirmation module obtains the application load information corresponding to the multi-tenant application 10 to determine whether to obtain tenant information corresponding to each of the single tenants in the tenant application based on the application load information, or may be understood as determining whether to execute a subsequent fragmentation step based on the application load information of the multi-tenant application 10. The application load information is determined by giving preset weight coefficients to different system parameters of the multi-tenant application and calculating scores. Wherein the system parameters include: and one or any combination of the CPU utilization rate, the memory utilization rate, the disk IO occupancy rate and the network IO occupancy rate of the multi-tenant application in the preset time. By acquiring the application load information of the multi-tenant application 10 to determine whether to execute the subsequent steps, the subsequent steps are guaranteed to be executed when the load pressure of the multi-tenant application 10 is large, so that the situation that resources are wasted due to the fact that the subsequent steps are executed due to the fact that the load pressure is not large is prevented. When it is determined that the load pressure of the multi-tenant application 10 is large, the tenant information respectively corresponding to the single tenants in the multi-tenant application 10 is acquired, so as to determine the target tenant according to the tenant information. Whether the tenant is the target tenant is determined through the tenant information, and whether the user is the user in the fourth quadrant (namely, the high-quality user) can also be determined through the tenant information, so that the aim of subsequently creating a single-tenant application for the target tenant is fulfilled, and the purpose of independently providing the tenant service for the single user through the single-tenant application is fulfilled.

The creation module 402 creates an image corresponding to the multi-tenant application as a multi-tenant application image, and extracts an image of a target tenant from the multi-tenant application image as a single-tenant application image.

The synchronization module 403 creates a single-tenant application corresponding to the target tenant based on the single-tenant application image, and synchronizes tenant data matched with the target tenant in the multi-tenant application to the single-tenant application, so as to independently provide tenant services through the synchronized single-tenant application.

Specifically, after the image corresponding to the target tenant is downloaded and obtained as the single-tenant application image, the single-tenant application 20 corresponding to the target tenant is created based on the single-tenant application image. At this time, the single-tenant application 20 created based on the single-tenant application image does not have any data associated with the target tenant, and cannot provide tenant service to the target tenant, but is only one application. After the single-tenant application 20 is created, the tenant data matched with the target tenant in the multi-tenant application 10 is synchronized to the single-tenant application 20, so that the target tenant is independently provided with the tenant service through the synchronized single-tenant application 20.

Referring to fig. 7, the synchronization module 403 includes: a first synchronization module 4031, a second synchronization module 4032, and a third synchronization module 4033. The first synchronization module 4031 determines whether to execute the synchronization policy included in the first synchronization step based on whether the full amount of data matching the target tenant is generated in the multi-tenant application 10. The second synchronization module 4032 determines whether to perform the synchronization steps included in the second synchronization policy based on whether incremental data matching the target tenant is generated in the multi-tenant application 10. The third synchronization module 4033 determines whether to perform the synchronization steps included in the third synchronization policy based on whether trace data matching the target tenant is generated in the multi-tenant application 10. The first synchronization module 4031, the second synchronization module 4032, and the third synchronization module 4033 are all specifically defined based on the determination, and therefore only the logic included in the first synchronization module 4031, the logic included in the second synchronization module 4032, or the logic included in the third synchronization module 4033 may be executed, the logic included in any two synchronization modules may be executed, the logic included in three synchronization modules may be executed, and the specific execution condition is specifically defined according to the three determinations.

Referring to fig. 8, the first synchronization module 4031 establishes a master-slave relationship between the multi-tenant database 102 and the single-tenant database 202 to synchronize data in the multi-tenant database 102 to the single-tenant database 202; when the data in the single-tenant database 202 is consistent with the data in the multi-tenant database 102, the master-slave relationship is cancelled (i.e., the multi-tenant database 102 and the single-tenant database 202 are independent of each other), while only the data in the single-tenant database 202 that matches the target tenant is retained.

Referring to fig. 9, the second synchronization module 4032 deploys a log synchronization module 40321, a log parsing module 40322 and a data replay module 40323. The log synchronization module 40321 synchronizes the incremental data matched with the target tenant in the multi-tenant application 10 to the single-tenant application 20, and sends the incremental data to the log analysis module 40322, so that the purpose of keeping the integrity of the operation record in the single-tenant application 20 is achieved. The log parsing module 40322 parses the incremental data and converts the parsed operation record into a DML database operation language, and then sends the converted operation record to the data playback module 40323. The data playback module 40323 performs data modification (e.g., adding data, deleting data, and modifying data) into the single-tenant database 202 based on the converted operation record. The second synchronization module 4032 records the time difference between the end time point of the last synchronization step and the start time point of the current synchronization step, and if the time difference is greater than the preset time, the logic included in the log synchronization module 40321, the log analysis module 40322, and the data playback module 40323 is repeatedly executed until the time difference between the end time point of the last synchronization step and the start time point of the current synchronization step is less than the preset time, and the execution is stopped.

Referring to fig. 10, the third synchronization module 4033 deploys a cache queue 40331 and an API playback module 40332.API requests matching the target tenant in the multi-tenant application 10 are copied to the cache queue 40331 through a route in the API gateway and are in turn forwarded to the API playback module 40332. The API replay module 40332 monitors the buffer queue 40331, and sends the buffer queue 40331API request to the single-tenant application 20, so as to sequentially respond to API requests matching the target tenant through the single-tenant application until the buffer queue is empty, and switches the gateway route to directly forward the API requests matching the target tenant to the single-tenant application.

The implementation system 400 disclosed above is based on the same inventive concept as the implementation method of the multi-tenant service, and the detailed embodiments can be referred to the above description, and are not repeated herein.

In addition, the logic included in the step S1 in the implementation method of the multi-tenant service is implemented by the determination module 401 in the implementation system 400, the logic included in the step S2 in the implementation method of the multi-tenant service is implemented by the creation module 402 in the implementation system 400, and the logic included in the step S3 in the implementation method of the multi-tenant service is implemented by the synchronization module 403 in the implementation system 400.

The above-listed detailed description is only a specific description of a possible embodiment of the present invention, and they are not intended to limit the scope of the present invention, and equivalent embodiments or modifications made without departing from the technical spirit of the present invention should be included in the scope of the present invention.

It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned.

Furthermore, it should be understood that although the present description refers to embodiments, not every embodiment may contain only a single embodiment, and such description is for clarity only, and those skilled in the art should integrate the description, and the embodiments may be combined as appropriate to form other embodiments understood by those skilled in the art.

Claims

1. A method for implementing a multi-tenant service is characterized by comprising the following steps:

2. The method for implementing multi-tenant service according to claim 1, wherein before obtaining tenant information corresponding to each of single tenants in the multi-tenant application, the method further comprises:

3. The method of claim 2, wherein the application load information is determined by applying preset weighting coefficients to different system parameters of the multi-tenant application and calculating scores;

4. The method for implementing the multi-tenant service according to claim 1, wherein the tenant information includes: the activity of each tenant and the service volume of each tenant are respectively corresponding to a single tenant;

5. The method of claim 4, wherein the API request comprises: one or any combination of API request quantity percentile, API request time consumption percentile and API request response data quantity percentile corresponding to a single tenant;

6. The method for implementing the multi-tenant service according to any one of claims 1 to 5, wherein the synchronizing of tenant data matched with a target tenant in the multi-tenant application to a single-tenant application is implemented based on a synchronization policy;

wherein the synchronization policy comprises:

determining whether to execute a synchronization step contained in a second synchronization strategy based on whether incremental data matched with a target tenant is generated in the multi-tenant application;

7. The method of claim 6, wherein the method further comprises,

the full volume data includes: data matched with the target tenant in a database corresponding to the multi-tenant application;

8. The method for implementing a multi-tenant service according to claim 7, wherein the synchronization step included in the first synchronization policy specifically includes:

and when the data in the database corresponding to the single-tenant application is consistent with the data in the database corresponding to the multi-tenant application, canceling the master-slave relationship, and only keeping the data matched with the target tenant in the database corresponding to the single-tenant application.

9. The method for implementing a multi-tenant service according to claim 8, wherein the synchronization step included in the second synchronization policy includes:

10. The method for implementing a multi-tenant service according to claim 9, wherein the synchronization step included in the third synchronization policy includes:

11. The method for implementing multi-tenant service according to claim 10, wherein after independently providing tenant service to the target tenant through the synchronized single-tenant application, the method further comprises:

12. A system for implementing a multi-tenant service, comprising:

the system comprises a determining module, a judging module and a judging module, wherein the determining module acquires tenant information respectively corresponding to single tenants in multi-tenant application so as to determine target tenants based on the tenant information;