CN117971278A - Multi-version management method, server and storage medium of multi-tenant SaaS system - Google Patents

Abstract

According to the multi-version management method and system for the multi-tenant SaaS system, the corresponding currently used target version of the tenant is searched and obtained from the user management library according to the tenant ID obtained from the tenant login request, the tenant configuration information is assembled according to the tenant login request, whether the target version carried in the current tenant configuration information is matched with the current SaaS service instance version or not is checked, if so, the domain name of the tenant is analyzed into the front-end data storage area of the public cloud OSS target version, and the front-end data storage area sends the micro-service gateway with the flow mapped by the target version to the SaaS service of the target version, so that each tenant of the SaaS system can select different versions of the system for use according to individual needs, and the working efficiency of the user is improved.

Description

Multi-version management method, server and storage medium of multi-tenant SaaS system

Technical Field

The invention relates to the technical field of SaaS management, in particular to a multi-version management method, a server and a storage medium of a multi-tenant SaaS system.

Background

Under the business scenario of multi-tenant SaaS in the life science field, the upgrade requirements of each tenant on the production environment version are different from each other: some tenants are reluctant to upgrade and still want to use the old version, some tenants only want to upgrade to some intermediate version of the SaaS system, and some tenants are willing to upgrade to the latest version of the system. However, most of the existing SaaS systems do not consider multi-version problems at the beginning of service architecture, only a unique production environment version is supported online, and only a unique version can be used by all tenants.

Disclosure of Invention

The invention discloses a multi-version management method of a multi-tenant SaaS system aiming at the defects in the prior art, which comprises the following steps:

Acquiring a tenant ID from a tenant login request, and searching and acquiring a corresponding currently used target version of the tenant from a user management library according to the tenant ID, wherein the user management library is configured to store mapping relations between each tenant and each version of a system;

assembling tenant configuration information according to a tenant login request, wherein the tenant configuration information comprises, but is not limited to, a tenant ID, a login account and a target version;

Checking whether a target version carried in the configuration information of the current tenant is matched with the version of the current SaaS service instance, if so, resolving the domain name of the tenant into a front-end data storage area of the public cloud OSS target version, and sending the flow to the SaaS service of the target version by a micro-service gateway mapped by the target version through the front-end data storage area.

Preferably, the micro service gateway is configured to cache the mapping relationship between the tenant and the version, and broadcast the version change event synchronously when the system version used by the tenant changes, and update the original cache to the latest version mapping relationship.

Preferably, the multi-version management method of the multi-tenant SaaS system further comprises the following steps:

When a system version is upgraded or a new system version is added, checking the library table metadata of a plurality of tenants mapped by the system version, selecting one tenant data source as a reference data source, checking the library table metadata in other tenant data sources with the reference data source in sequence, wherein the checking content comprises but is not limited to the number of tables, the sequence of the table characters, the number of the table characters and the data type, and adjusting and modifying that the checking is not passed.

Preferably, when upgrading a system version or adding a new system version, verifying library table metadata of multiple tenants mapped by the system version specifically includes: acquiring a plurality of tenant information of a system version which is selected and used for upgrading, and confirming a corresponding tenant database metadata storage position according to the tenant information; selecting a first data source as a reference data source for comparison and verification, recording when the fact that the table numbers of the first data source and the second data source are inconsistent is verified, and if the fact that the table numbers of the first data source, the third data source and the fourth data source are consistent is verified, considering that errors exist in the table numbers of the second data source; and if the table numbers of the first data source and the third data source are not consistent or the table numbers of the first data source and the fourth data source are not consistent, performing repeated verification again by taking the second data source as a reference data source until the table number with the correct rate larger than the set threshold value is confirmed as a final reference data source, and marking the data source with the different table number from the final reference data source as not passing the verification.

Preferably, the multi-version management method of the multi-tenant SaaS system further comprises the following steps:

After receiving a version rollback request of a tenant, mapping the tenant adjustment to a target version of the request rollback, simultaneously reserving a table and data which are more than the corresponding rollback version in the metadata of the tenant library, redundant fields and values after rollback, reserving the data type and the data range of the original fields and the table name, and resetting a default value for a new field which needs to be established for the rollback version.

