多租户和Google App Engine（GAE）Java

Multi-tenant applications, one instance serves more than one organization, but at the same time provides virtual isolation to data and applications from other tenants of the application. Since the hardware, Operating system, and in some cases application code are the same for all tenants of the application, it’s easier to maintain, monitor and make incremental changes based on aggregate data from tenants. It also provides economics of scale by which the services can be provided at lower cost to tenants.

多租户应用程序，一个实例为多个组织提供服务，但同时又将数据和应用程序与应用程序的其他租户虚拟隔离。 由于硬件，操作系统以及某些情况下的应用程序代码对于应用程序的所有租户都是相同的，因此基于租户的汇总数据来维护，监视和进行增量更改变得更加容易。 它还提供了规模经济性，从而可以以较低的成本向租户提供服务。

The Multi-tenancy Principal is not a new phenomenon, it has been around for at least a few decades, but with emergence of Cloud computing, multi-tenant architecture is gaining more ground in the application space on cloud. When you create an account on a storage service like DropBox, you are assigned is a 2GB of space from petabytes of storage they have. Your 2GB space is exclusively for you and no one else can access it unless you share it. But space assigned to each user is potentially on the same physical storage device or set of physical storage devices. So you are one of tenants of multi tenant storage system of DropBox!

多租户主体不是一个新现象，它已经存在了至少几十年，但是随着云计算的兴起，多租户体系结构在云的应用空间中获得了更多的应用。 在诸如DropBox之类的存储服务上创建帐户时，会从其拥有的PB级存储中分配2GB的空间。 您的2GB空间仅供您使用，除非您共享它，否则没有人可以访问它。 但是分配给每个用户的空间可能位于同一物理存储设备或一组物理存储设备上。 因此，您是DropBox多租户存储系统的租户之一！

多租户级别 (Levels of Multitenancy)

硬件和资源多租户 (Hardware and Resource multitenancy)

This is simplest form of multitenancy, and something which has been in existence for quite some time! When you get storage on Amazon S3 for your application, you are getting space on a shared storage space and you are one of many tenants of the infrastructure. Most IaaS consumers are tenants of the infrastructure they are using.

这是最简单的多租户形式，并且已经存在了很长时间！ 当您在应用程序的Amazon S3上获得存储时，您正在共享存储空间上获得空间，并且您是基础架构的众多租户之一。 大多数IaaS使用者都是他们使用的基础架构的租户。

数据多租户 (Data multitenancy)

Data multitenancy is achieved at a datastore level. Based on security and compliance constraints, and purpose of organization, the degree of architectural multitenancy might vary. Organizations wanting security and complete isolation of data might choose to have an isolated DB setup for their organization. Other possible variations might include having one schema for an organization within same Database, or having separate set of tables for each organization. A detailed treatment on this subject can be found here but would not be the main focus of our discussion here.

数据多租户是在数据存储级别实现的。 根据安全性和合规性约束以及组织的目的，体系结构多租户的程度可能会有所不同。 需要安全性和数据完全隔离的组织可能会选择为其组织设置隔离的数据库设置。 其他可能的变化可能包括在同一数据库中为一个组织使用一个架构，或者为每个组织使用一组单独的表。 您可以在此处找到有关此主题的详细处理方法，但这并不是我们此处讨论的重点。

When we talk about data multitenancy, the application code accessing the data is same. The application might be hosted on multiple servers for scaling, but essentially the UI screens, logic and customizations of tenants remains identical, it’s only the data that differs.

当我们谈论数据多租户时，访问数据的应用程序代码是相同的。 该应用程序可能托管在多个服务器上以进行扩展，但是本质上，UI屏幕，租户的逻辑和自定义保持不变，只是数据有所不同。

应用多租户 (Application multitenancy)

Multitenancy weaved throughout an application is most complex type, and the hardest one to achieve. So, how is it possible that each tenat will have different logic and screens accessing different data still sharing common resources. Let’s look at a high level architecture of such a system:

编织在整个应用程序中的多租户是最复杂的类型，也是最难实现的类型。 因此，每个租户如何可能具有不同的逻辑，并且访问不同数据的屏幕仍然共享公共资源。 让我们看一下这种系统的高级架构：

A complete multi-tenant system achieves multitenancy at data level in similar to data multitenancy we earlier discussed. At the application level, a run-time engine combines the tenant specific metadata and customization data to kernel code, which gives a tenant specific application. The same logic might be applied at data level for cases where each tenant has a different kind of schema/objects. With object databases, it’s far easier to have different schema/objects for each tenat, or even have different attributes on same object for meeting needs of different tenants.

完整的多租户系统可以在数据级别实现多租户，这与我们之前讨论的数据多租户类似。 在应用程序级别，运行时引擎将特定于租户的元数据和自定义数据组合到内核代码，从而提供特定于租户的应用程序。 对于每个租户具有不同种类的架构/对象的情况，可以在数据级别应用相同的逻辑。 使用对象数据库，为每个租户使用不同的模式/对象甚至在同一个对象上具有不同的属性以满足不同租户的需求要容易得多。

