【SaaS架构】SaaS存储策略 -找到合适的策略

选择多租户分区存储模型策略受到许多不同因素的影响。如果您正在从现有解决方案迁移，您可能会倾向于采用筒仓模型，因为它可以创建最简单、最干净的方式来过渡到多租户，而无需重写SaaS应用程序。如果您的监管或行业动态需要一个更独立的模型，那么池模型的效率和灵活性可能会为您打开通向快速、持续发布环境的道路。这里的关键是要认识到，您选择的战略将由您环境中的业务和技术考虑因素的组合驱动。

在以下各节中，我们重点介绍了每个模型的优点和缺点，并为您提供了一组定义良好的数据点，作为更广泛评估的一部分。您将了解每个模型如何影响您与敏捷性目标保持一致的能力，而敏捷性目标通常是采用SaaS模型的核心。在为SaaS环境选择架构策略时，请考虑该策略如何影响您在零停机环境中快速构建、交付和部署版本的能力。

评估权衡

如果您将三个分区模型（筒仓、桥和池）放在一个谱上，您将看到与采用任何一种策略相关的自然紧张关系。在一个模型中被列为优势的质量通常在另一模型中被表示为劣势。例如，筒仓模型的原则和价值体系往往与池模型的原则与价值体系相反。

分区模型权衡

上图突出了这些相互竞争的原则。在图的顶部，您将看到所表示的三个分区模型。左边是筒仓模型的优点和缺点。在右边，我们为池模型提供了类似的列表。桥梁模型有点混合了这些考虑因素，因此代表了极端情况下的利弊。

筒仓模型权衡

在完全独立的数据库中表示租户数据可能很有吸引力。除了简化现有单租户解决方案的迁移之外，这种方法还解决了一些租户可能对运行完全共享的基础设施的担忧。

优点

思洛对具有严格监管和安全约束的SaaS解决方案很有吸引力-在这些环境中，您的SaaS客户对其数据必须如何与其他租户隔离有非常明确的期望。思洛存储器模型允许您为租户提供一个选项，在租户数据之间创建一个更具体的边界，并让您的客户感觉到他们的数据存储在一个更专用的模型中。

跨租户的影响是有限的——这里的想法是，通过隔离思洛存储器模型，您可以确保一个租户的活动不会影响另一个租户。该模型允许租户特定的调整，其中系统的数据库性能SLA可以根据给定租户的需要进行调整。用于调整数据库的旋钮和刻度盘通常也具有到筒仓模型的更自然的映射，这使得配置以租户为中心的体验更加简单。

可用性是在租户级别进行管理的，最大限度地减少了租户的停机风险-每个租户都在自己的数据库中，您不必担心数据库停机可能会波及所有租户。如果一个租户存在数据问题，则不太可能对系统的其他租户产生不利影响。

缺点

资源调配和管理更为复杂——无论何时引入每租户的基础设施，都会引入另一个移动部分，必须逐个租户进行配置和管理。例如，您可以想象一个孤立的数据库解决方案会如何影响系统的租户登录体验。您的注册过程需要自动化，以便在注册过程中创建和配置数据库。这当然是可以实现的，但它增加了一层复杂性，也增加了SaaS环境中的潜在故障点。

您查看租户活动并对其做出反应的能力会受到影响-使用SaaS，您可能需要一种管理和监控体验，以提供跨租户的系统运行状况视图。您希望主动预测数据库性能问题，并以更全面的方式对策略作出反应。然而，筒仓模型使您更加努力地寻找和引入工具，以创建覆盖所有租户的聚合的、系统范围的健康视图。

思洛存储器模型的分布式影响了您跨租户有效分析和评估性能趋势的能力—每个租户都将数据存储在自己的思洛存储器中，您只能在以租户为中心的模型中管理和调整服务负载。这基本上导致引入一组一次性设置和策略，您必须独立管理和调整这些设置和策略。这可能既效率低下，又可能造成开销，从而削弱您快速响应客户需求的能力。

