一种基于SaaS的多租户数据处理方法和装置

摘要

本发明公开了一种基于SaaS的多租户数据处理方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；基于业务数据及其对应的业务场景构建SaaS数据库；响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户。该实施方式实现了多租户间的服务提供方信息的统一管理，满足了租户之间想实现部分数据共享的需求，降低了应用程序的开发和可扩展性成本，提高了数据利用率，提升了用户体验。

说明书

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于SaaS的多租户数据处理方法和装置。

背景技术

多租户技术(或称多重租赁技术，简称SaaS)，是一种软件架构技术，是实现如何在多用户环境下共用相同的系统或程序组件，并且可确保各用户间数据的隔离性。在当下云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍可以保障客户的数据隔离。

现有技术中至少存在如下问题：

现有的多租户数据处理方法中，由于数据库隔离导致多租户间的服务提供方信息难以统一管理，且无法满足租户之间想实现部分数据共享的需求，应用程序的开发和可扩展性成本较高，数据利用率较低，用户体验较差的技术问题。

发明内容

有鉴于此，本发明实施例提供一种基于SaaS的多租户数据处理方法和装置，能够实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验。

为实现上述目的，根据本发明实施例的第一方面，提供了一种基于SaaS的多租户数据处理方法，包括：

获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；

基于业务数据及其对应的业务场景构建SaaS数据库；

响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；

其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户。

进一步地，获取多租户对应的服务提供方的业务数据，根据业务数据的数据类型划分业务场景的步骤还包括：

根据多租户与其对应的服务提供方之间的历史交互数据，确定服务提供方的业务数据；

获取业务数据，并根据业务数据对应的业务类型划分业务场景，其中，业务场景包括：注册场景、审核场景、登录场景、信息管理场景。

进一步地，在获取业务数据的步骤之后，方法还包括：

对业务数据进行汇总、去重处理。

进一步地，在根据业务数据对应的业务类型划分业务场景的步骤之后，方法还包括：

获取多租户的业务需求对应的业务数据，并根据业务需求对应的业务数据对业务场景进行更新。

进一步地，基于业务数据及其对应的业务场景构建SaaS数据库的步骤还包括：

获取业务数据对应的服务提供方信息；

基于服务提供方信息、业务数据及其对应的业务场景构建连接服务提供方的SaaS服务平台，SaaS服务平台包括消息中间件和SaaS数据库。

进一步地，在基于业务数据及其对应的业务场景构建SaaS数据库的步骤之后，方法还包括：

获取多租户与其对应的服务提供方之间的交互数据，根据交互数据对业务数据进行更新，并根据更新后的业务数据对SaaS数据库内的相应数据进行更新。

进一步地，获取多租户与其对应的服务提供方之间的交互数据的步骤包括：

监控多租户与服务提供方进行业务交互的业务节点；针对各业务节点分别建立业务消息队列；

将业务节点处产生的交互数据发送至业务消息队列，从业务消息队列中获取交互数据。

进一步地，方法还包括：

监控业务消息队列对应的消息日志，

判断消息日志是否为信息发送失败日志；

若是，将信息发送失败日志所指示的交互数据存储至SaaS数据库。

进一步地，将信息发送失败日志所指示的交互数据存储至SaaS数据库，还包括：

设置调度周期，根据调度周期将信息发送失败日志所指示的交互数据存储至SaaS数据库。

进一步地，数据存储方式包括：

以独立数据库的方式进行数据存储，以共享数据库、隔离数据架构的方式进行数据存储，以共享数据库、共享数据架构的方式进行数据存储。

进一步地，方法还包括：

根据多租户对应的租赁状况、租赁需求对各租户对应的数据存储方式进行调整。

根据本发明实施例的第二方面，提供了一种基于SaaS的多租户数据处理装置，包括：

业务数据获取模块，用于获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；

数据库构建模块，用于基于业务数据及其对应的业务场景构建SaaS数据库；

数据处理模块，用于响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；

其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户。

进一步地，数据库构建模块还用于：

获取业务数据对应的服务提供方信息；

基于服务提供方信息、业务数据及其对应的业务场景构建连接服务提供方的SaaS服务平台，SaaS服务平台包括消息中间件和SaaS数据库。