The invention also discloses a multi-version management system of the multi-tenant SaaS system, which comprises a version acquisition module, an information configuration module and a version analysis module, wherein the version acquisition module is used for acquiring a tenant ID from a tenant login request, searching and acquiring a corresponding currently used target version of a tenant from a user management library according to the tenant ID, and the user management library is configured to store mapping relations of each tenant and each version of the system; the information configuration module is used for assembling tenant configuration information according to the tenant login request, wherein the tenant configuration information comprises, but is not limited to, tenant ID, login account and target version; the version analysis module is used for checking whether the target version carried in the configuration information of the current tenant is matched with the version of the current SaaS service instance, if so, analyzing the domain name of the tenant into a front-end data storage area of the public cloud OSS target version, and the front-end data storage area sends the flow to the SaaS service of the target version from the micro-service gateway mapped by the target version.

Preferably, the micro service gateway is configured to cache the mapping relationship between the tenant and the version, and broadcast the version change event synchronously when the system version used by the tenant changes, and update the original cache to the latest version mapping relationship.

Preferably, the system further comprises a data verification module, which is used for verifying the database table metadata of a plurality of tenants mapped by the system version when the system version is upgraded or a new system version is added, selecting one tenant data source as a reference data source, and verifying the database table metadata in other tenant data sources with the reference data source in sequence, wherein the verification content comprises, but is not limited to, the number of tables, the sequence of the tables, the number of the tables and the data type, and the adjustment and the modification are carried out when the verification fails.

The invention also discloses a server, which comprises a memory, a processor and a computer program stored in the memory and capable of running on the processor, wherein the processor realizes the steps of the multi-version management method of any multi-tenant SaaS system when executing the computer program.

The invention also discloses a computer readable storage medium storing a computer program which when executed by a processor implements the steps of the multi-version management method of the multi-tenant SaaS system as described in any one of the above.

According to the multi-version management method, the server and the storage medium of the multi-tenant SaaS system, the corresponding currently used target version of the tenant is searched and obtained from the user management library according to the tenant ID obtained from the tenant login request, the tenant configuration information is assembled according to the tenant login request, whether the target version carried in the current tenant configuration information is matched with the current SaaS service instance version or not is checked, if so, the domain name of the tenant is analyzed into the front-end data storage area of the public cloud OSS target version, and the front-end data storage area sends the micro-service gateway with the flow mapped by the target version to the SaaS service of the target version, so that each tenant of the SaaS system can select different versions of the system for use according to individual needs, and the working efficiency of the user is improved.

Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

fig. 1 is a schematic step diagram of a multi-version management method of a multi-tenant SaaS system according to an embodiment of the present invention.

Fig. 2 is a schematic flow chart of step S2 according to an embodiment of the invention.

Fig. 3 is a schematic flow chart of step S3 according to an embodiment of the invention.

Fig. 4 is a schematic flow chart of step S4 according to an embodiment of the invention.

Fig. 5 is a block diagram of a multi-version management system of a multi-tenant SaaS system according to another embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. It will be apparent that the described embodiments are some, but not all, embodiments of the invention. All other embodiments, which can be made by a person skilled in the art without creative efforts, based on the described embodiments of the present invention fall within the protection scope of the present invention.

Unless defined otherwise, technical or scientific terms used herein should be given the ordinary meaning as understood by one of ordinary skill in the art to which this invention belongs. The terms "first," "second," and the like in the description and in the claims, are not used for any order, quantity, or importance, but are used for distinguishing between different elements. Likewise, the terms "a" or "an" and the like do not denote a limitation of quantity, but rather denote the presence of at least one.

In a business scenario of multi-tenant SaaS (software as a service) in the life science field, upgrade requirements of each tenant on a production environment version are different from each other: some tenants are reluctant to upgrade and still want to use the old version, some tenants only want to upgrade to some intermediate version of SaaS (software as a service), and some tenants have a strong willingness to upgrade to the latest version of SaaS (software as a service). However, most of the existing SaaS systems do not consider similar problems at the beginning of the service architecture, only support the unique online of the production environment version, and all tenants can only use the unique version, which causes inconvenience to various works of users.

Therefore, the embodiment discloses a multi-version management method of a multi-tenant SaaS system, as shown in fig. 1, including the following steps:

