随着云原生时代的到来，线上基于云服务提供的sas租户平台越来越多 。
SaaS 是 Software-as-a-Service（软件即服务）的简称，从技术角度上可称之为 “多租户技术或称多重租赁技术”。它与 “按需软件、应用服务提供商、托管软件” 所具有相似的含义。它是一种通过互联网提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。用户不再需要购买软件，而改用向提供商租用基于Web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商会全权管理和维护软件，软件厂商在向客户提供互联网应用的同时，也提供软件的离线操作和本地数据存储，让用户随时随地都可以使用其定购的软件和服务。对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要。
大家可能一直没有考虑我们的数据存在于远程服务商那里。服务商如何保证数据的隔离以及安全？作为SaaS开发者，这是必须要考虑的问题。针对不同客户和场景有三种不同选型和方案。
方案一，独立数据库（物理隔离）
这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本较高。 在一个成熟的sas平台下，政府机关、医疗单位或者涉密机构不允许将数据与其他用户混淆，甚至要求我们提供独立的数据存储单元或者接入他们自己的数据库服务器。整个设备都是由甲方租户提供。
优点：
- 极好的可扩展性
- 完全隔离的数据环境
- 完全隔离的运算资源
- 易于理解与维护的架构
缺点：
- 高昂的软硬件成本
- 重复的基础数据与一致性问题：例如在软件运行过程中，我们为每个客户构建了一台虚拟机，需要有一些基础的字典数据，如字典表里的类型或者各种各样的运行基础数据。这些数据需要均摊成多份。例如在软件升级时，针对底层的基础数据需要进行升级或者增加一个字段，这时所有用户都需要同步维护。你可以考虑到这里面更新和维护的成本和风险相当高。
- 升级维护遇到新的挑战：例如我们发现了一个软件bug，针对不同用户定制了多种版本。问题来了，这些基础性软件bug需要适用于所有客户，否则可能会出现致命问题。
- 跨租户的汇总统计麻烦：因为我们已经进行了高度定制化，所以这个时候我们需要对每个用户进行适配。同时数据是分散存储的，我们需要收集整体运行数据，例如某个维度的全局汇总。这时候就比较麻烦，因为数据是分散的，所以我们需要开发额外的数据捕捉程序。
- 开发多数据源调度代理
使用场景：
- 不差钱儿又对数据安全要求极高的用户
方案二，共享数据库，Schema隔离（逻辑隔离）
这是第二种方案，即多个或所有租户共享 数据库服务器，但是每个租户一个 Schema。我们称之为逻辑隔离。
优点：
- 较低的服务器硬件成本
- 易于理解与维护的数据库架构
- Schema级别的隔离
- 独立运维，方便定制与扩展
缺点：
- 鸡蛋都装在一个篮子里，对数据数据架构要求更高
- 服务器资源争执问题，难以避免高负载操作对别的租户形成挤压：所有scheme都共享一台数据库服务器的计算资源，如果出现高压力，例如高io操作，就可能会影响其他租户的使用体验和执行性能，从而导致无法避免的打架情况。
- 跨租户的汇总统计麻烦
- 不同Schema的路由需要自定义
适用场景：
- 预算有限的中小型SAAS平台
方案三，字段级别隔离
优点：
- 最简单粗暴，通过“租户ID”字段区分数据
- 成本最低，结构最简单
- 方便全域统计分析
缺点：
- 毫无隔离性而言：这个优势相比于劣势更为致命。首先，毫无隔离性地将所有数据汇集在一起，这是严重的后果。
- 对单个租户定制与扩展几乎无法实现：单个租户几乎无法实现功能定制。例如我们在商品价格表中额外针对用户，扩展一个字段，其它用户又用不到它，扩展后会对整体产生全局影响。
适用场景：
- 初创型企业快速产品交付
- 提供产品原型
建议尽量避免使用，无论从性能还是架构来看都非常糟糕。我能想到的适用场景是初创型企业快速进行产品交付，如何快速提品原型，他们向客户演示时我们才会这么做。