Complexity in having a completely weaved multi-tenant application arises from having the filters for tenants throughout application, at the same time being able to deliver the promise of scale and speed. Various mechanisms such as metadata caching are used to achieve that. Best practical example of a multi-tenancy weaved through application are SalesForce applications.

拥有完全编织的多租户应用程序的复杂性源于在整个应用程序中都具有用于租户的过滤器，同时能够实现规模和速度的承诺。 使用诸如元数据缓存之类的各种机制来实现这一点。 通过应用程序编织的多租户的最佳实践示例是SalesForce应用程序。

Google App Engine中的多租户 (Multi tenancy in Google App Engine)

GAE provides the Namespace API to achieve multitenancy at a data level as of today. The Namespace API is available for Datastore, Task Queues and Memchache. The Blobstore API does not support Namespace yet, so your binary asset will have to be compartmentalized at the application level with mechanism designed in application. Namespace API also supports Google Apps domain, so if your tenants are going to be Google apps users, then you can set their domain name as Namespace for their data. There are various strategies to use namespace for example at user level, google apps domain level and so on.

到目前为止，GAE提供了Namespace API来实现数据级别的多租户。 命名空间API可用于数据存储，任务队列和Memchache。 Blobstore API目前尚不支持命名空间，因此您的二进制资产必须在应用程序级别使用应用程序中设计的机制进行分隔。 命名空间API还支持Google Apps域，因此，如果您的租户将成为Google Apps用户，则可以将其域名设置为数据的命名空间。 有多种使用命名空间的策略，例如在用户级别，Google Apps域级别等。

Namespace can be set before request enters the application by using filters configured in deployment descriptor. Namespace can also be set within request to other namespace to get common data, which can be unset or set to old namespace again.

可以使用部署描述符中配置的过滤器在请求进入应用程序之前设置名称空间。 也可以在请求中将名称空间设置为其他名称空间以获取公共数据，可以将其取消设置或再次设置为旧名称空间。

样例用例 (Sample use cases)

• Setting the Namespace to the current google apps domain – this will split data for each google apps user. This can be done in a filter so that request entering the application is Namespace aware. In the following piece of code, we are checking if Namespace is null and if it’s null we are setting it to the current google apps domain.
  将名称空间设置为当前的Google Apps域-这将为每个Google Apps用户拆分数据。 可以在过滤器中完成此操作，以便进入应用程序的请求可以识别名称空间。 在下面的代码中，我们正在检查Namespace是否为null，如果它为null，则将其设置为当前的Google Apps域。

[sourcecode language=”java”] if (NamespaceManager.get() == null) { NamespaceManager.set(NamespaceManager.getGoogleAppsNamespace()); } [/sourcecode]

[源代码语言=“ java”]如果(NamespaceManager.get()== null){NamespaceManager.set(NamespaceManager.getGoogleAppsNamespace()); } [/源代码]

If the data is split for each user, then user ID can be used as namespace;

如果为每个用户拆分了数据，则用户ID可以用作名称空间；

[sourcecode language=”java”] UserServiceFactory.getUserService().getCurrentUser().getUserId(); [/sourcecode]

[源代码语言=“ java”] UserServiceFactory.getUserService()。getCurrentUser()。getUserId(); [/源代码]

• A common namespace can be used across various tenants to access data common to all tenants for example to access zip codes of all cities in US can be retrieved from common namespace
  可以在各个租户之间使用公共名称空间来访问所有租户公共的数据，例如访问美国所有城市的邮政编码可以从公共名称空间中检索

[sourcecode language=”java”] String currentNs = NamespaceManager.get(); NamespaceManager.set(“COMMON_NS”); // Get data which is needed from common Namespace NamespaceManager.set(currentNs); [/sourcecode]

[源代码语言=“ java”]字符串currentNs = NamespaceManager.get(); NamespaceManager.set(“ COMMON_NS”); //从通用命名空间NamespaceManager.set(currentNs);获取所需的数据 [/源代码]

• Seperate namespaces can be used to separate data between dev, QA and staging environments, and versions of GAE can be used to host different stages of codebase for respective environments.
  单独的名称空间可用于在dev，QA和登台环境之间分离数据，GAE的版本可用于为相应环境托管不同的代码库阶段。
• Codebase of various modules of an application can be deployed in different versions like mail.APP_NAME.appspot.com and data specific to that module can be stored in individual namespaces.
  应用程序各个模块的代码库可以部署在不同版本中，例如mail.APP_NAME.appspot.com，并且该模块特定的数据可以存储在单独的命名空间中。
• Common data can be stored in common namespace, and namespaces can be switched when needed.
  通用数据可以存储在通用名称空间中，并且可以在需要时切换名称空间。

翻译自: https://www.sitepoint.com/multitenancy-and-google-app-engine-gae-java/