Step S1, acquiring a tenant ID from a tenant login request, and searching and acquiring a corresponding currently used target version of the tenant from a user management library according to the tenant ID, wherein the user management library is configured to store mapping relations of each tenant and each version of a system.

Specifically, firstly, the currently used system version of the tenant is queried according to the tenant ID, so that tenant configuration information is assembled later to obtain the configuration information.

In this embodiment, each tenant simultaneously supports sequential upgrade or cross-version upgrade of the current version, and when the system version used by each tenant changes, the system synchronously broadcasts a version change event and updates the system version corresponding to the tenant in the user management library to the latest state. Since the new version of the system is updated and the updated function of each tenant is not known, and the user is not satisfied with the new function of the new version and the experience of the updated system is reduced, the embodiment provides a pre-demonstration of the function module demonstration function before the updated function module related to the new version and the updated function module in the system version update, so as to help each tenant to experience the updated module function in advance, thereby determining whether to update or not.

Step S101, selecting updated demonstration target version identity according to the version update demonstration instruction, and acquiring a function demonstration component of a corresponding version from a version database according to the target version identity.

Step S102, inquiring and acquiring each intermediate version update information and each corresponding function demonstration component between the current target version and the demonstration target version in a version database, and forming a newly added function configuration table and a function demonstration component set according to the update information of each intermediate version and the demonstration target version, wherein the newly added function configuration table comprises the function information which is newly added after the current target version is updated to the demonstration target version.

Step S103, respectively calling corresponding function demonstration components from the function demonstration component set according to the newly-added function configuration table to carry out simulation presentation.

Wherein, the step S103 further includes:

According to functions to be demonstrated and corresponding demonstration configuration options selected from the newly-added function configuration table, the corresponding function demonstration components are centrally called from the function demonstration components to carry out simulation presentation, the demonstration configuration options comprise a first demonstration configuration mode and a second demonstration configuration mode, the first demonstration configuration mode is configured to carry out function simulation demonstration according to simulation configuration data prestored in the function demonstration components, and the second demonstration configuration mode is configured to acquire corresponding data from a current version operation system according to the configuration parameter table prestored in the function demonstration components to carry out function simulation demonstration as demonstration configuration data.

In this embodiment, the step S103 further includes:

The second demonstration configuration mode is further configured to acquire corresponding data from the current version operation system according to a pre-stored configuration parameter table, if partial parameters cannot be acquired, an information input interface is generated for a user to input corresponding missing parameters, and the acquired missing parameters are fed into the data acquired from the current system to serve as configuration data for demonstration to perform functional simulation demonstration.

The presenting configuration options further include a third presenting configuration mode, and the step S103 specifically further includes:

And acquiring the demonstration configuration options, and acquiring corresponding data from the current version running system according to a configuration parameter table prestored in the function demonstration component if the demonstration configuration options are in a third demonstration configuration mode.

Recording acquired data into a configuration parameter table, acquiring a missing parameter name which is not acquired yet, acquiring corresponding data from prestored simulation configuration data according to the missing parameter name, and supplementing the corresponding data into the configuration parameter table to form configuration data for demonstration; and sending the configuration data for demonstration to a function demonstration component for simulation presentation.

And step S104, when the function demonstration component is simulated, if the function demonstration component is provided with the comparison demonstration identification, the reference identification of the current function demonstration component is obtained, the comparison function module with the same reference identification in the current version operation system is queried according to the module identification, and the comparison function module is triggered to be started after the current user operation interface information is stored.

The step S104 specifically further includes the following steps.

Step S1041, when the function demonstration component is simulated, if the function demonstration component has a comparison demonstration identifier, obtaining a reference identifier of the current function demonstration component, and inquiring a comparison function module with the same reference identifier in the current version operation system according to the module identifier.

Step S1042, storing user operation interface information and operation record in the current version operation system, starting the comparison function module after the storage is completed, and transmitting initial input data identical to the function demonstration component to the comparison function module.

Step S1043, after receiving the user demonstration closing instruction or the demonstration completion information sent by the function demonstration component, closing the function demonstration component and restoring the running system of the current version to the saved original user operation interface.

