用户 ID 和身份验证

需要提供一种机制以支持用户标识和身份验证，允许用户拥有惟一的身份标识。由于多租户要求识别注册到系统中的所有用户，从而确定他们所属的租户，因此必须有一种明确的关系来将用户识别为属于某个特定租户。这种用户与租户的关系是非常重要的信息，用于限制用户可以访问的数据。

电子邮件地址是实现这一目的的一种典型方法，通过这种方式可以确保惟一性，每个用户可以被识别和标识为属于某个特定租户。

有多种身份验证机制和集成方法，因此必须具备一种灵活的机制来识别用户。通常，某个特定的租户需要能够利用其现有的 LDAP 或其他目录服务或身份验证机制来支持对 SaaS 应用程序的单点登录。尽管这种外部的用户身份验证非常重要，但是，需要由 SaaS 应用程序确定已识别的用户是属于它们所宣称的租户的成员。

对每个租户进行自定义

必须提供一种机制来支持对每个租户进行一定程度的基本自定义，从而使它们具有惟一的 URL、登入页面、标识、配色方案、字体，甚至包括语言。

对每个租户的基本配置是预期的功能，但是要真正地满足多租户的需求，必须在基本配置的基础上对每个租户实现一定程度的自定义。

所需的典型定制类似于租户对内部应用程序版本所作出的定制。包括添加字段甚至是表格，设置特殊的业务逻辑，或集成另一种应用程序。在每个租户的基础上能够进行这类自定义，同时无需建立单独的实例（否则会降低多租户设计的效率），这就是高性能 SaaS 架构的典型特征。

需要考虑的性能问题

多租户 SaaS 应用程序的性能问题通常与那些容纳同样数量的用户、具备相同的活动程度的 web 应用程序所遇到的问题相同。有许多不错的方法可以解决 web 应用程序中日益增长的容量需求问题；通常来讲，这些方法也都适用于多租户 SaaS 应用程序。这些技巧通常包括横向/纵向扩展和在一组服务器之间实现负载均衡。

横向/纵向扩展

云基础架构提供了许多以动态的、自动化的方式实现这种可扩展性的机会，从而能够在需要时提供资源，以及在使用更少的资源就可以满足性能服务水平协议（SLA）的情况下相应地减少资源。可以对这种灵活的能力进行调整，从而能够在提供服务的同时避免造成资源浪费：

• 横向扩展通常用于应用服务器层。
• 纵向扩展通常用于数据库层。

数据库集群化

对于 SaaS 应用程序，成功产品的用户总数可能会非常的高；在某些情况下，对数据库进行纵向扩展可能并不是一种好方法。许多数据库技术都能够提供一种集群化的数据库模型，允许对同一个数据库提供更多的容量。DB2® 提供的一些选项可以很好地应用于这种模型，并且可以用来创建数据库集群。

地理、分区和同步

然而，取决于 SaaS 应用程序及其用户群，其他一些技术也许更加合适。由于 SaaS 可以从世界上的任何位置访问，因此其用户群可能位于非常远的地方；这种距离会由于较长的网络拓扑而导致性能下降。

对于这类情况，使用分布在不同地区的云、对数据进行分区或使用同步维护一致性的效果可能会更好一些。究竟选择哪一种方法取决于具体应用程序的性质。一些用户可能无法接受长距离的同步。

独立的数据库

当然，在数据库容量无法满足需求时，最根本的方法（至少对于 SaaS 应用程序是这样）是建立单独的数据库。任何希望获得多租户 SaaS 应用程序的人都必须考虑到这种方式会导致不太可靠的解决方案，即需要针对每个租户提供数据库支持，这将直接导致效率低下，而这正是多租户力求避免的问题。

如果必须分割应用服务器以便只为一个数据库提供服务，那么多租户的高效率特性将进一步被折损。在竞争激烈的市场中，多租户的这些高效率特性对于 SaaS 公司获得成功至关重要。