筒仓限制了成本优化—筒仓模型的一次性特性可能会限制您调整存储资源消耗的能力，这可能是最显著的缺点。

池模型权衡

池模式代表了SaaS生活方式的终极承诺。使用池模型，您的重点是为租户提供统一的方法，使您能够优化租户存储资源调配、迁移、管理和监控。

优点

灵活性—一旦您的所有租户数据集中在一个存储结构中，您就可以更好地创建工具和生命周期，以支持一种简化的通用方法，快速为所有租户部署存储解决方案。这种灵活性也扩展到您的入职流程。使用池模型，您不需要为注册SaaS服务的每个租户提供单独的存储基础架构。您可以简单地配置新租户，并使用该租户的ID作为索引，从所有租户使用的共享存储模型中访问租户的数据。

存储监控和管理更简单—在池模型中，使用工具和聚合分析来总结租户存储活动更为自然。这里可以利用您用来管理单个存储模型的日常工具来构建系统运行状况的全面、跨租户视图。使用池模型，您可以更好地引入可用于主动响应系统事件的全局策略。通常，将数据统一到单个数据库和共享表示中简化了多租户存储、部署和管理体验的许多方面。

其他选项有助于优化SaaS解决方案的成本足迹-成本机会通常以性能调整的形式出现。例如，您可以将吞吐量优化作为一个策略应用于所有租户（而不是逐个租户管理单独的策略）。

池提高了部署自动化和操作灵活性—池模型的共享特性通常会降低数据库部署自动化的总体复杂性，这与SaaS对持续频繁发布新产品功能的需求非常吻合。

缺点

灵活性意味着管理规模和可用性的门槛更高—想象一下在池化多租户环境中存储中断的影响。现在，不是只有一个客户倒下，而是所有客户都倒下了。这就是为什么采用池模型的组织也倾向于在其环境的自动化和测试方面投入更多的资金。池式解决方案需要主动监控解决方案和健壮的版本控制、数据和模式迁移。发布必须顺利进行，租户问题需要得到有效捕捉和解决。

池对租户数据分布的管理提出了挑战—在某些情况下，租户数据的大小和分布也可能成为池存储的挑战。租户往往会在您的系统上施加不同程度的负载，这些变化可能会破坏您的存储性能。池模型需要更多地考虑您将使用哪些机制来解释租户负载的这些变化。数据的大小和分布也会影响数据迁移的方式。这些问题通常是特定存储技术所特有的，需要逐个解决。

共享环境的共享性质可能会在某些领域遇到阻力——对于某些SaaS产品，客户将需要一个筒仓模型来满足其法规和内部数据保护要求。

混合：商业妥协

对于许多组织来说，战略的选择并不像选择筒仓、桥梁或池模型那么简单。您的租户和您的企业将对您选择存储策略的方式产生重大影响。

在某些情况下，团队可能会确定一小部分需要筒仓或桥梁模型的租户。一旦他们做出了这一决定，他们就认为必须使用该模型实现所有存储。这人为地限制了您接受可能对池模式开放的租户的能力。事实上，这可能会增加一层租户的成本或复杂性，因为他们不需要筒仓或桥梁模型的属性。

一种可能的折衷方案是构建一个完全支持池存储的解决方案作为基础。然后，您可以为那些需要孤立存储解决方案的租户创建一个单独的数据库。下图提供了这种方法的一个实例。

混合筒仓/池存储

这里，我们有两个租户（租户1和租户2）正在利用思洛存储器模型，其余租户在池存储模型中运行。数据访问层将开发人员从租户的底层存储中隐藏起来，从而神奇地将其抽象出来。

尽管这可能会增加数据访问层和管理配置文件的复杂性，但它也可以为您的业务提供一种方式，将您的产品分层，以代表两个世界的最佳。