In this embodiment, the SaaS system upgrade supports a three-level upgrade deployment strategy of a test environment, a verification environment, and a production environment, so as to ensure stability and reliability in the system upgrade process, reduce risks possibly brought by deploying a new version directly in the production environment, and enable each tenant to interrupt the upgrade at any one step.

Step S201, a current target version identity and a target version identity to be upgraded, which is scheduled to be updated, are obtained according to a version upgrading instruction, and test environment information of the target version to be upgraded is obtained in a version database according to the target version identity to be upgraded to build a first operation environment, wherein the first operation environment is used for testing new version functions; after receiving a user test passing instruction, acquiring verification environment information of a target version to be upgraded from a version database to build a second running environment, wherein the second running environment is used for verifying the new version function; after receiving the user verification passing instruction, acquiring production environment information of the target version to be upgraded from the version database to build a third operation environment, wherein the third operation environment is used for carrying out final production and use on the new version.

The step S201 specifically includes:

step S2011, a current target version identity and a target version identity to be upgraded, which is scheduled to be updated, are obtained according to the version upgrading instruction.

Step S2012, the first running environment and the optional simulation configuration information are built by acquiring the test environment information of the target version to be upgraded from the version database according to the identity of the target version to be upgraded.

Step S2013, performing operation parameter configuration according to the parameter configuration options selected by the user, where the parameter configuration options include a first configuration option and a second configuration option, if the user adopts the first configuration option, inputting all the selectable analog configuration information into the first operation environment to perform parameter configuration to form a test system of a target version, if the user adopts the second configuration option, collecting user configuration data of the user under the current target version, replacing the collected user configuration data with corresponding information in the selectable analog configuration information, and then inputting the corresponding information into the first operation environment to perform parameter configuration to form the test system of the target version to be upgraded, where the user configuration data includes, but is not limited to, user role and authority setting information, data type and constraint information, service logic and rule information of the current target version.

The step S2013 includes:

And if the user adopts the second configuration option, acquiring user configuration data of the user under the current version, and converting the acquired user configuration data into configuration data of the target version to be upgraded according to a configuration information corresponding table of the target version to be upgraded and the current target version.

And comparing the converted configuration data with optional simulation configuration information to obtain missing configuration data, and sending the missing configuration data type and optional corresponding simulation data like a user.

And supplementing the missing configuration data newly supplemented by the user or the selected corresponding simulation data into the converted configuration data to form final configuration data of the target version to be upgraded, and inputting the final configuration data into the first operation environment to perform parameter configuration to form the test system of the target version to be upgraded.

The step S2013 further includes:

the parameter configuration options further comprise third configuration options, and if the user adopts the third configuration options, the difference quantity of the configuration data of the target version to be upgraded and the current target version is obtained.

If the difference quantity of the configuration data is lower than a first threshold value, directly generating a parameter configuration interface for acquiring user input data; if the user configuration data is larger than the first threshold, user configuration data of the user under the current target version is directly collected, the obtained user configuration data is converted into configuration data of the target version to be upgraded according to a configuration information corresponding table of the target version to be upgraded and the current target version, and candidate simulation configuration data are provided for the user to select for the configuration data of the target version to be upgraded, which is still missing after conversion.

The configuration data includes system option data configured to be available only through acquisition user input in the configuration options and auxiliary configuration data configured to be available through acquisition user input in the configuration options and auxiliary configuration simulation data corresponding to the acquired system option data in the selectable simulation configuration information of the target version to be upgraded from the version database.

Step S2, tenant configuration information is assembled according to the tenant login request, wherein the tenant configuration information comprises, but is not limited to, tenant ID, login account and target version.

Specifically, multi-terminal (desktop, notebook, cell, tablet) requests are performed on the client and traffic routing is performed on the public cloud server.

And step S3, checking whether the target version carried in the configuration information of the current tenant is matched with the version of the current SaaS service instance, and if so, resolving the domain name of the tenant into a front-end data storage area of the target version of the public cloud OSS, wherein the front-end data storage area sends the flow to the SaaS service of the target version from a micro-service gateway mapped by the target version.

Specifically, the target version is first checked, and when it is checked that the target version does not match the current SaaS instance version, a 503 (service unavailable) instruction is issued, which indicates that the target version issued by the user is wrong.

