谈一谈SaaS产品的架构设计
1. SaaS 是什么
从字面中理解SaaS的全称是Software as a service, 即软件即服务。
从服务模式来看，SaaS是一种软件授权和交付模式，以订阅模式代替传统授权模式，以集中式部署代替用户环境部署，通常被认为是按需付费软件。
目前SaaS被广泛的认为是云计算的一部分，跟Infrastructure as a service, platform as a service, xxx as a service等并列。
从用户访问方式来看，用户一般使用像浏览器这样的瘦客户端访问SaaS应用，随着更多的企业级软件陆续提供SaaS化，客户端也将变得更加丰富，如微软Office 365, 钉钉，Saleforces, Oracle Fusion Cloud等。
2. SaaS产品的前世今生
SaaS的产品可以简单的分为三个阶段。
第一阶段是在上世纪60年代，将各种商业应用集中托管在一台大型主机里，从这个年代起IBM和其它大型机厂商提供一种服务中心业务，为客户提供分时享用和效用计算服务，这些大型机厂商通过还提供计算资源和数据库存储服务。
第二阶段是上世纪90年代，随着Internet的不断扩展，一种新的集中计算服务出现，被称为应用服务提供商(ASP)。ASP不但提供应用服务所需要的主机，还提供专业化的业务应用，并且通过集中式的托管硬件与软件来降低客户成本。
第三阶段是进入新世纪后，SaaS将ASP模式发扬光大，但又有着明显的区别：
- 大多数的ASP厂商关注于管理和托管第三方独立软件厂商的软件，而SaaS厂商一般开发和管理自己的软件产品。
- 大多数的ASP厂商提供传统的客户端-服务器的应用，需要用户进行安装在自己个人电脑中，而大多数的SaaS应用今天都是运行在Web浏览器上，依赖Internet运行。
- 从架构上来看，大多数的ASP厂商强制为不同的业务应用维护不同的实例，而SaaS应用一般采用多租户架构，在同一个应用中服务不同的业务与用户，在数据访问上进行区分。
3. SaaS产品的架构设计
如上文所述，大多数主要SaaS应用都基于多租户架构，在这个架构中应用采用单一版本和统一的配置(硬件，网络，操作系统)为所有的用户服务。为了支持伸缩性，应用必须可以部署在多服务器中以支持横向扩展。有一些应用运行多版本共存，比如新版本上线后只能小部分用户开放以验证产品的稳定性，验证成功后才全量发布。
3.1 多租户架构优缺点
3.1.1 多租户架构优点
- 相对于单租户架构成本较低廉
- 提供灵活的按需付费价格模式
- 租户无需关心平台软件与硬件
- 租户的启用成本较低
- 服务提供者只需要监控和管理单一系统
3.1.2 多租户架构缺点
- 多租户应用相对于单租户架构缺少灵活性，对于租户的个性化需求可能需要较长时间满足。
- 多租户应用一般来说设计比单租户复杂，从系统设计之初中需要考虑安全隔离和资源合理共享。
- 多租户应用需要严格的授权与安全访问控制，从租户的角度是单一入口，从平台角度需要明确控制每个用户的访问权限，严格确保租户数据不被不当访问。
- 租户有可能受到其它租户的影响，比如说同一个应用中某租户在运行一个大查询并占用所有的计算资源，导致其它租户无法使用。
3.2 多租户架构设计
3.2.1 租户识别
租户识别是SaaS平台入口环节的重要功能，通过系统访问域名(DNS)和用户登陆信息来进行确认访问具体租户的应用与数据。
子域名进入：
域名格式参考：[租户域名].[部署池].[主域名].[根域名]
示例如下：my-pos.eastchina01.examledomain.com
公共域名进入：
登陆域: login.examledomain.com
用户成功登录后直接跳转到子域，用户在子域中访问系统，若一个用户绑定多个租户则由用户选择待进入的租户。
租户在资源层次结构中建立数据隔离边界,每个租户都有自己的以下属性：
- 唯一标识符
- 用户,角色，组织和权限
- 身份提供商和身份验证方法
3.2.2 存储资源隔离
多租户架构存储资源隔离模式主要有如下三种类型，不同类型的架构复杂度和成本均不同。
- 单一数据库且单一Shcema架构，所有租户的数据存储在相同数据库且同一个Schema中，通过业务表的租户标识字段区分，此架构是三种架构这中最简单成本最低的方式，所有租户均共用相同数据源。但此架构灵活性和扩展性较弱，依赖单数据源的扩展能力，长期的运营成本和管理成本较高。
- 单一数据库多Schema架构,将不同租户的数据存储在同一个数据库中的不同Schema中，可通过Schema控制数据访问权限。此架构可根据数据库不同，可以是多数据源或单数据源。
- 多数据库架构，将不同租户的数据存储不同数据库中，可以是不同的主机或者存储，对于隔离要求级别高的租户，可提供完全硬件隔离的架构。这种架构相对而管理和运维比较复杂，但对于租户来说隔离更加安全。
3.2.3 计算资源隔离
应用服务器采用共享集群的方式，将租户分配到不同的部署池中，租户的分配可采取随机或者容量规则，从并发数和数据库连接数的维度考虑每一个集群部署租户的数量。
3.2.4 缓存与消息中间件资源隔离
把所有的资源配置作为元数据，存储到配置中心，在系统运行时动态的创建和路由DataSource，消息集群，缓存集群，路由key为tenantId。
-
缓存服务，基于成本和管理的便利性，缓存服务采取垂直切分，根据业务模块和部署集群分配缓存集群。缓存KEY以Tenant识别符为前缀，在缓存访问层进行访问控制。
-
消息服务,基于成本与性能的考虑，给为每一个租户部署消息集群或者单独频道与队列变得复杂且低效。消息服务采取共享资源的访问，通过消息体进行约定，在消息体头部分加上租户标识，消息订阅者获得消息后根据消息头的租户ID进行处理，调用租户的API完成业务操作。
3.2.5 安全性
当租户选择一款SaaS产品时，产品的安全性将会放置在第一位考虑，如数据隔离，敏感数据加解密，数据访问权限，个人隐私以及运维流程。针对安全性的考虑，SaaS一般需要考虑以下几点：
- 统一的安全组件，安全组件就是统一对SaaS产品进行安全防护，保障租户的数据安全。比如说存储使用AES加密，加解密使用的密钥由租户掌握，使用时方对数据进行解密。
- 数据隔离组件，安全组件解决用户数据安全可靠的问题，数据还需要解决隐私的问题，各租户之音的数据必须相互不可见，相互隔离。
3.2.6 可配置界面
一个成熟的SaaS产品需提供灵活用户界面配置能力。当新版本发布时为业务对象增加一个字段，需要在Web端，移动端和关联的报表同步改动生效，那么产品能通过相同的工具和流程去配置产品。常见的配置项如下：
- 租户可自定义字段名称和描述
- 租户可自定义界面风格与页面布局
- 租户可增减字段以及校验逻辑
- 租户可自定义报表与分析
3.2.7 丰富的API
一个SaaS产品要取得成功，系统的集成能力是重要的一环，API设计是集成能力提供的关键因素。业内首屈一指的云厂商Amazon AWS的产品设计之初就提出Everything is API和The API first的策略。在产品内部所有的行为都应该是API的调用，无论是内部访问还是外部访问，一切设计均围绕API进行。
API能力以微软的AKS产品为例：
- 支持快速创建与发布API网关给内外部用户调用
- 有能力处理任务的数据格式并快速响应变化
- 有能力在任何时间任何地点连接后台服务，并提供管理，安全和优化的能力。
3.2.8 发布与部署策略
- 制定灵活的灰度来策略，可根据部署池，租户等策略进行灰度发布，并提供实时监控能力
- 自动化所有的发布流程，包括应用包，表结构更新以及数据补丁。
- 自动线上验收的能力，发布完成后系统有能力进行线上测试并汇总结果。
- 深入集成主流云厂商主要产品的API,通过CICD的能力一键完成发布与升级。
4. SaaS产品私有化部署
如果有土豪顾客对产品表示十分喜欢，受制于内部的安全因素无法在公有云上使用产品，灵活的SaaS需具备私有化的能力。要满足这个要求，在技术选型需考虑以下：
- 开放的技术栈，比如说Spring Cloud
- 主流的系统软件与中间件
- 引入尽量少技术产品与组件
- 容器化部署
- 可靠的CICD软件与流程
5. SaaS产品的简单实现
- 待续
6. 参考文档
- Multitenant SaaS on Azure
关于作者
微胖中年码农-老王