目录
1. SaaS成熟度模型
2. SaaS应用平台
3. SaaS应用实现层次
4. 多租户技术
5. 可配置性
5.1 业务构件
5.2 数据可配置
5.2.1 定制字段
5.2.2 预分配字段
5.2.3 名称值对
5.3 功能可配置
5.3.1 业务构件设计
5.3.2 功能包设计
5.3.3 销售包设计
6. 可伸缩性
6.1 应用服务器层水平扩展
6.2 数据库层水平扩展
6.2.1 垂直切分
6.2.2 读写分离
6.2.3 水平切分
7. 身份认证
7.1 单点登录
7.2 身份认证的方式
软件即服务 (Software as a Service, SaaS) 是托管在云端的应用软件，由 Web 浏览器、移动应用程序或瘦客户端通过互联网连接使用。用户通常通过订阅的方式，按需支付服务费用，而无需购买、安装和运维软件及相关硬件。SaaS服务商负责软件的维护、更新和安全保障，使用户能够随时随地通过网络访问最新版本的软件。SaaS应用广泛，涵盖了从办公自动化、客户关系管理（CRM）、企业资源规划（ERP）到项目管理和协作工具等各个领域。
1. SaaS成熟度模型
根据SaaS应用是否具有可配性、多租户、可伸缩性的特性，SaaS成熟度模型分成四级：用户定制/特定、可配置、多租户和可伸缩多租户。
（1）第一级成熟度模型—特定/定制
第一级成熟度模型类似于ASP（ Application Service Provider ）模式。在这种模型下，软件服务提供商为每个客户定制一套软件，并为其部署，如图1所示。每个客户使用使用独立的数据库实例和应用服务器实例。数据库中的数据结构和应用的代码都可能根据客户需求做过定制化修改。
图1. 成熟度1：特定/定制
（2）第二级成熟度模型—可配置
在第二级成熟度模型中，软件的部署架构没有发生太大变化，依然是为每个客户独立地部署一个运行实例，只是每个运行实例运行同一份代码，通过配置的不同来满足不同客户的个性化需求。因此，第二级成熟度模型的最主要特性是可配置性，如图2所示。
图2. 成熟度2：可配置
（3）第三级成熟度模型—单实例多租户架构
在第三级成熟度模型是在第二级成熟度模型的基础上增加了多租户支撑能力，软件服务提供商通过运行一个应用实例来为所有的租户服务，同时通过可配置的元数据来给每一个租户提供不同的用户体验和功能，如图3所示。
图3. 成熟度3：多租户架构
（4）第四级成熟度模型—可伸缩的多租户架构
第四级成熟度模型也称为可伸缩的多租户架构，SaaS应用的可伸缩是指随着租户数量的增加，系统架构不用做调整，而仅需要增加相应的硬件设备（(应用服务器、数据库服务器）即可，如图4所示。
图4. 成熟度4：可伸缩多租户架构
SaaS软件成熟度模型的渐进步骤：
- 实现多租户架构：多租户架构是SaaS应用的基本特征，也是实现SaaS规模效应的基本元素。
- 实现多租户下的高性能：高性能无论是对于客户体验，还是降低成本的角度都是至关重要的。
- 实现可配置：如何有效地抓住客户群体的需求变化，并针对这些变化进行相应的设计，实现可配置性，以取得可配置性与系统复杂性的平衡十分重要。
- 实现可伸缩：可伸缩包括应用层可伸缩和数据库可伸缩。可伸缩方面的考虑应该基于目前系统容量与未来一定时期内期望达到的系统容量。
2. SaaS应用平台
SaaS应用在功能上存在着共性，为了简化SaaS应用的开发，就需要把那些共性的功能以平台的形式实现，从而使所有SaaS应用可以直接使用这些功能，而不需要重复开发，实现这些功能的系统就是SaaS平台。
SaaS平台是基于基础设施即服务平台（IaaS平台）和平台即服务平台（PaaS平台）之上的。SaaS平台主要是为SaaS应用提供通用的运行环境或系统部件，如多租户支持、监控、认证和安全、定价与计费等功能，使SaaS软件提供商能够专注于客户所需业务的开发。
SaaS平台的直接使用者是独立软件提供商（ISV）。ISV基于SaaS平台提供的功能，快速实现客户的需求，并以SaaS的模式交付软件实现的功能。整合每个ISV都将面临的问题，也出现专业的整合服务提供商。
3. SaaS应用实现层次
SaaS应用的实现可分为四个层次，如图5所示。
图5. SaaS应用实现层次
（1）实现层次1：应用提供商依靠SaaS平台实现SaaS应用的交付，专注于用户需求。该方式会牺牲一定的系统灵活性和性能，但是能够以较低的投入快速实现客户需求，适用于规模较小或正在起步的公司。
（2）实现层次2：应用提供商使用PaaS层提供的应用环境进行SaaS应用的开发、测试和部署。该方式较第一种方案的应用提供商的要求更高，但是也赋予其更强的控制能力，使其能够针对应用的类型来优化SaaS基础功能，适用于规模较大、相对成熟的公司。
（3）实现层次3：应用提供商只使用云中提供的基础设施层服务。在该方式中，应用提供商不但需求实现SaaS应用的功能需求，还需要实现安全、数据隔离、用户认证等非功能性需求，同时，还需要负责应用的部署和维护工作。采用该实现层次的公司不但需要具有应用软件的开发能力，还必须具备丰富的平台软件开发能力。
（4）实现层次4：应用提供商不依赖于任何云计算下层的服务，而是在自有的硬件资源和运行环境上提供SaaS应用。在该方式中，应用提供商不依赖于任何云计算下层的服务，而是在自有的硬件资源和运行环境上提供SaaS应用。因此，应用提供商不仅要负责应用和平台功能的开发、部署，还需要提供和维护硬件资源。采用这种实现实现层次的公司往往具有雄厚的资金和技术实力。
4. 多租户技术
多租户技术使得大量的客户能够共享同一堆栈的软件、硬件资源，每个客户能够按需使用资源，能够对软件服务进行客户化配置，而且不影响其它客户的使用，这里的每个客户称为一个租户。如何进行有效的数据隔离是现实多租户技术核心。数据隔离是指多个租户在使用同一系统时，租户的业务数据是相互隔离存储的，不同租户的业务数据处理不会相互干扰。
目前SaaS多租户系统中的数据隔离主要有三种方案：独立数据库，共享数据库、隔离数据架构，共享数据库、共享架构。
图6. 三种数据隔离方案
（1）独立数据库。该方案是为每个租户分配一个独立数据库系统，这种实现方案的用户数据隔离级别最高，安全性最好，可以实现物理隔离，但是成本较高。
（2）共享数据库、隔离数据架构。在该方案中，所有租户共用同一数据库系统，每个租户在数据库系统中拥有一个独立的表空间。
（3）共享数据库、共享架构。该方案是最简单的数据隔离方法，即在每张表中都添加一个用于区分租户的字段（例如，tenantId）来标识每条数据属于哪个租户，当进行查询的时候每条语句都要添加该字段作为过滤条件，其特点是所有租户的数据全都存放在同一个表中，数据的隔离性是最低的，完全是通过字段来区分的，但该方案的成本较低。
三种数据隔离方案的对比如表1所示。在实际的多租户系统中，这种三方案是混合使用，针对不同的租户可以采用不同的数据隔离方案。
| 数据隔离方案 | 隔离级别 | 共享级别 | 安全性 | 成本 |
| 独立数据库 | 高 | 低 | 高 | 高 |
| 共享数据库、隔离数据架构 | 中 | 中 | 中 | 中 |
| 共享数据库、共享架构 | 低 | 高 | 低 | 低 |
5. 可配置性
可配置性是指SaaS应用能够支持不同租户对SaaS应用的配置进行定制。可配置性的基本要求是一个租户的客户化操作不会影响到其它租户，这就要求多租户系统能够对同一个SaaS应用实例的不同租户的配置进行描述和存储，并且能够在租户登陆SaaS应用时，根据该租户的客户化配置为其呈现相应的SaaS应用。多租户场景下，成千上万的租户共享同一个应用实例，在现有的平台技术中，比如Java EE，对应用配置的更改通常会对该平台中的所有用户产生影响，因此，如何支持不同租户对同一应用实例的独立客户化配置是多租户技术面临的一个基本挑战。
5.1 业务构件
业务构件（Business Component）是业务对象的软件实现，表达了自治的业务概念。业务对象是指在业务领域中具有独立存在意义的实体或概念，如客户、订单、产品等。业务构件与业务对象之间的对一对多的关系，即，一个业务构件可以实现多个对象的功能。
业务构件是SaaS应用进行配置的基本单元。从软件实现角度，一个业务构件的架构可分为六个层次：界面层、控制层、服务层、数据访问层、领域实体层和数据库层，如图7所示。
（1）用户界面层：负责与用户交互，展示数据并接收用户输入，提供图形化的用户界面，如Web页面、桌面应用程序UI、移动应用程序界面等。基于Web用户界面层一般采用HTML/CSS、JavaScript、Vue/React/Angular、elementUI/esayUI等技术实现。
（2）控制层：协调界面层和服务层之间的交互，接收来自界面层的用户请求，调用服务层提供的接口，并将执行结果返回给界面层的视图。在Spring框架中，控制层的组件采用@Controller注解来标识。
（3）服务层：实现业务对象的核心业务逻辑，不直接处理用户交互或数据存储，而是专注于执行核心的业务功能。服务层的组件可以协调多个数据访问对象并处理事务逻辑。在Spring框架中，服务层的组件采用@Service注解来标识。
（4）数据访问层：负责与数据库进行交互。提供抽象的数据访问接口，屏蔽底层数据存储技术的细节，执行增删改查等基本的数据操作。在Spring框架中，数据访问层主要主要采用ORM框架来实现，例如，MyBatis、Hibernate等。
（5）领域实体层：定义了业务构件所封装的业务对象和相应的业务实体，封装了业务实体的属性，对外提供相应的set/get操作。
（6）数据库层：负责数据的持久化存储和管理。提供数据库服务,保证数据的安全性、完整性和一致性。包括具体的数据库管理系统（例如MySQL、PostgreSQL，或NoSQL数据库如MongoDB），以及数据库的表结构、索引、存储过程和触发器。
业务构件不同层次之间遵循严格的依赖关系，下一层的组件不能访问上一层的组件。界面层的组件只能访问控制层的组件，不能直接访问服务层和数据访问层的组件。控制层组件只能访问服务层的组件，不能直接访问数据层组件，不同业务构件之间的控制层组件也不能相互访问。一个构件的控制层组件只能访问自己的数据访问层组件，不能访问其它业务构件的数据访问层组件，但可以访问其它业务构件的服务组件，其访问关系如图7所示。
5.2 数据可配置
SaaS应用中的数据可配置主要有三种方案：定制字段、预分配字段、名值对。
5.2.1 定制字段
定制字段是根据客户需求在数据表上增加相应的定制字段来保存扩展数据。例如，根据租户10需求，在客户表中增加来源（source）和介绍人（introduce）两个字段，如下图所示。
该解决方案更多还是在传统软件中被采用，针对SaaS应用系统，如果为每一个租户都添加额外的定制定制，随着定制字段的增多，将产生大量无意义字段，严重影响数据库性能。
5.2.2 预分配字段
预分配字段是指在用户可能有扩展需求的表中预设定一定数量的字段，当用户提出扩展需求时，使用其中的一个或多个字段来保存扩展数据。例如，在客户表中增加了三个预分配字段，一个整型字段（ExInt），一个字符串字段（ExtStr）和一个日期字段（ExtDate），如下图所示。
对于不同的租户，同一预分配字段的含义可能不同，例如，ExtStr对于租户10来说，保存的是来源，而对于租户20来说，保存的是职业。虽然设置了3个预分配字段，但却保存不了租户20的来源和介绍人两个扩展字段，因为这两个字段都要求按照字符串保存，而客户表只有一个预分配字符串字段。如果为每种数据类型都设置足够多的预分配字段，又会造成许多无意义的空闲字段。
针对上述预分配字段存在的问题，可以将所有的扩展数据转换为字符串以后再进行存储，这样预分配字段的数据类型就可以全部定义成字符串了，这样在预分配字段的总数不大于单个租户要扩展的字段个数情况下，就可以满足所有客户的数据可配置需求，如下图所示。 对于分配字段的含义和类型，需要单独定义一个配置元数据的数据表来保存。对于不同租户使用各表中的每一个扩展字段，在配置元数据表中分别保存一条配置记录，例如，同样保存在字段Ext1中的数据，对于租户10来说，要转换成字符串类型，对于租户20来说，要转换成整数类型，而对于租户30来说，要转换成日期类型。
有了元数据表，在使用租户的扩展数据时，就可以根据当前的租户tenantId和所在的数据表table查询到该租户使用了哪几个预分配字段，以及各字段的数据类型和数据含义。这样，就可以将扩展数据转换成相应的数据类型来使用，并在界面上展示该扩展数据的含义，真正实现数据的可配置。
预分配字段方案在虽然一定程度上很好地实现了数据的可配置性，但是预分配字段的个数在系统设计时就必须确定，如何确定预分配字段的个数是个困难的问题。如果预分配字段设计得太多，就会造成数据表膨胀，还会产生很多无意义的空闲字段，造成浪费，从而引发数据库性能下降等问题。如果预分配字段太少的话，更多用户的扩展数据就没有地方可以保存，无法满足扩展数据可配置的需求。
5.2.3 名称值对
为了解决预分配字段存在的问题，可以采用名称值对模式。名称值对模式将扩展数据的保存与原数据分离，另外用一张统一的扩展数据表来保存。扩展数据表将数据表的横向扩展列转换成纵向的数据集，将每一条原数据记录的每一个扩展字段，都保存成一条扩展数据行。将数据表中的数据记录与配置元数据表中的配置记录关联，构成扩展数据记录，如下图所示。
在配置元数据表中所配置的扩展数据与业务数据表中的租户TenantId是对应的，扩展数据表中的DataId与业务数据表中的主键是对应的，而扩展表的ConfigId与配置元数据表中配置扩展项是对应的。与租户配置的扩展数据项个数相对应，该租户的每一条业务数据都会有相应个数的扩展数据被保存。例如，租户20针对customer数据定义了两个扩展数据22（salary）和23（work），那么与租户20的业务数据112对应就会有两条扩展数据1003（salary:3000）和1004（work：Teacher）。
名称值对模式给扩展数据的保存提供了非常大的灵活性，可以提供无限数量的自定义扩展字段。针对不同的租户，定义不同的扩展数据，在扩展表中只会保存该租户的扩展数据，不会再有空闲的字段，其他租户也不会因此占有多余的空间，因此，这种模式不会造成资源的大量浪费。这种模式在带来灵活性的同时，也增加数据操作的复杂性。新增、修改和删除数据时，都需要对自定义数据进行分拆处理。查询数据时，也需要多次访问数据库才能获取到完整的业务数据。所有这些都会影响数据访问的性能。另外，该模式也无法针对扩展字段很方便地进行一些统计和关联查询。
5.3 功能可配置
SaaS应用具有“按需使用，按使用量付费”的特征，这种特征体现在两个方面：多租户SaaS应用能够支持让租户有选择地购买自己需要的功能，不同的租户可以同时使用不同的功能集合；同一租户在不同时期，可能会有不同的需求，可以选择不同的功能集合，并为之付费。
5.3.1 业务构件设计
业务构件是对业务对象的封装和实现，对外提供一组原子功能，所有原子功能叠加起来就是整个应用所提供的全部功能。例如，可将CRM系统划分为5个业务构件：产品、客户、客户服务、订单和行程。每个业务构件所提供的原子功能以及业务构件之间的关系如图8所示。
图8. 业务构件设计
5.3.2 功能包设计
功能包设计就是要根据用户的类型和系统的业务逻辑，综合考虑用户的使用场景和使用习惯，将原子功能进行组合，设计成功能包。功能包设计遵循高内聚、低耦合的原则，将相互关联的原子功能组合成一个个功能包。例如，根据上述原则对CRM系统进行功能包设计，将原子功能组合成7个功能包：订单管理、产品管理、基础管理、客户管理、客服人员管理、服务记录管理、行程管理，如图9所示。
图9. 功能包设计
5.3.3 销售包设计
通过功能包设计，已经将系统功能组合成几个相对比较独立的部分，但这些功能包仍然不可以完全独立使用。为了让客户购买以后能够充分地使用系统，还需要按不同的商业意图构造适宜于用户使用的销售包。销售包只是一种以向用户进行销售而定义的一种功能包。例如，针对CRM系统，按照用户需要使用功能多少将其划分为最小版、标准版、完整版；按照客户所属的行业类型划分为服务业版、制造业版，如图10所示。
图10. 销售包设计
6. 可伸缩性
SaaS应用的可伸缩是指随着用户数的增大，系统架构不用做调整，而仅需要增加/增强相应的硬件设备（应用服务器、数据库服务器）即可。实现可伸缩的最简单的方式是垂直扩展（Scale up），也就是增强硬件设备，但是这种方式通常面临高成本问题。SaaS应用的可伸缩一般采用水平扩展（Scale out），包括：应用服务器层水平扩展和数据库层水平扩展。
6.1 应用服务器层水平扩展
实现应用服务器层水平扩展的主要手段是负载均衡。负载均衡是一种在多个应用服务器实例之间分配工作负载的技术，其的目的是优化资源利用率，最大化吞吐量，减少延迟，并确保高可用性。实现负载均衡主要有两种方式：硬件负载均衡和软件负载均衡。基于硬件负载均衡是使用专业的硬件设备（如F5）进行流量分发，这些设备通常功能强大，性能稳定，但是价格较高。基于软件的负载均衡使用软件工具（如Nginx、Apache）进行流量分发，这些工具灵活性高、成本较低。Nginx是目前使用最为广泛的一种基于软件的负载均衡工具，其架构如图11所示。
图11. 基于Nginx的应用服务器层水平扩展
Nginx是一个高性能的反向代理服务器和负载均衡器，其基本工作流程如下:
1）客户端向Nginx发送HTTP请求。
2）Nginx根据预设的负载均衡策略，选择一个后端服务器来处理HTTP请求。
3）Nginx将HTTP请求转发给选定的后端服务器。
4）后端服务器处理请求并返回响应给Nginx。
5）Nginx将响应返回给客户端。
Nginx中的主要负载均衡策略如下：
- 轮询（Round Robin）：依次将请求分配给各服务器，适用于各服务器性能相近的情况。
- 加权轮询（Weighted Round Robin）：根据服务器的权重分配请求，用于处理不同性能服务器的场景。
- 最少连接（Least Connections）：将请求分配给当前连接数最少的服务器，适用于请求处理时间较长的情况。
- 源IP哈希（Source IP Hash）：根据源IP地址计算哈希值，将相同IP地址的请求分配给同一台服务器，适用于需要保持会话一致性的情况。
由于大部分应用的用户请求是有状态的（一般使用Session记录用户状态），在这种情况下，如何能够在多台应用服务器之间保持Session一致性是实现应用服务器水平扩展的关键。在负载均衡的环境中保持Session一致性是确保用户在不同服务器之间切换时没有中断或丢失会话的重要措施。使用Nginx进行负载均衡时，可以通过多种方式实现Session一致性。以下是几种常见的方法：
- Session复制: 将每个应用服务器的Session数据实时同步到其他服务器，保证所有服务器的Session数据一致，但这种方式会增加服务器之间的通信开销，影响性能。
- Session集中存储: 将Session数据存储在一个集中的存储服务中，如Redis、Memcached等。所有应用服务器都从这个集中存储读取Session数据，保证Session的一致性。这是目前比较常用的方案。
- 基于Cookie的Session粘滞: 将Session的ID或哈希值存储在Cookie中，通过Nginx的Hash算法将同一用户的请求始终路由到同一个后端服务器。这种方式简单易行，但是当后端服务器宕机时,Session会丢失。
- 基于IP的Session粘滞: 将同一IP的请求始终路由到同一个后端服务器。这种方式的缺点是当多个用户共享同一个IP时，会造成Session的混乱。
6.2 数据库层水平扩展
实现数据库层水平扩展的主要方案有：垂直切分、读写分离、水平切分。
6.2.1 垂直切分
数据库的垂直切分是指将SaaS应用中不同的功能模块所涉及的表划分到不同的物理数据库中，从而将对这些表的访问压力分担到多个不同的物理数据库中，如图12所示。垂直切分需要考虑问题是：原本可能存在的表连接，需要想办法去除；原本同一个数据库的事务操作，可能变成跨数据库的事务。数据库垂直切分到一定粒度以后，就很难继续下去，其切分代价较高。
图12. 数据库的垂直切分
6.2.2 读写分离
数据库的读/写分离的是指同一数据库在多个物理服务器上具有多份Copy，彼此同步，然后将数据库的写操作都统一到一个主服务器上，而读操作则分摊到多台从服务器上，如图13所示。通过读/写分离，可以实现数据库访问压力的分摊。对于读多写少的互联网应用，会广泛采用读/写分离技术。MySQL的Replication是被广泛使用的读写分离技术。对于读写分离，如果Slave Database Server过多可能造成Master-Slave之间的同步性能降低，另外，如果应用读/写比例不是很悬殊，单纯增加Slave Database Server对于SaaS应用性能的提升一般没有特殊作用。
图13. 数据库的读写分离
6.2.3 水平切分
数据的水平切分是指将原来存储在一个数据库中的数据，按照一定的规则，切分到多个不同的物理数据库中。对于数据库水平切分，每个数据库的数据结构完全相同，但是数据各不相同，最终对于业务数据的访问，会根据其数据所在的数据库，定位到某一个数据中查询，如图14所示。由于不同租户的数据被分布到不同的物理数据库上。因此，随着租户数量增加，仅需要通过增加新的租户业务数据库，并将新的租户映射到新增的租户业务数据库上即可。
图14. 数据库的水平切分
数据的水平切分应考虑如下原则：
- 按照租户来划分数据库，这是因为SaaS应用的不同租户之间在业务上没有任何联系，租户之间的数据是完全隔离的。只有很少部署的共享数据(平台配置信息)，但它们之间通常都是只读的，是不允许任何租户修改的。
- 租户和用户数据也存储在集中式数据库中，这是因为在用户登陆之前，系统是无法预知其属于那个租户的。
- 将租户分配到哪个物理数据库也作为关系表存储在集中式的租户数据库中，在用户登陆时，通过查询相应的关系表，即可确定其对应租户的业务数据存储在具体哪个物理数据库中。
三种数据库层水平扩展方案的比较如下表：
| 扩展方案 | 优点 | 不足 |
| 垂直切分 | 实现简单 | 扩展能力有限，强关联的应用不容易垂直切分 |
| 读写分离 | 可有效分担读的压力； | 对于读的比例不高的应用，扩展能力有限； |
| 水平切分 | SaaS应用中普遍适用； | 实现比较复杂，应用一般需要做较大改进； |
7. 身份认证
身份认证是为了解决“如何保证以数字身份进行操作的操作者就是这个数字身份的合法拥有者，也就是保证操作者的物理身份与数字身份相对应”的问题。身份认证就是对客户身份的识别和验证，这是保证整个系统应用安全的基础。SaaS应用身份认证技术与传统的应用系统身份认证技术基本一致，目前经常采用的认证方式是集中式的单点登录(Single Sign On, SSO)身份认证，即用户只需登录一次就可以访问所有相互信任的SaaS应用系统。
7.1 单点登录
下面以图15所示的应用描述单点登录流程的主要步骤：
- 当用户第一次访问SaaS服务A的时候，因为还没有登录，会被引导到SaaS的身份认证中心系统。
- 认证系统根据用户提供的登录名和密码信息进行身份验证。如果用户输入的认证信息通过验证，认证系统会将一个认证凭据(Ticket)返回给用户，并通过超链接将用户送回SaaS服务A，同时加上通过认证的Ticket作为合法认证凭据。
- SaaS服务A接收到请求后会把Ticket发送到认证系统进行，检查Ticket的合法性。通过Ticket身份认证后，用户访问信任该SaaS应用的其它SaaS服务时就不需要登录了。
图15. 单点登录流程
7.2 身份认证的方式
实现身份认证可以采用集中式认证、非集中式认证和混合认证三种方式。
集中式认证。集中式认证是由SaaS应用系统提供一个统一的用户身份认证中心。所有租户都到这个用户中心来管理和维护各租户的身份数据，SaaS应用直接到统一的认证中心对用户身份进行校验，如图16(a)所示。集中式认证在用户身份的安全性上更加容易得到保障，但需要租户在SaaS应用的身份认证中心维护自己的用户，不能复用已有系统的用户信息，不能与其他系统一起统一维护。
非集中式认证。非集中式认证就是各租户使用自己的用户身份认证系统进行身份校验，并且发布安全令牌。SaaS应用实现一个身份中心，负责接受安全令牌，并据此获取用户身份信息，允许用户使用系统，如图16(b)所示。非集中式认证最大程度地复用租户现有的认证中心，能够实现用户身份的统一维护，容易实现租户各个系统之间的单点登录。这种认证方式的安全性依赖于各租户自身的认证系统。由于各租户在管理上及对安全性的要求是不一致的，导致SaaS应用身份认证的安全性容易出现短板。
混合认证方式。对于多租户SaaS应用来说，可能需要面临集中式认证方式与多种非集中式认证方式同时存在的混合认证方式。一般情况下，大多数中小型租户自己并没有专门的身份认证中心，要求SaaS应用本身提供集中的认证中心；而对于较大的租户，可能已经建立起自己的身份认证系统，如图16(c)所示。这就要求SaaS应用既要实现统一的集中式认证中心，供大多数中小型租户使用，同时，还需要支持部分租户自身的身份认证系统。
图16. SaaS身份认证方式
三种认证方式在安全性、灵活性、用户使用体验、用户维护难度、实现复杂性等方面存在较大差异，如下表所示。
| 比较项 | 集中式 | 非集中式 | 混合方式 |
| 安全性 | 高 | 低 | 低 |
| 灵活性 | 低 | 中 | 高 |
| 用户使用体验 | 不好 | 好 | 好 |
| 用户维护难度 | 高 | 低 | 低 |
| 实现复杂性 | 低 | 中 | 高 |
参考文献
1. 叶伟等. 互联网时代的软件革命：SaaS应用架构设计. 电子工业出版社，2010.1
2. 雷葆华等. 云计算解码. 电子工业出版社, 2011.4.