根据本发明实施例的第三方面，提供了一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如上述任一种基于SaaS的多租户数据处理方法。

根据本发明实施例的第四方面，提供了一种计算机可读介质，其上存储有计算机程序，该程序被处理器执行时实现如上述任一种基于SaaS的多租户数据处理方法。

上述发明中的一个实施例具有如下优点或有益效果：因为采用获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；基于业务数据及其对应的业务场景构建SaaS数据库；响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户的技术手段，所以克服了现有的多租户数据处理方法中存在的多租户间的服务提供方信息难以统一管理，且无法满足租户之间想实现部分数据共享的需求，应用程序的开发和可扩展性成本较高，数据利用率较低，用户体验较差的技术问题，进而达到实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验的技术效果。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明第一实施例提供的基于SaaS的多租户数据处理方法的主要流程的示意图；

图2是根据本发明第二实施例提供的基于SaaS的多租户数据处理方法的主要流程的示意图；

图3是根据本发明实施例提供的基于SaaS的多租户数据处理装置的主要模块的示意图；

图4是本发明实施例可以应用于其中的示例性系统架构图；

图5是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明第一实施例提供的基于SaaS的多租户数据处理方法的主要流程的示意图；如图1所示，本发明实施例提供的基于SaaS的多租户数据处理方法主要包括：

步骤S101，获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个。

由于多租户之间存在实现部分数据共享的需求，通过上述设置，从多租户的服务提供方处获取该部分可以进行共享的业务数据，并根据业务数据划分业务场景，有利于后续通过对该部分业务数据进行整合、处理，构建共享数据库的方式，不仅可以满足租户之间想实现部分数据共享的需求，还能够实现多租户间的服务提供方信息的统一管理。

具体地，根据本发明实施例，上述获取多租户对应的服务提供方的业务数据，根据业务数据的数据类型划分业务场景的步骤还包括：

根据多租户与其对应的服务提供方之间的历史交互数据，确定服务提供方的业务数据；

获取业务数据，并根据业务数据对应的业务类型划分业务场景，其中，业务场景包括：注册场景、审核场景、登录场景、信息管理场景。

通过上述设置，根据分别根据各租户与其对应的服务提供方之间的历史交互数据，能够更精确地确定多租户想要共享的业务数据，进而提升业务数据的数据利用率；再根据上述业务数据的类型划分业务场景，有助于实现该部分业务数据的查询效率。

进一步地，根据本发明实施例，在获取业务数据的步骤之后，上述方法还包括：

对业务数据进行汇总、去重处理。

通过上述设置，将各租户对应的服务提供方的业务数据进行整合之后，进行去重处理，进一步简化了后续划分业务场景的流程。

优选地，根据本发明实施例，在根据业务数据对应的业务类型划分业务场景的步骤之后，上述方法还包括：

获取多租户的业务需求对应的业务数据，并根据业务需求对应的业务数据对业务场景进行更新。

通过上述设置，结合租户的实际需求，进一步拓展所要共享的业务数据的覆盖范围，进一步提升了用户体验。

步骤S102，基于业务数据及其对应的业务场景构建SaaS数据库。

具体地，根据本发明实施例，上述基于业务数据及其对应的业务场景构建SaaS数据库的步骤还包括：

获取业务数据对应的服务提供方信息；

基于服务提供方信息、业务数据及其对应的业务场景构建连接服务提供方的SaaS服务平台，SaaS服务平台包括消息中间件和SaaS数据库。

通过上述设置，构建连接上述至少一个服务提供方的SaaS服务平台，构建消息中间件(主要是消息队列，用于数据传输)和SaaS数据库(用于存储上述确定的业务数据，即租户之间想要共享的数据)，实现服务提供方与各环境部署的租户(采取不同的数据存储方式的租户)之间的数据交互，达到了数据共享的目的，降低了应用程序的开发和可扩展性成本，提高了数据利用率，提升了用户体验。

优选地，根据本发明实施例，在基于业务数据及其对应的业务场景构建SaaS数据库的步骤之后，上述方法还包括：

获取多租户与其对应的服务提供方之间的交互数据，根据交互数据对业务数据进行更新，并根据更新后的业务数据对SaaS数据库内的相应数据进行更新。

