多租户Sass架构 方案（转载）
多租户应用程序部署体系结构可以通过4种广泛的方式建模：
- 单独的应用程序和单独的数据库
- 共享应用程序和共享数据库
- 单独的应用程序和共享数据库
- 共享应用程序和单独的数据库
这里没有对与错。您应该考虑业务背景和约束条件，这是关于选择和后果的。在本文中，我打算记下一些关键点，以牢记这些多租户体系结构中的每一个。
单独的应用程序和单独的数据库
- 从开发和部署的角度来看，最容易实现。
- 只需为每个租户自动化部署基础架构即可快速设置。
- 从基础架构成本的角度来看，所有模型中最昂贵的。
- 大规模部署相对较长的部署时间以用于更新的应用程序版本。
- 从基础设施资源利用的角度来看，浪费更多。
- 应用程序的可伸缩性无状态标准意味着：
- 不保存用户请求数据
- 适应性：
- 这是启动SAAS平台的最佳方法，可用于产品市场，直至稳定和增长。
- 当您提供SAAS作为白色标签的产品时。
- 在客户端基础结构上部署SAAS产品时，可能出于合规性原因。
- 挑战：
- 您如何优化成本资源？
共享应用程序和共享数据库
- 所有多租户架构中最复杂的野兽。
- 最大限度地利用红外线利用率，以实现最大的盈利能力。
- 挑战：
单独的应用程序和共享数据库
- 一种模型，其中特定于租户的配置与已部署的实例相关联，但是都共享一个公共数据库。每个客户端的数据隔离是通过在数据库模式之前添加租户信息来实现的。
- 您有许多Web框架和Web插件都支持这种带有租户特定数据的前缀查询模型，以找到正确的数据源。例如，apartment (rails/ruby), multi-tenant (laravel/php),springboot（java）等。
- 关系数据库实例非常昂贵。它比您的应用程序实例价格更高，并且不如您的计算实例那么容易处理。您需要对容量规划进行一些前瞻性的展望。
- 当您以SaaS提供者的身份管理数据库实例并希望在总体成本上进行优化时，最简单的操作通常是使用共享数据库。
- 应用程序的可伸缩性无状态标准意味着：
- 不保存用户请求数据
- 不保留数据库响应
- 挑战：
- 随着交易量和数据量的增加，您如何管理？关系数据库凭借其优点是可以垂直伸缩的，而不能水平伸缩的。现在，这意味着随着您加入越来越多的租户，它可能会比您想象的更快成为瓶颈，具体取决于交易和数据量。
共享应用程序和单独的数据库
- 请求可以命中任何可用的应用程序实例。
- 每个请求都会动态获取租户特定的配置。
- 应用程序的可伸缩性无状态标准意味着：
- 不保存用户请求数据
- 不持有租户的配置
- 不保留数据库响应
- 挑战：
- 如何在每个请求的基础上动态访问正确的数据库？您如何最佳地进行延迟？想想Atlassian的Confluence，Jira，Bitbucket等产品套件。
- 如果SaaS应用程序在UI上提供了很多自定义功能，您如何最佳地获得针对租户的特定配置以获得延迟？Wix电子商务，Shopify等
希望能帮助您选择SAAS体系结构的设计...
