多租户环境下访问数据库的系统、设备和方法 【技术领域】
本发明涉及多租户技术，更具体地，涉及支持多租户环境下访问数据库的系统、装置和方法。
背景技术
由于SaaS(Software as a Service软件作为服务、软件即服务)的出现，软件行业正在经历一场深刻的变革。SaaS在许多国家已经流行并进入了普及阶段。SaaS的安全技术日新月异，越来越多的企业开始认可SaaS安全性和可靠性。基于互联网的特点，SaaS软件有许多区别于前一代软件的独特性，从服务器端软件和数据库、数据传输、到客户端浏览器都出现了许多新技术。
开发SaaS软件系统时，均建立在多重租赁(Multi-Tenant)的基础上，也就是一套软件和数据库平台，经过软件和数据库的隔离及保密等技术，多个企业(或者企业内部多个租户)同时使用。虽然不是多重租赁的SaaS产品不一定是“假SaaS”产品，然而多重租赁大大提高了运营效率、稳定性，降低运营商的维护和升级成本，变相地说最终消费者得到了价格上的实惠。
在SaaS系统中，相对于应用程序计算逻辑/层面而言，如何处理多租户(Multi-Tenant)对数据库的访问更具有挑战性。目前有多种多租户环境下的数据存储方案，比如租户独立数据库(Separate DB)、共享数据库但独立数据架构(Separate Schema)、共享数据库及数据架构等。在这些数据存储方案的基础上，能否解决多租户在使用SaaS应用程序时的数据访问问题是决定SaaS应用能否适应多租户要求的最大挑战。在解决这一问题时，通常需要考虑以下两点：一是便利性和低成本的转移，也就是在尽量不重写服务器端代码的前提下实现多租户对数据库的访问；二是满足多租户场景下的特定需要，例如安全隔离等需求。租户与用户是一组相对概念，也可以将两者简单地理解为，用户为租户下的用户帐号，一个租户下可以有多个用户帐号。
图1示出现有技术中传统单租户(多用户)环境下数据库访问的系统结构图。该系统在图1中总体由数字100表示。系统100使得单租户环境下的用户能够在运行应用实例时访问数据库。
需要一个Java数据库连接(JDBC)驱动来与所访问的特定数据库管理系统进行通讯。JDBC是一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。用户的SQL语句被送往数据库中，而其结果将被送回给用户。数据库可以位于另一台计算机上，用户通过网络连接到上面。这就叫做客户机/服务器配置，其中用户的计算机为客户机，提供数据库的计算机为服务器。网络可以是企业内部互联网Intranet(它可将公司职员连接起来)，也可以是国际互联网Internet。具体地，数据库访问接口101将用户发出的数据库连接请求发送至数据源(Data Source)102，通过调用对应的数据库访问接口驱动程序，例如JDBC驱动程序103来建立该用户至数据库的连接，并将该连接保存在数据源102的连接池中。用户至数据库的连接建立后，用户将对数据库的数据访问请求(比如SQL查询语句)发送至数据源(Data Source)102，再调用对应的数据库访问接口驱动程序，例如JDBC驱动程序103，将该访问数据库的请求发送至对应的数据库104，执行具体的用户访问数据库的操作。
现有技术中，可以在图1单租户数据库访问系统的基础上，通过为每个租户单独复制或重建一份应用实例及数据库的拷贝来解决多租户访问数据库的问题，使得每个租户具有连接至其特定数据库的特定数据源。这样做的好处是不需要对服务器端代码进行改写，然而却不能够满足多租户场景下对低成本的需求；或者通过改写服务器端代码以使其支持共享的应用实例和数据库的方法来解决上述问题，这样做的好处是可以节约成本并支持多租户场景下对数据库的访问，缺点是需要进行大量的服务器端的代码修改，并且需要技术人员对实现多租户技术场景的细节(比如共享及安全隔离)具有深入、充分的了解。
【发明内容】
考虑到上述问题，希望提供新的关于多租户数据库访问的技术方案及相关机制，利用多租户场景的特点提供透明地程序接口支持，从而实现方便、快捷、低成本地对应用软件进行支持多租户的扩展，并在管理和运行层面使得应用软件具有多租户功能。
基于上述问题和目的，本发明提供实现多租户场景下访问数据库的系统、装置和方法。
根据本发明第一方面，提供一种获取多租户数据库访问连接的装置，包括：信息接收单元，接收提交数据库访问请求的租户身份信息和与所述租户身份信息相关的元配置信息；连接池单元，保存多租户与数据库间的连接；以及连接获取单元，根据所述租户身份信息和所述元配置信息从所述连接池单元中获取提出请求的租户至对应数据库的连接。
根据本发明第二方面，提供一种获取多租户数据库访问连接的方法，包括：接收提交数据库访问请求的租户身份信息和与所述租户身份信息相关的元配置信息；以及根据所述租户身份信息和所述元配置信息从所述连接池单元中获取提出请求的租户至对应数据库的连接。
根据本发明第三方面，提供一种多租户数据库访问系统，包括：请求接收模块，接收租户访问数据库的请求；租户身份识别模块，识别提交数据库访问请求的租户身份信息；元数据存储模块，存储与租户身份相关的元配置信息；连接建立模块，建立所述提交请求的租户至所述对应数据库的连接；以及连接获取模块，获取所述提交请求的租户至对应数据库的连接；
利用本发明的多租户数据库访问处理方案，租户不需要大量地改写与数据库访问相关的服务器端的代码，也不需要为每个租户均复制或重建一套数据库拷贝，就能够以较低的成本、简单地利用支持多租户身份识别的数据源管理多租户对数据库的访问。并且，本发明为多租户环境下的应用软件、数据库服务提供商提供透明的程序接口，支持以较低的成本实现支持大量的租户。
【附图说明】
图1是示出了传统单租户环境下数据库访问系统的结构图；
图2是示出了获取多租户数据库访问连接的装置的结构图；
图3是示出了获取多租户数据库访问连接的方法的流程图；
图4是示出了多租户环境下数据库访问系统的结构图；
图5是示出了基于图4所示的多租户数据库访问系统的数据库访问接口驱动模块的一种实现；
图6是示出了根据本发明一个实施例的用于多租户环境下数据库访问的方法的流程图；
图7是示出了租户身份识别及登录模块的示例性实施方式的结构图；
图8是示出了多租户访问数据库时进行扩展操作的方法的流程图；
图9是示出了根据本发明的一实施例的多租户数据库访问系统的结构图。
【具体实施方式】
下面结合附图说明本发明的具体实施方式。
图2示出了获取多租户数据库访问连接的装置的结构图，该装置也可以理解为下面所述的多租户数据库访问系统中的数据源模块的一种实现。该装置在图2中总体由200表示。具体地，装置200包括信息接收单元201、连接关系获取单元202和连接池单元203。信息接收单元201接收租户身份信息以及租户元配置信息。其中租户身份信息可以由租户在登录时输入的租户ID中提取，并由例如图4中的租户身份识别模块405发送至信息接收单元201，而租户元配置信息包括租户对数据库的占用关系信息，例如租户对应于哪个数据库，是独占数据库还是与其它租户共享数据库，这样的信息可以存储在例如图4中的元数据存储模块中并发送至信息接收单元201。信息接收单元201在根据上述信息识别了租户身份并获取了租户对数据库的占用关系后，将向连接获取单元202发送获取该租户至对应数据库的连接的请求。连接获取单元202根据信息接收单元201发送的请求从连接池单元203中选择建立相应的从租户至数据库的连接。连接池单元203中保存各租户与图4中所示的数据库池404中的数据库对应的数据库连接。需要指出的是，当连接池单元203中尚未保存有该租户至对应数据库的连接时(比如租户第一次登陆数据库)，通常需要由装置200之外的连接建立单元来根据连接获取单元202接收到的发送自信息接收单元201的请求建立连接，并将该连接保存在连接池单元203中，此后该租户再次登录数据库时，连接获取单元202即可直接从连接池单元203中获取连接，而无需再调用连接建立单元来建立连接。连接建立单元通常为数据库访问接口驱动模块。然而，本领域技术人员可以了解，尽管以后租户登录的建立连接过程无需数据库访问接口驱动模块参与，但是租户发出的各种SQL语句仍然需要调用数据库访问接口驱动模块来执行。利用图2所示的装置(数据源模块)，可以提供一种新的支持各种多租户数据存储方案的访问数据库的机制。下面图5将详细描述连接建立单元，即数据库访问接口驱动模块。
图3示出获取多租户数据库访问连接的方法的步骤。步骤从301开始，获取租户的身份信息，从而对租户进行身份识别。具体地，租户的身份信息可以通过租户身份服务提供接口(SPI)来获得，租户身份服务提供接口具体可以是由Java语句编写而成的类模块。本领域技术人员可以通过多种方式实现用于获得租户身份信息的租户身份服务提供接口，可选地，可以通过基于线程的租户身份信息传递方式来实现，在该方式下，租户登录后将租户ID(tenant_id)置入本地线程对象中(具体参见图7)；还可以通过基于Java认证和授权服务(JAAS)的租户身份传递方式来实现，在该方式下，租户使用JAAS登录页面登录，并将租户ID插入到安全标记中。然而，不管采用什么方式实现对租户身份信息的记录、获取及识别，均落入本发明技术方案的保护范围。
仅识别了租户的身份信息还不足以建立该租户至特定数据库的访问连接，在步骤301中还需要获得租户元配置信息。租户元配置信息可以是至少包含了租户应连接至哪个数据库的信息，还可以包括租户是独占该数据库还是与其它租户共享该数据库的信息。基于这样的租户对数据库占用关系的信息以及上述请求访问数据库的租户身份信息，就可以在步骤304中获取租户至对应数据库的连接。从步骤301直接执行步骤304的前提是，已经保存了需要获取的租户至对应数据库的连接，如果该连接尚未被保存的话，则需要在步骤301后执行步骤302，根据所述租户身份信息和元配置信息建立连接，并执行步骤303保存所述建立的连接。这样以后再需要获取该连接时就不用执行步骤302和303，而可以在执行完步骤301后直接执行步骤304获取租户至对应数据库的连接。因此，在图3中，步骤302和步骤303用虚线表示，即这两个步骤不是必须的，而仅在尚未保存需要获取的连接的情况下才执行。在步骤304获取了租户至对应数据库的连接之后，还可以根据租户的需求在步骤305中，根据所述租户身份信息和元配置信息进行安全隔离、执行隔离和服务质量协议(SLA)控制等扩展操作，这些扩展操作的详细内容将在下文中具体描述。步骤305对于获取多租户数据库访问连接的方法而言也不是必需的步骤，因此在图3中也用虚线表示。
图4示出根据本发明的多租户环境下数据库访问系统的结构图。该系统在图4中总体由数字400表示。系统400使得多租户环境下的租户能够在无需大量改写服务器端源代码或者重新复制数据库拷贝的情况下实现对数据库的访问。系统400包括数据库访问接口模块401、数据源模块402、数据库访问接口驱动模块403、数据库池模块404、租户身份识别模块405及元数据存储模块406组成。
可选地，数据库访问接口模块401可以是例如JDBC(Java数据库连接)的用于执行SQL语句的API(应用程序接口)，它为数据库开发人员提供了一个标准的API，据此可以构建更高级的工具和接口。数据库池模块404包括多个数据库，根据租户要求的不同，一部分数据库可以由若干个租户共享，而另一部分数据库则由租户单独占有。租户身份识别模块405对租户身份进行识别，获取租户身份信息以便数据源模块402根据不同的租户获取相应的连接，在该连接尚未被记录的情况下，通过调用数据库访问接口驱动模块403，与数据库池模块404中的对应的数据库建立连接并在数据源模块402中记录该连接。租户身份识别模块405可以由用Java语言编写而成的类构成，其可以有多种实现方式。在一个具体实施例中，租户身份识别模块405可以基于线程实现，即登录后，将租户ID(tenant id)置入本地线程对象中(参见图7)。在另一个具体实施例中，租户识别模块可以基于Java认证和授权服务(JavaAuthentication and Authorization Service)实现，即租户登录时使用JAAS登录页面，并将租户ID(tenant id)插入安全标记中。可以理解，上述对租户身份识别模块405的具体实施方式的描述并非限制性的描述，本领域技术人员可以根据操作系统以及需求的不同，采用各种方式实现租户身份识别模块405，只要实现了识别并提供租户身份信息的功能即落入本发明的保护范围。
显然，仅仅依靠租户身份识别模块405对租户身份进行识别，不足以让数据源模块402判断应该与数据库池模块404中的哪一个数据库建立连接，还需要租户元数据存储模块406中存储的信息。租户元数据存储模块406存储关于各个租户数据访问层面的元信息，例如该租户应连接至哪个数据库，是独享该数据库还是与其它租户共享该数据库，租户对数据安全级别的要求，租户对服务质量的要求等信息，并且这些信息是可添加和扩展的。在一个具体实施例中，租户元数据存储模块406还存储各个租户对数据库安全隔离的要求的信息，以便确定在该租户访问数据库时是否需要进行安全隔离。进行安全隔离的目的在于保障多租户访问数据库时的数据安全，尤其是在多租户共享一个数据库的情况下，确保彼此无法访问对方的数据。在另一个具体实施例中，元数据存储模块406还存储服务质量协议SLA(Service Level Agreement)控制信息，以便对租户进行SLA跟踪和控制。根据租户与数据库服务提供商间的约定不同，SLA可以包括很多内容，例如，可以包括在多个租户共享数据库的情况并且同时发出数据访问请求的情况下，优先满足哪个租户的数据库访问请求。
来自数据库访问接口模块401的租户对数据库的访问请求、来自租户身份识别模块405的租户身份信息和来自租户元数据存储模块406的租户元配置信息被发送至数据源模块402，数据源模块402根据接收到的租户身份信息和租户元配置信息获取请求访问数据库的租户至对应的数据库间的连接，从而实现租户访问数据库的操作。如果数据源模块402中尚未记录要获取的连接的话，那么数据源模块402无法直接获取所需的连接，在这种情况下，通常根据数据库访问接口模块401的不同，数据源模块402还需要调用相应的数据库访问接口驱动模块403先建立好租户至对应的数据库的连接并将该连接保存或记录在数据源模块402中。例如，采用JDBC作为数据库访问接口401并且数据源模块302中没有保存需要获取的连接的情形下，数据源模块302需要调用JDBC驱动模块建立租户至对应的数据库的连接并将其保存或记录在数据源模块402中。可以理解，本领域技术人员可以根据操作系统以及需求的不同采用不同的数据库访问接口401，并相应地调用不同的数据库访问接口驱动模块403。需要指出的是，图4中所示的各模块及上述相应的文字描述的目的是更清晰地阐述技术方案的细节，本领域技术人员通过上述各模块的功能和调用关系可以理解，可以通过替代的方式或者更概括的方式对上述模块进行描述或实现，例如数据库访问接口模块401可以是请求接收模块，接收租户登录及访问数据库的请求；数据源模块402、租户身份识别模块405及租户元数据存储模块406可以构成连接获取模块，获取所述提交请求的租户至对应数据库的连接；而数据库访问接口驱动模块403可以是连接建立模块，建立并记录所述提交请求的租户至所述对应数据库的连接。
图5示出了基于图4所示的多租户数据库访问系统的数据库访问接口驱动模块的一种实现。该数据库访问接口驱动模块在图5中总体由500表示。具体地，数据库访问接口驱动模块500可以包括安全隔离单元501、执行隔离单元502、服务质量协议(SLA)控制单元503等单元，这些单元根据接收到的关于安全隔离、执行隔离和SLA控制的元数据信息来进行相应的处理。关于安全隔离、执行隔离和SLA控制等内容的元数据信息可以由例如图4中所示的租户元数据存储模块406存储并发送至安全隔离单元501、执行隔离单元502和SLA控制单元503。安全隔离单元、SLA控制单元所实现的功能在上文中已有描述。对于执行隔离单元502，其主要功能是在多个租户共享数据库且多租户同时发送大量数据访问请求的情况下，系统无法满足所有租户对数据库的所有访问请求，而以同等时间间隔或分配同等资源分别处理各租户对数据库的访问请求。可以这样理解，执行隔离单元502通常不需要特别存储与租户身份相关的元配置信息，而属于一种系统默认提供的功能，如果有租户需要较高优先级的数据库访问服务，则需要存储相应的元配置信息。需要注意的是，上述安全隔离单元501、执行隔离单元502和SLA控制单元503只是为了示例地说明数据库访问接口驱动模块500中可以提供这些功能，数据库访问接口驱动模块500不是必须包含某些特定的单元，本领域技术人员完全可以根据系统和租户的需求提供不同的功能单元。比如还可以在数据库访问接口驱动模块500中提供数据库分区单元等。也就是说，数据库访问接口驱动模块500是可以扩展的，在其中添加组件时只需对应地接收与该组件相关的元配置信息即可。需要说明的是，图5所示的扩展功能有时不是必需的，例如，当请求访问数据库的租户是独占数据库时，就不必在其访问数据库时进行安全隔离，而对于执行隔离和SLA控制等功能，同样可以依据租户的需求作出调整或增删。需要指出的是，正如在上文对图4的文字描述中所指出的，图5所示的模块当然还包括连接建立单元，但为了图示的简洁，在此并未示出该单元。本领域技术人员可以了解，数据库访问接口驱动模块的基本功能即为建立数据库连接。
图6示出了根据本发明一个实施例的用于多租户环境下数据库访问的方法的流程图。如图6所示，为了实现多租户环境下对数据库的访问，首先从步骤601开始，接收来自租户的访问数据库的请求，典型地可以是SQL语句的形式。在某些程序员对SQL语句不是非常熟悉的情况下，还可以利用iBatis(Internet与Abatis的组合)、Hibernate等Java持久层框架(JDBC上层的ORM解决方案)来提交访问数据库的请求，然而即使使用了iBatis、Hibernate等这些Java持久层框架，仍然需要调用JDBC来完成访问数据库请求的提交。本领域技术人员还可以理解，租户在发送具体的数据库执行操作(比如SQL查询指令)前通常应当先登录，以便建立起该租户至对应数据库的连接。租户的登录请求可以与发送具体的数据库执行操作指令同步进行，也可以先登录，后进行具体的数据库执行操作。本段所述的步骤601接收来自租户的访问数据库的请求包括接收租户登录数据库的请求和租户对数据库执行具体操作的请求。
在多租户环境下，为了对不同的租户建立正确的数据库连接，首先需要识别提出数据库访问请求的租户的身份。于是，在步骤602中获得租户的身份信息，从而对租户进行身份识别。具体地，获取租户的身份信息的方法在图3、图7及相应的文字说明中有详细描述。
仅识别了租户的身份信息还不足以建立该租户至特定数据库的访问连接，还要获得关于该租户对数据库占用关系的信息。因此在步骤603中获得租户元配置信息。租户元配置信息可以是至少包含了租户应连接至哪个数据库的信息，还可以包括租户是独占数据库还是与其它租户共享数据库的信息。基于这样的租户对数据库占用关系的信息以及步骤602中获得的请求访问数据库的租户身份信息，就可以在步骤604中判断请求访问数据库的租户至对应数据库的连接是否已建立并被记录。如果步骤604的判断为是，则直接执行步骤606获取该连接；如果步骤604的判断为否，则执行步骤605建立并记录该连接，再执行步骤606获取该连接。在步骤603中可以从例如租户元信息存储单元中获取租户元配置信息，租户元信息存储单元除了存储必要的租户对数据库占用关系的信息外，还可以根据系统和租户的需求存储诸如安全隔离、执行隔离以及是否需要SLA控制等其它元配置信息，以便在后续步骤中(参见步骤606)执行相应的扩展功能。租户对数据库的占用关系信息可以包括租户对应于哪个数据库，以及租户是独占该数据库还是与其它租户共享数据库，如果是共享数据库的话，是共享数据架构(Data Schema)还是具有不同的数据架构等信息。步骤606中可以从例如数据库连接池中获得与请求访问数据库的租户相匹配的至对应数据库的连接，数据库连接池通常位于数据源(Data Source)中，用于保存与多租户环境下的多个数据库对应的由租户至特定数据库的连接。可以理解，本段所述的元信息存储单元和数据库连接池均是为了示例地解释各个步骤，而并非对各个步骤作出任何限制性的解释。
如果数据源中不存在租户相匹配的数据库连接，则需要通过步骤605，即调用数据库访问接口驱动程序建立租户至数据库的连接，并将该连接记录于数据源(连接池)中，日后该租户再次发出访问数据库的请求时即可直接从数据源(连接池)中获取该连接。根据系统和租户的需求，还可以在步骤607中基于租户身份信息和存储的元配置信息对该租户访问数据库的操作进行安全隔离、执行隔离等扩展功能，以提升数据库访问系统的安全性能。此外，租户还可能需要实现SLA控制或者数据库分区等扩展功能，这些都可以在步骤608中实现，只要租户元配置信息中记录有相关信息即可。
图7示出了租户身份识别及登录模块的示例性实施方式的结构图。图7所示的示例性实施方式是基于线程而实现的。该租户身份识别及登录模块在图7中总体由700表示，包括：租户登录标签701、租户登录过滤器702、会话703、租户身份过滤器704、租户信息转发模块705、线程706、多租户数据源707和数据库池708。图7所示的实施方式中的租户登录标签701需要将租户登录页面进行微小的修改，例如在Java环境下，添加新的数据域“TenantID”并将“j_tenantID”作为输入的名字。之所以要对租户登录页面进行修改，是因为租户(通常指企业)内部的用户(比如企业内部员工)通常在登录时仅输入用户名，而一个租户往往又包括多个用户，仅输入用户名无法提取租户身份信息，因此要求用户在登录时除了输入用户名外还需输入其所属租户名。具体可以采用如下的代码段实现：
<td>
<div align＝″right″><font face＝arial size＝-1>Tenant ID：</font></div>
</td>
<td>
<input type＝″text″name＝″j_tenantID″class＝″short″id＝″j_tenantID″maxlength＝40>
</td>
在Java环境下，还需要修改Java的web程序的主要配置文件web.xml，在其中加入新的过滤器例如“ABC.LoginFilter”，具体可以采用如下的代码段实现：
<filter>
<filter-name>auth</filter-name>
<filter-class>ABC.LoginFilter</filter-class>
</filter>
根据上面的示例代码段和图7所示，对于租户登录请求而言，租户登录时，租户登录过滤器702(TenantLogin Filter)截取租户登录请求中的tenant_id，将tenant_id置入会话703(Session)中并通过租户身份信息转发模块705将tenant_id置入本地线程中，租户身份信息转发模块705是用于向本地线程传送及获取tenant_id的模块或功能单元，可以由程序代码来实现。从而，租户登录请求可以通过租户信息转发模块705从本地线程706(Thread Local)中获得tenant_id，从而进行租户登录的数据库请求；对于租户数据访问请求，由于租户已经登录并且tenant_id已经存储在会话(Session)中，因此该请求可由租户身份过滤器704(TenantIdentity Filter)截取并从已经存有tenant_id的会话703中获得tenant_id，然后通过租户信息转发模块705(TenantUtilSPIThreadlmpl)发送至本地线程，从而数据访问请求可以从本地线程703中获取tenant_id。需要注意的是，上文将租户登录过滤器702(TenantLogin Filter)和租户身份过滤器704(TenantIdentity Filter)做了区别描述，这只是为了更清晰地描述其功能，并不意味着必须有两个不同的处理单元或模块，事实上，一个过滤器也可以实现这两个过滤器的功能。还需要指出，本领域技术人员可以了解，上述技术手段的目的在于提取租户tenant_id并将其存储于session中，可以不使用过滤器filter而直接将tenant_id存储于session中，只要能够获取tenant_id信息即落入本发明保护范围。
此外，上文中已有记载，还可以通过基于JAAS的方式实现租户身份识别，只需要将租户ID加入全程Security name中即可实现。
还需要指出的是，根据应用实现环境的不同可以采取不同的方式实现图7所示的租户身份识别及登录模块，不拘泥于上述示例代码段或模块。
图8示出了多租户访问数据库时进行扩展操作的方法的流程图。图8所示的进行扩展操作的方法总体由800表示。通常，安全隔离在数据库访问接口驱动程序(如JDBC driver)中实现。在步骤801获取租户元配置信息，该元配置信息中存储有租户对扩展功能需求的信息，比如是否需要安全隔离以及安全隔离的等级等内容；在步骤802中，对租户提交的数据库访问请求，例如SQL语句进行解析(Parser)，以便对其进行修改；在步骤803中需要判断是否采用和别的租户共享表的模式，如果是，则需要执行步骤804，向SQL语句中加入tenant_id，然后执行步骤805，如果否，则直接执行步骤805；在步骤805中判断是否使用分区数据库并且采用基于租户的数据分发策略；如果是，则执行步骤806，在SQL语句中加入租户特定的数据分发键DBPK，如果否，则直接执行步骤807进行其它操作。
可以理解，图3所示的方法可由图2所示的装置200来执行，也可由图4所示的系统400的数据源模块来执行；图6所示的方法可由图4所示的系统400来执行，其中获取连接的部分步骤也可由图2所示的装置200来执行。
图9示出了根据本发明的一实施例的多租户数据库访问系统的结构图。图9所示的实施例是基于开放源代码Apache-DBCP实现的多租户数据库访问系统，该系统在图9中总体由900表示，包括基本数据源901，合并数据源902，多租户连接池模块903，连接池实例904，数据库访问接口驱动模块905，数据库驱动模块906，租户识别模块907，多租户元数据存储模块908和数据库池909。具体地，基本数据源901、合并数据源902、数据库驱动模块906、数据库池909为现有技术中基于开放源代码Apache的单租户数据库访问系统的通用模块。多租户连接池模块903根据接收到的租户识别模块907识别的租户身份信息和多租户元数据存储模块908中存储的租户元配置信息，从连接池中获取与发出数据库访问请求的租户相对应的数据库连接池实例904，连接池实例中的连接是通过调用数据库访问接口驱动模块905建立的、租户至对应数据库的连接，并且根据系统和租户的预订需求，在数据库访问接口驱动模块905中实现安全隔离、性能隔离、SLA控制等扩展功能。需要指出的是，现有技术基于开放源代码Apache的单租户数据库访问系统中，没有多租户连接池模块903和数据库访问接口驱动模块905，且只有一个连接池实例904，合并数据源902直接获取单一的连接池实例904并通过调用数据库驱动模块906建立单租户至数据库的连接。
应当了解，上面描述的本发明的技术方案同样可以扩展适用于多租户、多应用的场景，尤其是提供数据库服务的场景。该种场景尽管比上述单应用、多租户的场景要复杂一些，但是同样适用上述公开的技术方案。具体地，需要在图4所示的租户身份识别模块405中添加识别多应用的URL的功能组件，例如可以在图7所示的租户身份识别及登录模块的示例性实施方式中令租户登录过滤器和租户识别过滤器在截取租户tenant_id的同时也截取应用程序的URL，同时在图4所示的租户元数据存储模块406中在存储租户元配置信息的同时也存储多应用的元配置信息，这样即可以与单应用、多租户数据库访问相同的原理和机制实现多应用、多租户场景下的数据库访问。基于本段上述内容，前文所述的多租户数据库访问系统的数据源模块、多租户环境下数据库访问的方法也同样适用于多应用、多租户场景下对数据库的访问。
通过以上对具体实施例的描述，本领域技术人员可以理解，上述的系统、装置和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本实施例的装置、服务器及其单元可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合实现。
虽然以上结合具体实施例，对本发明的利用远程应用处理本地文件的系统及方法进行了详细描述，但本发明并不限于此。本领域普通技术人员能够在说明书教导之下对本发明进行多种变换、替换和修改而不偏离本发明的精神和范围。应该理解，所有这样的变化、替换、修改仍然落入本发明的保护范围之内。本发明的保护范围由所附权利要求来限定。