CN115480914B - Method and system for realizing multi-tenant service - Google Patents

Method and system for realizing multi-tenant service Download PDF

Info

Publication number
CN115480914B
CN115480914B CN202211068613.XA CN202211068613A CN115480914B CN 115480914 B CN115480914 B CN 115480914B CN 202211068613 A CN202211068613 A CN 202211068613A CN 115480914 B CN115480914 B CN 115480914B
Authority
CN
China
Prior art keywords
tenant
application
target
data
tenant application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202211068613.XA
Other languages
Chinese (zh)
Other versions
CN115480914A (en
Inventor
请求不公布姓名
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jiangsu Anchao Cloud Software Co Ltd
Original Assignee
Jiangsu Anchao Cloud Software Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jiangsu Anchao Cloud Software Co Ltd filed Critical Jiangsu Anchao Cloud Software Co Ltd
Priority to CN202211068613.XA priority Critical patent/CN115480914B/en
Publication of CN115480914A publication Critical patent/CN115480914A/en
Application granted granted Critical
Publication of CN115480914B publication Critical patent/CN115480914B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/24569—Query processing with adaptation to specific hardware, e.g. adapted for using GPUs or SSDs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G06F16/24578—Query processing with adaptation to user needs using ranking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

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, so as to determine a target tenant based on the tenant information; creating an image corresponding to the multi-tenant application to serve as a multi-tenant application image, and extracting an image of a target tenant from the multi-tenant application image to serve as a single-tenant application image; creating a single-tenant application corresponding to the target tenant based on the single-tenant application 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. According to the invention, the aim of decoupling tenant data, tenant service and tenant resources is fulfilled.

Description

Method and system for realizing multi-tenant service
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method and a system for implementing a multi-tenant service.
Background
Multi-tenant refers to a software architecture that supports one instance to serve multiple users (i.e., customers), each user being referred to as a tenant (i.e., tensor). The software gives the tenant the ability to make partial customizations to the system (e.g., user interface colors or business rules), but they cannot customize the code of the modified software.
The implementation method of the multi-tenant service in the prior art can be totally summarized into two types. One-instance multi-tenant service, i.e. one application instance is deployed to meet the requirements of multiple users, and different services are provided for each user through configuration metadata. The other is shared database multi-tenant service, and the implementation method is specifically divided into two types. The method comprises the following steps: first, the tenants share a physical database, and each tenant is subjected to database separation. The splitting refers to splitting data originally stored in one library into a plurality of libraries, and each tenant corresponds to one library to distinguish the data of the tenant. Second, tenants share a physical database, but do not separate. And distinguishing the data of the tenants through the IDs respectively corresponding to the tenants in the database table.
However, the customer's solution in addressing the personalized needs is to make expansion compatibility in the business code and database to achieve the personalized needs presented by each customer. The complexity of the personalized requirements is continuously improved along with the time, and the coupling of codes and data is easy to cause the problem of fading; meanwhile, the mutual influence on the aspects of performance, stability and the like can be caused.
In addition, the different parameters such as access amount and use frequency of different tenants represent that the actual resource requirements of different tenants are different. In the traditional single-instance multi-tenant service mode, resources are coupled together, and each tenant cannot monopolize the resource specification of the personalized requirements. Even with multi-instance load balancing, resources are essentially shared. Expanding the resource specification to a state larger than the peak value causes the 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 tenant data, and this method has a problem of data security. Once the service code has defects, the problem of data override and data misoperation is easily caused. Moreover, once the system encounters security attack, all tenants are involved; meanwhile, if one tenant generates a slow database query, all tenants are involved.
In view of this, there is a need for improvements in the multi-tenant service implementation methods in the art to address the above-described issues.
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 a plurality of tenants and the plurality of tenants share one database, 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 the multi-tenant application, so as to determine a target tenant based on the tenant information;
creating an image corresponding to a multi-tenant application as a multi-tenant application image, and extracting an image of a target tenant from the multi-tenant application image as a single-tenant application image;
and creating a single-tenant application corresponding to the target tenant based on the single-tenant application 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 invention, before acquiring tenant information corresponding to each individual tenant in the multi-tenant application, the method further comprises:
and acquiring application load information corresponding to the multi-tenant application, so as to determine whether to execute the step of acquiring tenant information respectively corresponding to single tenants 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 several of CPU usage rate, memory usage 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: tenant liveness and tenant traffic corresponding to individual tenants respectively;
the tenant activity is determined by the API request amount corresponding to a single tenant, and the tenant service amount is realized by the database data amount corresponding to the single tenant.
As a further improvement of the present invention, the API request amount includes: one or any combination of a single tenant corresponding API request quantity percentile, an API request time consuming percentile and an API request response data quantity percentile;
the tenant traffic includes: one or any combination of a plurality of accumulated data quantity percentiles corresponding to single tenants and average numbers of SQL slow query times percentiles.
As a further improvement of the invention, the synchronization of tenant data matched with a target tenant in the multi-tenant application to the single-tenant application is realized based on a synchronization policy;
wherein the synchronization policy includes:
Determining whether to execute a synchronization step contained in the first synchronization policy based on whether full data matching the target tenant is generated in the multi-tenant application;
determining whether to execute the synchronization step included in the second synchronization policy based on whether incremental data matching the target tenant is generated in the multi-tenant application;
whether to execute the synchronization step included in the third synchronization policy is determined based on whether the trace data matching 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 a target tenant in a database corresponding to the multi-tenant application;
the incremental data includes: an operation record matched with a target tenant and generated by the multi-tenant application in the ending time point of the last execution synchronization step and the starting time point of the current execution synchronization step;
the trace data includes: API requests in the multi-tenant application that match the target tenant.
As a further improvement of the present invention, the synchronization steps included in the first synchronization policy are specifically:
establishing a master-slave relation 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 simultaneously only retaining 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 which are generated by the multi-tenant application and are matched with the target tenant in the time point of ending the last execution synchronization step and the time point of starting the current execution synchronization step and importing the operation records into the database corresponding to the single-tenant application until the time difference formed by the time point of ending the last execution synchronization step and the time point of starting the current execution synchronization step is smaller than the preset time.
As a further improvement of the present invention, the third synchronization policy includes a synchronization step including:
copying the API request matched with the target tenant in the multi-tenant application to a cache queue, and forwarding the API request in the cache queue to the single-tenant application, so that the single-tenant application can sequentially respond to the API request matched with the target tenant until the cache queue is empty, and switching gateway routes 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 the independent provision of the tenant service to the target tenant by the synchronized single tenant application, the method further includes:
and deleting tenant data matched with the target tenant in the multi-tenant application.
Based on the same thought, the invention also discloses a system for realizing the multi-tenant service, which comprises the following steps:
the determining module acquires tenant information respectively corresponding to single tenants in the multi-tenant application so as to determine a target tenant based on the tenant information;
the system comprises a creation module, a storage module and a storage module, wherein the creation module creates an image corresponding to a multi-tenant application to serve as a multi-tenant application image, and extracts an image of a target tenant from the multi-tenant application image to serve as a single-tenant application image;
and the synchronization module is used for creating a single-tenant application corresponding to the target tenant based on the single-tenant application 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.
Compared with the prior art, the invention has the beneficial effects that:
a single-tenant application is created for the target tenant, so that independent tenant service is provided for the single tenant (namely, the target tenant) through the single-tenant application, the purpose of decoupling the tenant service is achieved, the single tenant is not interfered by other tenants, and the experience of the tenant is guaranteed. The single-tenant application is used for independently deploying a single-tenant database and storing tenant data corresponding to a target tenant, so that the aim of decoupling the tenant data of the target tenant from the multi-tenant application is fulfilled, and the data decoupling is realized, so that the problem that the coupling of codes and data in the prior art is easy to cause fading is solved, and the problem that the performance, the stability and the like caused by the coupling of the codes and the data are mutually influenced is solved.
Drawings
FIG. 1 is a topology diagram of a multi-tenant service implementation method of the present invention applied to a computer system;
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 of tenant partitioning based on traffic and liveness;
FIG. 4 is a flow chart of a synchronization strategy;
FIG. 5 is a diagram showing the steps involved in executing the first synchronization strategy;
FIG. 6 is a topology diagram of an implementation system based on one of the multi-tenant services shown in FIG. 1;
FIG. 7 is a topology of a synchronization module 403;
FIG. 8 is a topology diagram of logic contained in the first synchronization module 4031;
fig. 9 is a topology diagram of the second synchronization module 4032;
fig. 10 is a topology diagram of the third synchronization module 4033.
Detailed Description
The present invention will be described in detail below with reference to the embodiments shown in the drawings, but it should be understood that the embodiments are not limited to the present invention, and functional, method, or structural equivalents and alternatives according to the embodiments are within the scope of protection of the present invention by those skilled in the art.
Referring to fig. 1 to 5, an embodiment of a method for implementing a multi-tenant service is shown in the present invention.
The application scene of the implementation method of the multi-tenant service disclosed by the invention realizes the purpose of independently providing the tenant service for a single tenant under a multi-tenant architecture, and is used for solving 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 a database. The implementation method of the multi-tenant service can run in a Kubernetes platform, and the purpose of providing the tenant service for the tenant is achieved through a containerized tenant application (for example, a multi-tenant application and a single-tenant application disclosed below). The Kubernetes may also be deployed in other platforms, which may be understood as a service or system formed by a super fusion kiosk, computer, server, data center, or portable terminal through virtualization technology. Applicants' exemplary description of the deployment of Kubernetes100 in computer system 1000 is presented in this embodiment.
Referring to fig. 2, in the present embodiment, a method for implementing a multi-tenant service includes the following steps S1 to S3.
Step S1, acquiring tenant information respectively corresponding to single tenants in the multi-tenant application, so as to determine a target tenant based on the tenant information.
Illustratively, referring to FIG. 1, a computer system 1000 is provided with a Kubernetes100, with a multi-tenant application 10 and a single-tenant application 20 deployed within the Kubernetes 100. Multi-tenant micro-service 101 and multi-tenant database 102 are deployed within multi-tenant application 10, as are single-tenant micro-service 201 and single-tenant database 202 deployed within 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 commonly provide tenant services through one multi-tenant application 10; the single-tenant application 20 refers to an application formed to independently provide tenant services to a single tenant (i.e., a target tenant described below). A single tenant independently provides tenant services through a single tenant application. The multi-tenant application 10 performs the purpose of providing the tenant service of the plurality of tenants included in the multi-tenant application 10 through the multi-tenant micro service 101, and performs the purpose of storing the tenant data of the plurality of tenants included in the multi-tenant application 10 (the tenant data at this time merely means data generated by the multi-tenant application 10 executing the API service corresponding to the received API request) through the multi-tenant database 102. The single-tenant application 20 achieves the purpose of providing tenant service for a single tenant corresponding to the single-tenant application 20 through the single-tenant micro-service 201, and achieves the purpose of storing tenant data (the tenant data at this time merely refers to data generated by the single-tenant application 20 executing an API service corresponding to the disclosed API request) of the single-tenant corresponding to the single-tenant application 20 through the single-tenant database 202. 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 Kubernetes100 is a portable, extensible, open-source platform for managing containerized workloads and services that facilitates declarative configuration and automation. The container is similar to a virtual machine, but has relaxed isolation features, and can share the operating system between applications, so the container is lightweight. The multi-tenant application 10 and the single-tenant application 20 are both encapsulated in containers.
Specifically, first, the application load information corresponding to the multi-tenant application 10 is acquired to determine whether to acquire tenant information corresponding to each individual tenant in the multi-tenant application based on the application load information, which may also be understood as determining whether to execute a subsequent slicing step based on the application load information of the multi-tenant application 10 (that is, to perform acquiring tenant information corresponding to each individual tenant in the multi-tenant application to determine a target tenant and subsequent steps 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: the CPU usage, memory usage, disk IO occupancy, and network IO occupancy of the multi-tenant application 10 within a predetermined time may be one or any combination of several.
For example, if the predetermined time is 1 day, the scores of four indexes including the CPU utilization (i.e., cpu_usage) of the multi-tenant application 10 of the near day, the memory utilization (i.e., memory_usage) of the near day, the disk IO occupancy (i.e., disk_io_usage) of the near day, and the network IO occupancy (i.e., network_io_usage) of the near day are obtained, and the score ranges from 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, and application load information of the multi-tenant application 10 is determined. If the total score of the four indexes is greater than 50, the application load information of the multi-tenant application 10 is determined to be under a high load pressure, and the subsequent slicing step (i.e., determining the target tenant and creating the single-tenant application 20 for the target tenant) is triggered to be executed. The code for specifically calculating the total score of the four indexes can be referred to as follows
Table 1 shows:
table 1 code instance applying load information
If the multi-tenant application 10 has a score of 80 for the CPU utilization of the next day, 70 for the memory utilization of the next day, 60 for the disk IO occupancy of the next day, and 50 for the network IO occupancy of the next day. The total score of the four indicators is: 80 x 25% +70 x 25% +60 x 25% +50 x 25%, i.e. 60. 60 is greater than 50, the application load information of the multi-tenant application 10 is determined to be under a high load pressure, and the subsequent slicing steps (i.e., steps S1 to S3, which are disclosed below) are triggered to be performed.
It should be noted that the predetermined time may be one day as disclosed above, or may be other time, for example, one hour or two days, etc. The specific preset time can be adjusted according to the actual situation, if the client quantity is large (i.e. the number of tenants is large), the preset time can be short to obtain the application load information of the multi-tenant application 10; if the customer volume is small (i.e., less tenants), a longer time may be reserved to learn the application load information of multi-tenant application 10. The purpose of the predetermined time and calculating the score of the multi-tenant application 10 is to learn application load information (i.e., load pressure of the multi-tenant application 10) for a certain period of time or in a current state of the multi-tenant application 10. Of course, besides the foregoing method of calculating the scores of the different system parameters within the 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 to determine the target tenant and create the single-tenant application 20 for the target tenant, other methods may be adopted, for example, by manually feeding back, by the tenant, that the multi-tenant application 10 has a slower page loading, so that the load pressure of the multi-tenant application 10 is directly obtained, thereby executing the steps included in the subsequent steps S1 to S3. Of course, any other manner is possible, and the present embodiment does not specifically limit the manner in which the load pressure of the multi-tenant application 10 is obtained. In addition, in order to maintain the user experience of some clients (such as high-quality clients), a single-tenant application can be directly created for the tenant, so that the tenant service is provided for the tenant through the single-tenant application, the step of creating the single-tenant application again when the load pressure of the multi-tenant application is high is omitted, and meanwhile, the experience degree of the clients is also maintained.
In addition, by acquiring the application load information of the multi-tenant application 10 to determine whether to execute the subsequent step, the subsequent step is ensured to be executed when the load pressure of the multi-tenant application 10 is high, so as to prevent the situation of resource waste caused by executing the subsequent step due to low load pressure.
When the load pressure of the multi-tenant application 10 is determined to be large, acquiring tenant information corresponding to each individual tenant in the multi-tenant application 10; the tenant information comprises tenant liveness and tenant traffic corresponding to the single tenant. Tenant liveness is determined by the API request volume corresponding to a single tenant, and tenant traffic volume is determined by the database data volume corresponding to a single tenant. The API request amount includes: one or any combination of an API request volume percentile, an API request time consuming percentile and an API request response data volume percentile corresponding to a single tenant. Tenant traffic includes: one or any combination of a cumulative data volume percentile corresponding to a single tenant and an SQL slow query frequency percentile. And the tenant information is realized by respectively calculating scores based on weight coefficients for tenant liveness and tenant traffic corresponding to the single tenant in the same way as the application load information.
Referring to fig. 3, tenants a, B, C, and D shown in the drawing represent not only one tenant but also a general name of the tenant 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. The tenant A in the first quadrant has high activity and low traffic; the class of tenants represented by tenant B in the second quadrant has low activity and low traffic; the class of tenants represented by tenant C in the third quadrant has low activity and high traffic; the class of tenants represented by tenant D in the fourth quadrant has high activity and high traffic. Therefore, a class of tenants whose tenant activity and tenant traffic are both in a high range (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 services for such customers. Such users are defined as target tenants, and a single tenant application is created for the target tenants to independently provide tenant services for the target tenants, so that the target tenants are not interfered by other tenants, and the aim of reducing the load pressure of the multi-tenant application 10 is fulfilled while the experience degree of such clients is ensured.
For example, scores of three indicators of a near 30 day average API request volume percentile (i.e., api_request_count_per-center), a near 7 day average API request time consuming percentile (i.e., api_request_latency_per-center), and a near 7 day average API request response data volume percentile (i.e., api_response_data_size_per-center) corresponding to a single tenant in the multi-tenant application 10 are obtained, respectively. And simultaneously obtain scores of two indexes of an accumulated data quantity percentile (i.e. db_data_size_percentile) and a near 7-day average SQL slow query frequency percentile (i.e. db_slow_query_percentile) corresponding to single tenants in the multi-tenant application 10. The scores of five indexes corresponding to the single tenant are obtained in total, the weight coefficient of each index is defined as 20%, the total score of the five indexes is calculated according to the weight coefficient, and therefore tenant information corresponding to the single tenant is determined according to the obtained total score. If the total score of the five indexes is greater than 50, the tenant is judged to be the target tenant. The aforesaid percentile refers to the ranking number of tenants in the multi-tenant application 10, with a ranking of at most 100 and a ranking of at least 1. The ranking of each tenant in the multi-tenant application 10 is determined by the percentile to ultimately determine the target tenant. For a specific code for calculating the total score of the five indexes, reference may be made to the following table 2:
Table 2 code instance of tenant information
If the single tenant is 50 in the near 30-day average API request quantity percentile, 60 in the near 7-day average API request time consuming percentile, 70 in the near 7-day average API request response data quantity percentile, 70 in the accumulated data quantity percentile, and 80 in the near 7-day average SQL slow query frequency percentile. The total score of the five indexes is 50×20% +60×20% +70×20% +80×20%, i.e. 66, 66 is greater than 50, and the single tenant is determined as the target tenant. Determining whether the tenant is the target tenant through the tenant information can also be understood as determining whether the user is the user in the fourth quadrant (i.e. the high-quality user) through the tenant information, so that the purpose of subsequently creating a single-tenant application for the target tenant to independently provide tenant services for a single user through the single-tenant application is achieved. The foregoing steps may also be understood as selecting the high-quality client according to the tenant information, so as to achieve the purpose of creating a single-tenant application for the high-quality client to independently provide the high-quality client with the tenant service, so as to finally achieve the purpose of reducing the load pressure of the multi-tenant application 10 while guaranteeing the experience degree of the high-quality client.
And S2, creating an image corresponding to the multi-tenant application to serve as a multi-tenant application image, and extracting an image of a target tenant from the multi-tenant application image to serve as a single-tenant application image.
Illustratively, referring to fig. 1, the mirror repository 30 is disposed independently of the multi-tenant application 10 and the single-tenant application 20, and is used for storing mirrors. The image repository 30 may be deployed within the Kubernetes100, or may be deployed on the computer system 1000 and logically independent of the Kubernetes100, and the deployment location of the image repository 30 is not specifically limited in this embodiment. Preferably, the mirror repository 30 is deployed within the Kubernetes100 and 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 uploaded into the image repository 30. And downloading the image corresponding to the target tenant from the image warehouse 30 to serve as a single-tenant image corresponding to the target tenant. After the single-tenant image is obtained through downloading, the container application is started, so that the subsequent single-tenant application which independently provides tenant service and corresponds to the target tenant is conveniently created based on the single-tenant image.
It should be noted that, the manner of creating the multi-tenant application image may be any method in the prior art, which is not limited in this embodiment. 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 condition 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 fulfill the aim of monopolizing the individual requirement resource specification, so as to finally fulfill the aim of decoupling the resource, thereby solving the problem of resource waste existing in the prior art that the resource specification is expanded to a state larger than the peak value.
And step S3, creating a single-tenant application corresponding to the target tenant based on the single-tenant application 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 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, there is no data matching the target tenant in the single-tenant application 20 created based on the single-tenant application image, nor is it possible to provide tenant service to the target tenant, but only one application. After the step of synchronizing tenant data and configuring gateway switching traffic forwarding rules is performed, a single tenant application 20 that independently provides tenant services to the target tenant can be formed.
Illustratively, after the single-tenant application 20 is created, tenant data in the multi-tenant application 10 matched with the target tenant is synchronized to the single-tenant application 20, so that tenant services are independently provided to the target tenant through the synchronized single-tenant application 20. The method comprises the steps of synchronizing tenant data matched with a target tenant in a multi-tenant application to a single-tenant application, wherein the synchronization is realized based on a synchronization policy. The synchronization strategy includes: determining whether to execute the synchronization policy contained in the first synchronization step based on whether full amount of data matching the target tenant is generated in the multi-tenant application 10; determining whether to execute the synchronization step included in the second synchronization policy based on whether incremental data matching the target tenant is generated in the multi-tenant application; whether to perform the synchronization step included in the third synchronization policy is determined based on whether the trace data matching the target tenant is generated in the multi-tenant application 10.
Referring to fig. 4, the synchronization policy specifically includes the following steps S31 to S36.
Step S31, judging whether incremental data matched with a target tenant is generated in the multi-tenant application; if yes, go to step S32; if not, step S33 is performed.
Step S32, executing the synchronization step included in the first synchronization strategy on the total data matched with the target tenant in the database corresponding to the multi-tenant application.
Step S33, judging whether incremental data matched with a target tenant is generated in the multi-tenant application; if yes, go to step S34; if not, step S35 is performed.
Step S34, executing the synchronization step included in the second synchronization policy on the incremental data matched with the target tenant and generated in the multi-tenant application.
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 performed.
Step S36, executing the synchronization step included in the third synchronization policy on whether the trace data matched with the target tenant is generated in the multi-tenant application.
Step S37, the tenant data is synchronously completed, and tenant service is independently provided for the target tenant through the single tenant application after the synchronization is completed.
The full-scale data refers to data matching the target tenant in the database corresponding to the multi-tenant application 10 (i.e., the multi-tenant database 102), and is synchronized in full-scale form at the time of the first synchronization. The incremental data refers to an operation record generated by the multi-tenant application 10 and matched with the target tenant in the time point of ending the last execution of the synchronization step and the time point of starting the current execution of the synchronization step. The trace data refers to API requests in the multi-tenant application 10 that match the target tenant. The foregoing third synchronization policy (i.e., the first synchronization policy, the second synchronization policy, and the third synchronization policy) is determined based on three determinations (i.e., whether the full amount of data exists, whether the incremental amount of data exists, and whether the trace amount of data exists for the first determination, and whether the trace amount of data exists for the third determination) respectively, so that there may be a step of performing only the first synchronization policy (e.g., a step of performing only the first synchronization policy, a step of performing only the second synchronization policy, or a step of performing only the third synchronization policy), or a step of performing both the first synchronization policy and the second synchronization policy (e.g., a step of performing the first synchronization policy, a step of performing the second synchronization policy, etc.), and the specific execution situation is specifically defined according to the foregoing three determinations.
Referring to fig. 5, the foregoing synchronization steps included in executing the first synchronization policy on the total data matched with the target tenant in the database corresponding to the multi-tenant application specifically include the following steps S51 to S52.
Step S51, establishing a master-slave relation 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.
Specifically, a master-slave relationship of a database corresponding to the multi-tenant application 10 (i.e., the multi-tenant database 102 shown in fig. 1) and a database corresponding to the single-tenant application 20 (i.e., the single-tenant database 202 shown 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, thereby ensuring consistency of the data stored by both (i.e., the aforementioned multi-tenant database 102 and single-tenant database 202).
The master-slave relationship of the database refers to a relationship formed by 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 complete one) as the slave database. And the master database and the slave database are synchronized by a log synchronization mechanism. The data corresponding to the 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 manner of establishing the master-slave relationship may be that the database corresponding to the single-tenant application 20 is accessed to the database corresponding to the multi-tenant application 10 in a node manner, or that the database corresponding to the single-tenant application 20 is directly accessed to the database corresponding to the multi-tenant application 10, or that the database is accessed in a container manner, and the manner of establishing the master-slave relationship is not specifically limited in this embodiment.
In addition, the foregoing manner of synchronizing the 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 the data of the master database from the master database (i.e., the multi-tenant database 102) through a log synchronization mechanism to achieve the purpose of data synchronization, or the master database actively synchronizes the data of itself (i.e., the master database) to the slave database through a log synchronization mechanism to achieve the purpose of data synchronization. The present embodiment is not limited to a specific synchronization method.
And step 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 simultaneously only retaining 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 identical to 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 identical to 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 canceled. At this point, the single-tenant database 202 stores data consistent with that in the multi-tenant database 102, i.e., the single-tenant database 202 stores more than just data matching the target tenant. Therefore, a deletion operation is performed on the data in the database corresponding to the single-tenant application 20 (i.e., the single-tenant database 202) that does not match the target tenant, so as to delete the data in the single-tenant database 202 that does not match the target tenant, so that only the data matching the target tenant is retained, and unnecessary data is deleted, thereby achieving the purpose of saving the space of the single-tenant database 202.
Whether to execute the synchronization step included in the second synchronization policy is determined based on whether incremental data matched with the target tenant is generated in the multi-tenant application or not, specifically including: and repeatedly executing the steps of processing the operation records which are generated by the multi-tenant application and are matched with the target tenant in the time point of ending the last execution of the synchronization step and the time point of starting the current execution of the synchronization step and importing the operation records into the database corresponding to the single-tenant application until the time difference formed by the time point of ending the last execution of the synchronization step and the time point of starting the current execution of the synchronization step is smaller than the preset time.
The operation record may be understood as binlog, which refers to SQL statement information used for recording operations of a database by a user, including adding operations, deleting operations and modifying operations of a data table and contents, while query operations are not recorded. The code for a specific intercept operation record can be found in the following table 3:
table 3 intercepts code instances of operation records
For example, when the end time point of the first synchronization step (i.e., the time point corresponding to the case where the data in the single-tenant database 202 matches the data in the multi-tenant database 102) is denoted as T1 and the start time point of the present synchronization step is denoted as T2, a step of processing the operation record generated by the multi-tenant application 10 in the time period of T1 to T2 and matching the target tenant and importing the operation record into the database corresponding to the single-tenant application 20 is performed. The method comprises the following steps: and analyzing the operation records (i.e. binlog) which are generated by the multi-tenant 10 and are matched with the target tenant in the time period of T1-T2, converting the analyzed operation records into a DML database operation language, replaying the DML import data in the single-tenant application 20, and recording the time of finishing importing as T3. Then, a step of processing the operation record matching the target tenant generated by the multi-tenant application 10 in the period of T2 to T3 and importing the operation record into the database corresponding to the single-tenant application 20 is performed, and the time when importing is completed is recorded as T4. And by analogy, executing the steps of processing the operation records which are generated by the multi-tenant application 10 and are matched with the target tenant in the Tn-1 to Tn time periods and importing the operation records into the database corresponding to the single-tenant application 20. Until the time period (time difference) of Tn-1 to Tn is smaller than the preset time. And defining the preset time as 1 second, stopping until the time period Tn-1-Tn is less than 1 second, and ending the execution of the steps contained in the second synchronization strategy.
The preset time may be defined as 1 second, or may be defined as another time length. And 1 second is defined based on the experience requirement "2-5-8 principle" common in the industry. The principle of 2-5-8 is as follows: 2-5-8 principle of response time if the user can get a response within 2 seconds, the user will feel that the response speed of the system is fast. If the user gets a response in 2 seconds to 5 seconds, the user feels that 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 acceptable. If the user still fails to get a response after 8 seconds, the user may feel that the response speed of the system is slow, or that the system has lost the response, and choose to leave the secondary Web site, or initiate a secondary request. The preset time is defined as 1 second based on the above-described "2-5-8 principle", and may be defined as other time lengths, and of course, the preset time is preferably 1 second.
In addition, a synchronization step is performed on the operation records before the operation records are processed, so as to synchronize the operation records to the single-tenant application 20, thereby achieving the purpose of keeping the integrity of the operation records in the single-tenant application 20.
Whether to execute the synchronization step included in the third synchronization policy is determined based on whether to generate the trace data matched with the target tenant in the multi-tenant application, specifically: copying the API request matched with the target tenant in the multi-tenant application 10 to a cache queue, and forwarding the API request in the cache queue to the single-tenant application 20 so as to sequentially respond to the API request matched with the target tenant through the single-tenant application until the cache queue is empty, and switching gateway routes so as to directly forward the API request matched with the target tenant to the single-tenant application.
Specifically, the gateway API request mirror copy function is opened, and the API request matched with the target tenant in the multi-tenant application 10 is copied to the cache queue. At the same time, the API replays the snoop cache queue to forward API requests in the cache queue to the single tenant application 20. When the cache queue is empty (i.e., the API requests in the cache queue are all forwarded), the gateway route is cut off to forward the API requests issued by the target tenant directly to the single tenant application 20 without turning on the mirror copy function described above. At this time, the step execution of synchronizing the tenant data matched with the target tenant in the multi-tenant application to the single-tenant application ends, so that the tenant service can be independently provided to the target tenant by the single-tenant application 20 after synchronization (i.e., after synchronization of the tenant data). The tenant data may be understood as a generic term of the total data, the incremental data, and the trace data.
According to the method and the device for synchronizing the tenant data, the tenant data matched with the target tenant in the multi-tenant application are synchronized to the single-tenant application independently providing the tenant service based on the synchronization strategy, the problem of poor user experience caused by stopping service to finish data migration in the prior art is solved, the synchronization of the tenant data is continuously stopped and finished under the condition that the flow is continuously provided, the purpose that a user does not feel is achieved, and the user experience is guaranteed.
After the synchronized single-tenant application independently provides tenant service for the target tenant, deleting tenant data matched with the target tenant in the multi-tenant application 10, thereby achieving the purpose of saving resources in the multi-tenant application 10.
According to the implementation method of the multi-tenant service, the application load information of the multi-tenant application 10 is acquired to judge whether the load pressure of the multi-tenant application 10 is high or not at the current time. When the load pressure of the multi-tenant application 10 is high, tenant information corresponding to each individual tenant in the multi-tenant application 10 is acquired, and thus the target tenant is selected. The target tenant may be understood as a premium customer, i.e. a customer whose tenant service requirements are high. The number of target clients may be determined by the tenant activity and tenant traffic, or may be determined by other manners, which are specifically described above and not repeated herein.
After determining the target client, creating a single-tenant application 20 for the target tenant in a mirroring manner, and synchronizing tenant data of the target tenant to the single-tenant application 20, so as to independently provide tenant services for the target tenant through the synchronized single-tenant application. Compared with the prior art that a plurality of tenants correspond to one multi-tenant application 10 to provide tenant services for the plurality of tenants through the multi-tenant application 10, the method and the device create a single-tenant application 20 for a 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 decoupling the tenant services is achieved, the single tenant is ensured not to be interfered by other tenants, and the experience degree of the tenant is ensured. The single-tenant application 20 is independently deployed with the single-tenant database 202 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, and achieve data decoupling, so as to solve the problem that the coupling of codes and data in the prior art is easy to cause degradation, and solve the problem that the performance, stability and other aspects are affected mutually due to the coupling of the codes and the data. And determining the target tenant through the tenant information, thereby independently creating a single-tenant application 20 corresponding to the target tenant for the target tenant to independently provide tenant service for the target tenant, and simultaneously, the target tenant monopolizes the resources contained in the single-tenant application 20. Tenant information represents the needs of tenants, the actual resource needs corresponding to the tenants with different needs are also different, and in the prior art, resource coupling results in that each tenant cannot monopolize the resource specification of its personalized needs. Even though the multi-instance load balancing mode is adopted, the shared resource essentially has the following problems: the resource specification is expanded to a state larger than the peak value so as to meet each tenant as much as possible, and at this time, the problem of resource waste is necessarily existed. Therefore, the single-tenant application 20 is created for the target tenant to provide the independent resource specification for the target tenant, so that the purpose of decoupling the resource is realized by the exclusive use of the resource specification by the target tenant, and the problem of resource waste in the prior art of sharing the resource 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 shown in the invention realizes the implementation of the target tenant (i.e. the high-quality client) and provides the independent tenant service with double consideration of stability and security for the target tenant. 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, this embodiment also discloses an implementation system of multi-tenant service (simply referred to as "implementation system", i.e. implementation system 400 shown in fig. 6). As shown in fig. 6, the implementation system 400 includes: a determination module 401, a creation module 402 and a synchronization module 403.
As shown in fig. 6, the implementation system 400 is a system configured by the entire computer code included in correspondence with the determination module 401, the creation module 402, and the synchronization module 403, and may be configured not only by deployment in a location but also by logic. As for the deployment positions of the three modules (i.e., the determining module 401, the creating module 402, and the synchronizing module 403) may be deployed in the Kubernetes100 in an integral manner, or may be deployed in the computer system 1000 and logically independent of the Kubernetes100, or may be deployed in the Kubernetes100 and the computer system 1000 independently (e.g., the determining module 401 is deployed inside the Kubernetes100, the creating module 402 and the synchronizing module 403 are deployed outside the Kubernetes100 and inside the computer system 1000, etc.), and the three modules integrally form the implementation system 400, which is not limited to the specific deployment manner in the present embodiment.
The confirmation module 401 obtains tenant information respectively corresponding to individual tenants in the multi-tenant application, so as to determine a target tenant based on the tenant information.
Specifically, the confirmation module obtains the application load information corresponding to the multi-tenant application 10, so as to determine whether to obtain the tenant information corresponding to the individual tenants in the tenant application based on the application load information, which may also be understood as determining whether to execute the subsequent slicing 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 a plurality of CPU utilization rate, memory utilization rate, disk IO occupancy rate and 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 step, the subsequent step is executed when the load pressure of the multi-tenant application 10 is high, so that resource waste caused by executing the subsequent step due to low load pressure is prevented. When the load pressure of the multi-tenant application 10 is determined to be large, tenant information corresponding to each individual tenant in the multi-tenant application 10 is acquired, so that a target tenant is determined according to the tenant information. Determining whether the tenant is the target tenant through the tenant information can also be understood as determining whether the user is the user in the fourth quadrant (i.e. the high-quality user) through the tenant information, so that the purpose of subsequently creating a single-tenant application for the target tenant to independently provide tenant services for a single user through the single-tenant application is achieved.
The creation module 402 creates an image corresponding to the multi-tenant application as a multi-tenant application image, and extracts an image of the target tenant from the multi-tenant application image as a single-tenant application image.
Specifically, a multi-tenant application image is created in a container form based on the multi-tenant application 10 and uploaded into the image repository 30. And downloading the image corresponding to the target tenant from the image warehouse 30 to serve as a single-tenant image corresponding to the target tenant. After the single-tenant image is obtained through downloading, the container application is started, so that the subsequent single-tenant application which independently provides tenant service and corresponds to the target tenant is conveniently created based on the single-tenant 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 to be 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, there is no data associated with the target tenant in the single-tenant application 20 created based on the single-tenant application image, and the target tenant cannot be provided with the tenant service, which is only one application. 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 tenant services are independently provided for the target tenant through the synchronized single-tenant application 20.
Referring to fig. 7, the synchronization module 403 includes: the first synchronization module 4031, the second synchronization module 4032, and the third synchronization module 4033. Wherein the first synchronization module 4031 determines whether to execute the synchronization policy included in the first synchronization step based on whether 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 contained 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 step included in the third synchronization policy based on whether the 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 specifically defined based on the determination, and therefore, only the logic included in the first synchronization module 4031 or the logic included in the second synchronization module 4032 or the logic included in the third synchronization module 4033 may be executed, or any two of the logic included in any two of the three synchronization modules may be executed, or the logic included in the three synchronization modules may be executed, where the specific execution 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 canceled (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 playback module 40323. The log synchronizing 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 parsing module 40322, so as to achieve the purpose of keeping the integrity of the operation record in the single-tenant application 20. The log parsing module 40322 parses the incremental data and converts the parsed operation records into a DML database operation language, and then sends the converted operation records to the data replay module 40323. The data replay module 40323 performs modifications of data (e.g., adding data, deleting data, and modifying data) into the single tenant database 202 based on the translated operational records. The second synchronization module 4032 also records the time difference between the last synchronization step ending time point and the current synchronization step starting time point, and if the time difference is greater than the preset time, the logic included in the log synchronization module 40321, the log parsing module 40322 and the data playback module 40323 is repeatedly executed until the time difference between the last synchronization step ending time point and the current synchronization step starting time point is less than the preset time, and the process is stopped.
Referring to fig. 10, the third synchronization module 4033 deploys a cache queue 40331 and an API replay module 40332. The API requests in the multi-tenant application 10 that match the target tenant are copied to the cache queue 40331 by a route in the API gateway and forwarded in turn to the API replay module 40332. The API replay module 40332 listens to the cache queue 40331 and sends the cache queue 40331API requests to the single-tenant application 20 to respond to the API requests matched with the target tenant in sequence through the single-tenant application until the cache queue is empty, and switches the gateway route to directly forward the API requests matched with the target tenant to the single-tenant application.
The implementation system 400 disclosed above and the implementation method of a multi-tenant service described above are based on the same inventive concept, and the detailed description of the implementation system may be referred to in the foregoing description, which is not repeated here.
In addition, the logic included in step S1 in the method for implementing a multi-tenant service is implemented by the determining module 401 in the implementing system 400, the logic included in step S2 in the method for implementing a multi-tenant service is implemented by the creating module 402 in the implementing system 400, and the logic included in step S3 in the method for implementing a multi-tenant service is implemented by the synchronizing module 403 in the implementing system 400.
The above list of detailed descriptions is only specific to practical embodiments of the present invention, and they are not intended to limit the scope of the present invention, and all equivalent embodiments or modifications that do not depart from the 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 characteristics 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 disclosure describes embodiments, not every embodiment is provided with a separate embodiment, and that this description is provided for clarity only, and that the disclosure is not limited to the embodiments described in detail below, and that the embodiments described in the examples may be combined as appropriate to form other embodiments that will be apparent to those skilled in the art.

Claims (12)

1. A method for implementing a multi-tenant service, comprising:
acquiring tenant information respectively corresponding to single tenants in the multi-tenant application, so as to determine a target tenant based on the tenant information;
creating an image corresponding to a multi-tenant application as a multi-tenant application image, and extracting an image of a target tenant from the multi-tenant application image as a single-tenant application image;
creating a single-tenant application corresponding to the target tenant based on the single-tenant application image, and synchronizing tenant data matched with the target tenant in the multi-tenant application to the single-tenant application based on a synchronization strategy so as to independently provide tenant service for the target tenant through the synchronized single-tenant application;
the tenant data comprises full data, incremental data and trace data, wherein the trace data comprises an API request matched with a target tenant in the multi-tenant application.
2. The method for implementing the multi-tenant service according to claim 1, further comprising, before acquiring tenant information corresponding to each of the individual tenants in the multi-tenant application:
and acquiring application load information corresponding to the multi-tenant application, so as to determine whether to execute the step of acquiring tenant information respectively corresponding to single tenants in the multi-tenant application based on the application load information.
3. The method for implementing the multi-tenant service according to claim 2, wherein 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 several of CPU usage rate, memory usage rate, disk IO occupancy rate and network IO occupancy rate corresponding to the multi-tenant application.
4. The method for implementing the multi-tenant service according to claim 1, wherein the tenant information includes: tenant liveness and tenant traffic corresponding to individual tenants respectively;
the tenant activity is determined by the API request amount corresponding to a single tenant, and the tenant service amount is realized by the database data amount corresponding to the single tenant.
5. The method for implementing the multi-tenant service of claim 4, wherein the API request amount comprises: one or any combination of a single tenant corresponding API request quantity percentile, an API request time consuming percentile and an API request response data quantity percentile;
the tenant traffic includes: one or any combination of a plurality of accumulated data quantity percentiles corresponding to single tenants and average numbers of SQL slow query times percentiles.
6. The method for implementing a multi-tenant service according to any one of claims 1 to 5, wherein the synchronization policy includes:
determining whether to execute a synchronization step contained in the first synchronization policy based on whether full data matching the target tenant is generated in the multi-tenant application;
determining whether to execute the synchronization step included in the second synchronization policy based on whether incremental data matching the target tenant is generated in the multi-tenant application;
whether to execute the synchronization step included in the third synchronization policy is determined based on whether the trace data matching the target tenant is generated in the multi-tenant application.
7. The method for implementing multi-tenant service of claim 6, wherein,
the full-scale data includes: data matched with a target tenant in a database corresponding to the multi-tenant application;
the incremental data includes: and the operation records which are generated by the multi-tenant application and are matched with the target tenant are generated in the time point when the last execution of the synchronization step is ended and the time point when the current execution of the synchronization step is started.
8. The method for implementing the multi-tenant service according to claim 7, wherein the synchronization step included in the first synchronization policy specifically includes:
Establishing a master-slave relation 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 simultaneously only retaining the data matched with the target tenant in the database corresponding to the single-tenant application.
9. The method for implementing the multi-tenant service according to claim 8, wherein the step of synchronizing included in the second synchronization policy includes:
and repeatedly executing the steps of processing the operation records which are generated by the multi-tenant application and are matched with the target tenant in the time point of ending the last execution synchronization step and the time point of starting the current execution synchronization step and importing the operation records into the database corresponding to the single-tenant application until the time difference formed by the time point of ending the last execution synchronization step and the time point of starting the current execution synchronization step is smaller than the preset time.
10. The method for implementing the multi-tenant service according to claim 9, wherein the step of synchronizing included in the third synchronization policy includes:
Copying the API request matched with the target tenant in the multi-tenant application to a cache queue, and forwarding the API request in the cache queue to the single-tenant application, so that the single-tenant application can sequentially respond to the API request matched with the target tenant until the cache queue is empty, and switching gateway routes to directly forward the API request matched with the target tenant to the single-tenant application.
11. The method for implementing multi-tenant service according to claim 10, wherein after the independently providing the tenant service to the target tenant by the synchronized single-tenant application, the method further comprises:
and deleting tenant data matched with the target tenant in the multi-tenant application.
12. A system for implementing a multi-tenant service, comprising:
the determining module acquires tenant information respectively corresponding to single tenants in the multi-tenant application so as to determine a target tenant based on the tenant information;
the system comprises a creation module, a storage module and a storage module, wherein the creation module creates an image corresponding to a multi-tenant application to serve as a multi-tenant application image, and extracts an image of a target tenant from the multi-tenant application image to serve as a single-tenant application image;
the synchronization module is used for creating a single-tenant application corresponding to the target tenant based on the single-tenant application image, synchronizing tenant data matched with the target tenant in the multi-tenant application to the single-tenant application based on a synchronization strategy, and independently providing tenant service for the target tenant through the synchronized single-tenant application;
The tenant data comprises full data, incremental data and trace data, wherein the trace data comprises an API request matched with a target tenant in the multi-tenant application.
CN202211068613.XA 2022-09-02 2022-09-02 Method and system for realizing multi-tenant service Active CN115480914B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211068613.XA CN115480914B (en) 2022-09-02 2022-09-02 Method and system for realizing multi-tenant service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211068613.XA CN115480914B (en) 2022-09-02 2022-09-02 Method and system for realizing multi-tenant service

Publications (2)

Publication Number Publication Date
CN115480914A CN115480914A (en) 2022-12-16
CN115480914B true CN115480914B (en) 2023-07-21

Family

ID=84422592

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211068613.XA Active CN115480914B (en) 2022-09-02 2022-09-02 Method and system for realizing multi-tenant service

Country Status (1)

Country Link
CN (1) CN115480914B (en)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8977735B2 (en) * 2011-12-12 2015-03-10 Rackspace Us, Inc. Providing a database as a service in a multi-tenant environment
US9838370B2 (en) * 2012-09-07 2017-12-05 Oracle International Corporation Business attribute driven sizing algorithms
CN103440195A (en) * 2013-07-11 2013-12-11 盛科网络（苏州）有限公司 Switch chip verification method and device based on logic chip
CA2930026C (en) * 2013-11-11 2020-06-16 Amazon Technologies, Inc. Data stream ingestion and persistence techniques
CN110830351B (en) * 2018-08-07 2023-07-21 深信服科技股份有限公司 Tenant management and service providing method and device based on SaaS service mode
CN113342827A (en) * 2021-07-01 2021-09-03 广东电网有限责任公司 Power grid data storage method, storage medium and system based on multi-tenant technology

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SaaS多租户数据管理及实现策略;殷伟凤;《软件工程》;第19卷(第1期);第44-47页 *

Also Published As

Publication number Publication date
CN115480914A (en) 2022-12-16

Similar Documents

Publication Publication Date Title
CN109947773B (en) Deploying changes to key patterns in a multi-tenant database system
CN101819577B (en) Method, system and apparatus for maintaining file system client directory caches
CN107797767B (en) One kind is based on container technique deployment distributed memory system and its storage method
HU219996B (en) Client computer, as well as method for operating it
US20090049107A1 (en) Method and System of Database Management for Replica Database
JPH06161855A (en) File device and method for access to file
US11379418B2 (en) File system warnings for moves of shared content items
WO2011103537A1 (en) Data synchronization between a data center environment and a cloud computing environment
US7499904B2 (en) System and method for client mastered replication of local files
TWI329278B (en) Method, system and program product for preserving and restoring mobile device user settings
EP1480130B1 (en) Method and apparatus for moving data between storage devices
US20220188273A1 (en) Per-node metadata for custom node behaviors across platforms
JP2019511796A (en) File management method and file management apparatus using the same {METHOD FOR MANAGING FILES AND APPARATUS USING THE SAME}
CN108427728A (en) Management method, equipment and the computer-readable medium of metadata
CN108037937A (en) A kind of method of dynamic more new resources
JP7038864B2 (en) Search server centralized storage
CN108762982A (en) A kind of database restoring method, apparatus and system
CN110096237A (en) Replica processes method and node, storage system, server, readable medium
EP3061011B1 (en) Method for optimizing index, master database node and subscriber database node
CN115480914B (en) Method and system for realizing multi-tenant service
CN111459619A (en) Method and device for realizing service based on cloud platform
US20150350315A1 (en) Zero copy volume reconstruction
JP2020502605A (en) Accessing historical content items in the content management system via placeholders
JP2011522337A (en) Method of synchronizing software modules of computer system distributed to server cluster, application to synchronization system and data storage
US10169343B2 (en) Deferring the cost of virtual storage

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant