【SaaS架构】SaaS镜头-架构支柱-可靠性支柱

语言 Chinese, Simplified

SEO Title

SaaS Lens - Architecture Pillars -Reliability Pillar

可靠性支柱包括系统从基础设施或服务中断中恢复的能力，动态获取计算资源以满足需求的能力，以及减轻诸如错误配置或瞬时网络问题等中断的能力。

设计原则

在云计算中，有许多原则可以帮助您提高可靠性。

释义

云计算中的可靠性有三个最佳实践领域：

基础
变更管理
故障管理

为了实现可靠性，系统必须有一个规划良好的基础和适当的监控，以及处理需求或需求变化的机制。系统应设计为检测故障并自动修复。

最佳实践

话题

基础

SaaS REL 1：如何限制单个租户施加可能影响系统其他租户可用性的负载的能力？

多租户环境中租户的工作量可能会不断变化。租户可能会对系统施加不同类型的负载。具有新工作负载配置文件的新租户也可能会不断添加到系统中。这些因素可能使SaaS公司创建一个具有足够弹性的架构来应对和响应这些不断变化的需求变得非常具有挑战性。

这些负载变化可能会对租户的体验产生不利影响。设想一个场景，其中一个租户最终在系统的某个方面承受了极大的负载。如果它们可以通过API与您的系统交互，这一点尤其明显。在这种情况下，该租户的负载最终可能会消耗不成比例的系统资源，进而影响整个系统的可靠性或其他租户的体验。

对于具有分层服务的系统，一个租户影响另一个租户的能力可能会变得更加复杂。例如，系统可能具有基本、高级和高级层。如果允许这些层中的每一层对系统施加任何级别的负载，我们可能会发现基本层正在影响高级层租户的可靠性。

在多租户环境中，您需要特别主动地识别可能影响系统可靠性的工作负载和消耗模式。多租户环境中的可靠性问题很容易在您的系统中级联，并可能影响所有客户的体验。

为了解决这些工作负载问题，您的系统必须引入能够检测和解决工作负载问题的机制，才能影响应用程序的可靠性。

应用程序的架构和应用程序堆栈将影响您应用的策略，以防止租户影响系统的可靠性和其他租户的体验。一种常见的方法是使用节流来防止租户消耗多余的资源。图21中的图表提供了使用AmazonAPI网关实现这一点的示例。

在本例中，您将看到我们利用API网关的使用计划为系统的每个租户定义了单独的使用体验。这种方法为系统的基本层和高级层使用单独的API密钥，这些密钥与具有不同SLA的使用计划相连接。这种方法实现了两种不同级别的控制。首先，它可以确保通过配置使用计划，防止所有租户在我们的系统中充满请求。另一个好处是，我们可以使用这些使用计划配置来防止较低层租户影响较高层租户的体验。

虽然此模型依赖于API网关来实现节流策略，但此核心概念可以应用于其他基础结构构造。这种方法的基本目标是能够在应用程序的入口点监控和管理访问，检测并限制可能会影响环境整体可靠性的任何租户。

图21：按层级限制租户

SaaS REL 2：如何主动检测和维护租户健康？

SaaS环境中的可靠性通常在很大程度上受到供应商在问题影响租户之前主动识别和补救问题的能力的影响。在多租户环境中构建一个主动的健康视图需要您提供额外的可靠性数据，这些数据可以提供租户工作负载健康趋势的更详细、租户感知的见解。

这些租户感知洞察用于识别租户特定的趋势、活动或洞察，这些趋势、活动和洞察可以有效捕获可能影响租户或整个系统可靠性的情况。拥有这些数据并主动将其呈现出来，允许您构建警报、策略和自动化，以尝试修复系统而不会导致停机。

为了实现这一点，您需要在应用程序中引入代码，以通过租户上下文发布健康洞察。这首先要确定体系结构中表示有用健康数据的工作流和事件。这可能是消费数据、缩放洞察、延迟度量等。这些洞察中的每一个都将通过日志文件或数据仓库发布，以汇总数据。