In this embodiment, a one-to-one mapping is performed between different namespaces (namespaces) and different versions of SaaS services, so that the different versions do not affect each other, resources are strictly isolated, and resource utilization rate is improved.

As shown in fig. 2, the embodiment includes a tenant management module for managing tenant information, a full-link gray level configuration module for maintaining a mapping relationship between a tenant and a target version, wherein the input is a tenant ID, the target version used by the tenant is output, and a version verifier module for assembling a single tenant context (including tenant, account, version, etc. information) at each request in the system. The DNS server firstly analyzes the domain name of the tenant to a front-end Bucket of a public cloud OSS (object storage) target version; the front end in turn beats traffic to the microservice gateway within Kubernetes and the Namespace of the target version map; the micro-service gateway finally routes the traffic to the SaaS service within the current Namespace.

As shown in fig. 3, in this scheme, a Kubernetes (container orchestration engine) cluster is built by multiple servers, one node in the cluster is a server, and the scheduling of the SaaS service instance is dynamically allocated according to the resource utilization rate by using a scheduler of the Kubernetes (container orchestration engine), and the traffic routing across the nodes is scheduled by using virtual bridges of the Kubernetes (container orchestration engine) nodes. Meanwhile, the adjustment strategies of different versions are the same, and service instances under different versions or service instances under the same version can be simultaneously scheduled to the same node (server), so that the resource utilization rate is further improved.

Further, the micro service gateway is configured to cache the mapping relation between the tenant and the version, and synchronously broadcast a version change event when the system version used by the tenant is changed, and update the original cache to the latest version mapping relation.

Specifically, the micro-service gateway layer can cache the mapping relation between the tenant and the version, avoid frequent table lookup, and improve the QPS (query times per second) of the system.

In this embodiment, there may be a case where multiple client library table metadata using the same version are inconsistent in the process of performing version upgrade, resulting in serious problems of system failure and table field mapping errors, for example, if an application depends on specific library table metadata and different versions of library table metadata define different structures or rules, the application may not process data correctly or perform a desired function. Thus, to circumvent this problem, the present embodiment specifies that when a field is newly added in a new version, the newly declared field is explicitly specified after a particular field, including but not limited to the primary key field, the last modified timestamp field, the leading or trailing fields of the custom field, the version control field, the last field of the standard field set. Meanwhile, the embodiment also designs a database table metadata checker, and performs integral check on the database table metadata of a plurality of data sources in the same version, and then the method further comprises the following steps.

And S4, when the system version is upgraded or a new system version is added, checking the library table metadata of a plurality of tenants mapped by the system version, selecting one tenant data source as a reference data source, checking the library table metadata in other tenant data sources with the reference data source in sequence, wherein the checking content comprises but is not limited to the number of tables, the sequence of the table fields, the number of the table fields and the data type, and adjusting and modifying that the checking is not passed.

Specifically, the database management tool is used for collecting the database table metadata in each tenant data source by querying the metadata tables such as information_schema in the metadata database of the database or using the database management tool, and checking the place where each tenant data source is inconsistent with the database table metadata of the reference data source by taking the reference data source as a standard, and further generating a check report according to the comparison result after the completion, wherein the check report comprises INFORMATION such as inconsistent tables, fields, data types and the like and suggested repairing steps.

As shown in fig. 4, the step S4 specifically includes the following steps.

Step S41, acquiring a plurality of pieces of tenant information for selecting and using the upgraded system version, and confirming the corresponding tenant database metadata storage position according to the tenant information.

Specifically, a plurality of tenant IDs using the upgrade system version are obtained from the user management library, and storage positions of library table metadata corresponding to each tenant are confirmed according to the tenant IDs.

Step S42, selecting the first data source as a reference data source for comparison and verification, recording when the fact that the table numbers of the first data source and the second data source are inconsistent is verified, and if the fact that the table numbers of the first data source, the third data source and the fourth data source are consistent is verified, considering that errors exist in the table numbers of the second data source; and if the table numbers of the first data source and the third data source are not consistent or the table numbers of the first data source and the fourth data source are not consistent, performing repeated verification again by taking the second data source as a reference data source until the table number with the correct rate larger than the set threshold value is confirmed as a final reference data source, and marking the data source with the different table number from the final reference data source as not passing the verification.