在设计中利用负载均衡

在不得不使用独立数据库的情况下（不管出于什么原因），尽可能保持高效率的一种方法就是采用一种特殊的多租户设计，能够允许负载均衡的集群中的任何应用服务器访问多个数据库中最合适的那个数据库。通过这种方式，负载均衡的集群的效率就可以得到保持，所有应用服务器都能够连接到任意数据库以完成它们所支持的用户会话。这在多数据库的限制下实现了最大程度的效率。

容量并不是惟一的要求

除了满足容量需求外，使用多个数据库还出于正当理由，比如要求对某些高度安全的租户使用加密的数据库。容量不是问题，因此重要的是采用一种可以最大化效率的设计，即使需要一种本身比较低效的模型。

需要考虑的安全性问题

大量调查显示，SaaS 应用程序的用户通常将安全性排在首位，或至少非常接近首位。任何 SaaS 提供商都不能忽视安全性。但是，数据安全性的概念常常被局限于 SaaS 应用程序本身的上下文内。

大多数 SaaS 应用程序架构采取了一些保护数据安全性的措施，将阻止一个租户查看另一个租户的数据作为一个基本要求。但是：

• SaaS 应用程序必须具备的一种能力就是与其他应用程序集成并交互。
• 这些所谓的其他应用程序中的其中一些可能位于应用程序的外部（不受 SaaS 提供商的控制）。
• 并不是所有 SaaS 应用程序都被设计为对外部应用程序具有访问性。

这些其他应用程序可以是需要访问或共享数据的内部应用程序；也可以是对数据进行挖掘以获得趋势的分析或报告编写工具。即使是数据库管理员使用的实用工具也会引起安全问题，如果租户可以使用它们访问，或者更糟，操作不属于它们的数据的话。

面向 SaaS 的最佳实践架构必须考虑到并不是所有数据访问都在应用程序的控制之下；必须有一些机制来确保为每个租户提供数据保护，不管是通过 SaaS 应用程序还是通过一些外部应用程序实现访问。

选择技术堆栈

在选择技术堆栈时经常需要进行一些权衡；对于 SaaS 应用程序尤其如此，因为要对所有租户作出决策。让我们看看在这个过程中需要考虑的一些问题。

操作系统考虑

web 应用程序中的操作系统也许是与用户最不相干的，因为用户是通过浏览器进行交互的。然而，一些经济和技术方面的因素可能会有一些影响：

• 如果需要依赖特定的代码，而这些代码又依赖于操作系统，那么在做选择时需要考虑这种约束。
• 如果存在集成外部应用程序的普遍需求，而在某种操作系统上进行这种集成要比在另外一种操作系统上更好，那么在选择时也要考虑到。

考虑到云的经济效益，人们总是倾向于那些性能良好、许可费更低的操作系统。扩展 web 应用程序的主要方法就是横向扩展；这意味着随着 SaaS 应用程序的发展，web 应用服务器实例的总数也将随之增加，这将产生直接的操作成本。

数据库考虑

web 应用程序中的数据库对于最终用户来说可能也不是一个关键的考量因素，因为他们的交互是通过浏览器完成的，并且只要应用程序能够存储和检索其数据，那么数据库与他们就没有多大的关系。

经济和技术方面的因素再一次对应用程序开发人员产生了影响。如果应用程序需要依赖数据库的一些特殊特性，那么在做选择时就会受到限制。

数据库的选择对于应用程序的许多设计都非常重要，对 SaaS 环境的特殊需求也会影响数据库的选择。

在 SaaS 应用程序中，由于最终的用户数的原因，对数据库的要求会更高一些；因此数据库的可扩展性非常重要。数据库可扩展性通常在一个单独的实例上实现，同时使用越来越强大的数据库服务器满足要求更加苛刻的应用程序。但是 SaaS 应用程序要求的可扩展性可能会超出纵向可扩展性的极限，因此，数据库可扩展性的下一步是采用集群化功能。