一种多租户服务的实现方法及系统与流程

1.本发明涉及计算机技术领域，尤其涉及一种多租户服务的实现方法及系统。


背景技术：

2.多租户是指软件架构支持一个实例服务多个用户(即，customer)，每个用户被称之为租户(即，tenant)。软件给予租户可以对系统进行部分定制的能力(例如，用户界面颜色或者业务规则)，但是他们不能定制修改软件的代码。
3.现有技术中多租户服务的实现方法可以整体总结为两种。一种为单实例多租户服务，即，部署一个应用实例即可满足多个用户的要求，通过配置元数据给每个用户提供不同的服务。另一种为共享数据库多租户服务，此种实现方法具体划分为两种。具体为：第一种，租户之间共享物理数据库，并对每个租户进行分库。所谓分库是指将原本存储于一个库的数据拆分至多个库，每个租户分别对应一个库以区分租户的数据。第二种，租户之间共享一个物理数据库，但是不进行分库。在数据库表中通过租户所分别对应的id以区分租户的数据。
4.然而，客户在提出个性化需求时的解决方法是，在业务代码和数据库中进行扩展兼容，以实现每个客户所提出的个性化需求。而随着时间的推移，个性化需求的复杂度在不断地提升，此时代码和数据的耦合则很容易引发衰退的问题；同时，还会导致性能、稳定性等方面出现相互影响的问题。
5.另外，不同租户的访问量、使用频率等参数各不相同代表着，不同租户实际资源的需求是不同的。传统的单实例多租户服务模式下，资源是耦合在一起的，每个租户无法独占其个性化需求的资源规格。即使采用多实例负载均衡的方式，本质上还是共享资源。将资源规格扩容到大于峰值的状态，则会导致存在资源浪费的缺陷。
6.此外，共享数据库多租户服务模式下，通常是在表中增加“租户id”以区分租户的数据，而这种方法存在数据安全的问题。一旦业务代码存在缺陷，容易导致数据越权以及数据误操作的问题发生。而且，系统一旦遭遇安全攻击，则会波及所有租户；同时，若一个租户产生数据库慢查询则会波及所有的租户。
7.有鉴于此，有必要对现有技术中的多租户服务实现方法予以改进，以解决上述问题。


技术实现要素：

