完全理解微商城多租户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），使用表进行数据隔离数据库。底层库好比是：DB二、ORACLE等，一个数据库下能够有多个SCHEMA。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

数据库模式参考模式四。

优势：有利于定制不一样租户的个性化需求。例如：交互界面不一样、工做流不一样等等。

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

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

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

调用链路变长，须要作必定的优化处理；

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

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