在SaaS服务平台搭建完成之后，实时(或者周期性)地监控多租户与其对应的服务提供方之间的交互数据，并对数据库中的相应数据进行更新，以保证SaaS服务平台与各租户之间数据保持一致性。

进一步地，根据本发明实施例，上述获取多租户与其对应的服务提供方之间的交互数据的步骤包括：

监控多租户与服务提供方进行业务交互的业务节点；针对各业务节点分别建立业务消息队列；

将业务节点处产生的交互数据发送至业务消息队列，从业务消息队列中获取交互数据。

通过上述设置，建立了消息同步机制，实现了平台与不同租户之间的数据同步与交互，保证了服务提供方对应的租户在SaaS服务平台进行注册、信息管理等业务操作时，保证SaaS服务平台与各租户之间数据一致性。

优选地，根据本发明实施例，上述方法还包括：

监控业务消息队列对应的消息日志，

判断消息日志是否为信息发送失败日志；

若是，将信息发送失败日志所指示的交互数据存储至SaaS数据库。

通过上述设置，建立了定时巡检和补全机制，通过定时巡检对业务节点进行监控，再通过补全机制获取业务节点处产生的交互数据，并将该交互数据存储至数据库中，进一步保证了数据一致性。

示例性地，根据本发明实施例，上述将信息发送失败日志所指示的交互数据存储至SaaS数据库，还包括：

设置调度周期，根据调度周期将信息发送失败日志所指示的交互数据存储至SaaS数据库。

根据本发明实施例的一具体实施方式，可以通过定时(例如每半小时)启动数据补全服务，扫描数据库中的信息发送失败日志对应的交互数据，并将该交互数据发送至相应的租户。

步骤S103，响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户。

其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户。

构建好共享数据库(即上述SaaS数据库)之后，根据租户发起的数据获取请求，可直接从共享数据库中获取相应的目标数据。通过上述设置，实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验的技术效果。

进一步地，根据本发明实施例，上述数据存储方式包括：

以独立数据库的方式进行数据存储，以共享数据库、隔离数据架构的方式进行数据存储，以共享数据库、共享数据架构的方式进行数据存储。

其中，以独立数据库的方式进行数据存储是指，一个租户对应一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本较高。

以共享数据库、隔离数据架构的方式进行数据存储，是指多个或所有租户共享Database(数据库)，但是每个租户一个Schema(也可叫做一个user)。为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多的租户数量。

以共享数据库、共享数据架构的方式进行数据存储，是指租户共享同一个Database、同一个Schema，但在表中增加TenantID多租户的数据字段。这是共享程度最高、隔离级别最低的数据存储方式，但是所需费用最低。

优选地，根据本发明实施例，上述方法还包括：

根据多租户对应的租赁状况、租赁需求对各租户对应的数据存储方式进行调整。

其中，租赁状况包括租户信用信息、付款信息等描述租户当期那租赁状况的信息；租赁需求主要指租户当前对存储空间的需求。

通过上述设置，根据租户信用信息、付款信息、存储空间等可以调整各租户对应的数据存储方式，即实现租户在三种数据存储方式之间的切换，进一步提升了用户体验。

根据本发明实施例的技术方案，因为采用获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；基于业务数据及其对应的业务场景构建SaaS数据库；响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户的技术手段，所以克服了现有的多租户数据处理方法中存在的多租户间的服务提供方信息难以统一管理，且无法满足租户之间想实现部分数据共享的需求，应用程序的开发和可扩展性成本较高，数据利用率较低，用户体验较差的技术问题，进而达到实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验的技术效果。

图2是根据本发明第二实施例提供的基于SaaS的多租户数据处理方法的主要流程的示意图；如图2所示，本发明实施例提供的基于SaaS的多租户数据处理方法主要包括：

步骤S201，根据多租户与其对应的服务提供方之间的历史交互数据，确定服务提供方的业务数据，对业务数据进行汇总、去重处理；其中，服务提供方的数量为至少一个。

通过上述设置，根据分别根据各租户与其对应的服务提供方之间的历史交互数据，能够更精确地确定多租户想要共享的业务数据，进而提升业务数据的数据利用率。

进一步地，根据本发明实施例的一具体实施方式，上述对业务数据进行汇总、去重处理的步骤还包括：

