彻底理解微商城多租户Saas架构设计

彻底理解微商城多租户Saas架构设计

原文链接：https://blog.csdn.net/haponchang/article/details/104246317，感谢作者提供这么好的总结！

1.具体的SaaS架构必须

1.先仔细选择最适合应用程序需求的租户模型，

2.需要根据租户模型来选定最终的架构，即应用程序设计和管理、每个租户的数据如何映射到存储等等。

避免因租户模型的切换而付出昂贵的代价。

租户模型  --》 应用程序设计 + 数据设计方案

2.影响租户模型的相关因素包括：

2.1可扩展性（Scalability）

• 租户的数量级
• 每个租户的存储级别
• 整体存储
• 工作负载

2.2租户隔离性（Tenant isolation）

• 数据隔离和性能（是否一个租户的负载会影响到其他租户）

2.3单租户成本（Per-tenant cost）

• 数据库成本

2.4 开发复杂度（Development complexity）

• 数据结构的变化
• 查询语句的变化

2.5运维复杂度（Operational complexity）

• 性能监控
• 数据结构schema管理
• 租户数据恢复
• 灾备

2.4可定制化程度（Customizability）

根据租户的需求自定义架构的容易程度
这个租户的讨论集中在数据层。但考虑一下应用层。应用程序层被视为一个整体实体。如果将应用程序划分为许多小型组件，您的租户模型选择可能会发生变化。对于租户和存储技术或使用的平台，您可以对其他组件进行不同的处理。

3 常见的架构模式有以下几种：

3.1独立服务+独立数据库

这个模型中，应用层和数据层都是隔离的。

应用程序的每个实例都是独立实例。

租户拥有自己独立的数据库，每个应用程序实例只需要一个数据库。

对租户的管理独立于系统之外，对于每一个租户，整个应用程序需要重复安装一次。供应商都可以为租户管理软件。每个应用程序实例都配置为连接到其相应的数据库。

优点：为不同的租户提供独立的应用实例和数据库，有助于简化数据模型和业务模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复系统或数据均比较简单，系统间也不会相互影响。

问题：数据库层面，每个租户数据库都作为独立数据库进行部署。该模型提供了最大的数据库隔离。但隔离需要为每个数据库分配足够的资源来处理其高峰负载。这里重要的是， 弹性池不能用于部署在不同资源组或不同订阅中的数据库。这种限制使得这种独立的单租户应用程序模型成为从整体数据库成本角度来看最昂贵的解决方案；应用层面，每个租户若存在个性化定制，则需要对项目进行横向扩展，扩展时务必需要保证与主干版本的兼容性问题。运维层面，应用和数据库的安装数量会随租户的数量线性递增，随之带来维护成本和购置成本的增加。

3.2一套服务+独立数据库

这个模型中，应用层是共享的，数据层都是隔离的。

应用程序仅部署一套，所有租户实例共享。

租户仍拥有自己独立的数据库，应用程序需对接多个租户的数据库。

对租户的管理由配置中心（Config Server）管理，配置中心提供了配置，监视和管理共享所需的功能，供应商使用这些工具为租户管理软件。对于每一个租户，整个应用程序仅需要安装一次，应用程序实际请求结合配置中心请求相应的数据库。

优点：为不同的租户提供独立数据库，有助于简化数据模型扩展设计，满足不同租户的独特需求；如果出现故障，数据恢复均比较简单，也可以自动将单个租户恢复到较早的时间点。因为恢复只需要恢复存储租户的一个单租户数据库。这种恢复对其他租户没有影响，这证实了管理运营处于每个租户的细粒度级别。应用层面的维护成本和购置成本有所减少。

问题：数据库层面，同模型一；应用层面，每个租户若存在个性化定制，则需要对项目进行横向扩展，扩展时务必需要保证与主干版本的兼容性问题。运维层面，数据库的运维问题同模式一，应用层面的运维在版本控制的问题上难度有所增加。

3.3 一套服务+一套数据库（不同schema）

这个模型中，应用层是共享的，数据库共享，但数据是隔离的。

应用程序和数据库仅部署一套，所有租户共享。

多个或所有租户共享Database，也就是说共同使用一个数据库，但是每个租户一个Schema（也可叫做一个user），使用表进行数据隔离数据库。底层库比如是：DB2、ORACLE等，一个数据库下可以有多个SCHEMA。

应用程序需对接多个租户的数据库。

对租户的管理由配置中心（Config Server）管理，同模式二。

优点：为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多的租户数量。

问题：数据库层面，如果出现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据；应用层面，配置中心需要对租户信息进行完整且合理的分配和维护。

3.4 一套服务+一套数据库（相同schema）

模型与模型三的差别在于共享数据库，共享 Schema，共享数据表。也就是说共同使用一个数据库一个表使用字段进行数据隔离。如表中增加TenantID多租户的数据字段。这是共享程度最高、隔离级别最低的模式。

简单来讲，即每插入一条数据时都需要有一个客户的标识。这样才能在同一张表中区分出不同客户的数据，这也是我们系统目前用到的(tenant_id)。

优点：方案的维护和购置成本低，允许每个数据库支持的租户数量最多。

缺点：隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；数据备份和恢复最困难，需要逐表逐条备份和还原。

3.5网关+前台+中台+数据存储

模式五与之前的模式的最大区别是，在原有的web Service进行细化拆分，优化成 网关+前台+中台+数据存储的模式。

网关用于接收租户的请求，并发送给前台。

前台的数量与租户一致，每一个租户对应一个前台服务，方便针对租户进行个性化定制。

中台负责提供处理所有的业务请求，中台不关心租户是谁，将重心关注在业务的处理上。配置中心用于配置租户的接口权限、流程定制等相关配置信息。结合业务逻辑返回给前台特定租户的相关信息。

数据库模式参考模式四。

优点：有利于定制不同租户的个性化需求。例如：交互界面不同、工作流不同等等。

服务只需要根据用户需求在前台做相应的横向扩展即可；

不同租户间服务相互独立，互不影响。

缺点：模块划分需要做好划分，重点注重业务之间的低耦合；

调用链路变长，需要做一定的优化处理；

模块纵向拆分后，后期研发和运维难度均会有所增加；

好文收集不易，请转发或在看，谢谢！