多租户系统设计
SaaS 的系统分级
SaaS 系统架构成熟度模型的 5 个级别——从“混乱”到“乌托邦“
• 第 0 级（混乱）：每次新增一个客户，都会新增软件的一个实例。
• 第 1 级（受控的混乱）：所有客户都运行在软件的同一个版本上，而且任何的定制化都通过修改配置来实现。
• 第 2 级（多租户 [multi-tenant]、高层建筑 [HigHRise]）：所有的客户都已经可以在软件的同一个版本上运行了，而且他们都在同一个“实例”上运行。
• 第 3 级（多租户， 扩建 [Build-Out]）：此时你已经拥有了多租户、单一版本的软件模型。不过你还是可以通过硬件扩展（scale-out）的方式来停止扩大。
• 第 4 级（乌托邦）：仿佛第 3 级，除非你可以找出有效的方式，以在不同的“实例”上运行不同版本的软件
多租户可以分为几个不同的类别：
• 云中的简单虚拟化，其中只对硬件停止共享。
• 共享应用程序，对每个租户使用不同的数据库。
• 共享应用程序和数据库（效率最高，真正的多租户）。
我们要实现的也即效率最高的，真正的多租户业务模型。但选择是有个挑选的过程的，下面分别介绍下各种多租户的数据隔离方案。
独立应用独立库
有多个不同的应用，每个应用都有自己的数据库。这种方式虽然保证了租户数据的隔离，但无论是在扩展性和本钱上都是最差的，故首先淘汰这种方式。
同一个应用程序，每个租户一个库
优点是
• 租户数据在数据库维护物理上隔离了，
• 由于是每个租户一个库可以在库表设计上做单独扩展，但这也引起了应用程序的兼容问题
缺点是数据库维护本钱高，（举例：在相同数据构造的情况下，增加表中的列或索引，需要操作多个库）开发本钱也高。
同一个应用程序，同一个数据库
缺点：多租户数据库必然会牺牲租户隔离。多个租户的数据一起存储在一个数据库中。在开发过程中，确保查询不会暴露来自多个租户的数据。
优点：是所有方案中本钱最低的。
分片多租户
分片多租户即：多租户的单应用+支持多租户的单数据库（分片）
看起来是不是跟第一个图中：同一个应用程序，每个租户一个库形式差不多，只不过每个库多了几个租户数据？
其实是大不相同的。
首先，第一种形式中不同租户的库是可以分别扩展的，也就是构造可以不一样，但分片多租户的是同一种数据构造。
其次，分片形式的扩展性很强，它可以是一个分片一个租户，也可以是一个分片多个租户，详细要看详细的分片战略。
来看下分片形式下详细的指标情况：
我们的模型选择
基于以上的分析，我们选择采用分片多租户的模型，因为这样可以获得无限的扩展才干，且对租户数据的隔离性也比较好。
这样的话数据库构培养是统一的，不同分片是同一库表构造。而详细分库规则是可以配置的，建议前期依照 一租户一库 的战略配置。
开发理论
• 每一个表的设计都应该考虑是否要参与 “租户 ID”字段，用来区别不同“租户”，或者不同客户，另外，也方便后面用“租房 ID”作为 分片键
• 我们将引入 ShardingSphere 帮我们做数据库的分库分表，对于应用来说是相对透明的，减少应用开发在数据库层面由于引入分库分表的复杂度。
• 我们利用分片规则对数据停止分片，例如根据租户 ID，配置分库分表规则
多租户与单租户的区别。租户可分为多租户和单租户，简单一点理解就是——多租户是多个客户使用同一个实例，数据存储在相同的位置，通过数据库、数据表和tenantID字段三种方式停止数据隔离，适宜规范化水平较高的场景；单租户是指多个客户使用多个实例，各个客户使用的实例和数据存储单独运行，更适宜定制化需求场景。 |