整合各租户现有供应商的全量关键数据(包括现有各租户环境下的存量供应商数据，关键数据例如供应商企业基础数据，供应商服务区域数据，供应商入库相关数据，供应商联系人数据，供应商账户信息数据，供应商用户数据等)，并在供应商平台(即后续构建的连接服务提供方的SaaS服务平台)对应的SaaS数据库进行数据初始化(界定数据采集边界(界定边界时需要注意各租户下剔除重复数据，保证采集数据的有效性；同时，界定采集条件，根据条件筛选对应数据)；)采集并整合各租户存量供应商数据；供应商平台与各租户间数据库结构同步(利用otter工具同步供应商平台与各租户间数据库结构)；供应商平台数据初始化(将整合后的全量供应商数据刷入供应商平台数据库)；同步平台与各租户间的数据，使其保持一致性)，由于供应商平台应该作为数据统一中转交互的中台，因此SaaS服务平台上线时，需要保证SaaS服务平台的数据是各租户环境数据总和(去重)，还需要对各租户下的存量数据进行数据整合，并将整合后的数据进行去重之后，全量初始化到供应商平台(SaaS服务平台)的数据库中，以保证平台上线时，各租户环境下供应商对应的数据保持一致。

具体地，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户。

根据本发明实施例，上述数据存储方式包括：

以独立数据库的方式进行数据存储，以共享数据库、隔离数据架构的方式进行数据存储，以共享数据库、共享数据架构的方式进行数据存储。其中，以独立数据库的方式进行数据存储的租户数据隔离级别最高，安全性最好，但成本较高。以共享数据库、隔离数据架构的方式进行数据存储的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多的租户数量。以共享数据库、共享数据架构的方式进行数据存储是共享程度最高、隔离级别最低的数据存储方式，但是所需费用最低。

进一步地，根据本发明实施例，上述方法还包括：

根据多租户对应的租赁状况、租赁需求对各租户对应的数据存储方式进行调整。

其中，租赁状况包括租户信用信息、付款信息等描述租户当期那租赁状况的信息；租赁需求主要指租户当前对存储空间的需求。

通过上述设置，根据租户信用信息、付款信息、存储空间等可以调整各租户对应的数据存储方式，即实现租户在三种数据存储方式之间的切换，进一步提升了用户体验。

步骤S202，根据业务数据划分业务场景；其中，业务场景包括：注册场景、审核场景、登录场景、信息管理场景。

具体地，根据本发明实施例，针对不同环境租户(即采取不同数据存储方式的租户)间需要共享的供应商(即服务提供方)相关数据，抽象供应商对应的相关业务场景，抽象的业务场景主要是在采购业务中，高频操作，且未涉及供应商与各租户之间相对独立的业务交互，例如，供应商注册，供应商注册审核，供应商登录，供应商基本信息管理，供应商信息变更等供应商常用的业务场景，有助于降低应用程序的开发和可扩展性成本，提高数据利用率。

通过上述设置，根据业务数据划分业务场景，有利于后续通过对该部分业务数据进行整合、处理，构建共享数据库的方式，不仅可以满足租户之间想实现部分数据共享的需求，还能够实现多租户间的服务提供方信息的统一管理，有助于实现该部分业务数据的查询效率。

步骤S203，获取多租户的业务需求对应的业务数据，并根据业务需求对应的业务数据对业务场景进行更新。

具体地，根据本发明实施例，在供应商平台稳定运行后，考虑一些增值业务场景，以便于后续供应商进行大数据分析，制作供应商报表等。获取该部分的业务数据，拓展相应的业务场景，通过上述设置，结合租户的实际需求，进一步拓展所要共享的业务数据的覆盖范围，进一步提升了用户体验。

步骤S204，获取业务数据对应的服务提供方信息；基于服务提供方信息、业务数据及其对应的业务场景构建连接服务提供方的SaaS服务平台，SaaS服务平台包括消息中间件和SaaS数据库。

通过上述设置，构建连接上述至少一个服务提供方的SaaS服务平台，构建消息中间件(主要是消息队列，用于数据传输)和SaaS数据库(用于存储上述确定的业务数据，即租户之间想要共享的数据，可以是数据库集群)，实现服务提供方与各环境部署的租户(采取不同的数据存储方式的租户)之间的数据交互，达到了数据共享的目的，降低了应用程序的开发和可扩展性成本，提高了数据利用率，提升了用户体验。