Specifically, inconsistent data is found out in a comparison mode, and the uncertain data is repeatedly checked in a repeated check mode for multiple times, so that the problem caused by check errors is avoided.

The embodiment also supports tenant version rollback, especially cross-version rollback, and further comprises the following steps:

step S5, after receiving a version rollback request of a tenant, mapping the tenant adjustment to a target version of the request rollback, retaining a list and data which are more than the corresponding rollback version in the table metadata of the tenant library, redundant fields and values after rollback, retaining the data type and data range of the original fields and the list name, and resetting a default value for a new field which needs to be established for the rollback version.

Specifically, this step S5 may specifically include the following:

step S51, searching a corresponding problem function module in a system function table according to the recorded problem data fed back in the use of the current version, and acquiring an updated function configuration table of each historical version in the version update record.

The step S51 may specifically include:

Step S511, inquiring the currently running system version and each history version information in the version database according to the rollback request, and collecting the update functions described on the update function configuration table in each history version information and the related function modules to form a version update record database and a rollback feedback interface.

Step S512, the version update record database is searched according to the problem description of the user on the rollback feedback interface to obtain the corresponding problem function module, the function update description of the problem function module is fed back to the user, and the problem function module is confirmed according to the user feedback. The rollback feedback interface comprises a first-stage problem acquisition interface and a second-stage function update interface.

And searching a version update record database according to the problem description of the user on a first-stage problem acquisition interface of the rollback feedback interface to obtain update description contents in each version related to the update of the problem function module, and respectively forming a plurality of update description options by taking the version as a unit to form a second-stage function update interface by the update description of the problem function module in each version.

And updating the description content retrieval version update record database according to the problem function module selected by the user on the second-level function update interface to confirm the corresponding first association history version.

The rollback feedback interface may include a delete/modify configuration option group, where the delete/modify configuration option group includes a question function module option that may be selected by a user, and the question function module option includes a function module name that is added or adjusted in relation to each history version update; the rollback feedback interface is configured to take an option selected by a user as a question function module.

The rollback feedback interface may further include a reserved configuration update option group, where the reserved configuration update option group includes reserved function module options that may be reserved in the rollback target version for selection by a user, and the reserved function module options include function module names that are added or adjusted in relation to each history version update.

Step S52, searching the updated or modified association history version related to the problem function module in each updated function configuration table according to the problem function module, and recommending the previous version of the association history version to the user as a rollback target version.

Specifically, whether the option information of the reserved functional module is collected or not is judged, if not, a first association history version related to the update or modification of the problem functional module is searched in each update function configuration table according to the problem functional module, and a previous version of the first association history version is recommended to a user as a rollback target version. If the option information of the reserved functional module is acquired, searching a second association history version related to the new or modified reserved functional module in each updated functional configuration table according to the option of the reserved functional module, wherein the first association history version is higher than the second association history version, acquiring an intermediate version set between the first association history version and the second association history version, and recommending the earliest version in the intermediate version set to a user as a rollback target version.

In this embodiment, if the first association history version is not higher than the second association history version or there is no intermediate version between the first association history version and the second association history version, information that cannot maintain the function module is sent to the user, and if a rollback instruction is received, a previous version of the first association history version is recommended to the user as a rollback target version.

In this embodiment, if the update function configuration table is searched for that the update or modification related to the problem function module includes a plurality of update history versions according to the problem function module, the update description contents for the problem function module in each of the update history versions are fed back to the user in version units to form a version confirmation interface composed of a plurality of update description content options; and taking the version of the update description content of the problem function module selected by the user on the version confirmation interface as a first association history version.

Step S53, after obtaining the rollback version confirmation instruction, rollback the current user version to the rollback target version, and storing redundant tables and data after the rollback of the current user version to the target version.

Specifically, during the process of rolling back the current user version to the rolling back target version, the fields and the corresponding values, which are more than the rolling back target version, in the table of the current user version are stored, and when a new field is declared, the default value is set, the existing fields of the current user version are kept from being changed in data type, and the value range for storing the same data type is not changed.