一旦在存储库中聚合了这些健康数据，就可以引入工具，根据对聚合的健康数据的分析来显示警报或触发策略。

SaaS REL 3：您如何测试SaaS应用程序的多租户功能？

多租户环境的测试模型不仅仅是确保应用程序的功能按预期工作。SaaS提供商还必须创建测试，以验证您的系统是否能够有效解决与多租户解决方案相关的常见可靠性问题。

作为多租户测试策略的一部分，您需要包含许多不同的维度。在许多情况下，这些测试旨在验证您现有的结构，以解决SaaS产品的规模、操作和可靠性问题。

需要注意的是，SaaS测试通常是模拟应用程序可能遇到的极端情况。您应该专注于构建一套测试，这些测试可以有效地建模和评估您的系统将如何响应预期和意外情况。除了确保客户拥有积极的体验外，您的测试还必须考虑实现规模的成本效益。如果您为响应活动而过度分配资源，则可能会影响业务的底线。

您可以在SaaS环境中增强负载和性能测试策略的一些特定领域是：

跨租户影响测试–创建模拟场景的测试，其中租户的子集对系统造成不成比例的负载。这将允许您确定当负载未在租户之间均匀分布时系统如何响应，并评估这可能会如何影响租户的整体体验。如果您的系统被分解为单独的可扩展服务，那么您需要创建测试来验证每个服务的扩展策略，以确保它们按照正确的标准进行扩展。
租户消耗测试–创建一系列负载配置文件（例如，扁平、尖峰和随机），跟踪资源和租户活动度量，并确定消耗和租户活动之间的增量。您最终可以将此增量作为监控策略的一部分，以确定次优资源消耗。您还可以将此数据与其他测试数据一起使用，以确定是否正确调整了实例的大小，是否正确配置了IOPS，以及是否优化了AWS占用空间。
租户工作流测试–使用这些测试来评估SaaS应用程序的不同工作流如何响应多租户环境中的负载。其想法是选择您的解决方案中众所周知的工作流，并将负载集中在具有多个租户的工作流上，以确定这些工作流是否会在多租户环境中造成瓶颈或资源过度分配。
租户入职测试–当租户注册您的系统时，您希望确保他们拥有积极的体验，并且您的入职流程具有弹性、可扩展性和高效性。如果您的SaaS解决方案在入职过程中提供了基础设施，则情况尤其如此。您需要确定活动的激增不会影响入职流程。这也是一个您可能依赖第三方集成（例如计费）的领域。您可能希望验证这些集成是否支持其SLA。在某些情况下，您可以实施回退策略来处理这些集成的潜在中断。在这些情况下，您需要引入测试来验证这些容错机制是否按预期执行。
API节流测试–API节流的概念并非SaaS解决方案独有。通常，您发布的任何API都应该包含节流的概念。对于SaaS，您还需要考虑不同层的租户如何通过您的API施加负载。例如，免费层的租户可能不被允许施加与黄金层租户相同的负载。这使您能够验证与每个层关联的限制策略是否已成功应用和实施。
数据分布测试–在大多数情况下，SaaS租户数据不会被统一分布。租户数据配置文件中的这些变化可能会导致总体数据占用量失衡，并可能影响解决方案的性能和成本。为了抵消这种动态，SaaS团队通常会引入分片策略来解释和管理这些变化。共享策略对您的解决方案的性能和成本状况至关重要，因此，它们是测试的首选。数据分发测试允许您验证所采用的分片策略是否能够成功分发系统可能遇到的租户数据的不同模式。在存储了大量客户数据之后，尽早进行这些测试可能有助于避免迁移到新分区模型的高昂成本。
租户隔离测试–SaaS客户希望采取一切措施确保其环境安全，其他租户无法访问。为了支持这一需求，SaaS提供商构建了许多策略和机制来保护每个租户的数据和基础设施。引入不断验证这些策略实施的测试对任何SaaS提供商都至关重要。