根据本发明实施例，通过构建连接服务提供方的SaaS服务平台，实现了多模式部署方案下的多租户对应的数据入口统一分析管理。通过以供应商统一平台(SaaS服务平台)作为供应商注册以及登录的统一入口，那么该平台将全量的供应商相关数据进行存储，既满足了各租户与平台之间的数据交互，也有利于平台收集相同供应商在不同租户下的业务数据，形成全方位的数据分析管理。

步骤S205，响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户。

本发明实施例主要实现了多模式部署方案下(多种数据存储方式)的租户间的数据共享，构建好共享数据库(即上述SaaS数据库)之后，根据租户发起的数据获取请求，可直接从共享数据库中获取相应的目标数据。通过上述设置，实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验的技术效果。

步骤S206，监控多租户与服务提供方进行业务交互的业务节点；针对各业务节点分别建立业务消息队列；将业务节点处产生的交互数据发送至业务消息队列，从业务消息队列中获取交互数据；根据交互数据对业务数据进行更新，并根据更新后的业务数据对SaaS数据库内的相应数据进行更新。

具体地，根据本发明实施例的一具体实施方式，上述步骤实际上是建立一种消息同步机制，该消息同步机制包括：梳理触发消息同步的业务节点(比如供应商注册时，实名认证时，都应该触发消息同步机制，保证租户及供应商信息的一致性)；建立消息统一发送窗口(供应商平台作为统一入口，建立发送窗口，使得供应商数据以供应商平台为起点，发送至各个租户)；通过消息队列的形式建立平台与租户间的消息传输通道；定义职责链机制用于接收并处理消息同步机制发送的业务数据(租户端应该定义职责链，职责链类似于一个工厂，是租户端接收数据的发动来源，只需要定义一个通用模式，后续通过工厂为各场景的接收方法产出对应的处理方法，用于监听，接收，处理供应商平台传输过来的数据)；根据不同业务场景实例化对应的职责链实例，实现消息接收处理(例如注册需要实例化注册信息职责链，用户实名信息需要定义实名信息处理职责链)。

通过上述设置，建立了消息同步机制，实现了平台与不同租户之间的数据同步与交互，保证了服务提供方对应的租户在SaaS服务平台进行注册、信息管理等业务操作时，保证SaaS服务平台与各租户之间数据一致性。

步骤S207，监控业务消息队列对应的消息日志，在消息日志为信息发送失败日志的情况下，将信息发送失败日志所指示的交互数据存储至SaaS数据库。