8.本发明的目的在于解决现有技术多租户服务中一个应用实例提供给多个租户及多个租户共享一个数据库所存在的数据耦合导致的性能衰退、稳定性不足等问题，以及共享一个数据库所导致的数据不安全问题。
9.为实现上述目的，本发明提供了一种多租户服务的实现方法，包括：
10.获取多租户应用中单个租户所分别对应的租户信息，以基于所述租户信息确定目标租户；
11.创建多租户应用对应的镜像以作为多租户应用镜像，并从所述多租户应用镜像中提取目标租户的镜像以作为单租户应用镜像；
12.基于所述单租户应用镜像创建目标租户对应的单租户应用，将多租户应用中与目标租户匹配的租户数据同步至单租户应用，以通过同步后的单租户应用对目标租户独立提供租户服务。
13.作为本发明的进一步改进，在获取多租户应用中单个租户所分别对应的租户信息之前，还包括：
14.获取多租户应用对应的应用负载信息，以基于所述应用负载信息确定是否执行获取多租户应用中单个租户所分别对应的租户信息的步骤。
15.作为本发明的进一步改进，所述应用负载信息通过对多租户应用的不同系统参数给予预设权重系数并计算得分予以确定；
16.其中，所述系统参数包括：多租户应用对应的cpu使用率、内存使用率、磁盘io占用率、以及网络io占用率中的一种或者任意几种组合。
17.作为本发明的进一步改进，所述租户信息包括：单个租户分别对应的租户活跃度以及租户业务量；
18.其中，所述租户活跃度通过单个租户对应的api请求量予以确定，所述租户业务量通过单个租户对应的数据库数据量予以实现。
19.作为本发明的进一步改进，所述api请求量包括：单个租户对应的api请求量百分位、api请求耗时百分位、以及api请求响应数据量百分位中的一种或者任意几种组合；
20.所述租户业务量包括：单个租户对应的累计数据量百分位、以及sql慢查询次数百分位的平均数中的一种或者任意几种组合。
21.作为本发明的进一步改进，所述将多租户应用中与目标租户匹配的租户数据同步至单租户应用基于同步策略予以实现；
22.其中，所述同步策略包括：
23.基于多租户应用中是否产生与目标租户匹配的全量数据，以确定是否执行第一次同步策略所包含的同步步骤；
24.基于多租户应用中是否产生与目标租户匹配的增量数据，以确定是否执行第二次同步策略所包含的同步步骤；
25.基于多租户应用中是否产生与目标租户匹配的微量数据，以确定是否执行第三次同步策略所包含的同步步骤。
26.作为本发明的进一步改进，所述全量数据包括：多租户应用对应的数据库中与目标租户匹配的数据；
27.所述增量数据包括：上次执行同步步骤结束时间点与本次执行同步步骤开始时间点内多租户应用所产生的与目标租户匹配的操作记录；
28.所述微量数据包括：多租户应用中与目标租户匹配的api请求。
29.作为本发明的进一步改进所述第一次同步策略所包含的同步步骤，具体为：
30.建立多租户应用对应的数据库与单租户应用对应的数据库的主从关系，以将多租户应用对应的数据库中的数据同步至所述单租户应用对应的数据库；
31.在单租户应用对应的数据库中的数据与多租户应用对应的数据库中的数据一致
时，取消所述主从关系，同时仅保留单租户应用对应的数据库中与目标租户匹配的数据。
32.作为本发明的进一步改进，所述第二次同步策略所包含的同步步骤，包括：
33.重复执行对上次执行同步步骤结束时间点与本次执行同步步骤开始时间点内多租户应用所产生的与目标租户匹配的操作记录进行处理并导入单租户应用对应的数据库的步骤，直至所述上次执行同步步骤结束时间点与所述本次执行同步步骤开始时间点所形成的时间差小于预设时间。
34.作为本发明的进一步改进，所述第三次同步策略所包含的同步步骤，包括：
35.将多租户应用中与目标租户匹配的api请求拷贝至缓存队列，并将缓存队列中的api请求转发至单租户应用，以通过单租户应用依次响应所述与目标租户匹配的api请求，直至缓存队列为空时，切换网关路由以将与目标租户匹配的api请求直接转发至单租户应用。
36.作为本发明的进一步改进，所述通过同步后的单租户应用对目标租户独立提供租户服务之后，还包括：
37.将多租户应用中与目标租户匹配的租户数据删除。
38.基于相同发明思想，本发明还揭示了一种多租户服务的实现系统，包括：
39.确定模块，所述确定模块获取多租户应用中单个租户所分别对应的租户信息，以基于所述租户信息确定目标租户；
40.创建模块，所述创建模块创建多租户应用对应的镜像以作为多租户应用镜像，并从所述多租户应用镜像中提取目标租户的镜像以作为单租户应用镜像；
41.同步模块，所述同步模块基于所述单租户应用镜像创建目标租户对应的单租户应用，将多租户应用中与目标租户匹配的租户数据同步至单租户应用，以通过同步后的单租户应用对目标租户独立提供租户服务。
42.与现有技术相比，本发明的有益效果是：
43.为目标租户创建单个的单租户应用，以通过单租户应用对单个租户(即，目标租户)提供独立的租户服务，从而实现租户服务解耦的目的，保证单个租户不受其他租户的干扰，以保证了租户的体验度。单租户应用独立部署单租户数据库，用以存储目标租户对应的租户数据，从而实现将目标租户的租户数据从多租户应用中解耦的目的，以实现了数据的解耦，从而以解决了现有技术中所存在的代码和数据的耦合则很容易引发衰退的问题，并解决了代码和数据的耦合所导致的性能、稳定性等方面出现相互影响的问题。
附图说明
44.图1为本发明所示出的一种多租户服务的实现方法应用于计算机系统的拓扑图；
45.图2为本发明所示出的一种多租户服务的实现方法的步骤示意图；
46.图3为基于业务量与活跃度对租户进行划分的坐标示意图；
47.图4为同步策略的流程图；
48.图5为执行第一次同步策略所包含的同步步骤的具体步骤示意图；
49.图6为基于图1所示的一种多租户服务的实现系统的拓扑图；
50.图7为同步模块403的拓扑图；
51.图8为第一同步模块4031所包含逻辑的拓扑图；
52.图9为第二同步模块4032的拓扑图；
53.图10为第三同步模块4033的拓扑图。
具体实施方式
54.下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。
55.请参图1至图5所示，本发明示出了一种多租户服务的实现方法的一种具体实施方式。
56.本发明所揭示的一种多租户服务的实现方法的应用场景为多租户架构下实现单个租户独立提供租户服务的目的，用以解决现有技术中所存在的数据耦合导致的性能衰退、稳定性不足等问题，以及共享一个数据库所导致的数据不安全问题。该多租户服务的实现方法可以运行在kubernetes平台中，通过容器化的租户应用(例如，下文所揭示的多租户应用以及单租户应用)实现对租户提供租户服务的目的。该kubernetes还可以部署于其他平台中，该平台可以理解为由超融合一体机、计算机、服务器、数据中心或者便捷式终端通过虚拟化技术所形成的一种服务或者系统。申请人在本实施例中，将kubernetes100部署于计算机系统1000中为范例予以示范性说明。
57.参图2所示，在本实施方式中，一种多租户服务的实现方法包括以下步骤s1至步骤s3。
58.步骤s1、获取多租户应用中单个租户所分别对应的租户信息，以基于租户信息确定目标租户。
59.示例性地，参图1所示，一种计算机系统1000内部署kubernetes100，kubernetes100内部署多租户应用10与单租户应用20。多租户应用10内部署多租户微服务101与多租户数据库102，同样，单租户应用20内部署单租户微服务201与单租户数据库202。其中，多租户应用10是指用以对多个租户提供租户服务所形成的应用，多个租户共同通过一个多租户应用10提供租户服务；单租户应用20是指用以对单个租户(即，下述目标租户)独立提供租户服务所形成的应用。单个租户单独通过一个单租户应用独立提供租户服务。多租户应用10通过多租户微服务101实现对外提供多租户应用10中所包含的多个租户的租户服务的目的，通过多租户数据库102实现存储多租户应用10中所包含的多个租户的租户数据(此时的租户数据仅仅是指多租户应用10执行所接收的api请求对应的api服务所产生的数据)的目的。单租户应用20通过单租户微服务201实现对单租户应用20所对应的单个租户提供租户服务的目的，通过单租户数据库202实现存储单租户应用20所对应的单个租户的租户数据(此时的租户数据仅仅是指单租户应用20执行所揭示的api请求对应的api服务所产生的数据)的目的。多租户应用10与单租户应用20之间为相互独立的关系，互不干扰。
60.需要说明的是，kubernetes100是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。容器类似于虚拟机，但容器具有被放宽的隔离特点，可以在应用程序之间共享操作系统，因此容器是轻量级的。前述多租户应用10与单租户应用20均以容器形式封装。
61.具体地，首先，获取多租户应用10对应的应用负载信息，以基于应用负载信息确定
是否获取租户应用中单个租户所分别对应的租户信息，也可以理解为基于多租户应用10的应用负载信息确定是否执行后续分片步骤(即，执行获取多租户应用中单个租户所分别对应的租户信息，以基于租户信息确定目标租户及后续步骤)。应用负载信息是通过对多租户应用的不同系统参数给定预设权重系数并计算得分予以确定。其中，系统参数包括：预定时间内多租户应用10的cpu使用率、内存使用率、磁盘io占用率、以及网络io占用率中的一种或者任意几种组合。
62.例如，预定时间为1天，则获取多租户应用10近一天的cpu使用率(即，cpu_usage)、近一天的内存使用率(即，memory_usage)、近一天的磁盘io占用率(即，disk_io_usage)、以及近一天的网络io占用率(即，network_io_usage)四个指标的得分，得分范围为1～100。将每个指标的预设权重系数定义为25％，从而根据预设权重系数计算四个指标的总得分，从而确定多租户应用10的应用负载信息。若计算出的四个指标的总得分大于50，则判定多租户应用10的应用负载信息为负载压力较大，并触发执行后续分片步骤(即，确定出目标租户并为目标租户创建单租户应用20)。具体计算前述四个指标总得分的代码可参考下
63.表1所示：
[0064][0065]
表1应用负载信息的代码实例
[0066]
若多租户应用10近一天的cpu使用率的得分为80，近一天的内存使用率的得分为70，近一天的磁盘io占用率的得分为60，以及近一天的网络io占用率的得分为50。四个指标的总得分为：80*25％ 70*25％ 60*25％ 50*25％，即为60。60大于50，则判定多租户应用10的应用负载信息为负载压力较大，并触发执行后续分片步骤(即，下文所揭示的步骤s1至步骤s3所包含的步骤)。
[0067]
需要说明的是，预定时间可以是如前述所揭示的一天，也可以是其他时间，例如，一小时或者两天等等。具体的预定时间可以根据实际情况予以调整，若客户量较大(即，租户较多)，则可以预定较短的时间以得知多租户应用10的应用负载信息；若客户量较小(即，租户较少)，则可以预定较长的时间以得知多租户应用10的应用负载信息。预定时间并计算多租户应用10的得分的目的是为了得知多租户应用10的某一段时间或者当前状态下的应用负载信息(即，多租户应用10的负载压力)。当然，除了前述通过计算预定时间内不同系统参数的得分的方式以实现得知多租户应用10的应用负载信息的目的，从而确定是否执行后续步骤后续确定出目标租户并为目标租户创建单租户应用20的步骤之外，还可以是通过其他方式，例如，通过租户人工反馈多租户应用10出现页面加载较慢的情况，从而可以直接得出多租户应用10的负载压力较大，从而执行后续步骤s1至步骤s3所包含的步骤。当然还可以是其他任意方式，本实施例不对得出多租户应用10的负载压力的方式作具体限定。另外，为了维护某些客户(例如，优质客户)的用户体验，还可以直接为租户单独创建单个的单租户应用，从而通过单租户应用为租户提供租户服务，从而省略了在多租户应用的负载压力
较大时再创建单租户应用的步骤，同时还维护了客户的体验度。
[0068]
另外，通过获取多租户应用10的应用负载信息以确定是否执行后续步骤，从而保证在多租户应用10的负载压力较大时执行后续步骤，以防止出现负载压力不大而执行后续步骤所导致的资源浪费的情况。
[0069]
在确定多租户应用10的负载压力较大时，获取多租户应用10中单个租户的所分别对应的租户信息；其中，租户信息包括单个租户分别对应的租户活跃度以及租户业务量。租户活跃度通过单个租户对应的api请求量予以确定，租户业务量通过单个租户对应的数据库数据量予以确定。api请求量包括：单个租户对应的api请求量百分位、api请求耗时百分位、以及api请求响应数据量百分位中的一种或者任意几种组合。租户业务量包括：单个租户对应的累计数据量百分位、以及sql慢查询次数百分位中的一种或者任意几种组合。与上述应用负载信息同理，租户信息通过对单个租户对应的租户活跃度以及租户业务量分别基于权重系数并计算得分予以实现。
[0070]
参图3所示，图中所示出的租户a、租户b、租户c、以及d不仅仅代表一个租户，而是代表位于该象限租户的统称。横坐标代表业务量(即，前述租户业务量)，纵坐标代表活跃度(即，前述租户活跃度)，横坐标和纵坐标均自原点向外由低至高。第一象限的租户a所代表的一类租户活跃度高，而业务量低；第二象限的租户b所代表的一类租户活跃度低，业务量也低；第三象限的租户c所代表的一类租户活跃度低，而业务量高；第四象限的租户d所代表的一类租户活跃度高，业务量也高。因此，将租户活跃度与租户业务量均位于高范围的一类租户(即，第四象限的租户d)定义为优质客户，而此类客户往往对应用的稳定性、安全性均有高要求，因此有必要为此类客户提供更好地租户服务。将此类用户定义为目标租户，并为之创建单个租户应用以独立为目标租户提供租户服务，保证目标租户不受其他租户的干扰，从而在保证此类客户的体验度的同时，还实现了减轻多租户应用10的负载压力的目的。
[0071]
例如，获取多租户应用10中单个租户所分别对应的近30天日均api请求量百分位(即，api_request_count_percentile)、近7天日均api请求耗时百分位(即，api_request_latency_percentile)、以及近7天日均api请求响应数据量百分位(即，api_response_data_size_percentile)三个指标的得分。同时获取多租户应用10中单个租户所分别对应的累计数据量百分位(即，db_data_size_percentile)、以及近7天日均sql慢查询次数百分位(即，db_slow_query_percentile)两个指标的得分。总计得出单个租户所分别对应的五个指标的得分，将每个指标的权重系数定义为20％，以根据权重系数计算五个指标的总得分，从而根据得出的总得分确定单个租户所分别对应的租户信息。若计算出的五个指标的总得分大于50，则判定该租户为目标租户。前述百分位是指多租户应用10中租户的排名数，排名最高为100，排名最低为1。通过百分位确定出多租户应用10中的每个租户的排名，以最终确定出目标租户。具体计算前述五个指标总得分的代码可参考下表2所示：
[0072]
[0073][0074]
表2租户信息的代码实例
[0075]
若单个租户近30天日均api请求量百分位为50、近7天日均api请求耗时百分位为60、近7天日均api请求响应数据量百分位为70、累计数据量百分位为70、以及近7天日均sql慢查询次数百分位为80。五个指标的总得分为50*20％ 60*20％ 70*20％ 70*20％ 80*20％，即为66，66大于50，则判定该单个租户为目标租户。通过租户信息确定该租户是否为目标租户，也可以理解为通过租户信息确定该用户是否为第四象限的用户(即，优质用户)，从而实现后续为目标租户创建单租户应用，以通过单租户应用独立对单个用户提供租户服务的目的。前述步骤也可以理解为根据租户信息选择出优质客户，从而实现为优质客户创建单租户应用以对优质客户独立提供租户服务的目的，以最终达到保证优质客户体验度的同时，减轻多租户应用10的负载压力的目的。
[0076]
步骤s2、创建多租户应用对应的镜像以作为多租户应用镜像，并从多租户应用镜像中提取目标租户的镜像以作为单租户应用镜像。
[0077]
示例性地，参图1所示，镜像仓库30独立部署于多租户应用10与单租户应用20，用以存储镜像。镜像仓库30可以部署于kubernetes100内，也可以部署于计算机系统1000且逻辑上独立于kubernetes100，本实施例不对镜像仓库30的部署位置作具体限定。优选为，镜像仓库30部署于kubernetes100内并与多租户应用10与单租户应用20相互独立。
[0078]
具体地，基于多租户应用10以容器形式创建多租户应用镜像，并将多租户应用镜像上传至镜像仓库30中。从镜像仓库30中下载目标租户对应的镜像，以作为目标租户对应的单租户镜像。下载得到单租户镜像之后，启动容器应用，从而方便后续基于单租户镜像创建目标租户对应的独立提供租户服务的单租户应用。
[0079]
需要说明的是，创建多租户应用镜像的方式可以是现有技术中的任意一种方法，本实施例对此不作限定。同时，根据镜像创建单租户应用20，保证单租户应用20的资源规格与原有的规格一致，以防止出现资源规格与目标租户不匹配的情况；同时目标租户独占单租户应用20中资源规格，以实现独占个性化需求资源规格的目的，以最终实现了资源解耦的目的，从而解决了现有技术中将资源规格扩容到大于峰值的状态所存在的资源浪费的问题。
[0080]
步骤s3、基于单租户应用镜像创建目标租户对应的单租户应用，将多租户应用中与目标租户匹配的租户数据同步至单租户应用，以通过同步后的单租户应用独立提供租户服务。
[0081]
在下载得到目标租户对应的镜像以作为单租户应用镜像之后，基于单租户应用镜像创建目标租户对应的单租户应用20。此时，基于单租户应用镜像所创建的单租户应用20中不存在任何与目标租户匹配的数据，也不能够对目标租户提供租户服务，仅仅是一个应用。而在后续执行租户数据同步并配置网关切换流量转发规则的步骤之后，才能形成独立对目标租户提供租户服务的单租户应用20。
[0082]
示例性地，创建单租户应用20之后，将多租户应用10中与目标租户匹配的租户数据同步至单租户应用20，从而通过同步后的单租户应用20独立对目标租户提供租户服务。其中，将多租户应用中与目标租户匹配的租户数据同步至单租户应用基于同步策略予以实现。同步策略包括：基于多租户应用10中是否产生与目标租户匹配的全量数据，以确定是否执行第一次同步步骤所包含的同步策略；基于多租户应用中是否产生与目标租户匹配的增量数据，以确定是否执行第二次同步策略所包含的同步步骤；基于多租户应用10中是否产生与目标租户匹配的微量数据，以确定是否执行第三次同步策略所包含的同步步骤。
[0083]
参图4所示，同步策略具体包括以下步骤s31至步骤s36。
[0084]
步骤s31、判断多租户应用中是否产生与目标租户匹配的增量数据；若是，则执行步骤s32；若否，则执行步骤s33。
[0085]
步骤s32、对多租户应用对应的数据库中的与目标租户匹配的全量数据执行第一次同步策略所包含的同步步骤。
[0086]
步骤s33、判断多租户应用中是否产生与目标租户匹配的增量数据；若是，则执行步骤s34；若否，则执行步骤s35。
[0087]
步骤s34、对多租户应用中所产生的与目标租户匹配的增量数据执行第二次同步策略所包含的同步步骤。
[0088]
步骤s35、判断多租户应用中是否产生与目标租户匹配的微量数据；若是，则执行步骤s36；若否，则执行步骤s37。
[0089]
步骤s36、对多租户应用中是否产生与目标租户匹配的微量数据执行第三次同步策略所包含的同步步骤。
[0090]
步骤s37、租户数据同步完成，通过同步完成后的单租户应用独立对目标租户提供租户服务。
[0091]
需要说明的是，全量数据是指多租户应用10对应的数据库(即，多租户数据库102)中与目标租户匹配的数据，在第一同步时以全量的形式同步。增量数据是指上次执行同步步骤结束时间点与本次执行同步步骤开始时间点内多租户应用10所产生的与目标租户匹配的操作记录。微量数据是指多租户应用10中与目标租户匹配的api请求。前述三次同步策略(即，第一次同步策略、第二次同步策略以及第三次同步策略)分别基于三次判断(即，第一次判断是否存在全量数据、第二次判断是否存在增量数据以及第三次判断是否存在微量数据)从而确定是否执行三次策略所包含的同步步骤，因此可能存在仅执行一次同步策略所包含的同步步骤(例如，仅执行第一次同步策略所包含的同步步骤，或者仅执行第二次同步策略所包含的同步步骤，或者仅执行第三次同步策略所包含的同步步骤)，也可能存在执行两次同步策略所包含的步骤(例如，执行第一次同步策略所包含的同步步骤与第二次同步策略所包含的同步步骤等等)，还可以是执行三次同步策略所包含的步骤，具体的执行情况根据前述三次判断予以具体限定。
[0092]
参图5所示，前述对多租户应用对应的数据库中的与目标租户匹配的全量数据执行第一次同步策略所包含的同步步骤具体包括以下步骤s51至步骤s52。
[0093]
步骤s51、建立多租户应用对应的数据库与单租户应用对应的数据库的主从关系，以将多租户应用对应的数据库中的数据同步至单租户应用对应的数据库。
[0094]
具体地，建立多租户应用10对应的数据库(即，图1中所示出的多租户数据库102)
与单租户应用20对应的数据库(即，图1中所示出的单租户数据库202)的主从关系。建立主从关系之后，将多租户数据库102中的数据同步至单租户数据库202，从而保证两者(即，前述多租户数据库102与单租户数据库202)所存储数据的一致性。
[0095]
需要说明的是，数据库的主从关系是指主数据库与从数据库所形成的关系。主从复制，以建立一个与主数据库完全一样的数据库环境，并将其(即，前述完全一个的数据库环境)称之为从数据库。主数据库与从数据库之间通过日志同步机制进行数据的同步。前述多租户应用10对应的数据(即，图1中所示出的多租户数据库102)即为主数据库，单租户应用20对应的数据库(即，图1中所示出的单租户数据库202)即为从数据库。建立主从关系的方式可以是单租户应用20对应的数据库以节点方式接入多租户应用10对应的数据库，或者单租户应用20对应的数据库直接接入多租户应用10对应的数据库，又或者以容器方式接入，本实施例对建立主从关系的方式不作具体限定。
[0096]
另外，前述将多租户数据库102中的数据同步至单租户数据库202的方式可以是从数据库(即，单租户数据库202)主动从主数据库(即，多租户数据库102)中同步主数据库的数据通过日志同步机制以实现数据同步的目的，也可以是主数据库主动将自身(即，主数据库)的数据通过日志同步机制同步至从数据库以实现数据同步的目的。本实施例不对具体的同步方式作限定。
[0097]
步骤s52、在单租户应用对应的数据库中的数据与多租户应用对应的数据库中的数据一致时，取消主从关系，同时仅保留单租户应用对应的数据库中与目标租户匹配的数据。
[0098]
具体地，在单租户应用20对应的数据库(即，图1中所示出的单租户数据库202)中的数据与多租户应用10对应的数据库(即，图1中所示出的多租户数据库102)中的数据一致时(也可以理解为，单租户数据库202中的数据与多租户数据库102中的数据相同)，取消多租户数据库102与单租户数据库202之间所形成的主从关系。此时单租户数据库202存储与多租户数据库102中一致的数据，即，单租户数据库202中不仅仅存储与目标租户匹配的数据。因此对单租户应用20对应的数据库(即，单租户数据库202)中与目标租户不匹配的数据执行删除操作，以删除单租户数据库202中与目标租户不匹配的数据，从而仅仅保留与目标租户匹配的数据，以对不必要的数据进行删除，从而实现了节省单租户数据库202的空间的目的。
[0099]
前述基于多租户应用中是否产生与目标租户匹配的增量数据，以确定是否执行第二次同步策略所包含的同步步骤，具体为：重复执行对上次执行同步步骤结束时间点与本次执行同步步骤开始时间点内多租户应用所产生的与目标租户匹配的操作记录进行处理并导入单租户应用对应的数据库的步骤，直至上次执行同步步骤结束时间点与本次执行同步步骤开始时间点所形成的时间差小于预设时间。
[0100]
其中，可以将操作记录理解为binlog，binlog是指用于记录用户对数据库操作的sql语句信息，包括数据表和内容的增加操作、删除操作以及修改操作，而查询操作则不会被记录。具体截取操作记录的代码可参考下表3所示：
[0101][0102][0103]
表3截取操作记录的代码实例
[0104]
例如，将第一次同步步骤结束时间点(即为，单租户数据库202中的数据与多租户数据库102中的数据一致时所对应的时间点)记为t1，将本次同步步骤开始时间点记为t2，则执行对t1～t2时间段内多租户应10所产生的与目标租户匹配的操作记录进行处理并导入单租户应用20对应的数据库的步骤。具体为：对t1～t2时间段内多租户应10所产生的与目标租户匹配的操作记录(即，binlog)进行解析，并将解析后的操作记录转化为dml数据库操作语言，在单租户应用20中重放dml导入数据，同时记录导入完成的时间为t3。然后，执行对t2～t3时间段内多租户应10所产生的与目标租户匹配的操作记录进行处理并导入单租户应用20对应的数据库的步骤，并记录导入完成的时间为t4。依次类推，执行对tn-1～tn时间段内多租户应10所产生的与目标租户匹配的操作记录进行处理并导入单租户应用20对应的数据库的步骤。直至tn-1～tn时间段(时间差)小于预设时间。将预设时间定义为1秒，则直至tn-1～tn时间段小于1秒停止，至此，第二次同步策略所包含的步骤执行结束。
[0105]
需要说明的是，前述将预设时间定义为1秒，也可以是定义为其他的时间长度。而定义为1秒则是基于业内通用的体验要求“2-5-8原则”。“2-5-8原则”具体为：响应时间的2-5-8原则，若用户能够在2秒内得到响应，则用户会感觉系统的响应速度很快。若用户在2秒～5秒内得到响应，则用户会感觉系统的响应速度适中。若用户在5秒～8秒内得到响应，则用户会感觉系统的响应速度较慢，但是可以接受。若用户在8秒之后仍然无法得到响应时，则用户会感觉系统的响应速度很慢，或者认为系统已经丢失响应，而选择离开次web站点，或者发起二次请求。基于上述“2-5-8原则”前述范例将预设时间定义为1秒，同样可以定义为其他的时间长度，当然，预设时间优选为1秒。
[0106]
另外，在前述对操作记录进行处理之前还对操作记录执行同步步骤，以将操作记录同步至单租户应用20，从而实现在单租户应用20保留操作记录完整性的目的。
[0107]
前述基于多租户应用中是否产生与目标租户匹配的微量数据，以确定是否执行第三次同步策略所包含的同步步骤，具体为：将多租户应用10中与目标租户匹配的api请求拷贝至缓存队列，并将缓存队列中的api请求转发至单租户应用20，以通过单租户应用依次响应与目标租户匹配的api请求，直至缓存队列为空时，切换网关路由以将与目标租户匹配的api请求直接转发至单租户应用。
[0108]
具体地，开启网关api请求镜像复制功能，将多租户应用10中与目标租户匹配的api请求拷贝至缓存队列中。同时，api重放监听缓存队列以将缓存队列中的api请求转发至单租户应用20。当缓存队列为空时(即，缓存队列中的api请求均已转发)，则切断网关路由从而将目标租户所发出的api请求直接转发至单租户应用20，而不用开启前述镜像复制功
能。此时，将多租户应用中与目标租户匹配的租户数据同步至单租户应用的步骤执行结束，从而可以通过同步后(即，租户数据同步后)的单租户应用20对目标租户独立提供租户服务。其中，租户数据可以理解为前述全量数据、增量数据以及微量数据的统称。
[0109]
通过前述基于同步策略将多租户应用中与目标租户匹配的租户数据同步至独立提供租户服务的单租户应用，解决了现有技术中所存在的停服完成数据迁移所导致的用户体验度差的问题，保证了不断有流量的情况下不停服同时完成租户数据的同步，从而实现了用户无感知的目的，以保证了用户的体验。
[0110]
在通过同步后的单租户应用对目标租户独立提供租户服务之后，将多租户应用10中与目标租户匹配的租户数据删除，从而实现节省多租户应用10内资源的目的。
[0111]
本发明所示出的一种多租户服务的实现方法，通过获取多租户应用10的应用负载信息以判断当前时间多租户应用10是否负载压力较大。在多租户应用10负载压力较大时，获取多租户应用10中单个租户所分别对应的租户信息，从而选择出目标租户。可以将目标租户理解为优质客户，即，租户服务需求高的客户。目标客户可以若干个，可以是通过前述租户活跃度与租户业务量予以确定，也可以是其他方式予以确定，具体参前文所述，在此不再赘述。
[0112]
在确定出目标客户之后，通过镜像方式为目标租户创建单个的单租户应用20，并将目标租户的租户数据同步至单租户应用20，以通过同步后的单租户应用对目标租户独立提供租户服务。相比与现有技术中的多个租户对应一个多租户应用10以通过多租户应用10为多个租户提供租户服务，本发明为目标租户创建单个的单租户应用20，以通过单租户应用20对单个租户(即，目标租户)提供独立的租户服务，从而实现租户服务解耦的目的，保证单个租户不受其他租户的干扰，以保证了租户的体验度。单租户应用20独立部署单租户数据库202，用以存储目标租户对应的租户数据，从而实现将目标租户的租户数据从多租户应用10中解耦的目的，以实现了数据的解耦，以解决了现有技术中所存在的代码和数据的耦合则很容易引发衰退的问题，并解决了代码和数据的耦合所导致的性能、稳定性等方面出现相互影响的问题。通过租户信息确定出目标租户，从而为目标租户单独创建目标租户对应的单租户应用20以独立为目标租户提供租户服务，同时目标租户独占单租户应用20所包含的资源。租户信息代表着租户的需求，不同需求的租户所对应的实际资源的需求也是不同的，而现有技术中，资源耦合导致每个租户无法独占其个性化需求的资源规格。而即使采用多实例负载均衡的方式，本质上还是共享资源，共享资源所存在的问题是：将资源规格扩容到大于峰值的状态以尽可能满足每个租户，此时必然存在资源浪费的问题。因此本发明通过对目标租户创建单租户应用20，以为目标租户提供单独的资源规格，以实现目标租户对资源规格独占，从而实现资源解耦的目的，以最终解决了现有技术中共享资源所存在的资源浪费的问题。另外，将目标租户的租户数据独立存储于单租户应用20中，以保证了租户数据的安全性，解决了现有技术中多租户服务模式下的共享数据库所存在的数据安全的问题。综上，通过本发明所示出的多租户服务的实现方法，实现了目标租户(即，优质客户)的实现，并为其提供稳定性、安全性双重兼顾的独立租户服务。同时，在目标租户对应的单租户应用20的独立提供租户服务的运行模式下，还实现了减轻多租户应用10的负载压力的目的。
[0113]
基于相同发明思想，本实施例还揭示了一种多租户服务的实现系统(简称“实现系
统”，即，图6中所示出的实现系统400)。参图6所示，实现系统400包括：确定模块401、创建模块402以及同步模块403。
[0114]
参图6所示，实现系统400是通过确定模块401、创建模块402以及同步模块403所对应包含的计算机代码整体构成的系统，不仅仅是位置上的部署，也可以是逻辑上的构成。至于三个模块(即，确定模块401、创建模块402以及同步模块403)的部署位置可以是以整体方式部署于kubernetes100，或者部署于计算机系统1000且逻辑上独立于kubernetes100，也可以是分别独立部署于kubernetes100与计算机系统1000(例如，确定模块401部署于kubernetes100内侧，创建模块402以及同步模块403均部署于kubernetes100外侧与计算机系统1000内侧等等)，而三者整体构成了实现系统400，本实施例不对具体的部署方式予以限定。
[0115]
确认模块401获取多租户应用中单个租户所分别对应的租户信息，以基于租户信息确定目标租户。
[0116]
具体地，确认模块获取多租户应用10对应的应用负载信息，以基于应用负载信息确定是否获取租户应用中单个租户所分别对应的租户信息，也可以理解为基于多租户应用10的应用负载信息确定是否执行后续分片步骤。应用负载信息是通过对多租户应用的不同系统参数给予预设权重系数并计算得分予以确定。其中，系统参数包括：预定时间内多租户应用的cpu使用率、内存使用率、磁盘io占用率、以及网络io占用率中的一种或者任意几种组合。通过获取多租户应用10的应用负载信息以确定是否执行后续步骤，从而保证在多租户应用10的负载压力较大时执行后续步骤，以防止出现负载压力不大而执行后续步骤所导致的资源浪费的情况。在确定多租户应用10的负载压力较大时，获取多租户应用10中单个租户的所分别对应的租户信息，以根据租户信息确定目标租户。通过租户信息确定该租户是否为目标租户，也可以理解为通过租户信息确定该用户是否为第四象限的用户(即，优质用户)，从而实现后续为目标租户创建单租户应用，以通过单租户应用独立对单个用户提供租户服务的目的。
[0117]
创建模块402创建多租户应用对应的镜像以作为多租户应用镜像，并从多租户应用镜像中提取目标租户的镜像以作为单租户应用镜像。
[0118]
具体地，基于多租户应用10以容器形式创建多租户应用镜像，并将多租户应用镜像上传至镜像仓库30中。从镜像仓库30中下载目标租户对应的镜像，以作为目标租户对应的单租户镜像。下载得到单租户镜像之后，启动容器应用，从而方便后续基于单租户镜像创建目标租户对应的独立提供租户服务的单租户应用。
[0119]
同步模块403基于单租户应用镜像创建目标租户对应的单租户应用，将多租户应用中与目标租户匹配的租户数据同步至单租户应用，以通过同步后的单租户应用独立提供租户服务。
[0120]
具体地，在下载得到目标租户对应的镜像以作为单租户应用镜像之后，基于单租户应用镜像创建目标租户对应的单租户应用20。此时，基于单租户应用镜像所创建的单租户应用20中不存在任何与目标租户有关联的数据，也不能够对目标租户提供租户服务，仅仅是一个应用。创建单租户应用20之后，将多租户应用10中与目标租户匹配的租户数据同步至单租户应用20，从而通过同步后的单租户应用20独立对目标租户提供租户服务。
[0121]
参图7所示，同步模块403包括：第一同步模块4031、第二同步模块4032以及第三同
步模块4033。其中，第一同步模块4031基于多租户应用10中是否产生与目标租户匹配的全量数据，以确定是否执行第一次同步步骤所包含的同步策略。第二同步模块4032基于多租户应用10中是否产生与目标租户匹配的增量数据，以确定是否执行第二次同步策略所包含的同步步骤。第三同步模块4033基于多租户应用10中是否产生与目标租户匹配的微量数据，以确定是否执行第三次同步策略所包含的同步步骤。第一同步模块4031、第二同步模块4032以及第三同步模块4033均是基于判断予以具体限定，因此可能仅执行第一同步模块4031所包含的逻辑或者第二同步模块4032所包含的逻辑或者第三同步模块4033所包含的逻辑，也可以是执行其中任意两个同步模块所包含的逻辑，还可以是执行三个同步模块所包含的逻辑，具体的执行情况根据三次判断予以具体限定。
[0122]
参图8所示，第一同步模块4031建立多租户数据库102与单租户数据库202的主从关系，以将多租户数据库102中的数据同步至单租户数据库202；在单租户数据库202中的数据与多租户数据库102中的数据一致时，取消主从关系(即，多租户数据库102与单租户数据库202相互独立)，同时仅保留单租户数据库202中与目标租户匹配的数据。
[0123]
参图9所示，第二同步模块4032部署日志同步模块40321、日志解析模块40322以及数据重放模块40323。日志同步模块40321将多租户应用10中与目标租户匹配的增量数据同步至单租户应用20，并将增量数据发送至、日志解析模块40322，从而是实现在单租户应用20中保留操作记录完整性的目的。日志解析模块40322对增量数据进行解析并将解析后的操作记录转化为dml数据库操作语言，然后将转化后的操作记录发送至数据重放模块40323。数据重放模块40323基于转化后的操作记录向单租户数据库202中进行数据的修改(例如，增加数据、删除数据、以及修改数据)。第二同步模块4032还会对上次执行同步步骤结束时间点与本次执行同步步骤开始时间点所形成的时间差进行记录，若时间差大于预设时间，则重复执行日志同步模块40321、日志解析模块40322以及数据重放模块40323所包含的逻辑，直至上次执行同步步骤结束时间点与本次执行同步步骤开始时间点所形成的时间差小于预设时间，停止。
[0124]
参图10所示，第三同步模块4033部署缓存队列40331以及api重放模块40332。通过api网关中的路由将多租户应用10中与目标租户匹配的api请求拷贝至缓存队列40331，并依次转发至api重放模块40332。api重放模块40332监听缓存队列40331，并将缓存队列40331api请求发送至单租户应用20，以通过单租户应用依次响应与目标租户匹配的api请求，直至缓存队列为空时，切换网关路由以将与目标租户匹配的api请求直接转发至单租户应用。
[0125]
上文所揭示的实现系统400与前述一种多租户服务的实现方法基于相同发明思想，具体实施方式可参前文所述，在此不再赘述。
[0126]
另外，前述一种多租户服务的实现方法中的步骤s1所含逻辑由实现系统400中确定模块401予以实现，前述一种多租户服务的实现方法中的步骤s2所含逻辑由实现系统400中创建模块402予以实现，前述一种多租户服务的实现方法中的步骤s3所含逻辑由实现系统400中同步模块403予以实现。
[0127]
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
[0128]
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
[0129]
此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。