According to the multi-version management method, the server and the storage medium of the multi-tenant SaaS system, the target version currently used by the corresponding tenant is searched and obtained from the user management library according to the tenant ID obtained from the tenant login request, the tenant configuration information is assembled according to the tenant login request, whether the target version carried in the current tenant configuration information is matched with the current SaaS service instance version or not is checked, if so, the domain name of the tenant is analyzed into the front-end data storage area of the public cloud OSS target version, and the front-end data storage area sends the flow to the SaaS service of the target version through the micro-service gateway mapped by the target version, so that each tenant of the SaaS system can select different versions of the system for use according to individual needs, and the working efficiency of the user is improved.

In another embodiment, as shown in fig. 5, a multi-version management system of a multi-tenant SaaS system is further disclosed, which comprises a version acquisition module 1, an information configuration module 2 and a version analysis module 3, wherein the version acquisition module 1 is configured to acquire a tenant ID from a tenant login request, search and acquire a target version currently used by a corresponding tenant from a user management library according to the tenant ID, and the user management library is configured to store mapping relations between each tenant and each version of the system. The information configuration module 2 is configured to assemble tenant configuration information according to a tenant login request, where the tenant configuration information includes, but is not limited to, a tenant ID, a login account, and a target version. And the version analysis module 3 is used for checking whether the target version carried in the configuration information of the current tenant is matched with the version of the current SaaS service instance, if so, analyzing the domain name of the tenant into a front-end data storage area of the public cloud OSS target version, and sending the flow from the micro-service gateway mapped by the target version to the SaaS service of the target version by the front-end data storage area.

In this embodiment, the micro service gateway is configured to cache the mapping relationship between the tenant and the version, and broadcast the version change event synchronously when the system version used by the tenant changes, and update the original cache to the latest version mapping relationship.

In this embodiment, the system further includes a data verification module 4, configured to, when upgrading a system version or adding a new system version, verify library table metadata of multiple tenants mapped by the system version, select one tenant data source as a reference data source, and verify the library table metadata in other tenant data sources with the reference data source sequentially, where the verification content includes, but is not limited to, table number, table field order, table field number and data type, and adjust and modify that the verification is not passed.

It should be noted that, in the present description, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different manner from other embodiments, and similar portions of each embodiment are referred to each other. For the multi-version management system of the multi-tenant SaaS system disclosed in the embodiment, the description is relatively simple because the multi-version management system corresponds to the multi-version management method of the multi-tenant SaaS system disclosed in the embodiment, and the relevant points are referred to in the description of the method section.

In other embodiments, there is also provided a server comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the multi-version management method of the multi-tenant SaaS system as described in the above embodiments when the computer program is executed. Wherein the server may include, but is not limited to, a processor, a memory. It will be appreciated by those skilled in the art that the schematic is merely an example of a server and is not limiting of the server, and may include more or fewer components than shown, or certain components may be combined, or different components.

The multi-version management system of the multi-tenant SaaS system may be stored in a computer readable storage medium if implemented in the form of software functional units and sold or used as a stand alone product. Based on such understanding, the present invention may implement all or part of the flow of the method of the foregoing embodiment, or may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of the multi-version management method embodiment of each multi-tenant SaaS system. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash disk, a removable hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory, a random access memory, an electrical carrier wave signal, a telecommunication signal, a software distribution medium, and so forth. It should be noted that the computer readable medium contains content that can be appropriately scaled according to the requirements of jurisdictions in which such content is subject to legislation and patent practice, such as in certain jurisdictions in which such content is subject to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the invention.

In summary, the foregoing description is only of the preferred embodiments of the present invention, and all equivalent changes and modifications made in accordance with the claims should be construed to fall within the scope of the invention.

Claims (10)

1. The multi-version management method of the multi-tenant SaaS system is characterized by comprising the following steps of:

Acquiring a tenant ID from a tenant login request, and searching and acquiring a corresponding currently used target version of the tenant from a user management library according to the tenant ID, wherein the user management library is configured to store mapping relations between each tenant and each version of a system;

assembling tenant configuration information according to a tenant login request, wherein the tenant configuration information comprises, but is not limited to, a tenant ID, a login account and a target version;