根据本发明实施例，上述步骤实质上是构建了定时巡检和补全机制，主要包括：建立消息队列监听服务(用于监听消息队列的消息日志(主要是信息发送失败日志)，并将相应交互数据存储到数据库；建立消息补全服务(扫描并拉取存储在数据库中的信息发送失败日志记录，并调用相应的交互数据进行重发，将交互数据再次发往各租户)；建立定时调度任务(通过定时，例如每半小时启动消息补全服务，扫描数据库中的信息发送失败日志记录并重发)；

通过上述设置，建立了定时巡检和补全机制，通过定时巡检对业务节点进行监控，再通过补全机制获取业务节点处产生的交互数据，并将该交互数据存储至数据库中，进一步保证了数据一致性。

示例性地，根据本发明实施例，上述将信息发送失败日志所指示的交互数据存储至SaaS数据库，还包括：

设置调度周期，根据调度周期将信息发送失败日志所指示的交互数据存储至SaaS数据库。

根据本发明实施例的一具体实施方式，可以通过定时(例如每半小时)启动数据补全服务，扫描数据库中的信息发送失败日志对应的交互数据，并将该交互数据发送至相应的租户。

根据本发明实施例的技术方案，因为采用获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；基于业务数据及其对应的业务场景构建SaaS数据库；响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户的技术手段，所以克服了现有的多租户数据处理方法中存在的多租户间的服务提供方信息难以统一管理，且无法满足租户之间想实现部分数据共享的需求，应用程序的开发和可扩展性成本较高，数据利用率较低，用户体验较差的技术问题，进而达到实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验的技术效果。

图3是根据本发明实施例提供的基于SaaS的多租户数据处理装置的主要模块的示意图；如图3所示，本发明实施例提供的基于SaaS的多租户数据处理装置300主要包括：

业务数据获取模块301，用于获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个。

通过上述设置，不仅可以满足租户之间想实现部分数据共享的需求，还能够实现多租户间的服务提供方信息的统一管理。

具体地，根据本发明实施例，上述业务数据获取模块301还用于：

根据多租户与其对应的服务提供方之间的历史交互数据，确定服务提供方的业务数据；

获取业务数据，并根据业务数据对应的业务类型划分业务场景，其中，业务场景包括：注册场景、审核场景、登录场景、信息管理场景。

通过上述设置，不仅可以更精确地确定多租户想要共享的业务数据，进而提升业务数据的数据利用率；还有助于实现该部分业务数据的查询效率。

进一步地，根据本发明实施例，上述基于SaaS的多租户数据处理装置300还包括去重模块，在获取业务数据的步骤之后，去重模块用于：

对业务数据进行汇总、去重处理。

通过上述设置，将各租户对应的服务提供方的业务数据进行整合之后，进行去重处理，进一步简化了后续划分业务场景的流程。

优选地，根据本发明实施例，上述基于SaaS的多租户数据处理装置300还包括更新模块，在根据业务数据对应的业务类型划分业务场景的步骤之后，更新模块用于：

获取多租户的业务需求对应的业务数据，并根据业务需求对应的业务数据对业务场景进行更新。

通过上述设置，结合租户的实际需求，进一步拓展所要共享的业务数据的覆盖范围，进一步提升了用户体验。

数据库构建模块302，用于基于业务数据及其对应的业务场景构建SaaS数据库。

具体地，根据本发明实施例，上述数据库构建模块302用于：

获取业务数据对应的服务提供方信息；

基于服务提供方信息、业务数据及其对应的业务场景构建连接服务提供方的SaaS服务平台，SaaS服务平台包括消息中间件和SaaS数据库。

通过上述设置，构建连接上述至少一个服务提供方的SaaS服务平台，构建消息中间件和SaaS数据库，实现了服务提供方与各环境部署的租户(采取不同的数据存储方式的租户)之间的数据交互，达到了数据共享的目的。

优选地，根据本发明实施例，在基于业务数据及其对应的业务场景构建SaaS数据库的步骤之后，更新模块还用于：

获取多租户与其对应的服务提供方之间的交互数据，根据交互数据对业务数据进行更新，并根据更新后的业务数据对SaaS数据库内的相应数据进行更新。

通过实时(或者周期性)地监控多租户与其对应的服务提供方之间的交互数据，并对数据库中的相应数据进行更新，保证了SaaS服务平台与各租户之间数据保持一致性。

进一步地，根据本发明实施例，上述更新模块还用于：

监控多租户与服务提供方进行业务交互的业务节点；针对各业务节点分别建立业务消息队列；

将业务节点处产生的交互数据发送至业务消息队列，从业务消息队列中获取交互数据。

通过上述设置，建立了消息同步机制，实现了平台与不同租户之间的数据同步与交互，保证了服务提供方对应的租户在SaaS服务平台进行注册、信息管理等业务操作时，保证SaaS服务平台与各租户之间数据一致性。

优选地，根据本发明实施例，上述基于SaaS的多租户数据处理装置300还包括监控模块，用于：

监控业务消息队列对应的消息日志，

判断消息日志是否为信息发送失败日志；

若是，将信息发送失败日志所指示的交互数据存储至SaaS数据库。

通过上述设置，建立了定时巡检和补全机制，通过定时巡检对业务节点进行监控，再通过补全机制获取业务节点处产生的交互数据，并将该交互数据存储至数据库中，进一步保证了数据一致性。

示例性地，根据本发明实施例，上述监控模块还用于：

设置调度周期，根据调度周期将信息发送失败日志所指示的交互数据存储至SaaS数据库。

根据本发明实施例的一具体实施方式，可以通过定时(例如每半小时)启动数据补全服务，扫描数据库中的信息发送失败日志对应的交互数据，并将该交互数据发送至相应的租户。

数据处理模块303，用于响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户。

其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户。

通过上述设置，实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验的技术效果。

进一步地，根据本发明实施例，上述数据存储方式包括：

以独立数据库的方式进行数据存储，以共享数据库、隔离数据架构的方式进行数据存储，以共享数据库、共享数据架构的方式进行数据存储。

其中，以独立数据库的方式进行数据存储的租户数据隔离级别最高，安全性最好，但成本较高。

以共享数据库、隔离数据架构的方式进行数据存储的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多的租户数量。

以共享数据库、共享数据架构的方式进行数据存储是共享程度最高、隔离级别最低的数据存储方式，但是所需费用最低。

优选地，根据本发明实施例，上述基于SaaS的多租户数据处理装置300还包括调整模块，用于：

根据多租户对应的租赁状况、租赁需求对各租户对应的数据存储方式进行调整。

其中，租赁状况包括租户信用信息、付款信息等描述租户当期那租赁状况的信息；租赁需求主要指租户当前对存储空间的需求。

通过上述设置，根据租户信用信息、付款信息、存储空间等可以调整各租户对应的数据存储方式，即实现租户在三种数据存储方式之间的切换，进一步提升了用户体验。

根据本发明实施例的技术方案，因为采用获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；基于业务数据及其对应的业务场景构建SaaS数据库；响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户的技术手段，所以克服了现有的多租户数据处理方法中存在的多租户间的服务提供方信息难以统一管理，且无法满足租户之间想实现部分数据共享的需求，应用程序的开发和可扩展性成本较高，数据利用率较低，用户体验较差的技术问题，进而达到实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验的技术效果。

图4示出了可以应用本发明实施例的基于SaaS的多租户数据处理方法或基于SaaS的多租户数据处理装置的示例性系统架构400。

如图4所示，系统架构400可以包括终端设备401、402、403，网络404和服务器405(此架构仅仅是示例，具体架构中包含的组件可以根据申请具体情况调整)。网络404用以在终端设备401、402、403和服务器405之间提供通信链路的介质。网络404可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备401、402、403通过网络404与服务器405交互，以接收或发送消息等。终端设备401、402、403上可以安装有各种通讯客户端应用，例如数据处理类类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备401、402、403可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器405可以是提供各种服务的服务器，例如对用户利用终端设备401、402、403所(进行数据处理)的服务器(仅为示例)。该服务器可以对接收到的业务数据等数据进行分析等处理，并将处理结果(例如目标数据--仅为示例)反馈给终端设备。

需要说明的是，本发明实施例所提供的基于SaaS的多租户数据处理方法一般由服务器405执行，相应地，基于SaaS的多租户数据处理装置一般设置于服务器405中。

应该理解，图4中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图5，其示出了适于用来实现本发明实施例的终端设备或服务器的计算机系统500的结构示意图。图5示出的终端设备或服务器仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图5所示，计算机系统500包括中央处理单元(CPU)501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行各种适当的动作和处理。在RAM 503中，还存储有系统500操作所需的各种程序和数据。CPU 501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

以下部件连接至I/O接口505：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被中央处理单元(CPU)501执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括业务数据获取模块、数据库构建模块和数据处理模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，业务数据获取模块还可以被描述为“用于获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；基于业务数据及其对应的业务场景构建SaaS数据库；响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户。

根据本发明实施例的技术方案，因为采用获取多租户对应的服务提供方的业务数据，根据业务数据划分业务场景；其中，服务提供方的数量为至少一个；基于业务数据及其对应的业务场景构建SaaS数据库；响应于租户发起的数据获取请求，从SaaS数据库中获取相应的目标数据，并将目标数据发送至租户；其中，租户是指从服务提供方处租赁数据存储空间的用户，多租户包括至少两个采取不同数据存储方式的租户的技术手段，所以克服了现有的多租户数据处理方法中存在的多租户间的服务提供方信息难以统一管理，且无法满足租户之间想实现部分数据共享的需求，应用程序的开发和可扩展性成本较高，数据利用率较低，用户体验较差的技术问题，进而达到实现多租户间的服务提供方信息的统一管理，满足租户之间想实现部分数据共享的需求，降低应用程序的开发和可扩展性成本，提高数据利用率，提升用户体验的技术效果。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。