Checking whether a target version carried in the configuration information of the current tenant is matched with the version of the current SaaS service instance, if so, resolving the domain name of the tenant into a front-end data storage area of the public cloud OSS target version, and sending the flow to the SaaS service of the target version by a micro-service gateway mapped by the target version through the front-end data storage area.

2. The multi-version management method of the multi-tenant SaaS system of claim 2 wherein: the micro service gateway is configured to cache the mapping relation between the tenant and the version, and synchronously broadcast a version change event when the system version used by the tenant is changed, and update the original cache to the latest version mapping relation.

3. The multi-version management method of a multi-tenant SaaS system of claim 2 further comprising the steps of:

When a system version is upgraded or a new system version is added, checking the library table metadata of a plurality of tenants mapped by the system version, selecting one tenant data source as a reference data source, checking the library table metadata in other tenant data sources with the reference data source in sequence, wherein the checking content comprises but is not limited to the number of tables, the sequence of the table characters, the number of the table characters and the data type, and adjusting and modifying that the checking is not passed.

4. The multi-version management method of the multi-tenant SaaS set forth in claim 3, wherein when upgrading a system version or adding a new system version, verifying library table metadata of a plurality of tenants mapped by the system version specifically includes:

acquiring a plurality of tenant information of a system version which is selected and used for upgrading, and confirming a corresponding tenant database metadata storage position according to the tenant information;

Selecting a first data source as a reference data source for comparison and verification, recording when the fact that the table numbers of the first data source and the second data source are inconsistent is verified, and if the fact that the table numbers of the first data source, the third data source and the fourth data source are consistent is verified, considering that errors exist in the table numbers of the second data source; and if the table numbers of the first data source and the third data source are not consistent or the table numbers of the first data source and the fourth data source are not consistent, performing repeated verification again by taking the second data source as a reference data source until the table number with the correct rate larger than the set threshold value is confirmed as a final reference data source, and marking the data source with the different table number from the final reference data source as not passing the verification.

5. The multi-version management method of a multi-tenant SaaS set forth in claim 4, further comprising the steps of:

After receiving a version rollback request of a tenant, mapping the tenant adjustment to a target version of the request rollback, simultaneously reserving a table and data which are more than the corresponding rollback version in the metadata of the tenant library, redundant fields and values after rollback, reserving the data type and the data range of the original fields and the table name, and resetting a default value for a new field which needs to be established for the rollback version.

6. A multi-version management system of a multi-tenant SaaS system, comprising:

the system comprises a version acquisition module, a user management library and a system management module, wherein the version acquisition module acquires a tenant ID from a tenant login request, and searches and acquires a corresponding currently used target version of a tenant from the user management library according to the tenant ID, and the user management library is configured to store mapping relations of each tenant and each version of the system;

The information configuration module is used for assembling tenant configuration information according to the tenant login request, wherein the tenant configuration information comprises, but is not limited to, tenant ID, login account and target version;

the version analysis module is used for checking whether the target version carried in the configuration information of the current tenant is matched with the version of the current SaaS service instance, if so, analyzing the domain name of the tenant into a front-end data storage area of the public cloud OSS target version, and the front-end data storage area sends the flow to the SaaS service of the target version from the micro-service gateway mapped by the target version.

7. The multi-version management system of the multi-tenant SaaS recited in claim 6 wherein the micro-service gateway is configured to cache the mapping relationship between tenants and versions, and to synchronize broadcast version change events when changes occur to system versions used by tenants, updating the original cache to the latest version mapping relationship.

8. The multi-version management system of the multi-tenant SaaS system of claim 6, further comprising a data verification module, configured to, when upgrading a system version or adding a new system version, verify library table metadata of multiple tenants mapped by the system version, select one tenant data source as a reference data source, and verify the library table metadata in other tenant data sources with the reference data source in sequence, where the verification content includes, but is not limited to, a table number, a table word sequence, a table word number, and a data type, and adjust and modify that verification is failed.

9. A server comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized by: the processor, when executing the computer program, implements the steps of the method according to any one of claims 1-5.

10. A computer-readable storage medium storing a computer program, characterized in that: the computer program implementing the steps of the method according to any of claims 1-5 when executed by a processor.