【SaaS架构】SaaS镜头-架构支柱-性能效率支柱 |

语言 Chinese, Simplified

SEO Title

SaaS Lens - Architecture Pillars -Performance Efficiency Pillar

性能效率支柱侧重于有效利用计算资源来满足需求，并随着需求的变化和技术的发展而保持这种效率。

释义

云计算中的性能效率有四个最佳实践领域：

选择（计算、存储、数据库、网络）
回顾
监测
权衡取舍

采用数据驱动方法选择高性能架构。从高层设计到资源类型的选择和配置，收集架构各个方面的数据。通过周期性地审查您的选择，您将确保您正在利用不断发展的AWS云。

监控将确保您意识到与预期性能的任何偏差，并可以对此采取行动。最后，您的体系结构可以进行权衡以提高性能，例如使用压缩或缓存，或放宽一致性要求。

最佳实践

话题

选择

SaaS性能1：如何防止一个租户对另一个租户的体验产生负面影响？

在多租户环境中，租户可能具有对系统施加显著不同负载的配置文件和用例。具有新工作负载配置文件的新租户也可能会不断添加到系统中。这些因素使得SaaS公司构建一个能够满足这些租户快速发展的性能需求的架构非常具有挑战性。

处理和管理租户负载的这些变化是SaaS环境性能概要的关键。SaaS架构必须能够成功检测这些租户消费趋势，并应用能够有效扩展以满足租户需求或限制单个租户活动的策略。

有多种策略可用于管理租户可能对系统造成不成比例负载的情况。这可以通过隔离高需求资源、引入扩展策略或应用节流策略来实现。

在最简单和最极端的情况下，您可以考虑为应用程序的部分创建租户特定的部署。图22中的图表说明了一种分解系统以解决性能挑战的方法。

图22：使用孤立服务解决性能问题

在本例中，您将注意到我们有两个不同的部署足迹（一些在思洛存储器模型中，一些在池模型中）。在图的左侧，您将看到为每个租户部署了Product、Order和Cart微服务的单独实例。同时，在图的右侧，您将看到所有租户共享的微服务集合。

该方法背后的基本思想是开发特定的服务，这些服务被视为对应用程序的性能概要至关重要。通过将它们分开，您的系统可以确保任何一个租户的负载不会影响其他租户的性能（对于这组服务）。此策略可能会增加成本并降低环境的操作灵活性，但仍然是实现性能目标的有效方法。同样的方法也可用于解决合规性和隔离要求。

例如，您可以为每个租户部署一个订单管理微服务，以限制一个租户对另一个租户的订单处理体验产生不利影响的能力。这增加了操作复杂性并降低了成本效率，但可以作为一种暴力手段，有选择地针对应用程序关键领域的跨租户性能问题。

理想情况下，您应该尝试通过构造来解决这些性能需求，这些构造可以解决租户负载问题，而不会吸收单独部署服务的开销和成本。在这里，您将专注于创建一个扩展配置文件，使您的共享基础架构能够有效地响应租户负载和活动的变化。

基于容器的架构（如AmazonEKS或AmazonECS）可以配置为基于租户需求扩展服务，而不需要任何过度资源调配。容器快速扩展的能力增强了系统对急剧租户负载的有效响应能力。将容器的扩展速度与AWS Fargate的成本概况相结合，通常是弹性、运营灵活性和成本效率的完美结合，可以帮助组织解决租户的巨大负载，而不会过度配置环境。

使用AWS Lambda构建的无服务器SaaS架构也可能非常适合解决租户负载过高的问题。AWS Lambda的管理特性允许您的应用程序服务快速扩展，以解决租户负载的峰值问题。这种方法可能需要考虑并发性和冷启动因素。然而，它可以代表限制跨租户性能影响的有效策略。

虽然响应式扩展策略可以帮助解决这个问题，但您可能需要采取其他措施，以简单地防止租户施加可能会造成跨租户影响的负载。在这些场景中，您可以选择通过设置限制（可能按层）来检测和约束租户的活动，这些限制将应用节流来控制系统上的负载级别。这将通过引入节流政策来实现，该政策将检查租户的负载，识别超出限制的活动，并限制他们的体验。

SaaS性能2：您如何确保基础设施资源的消耗与租户的活动和工作负载保持一致？

SaaS公司的商业模式通常严重依赖于一种策略，该策略允许他们将基础设施的成本与租户的实际活动相一致。由于SaaS系统中租户的负载和组成不断变化，因此您需要一种架构策略，该策略可以有效地以一种模式来扩展资源的消耗，这种模式非常反映SaaS体验中的这些实时、不可预测的消耗模式。

图23中的图表提供了一个环境的假设示例，该环境已协调了基础设施消耗和租户活动。这里蓝色实线表示租户在一段时间内的实际活动趋势。红色虚线表示为解决租户负载而配置的实际基础设施。

图23：调整租户活动和消费

在理想的环境中，我们的策略是尽量缩小红线和蓝线之间的差距。在这里，您总是有一定的误差余量，因为您有一些缓冲，以确保不会影响系统的可用性或性能。同时，您希望能够提供足够的基础设施，以支持租户当前的性能需求。

这里的关键挑战是，图中显示的负载通常是不可预测的。虽然可能存在一些一般趋势，但您的架构和扩展策略不能假设今天的负载明天甚至未来一小时都会相同。

调整消费与活动的最简单方法是使用提供无服务器体验的AWS服务。这方面的经典例子是AWS Lambda。使用AWS Lambda，您可以构建一个服务器和扩展策略不再由您负责的模型。使用无服务器，您的SaaS应用程序只会产生与租户消费直接相关的费用。如果您的SaaS系统没有负载，那么AWS Lambda将不会产生任何成本。

AWS Fargate还支持基于容器的版本，这是一种无服务器的心态。通过将Fargate与AmazonEKS或AmazonECS一起使用，您只需支付应用程序实际消耗的容器计算成本。

这种使用无服务器模型的能力超出了计算构造。例如，您的解决方案的存储部分也可以依赖于无服务器技术。AmazonAuroraServerless允许您存储关系数据，而无需调整运行数据库的实例的大小。相反，AmazonAuroraServerless将根据实际负载来调整您的环境大小，并且只对您的应用程序消耗的内容收费。

任何让您不再需要创建扩展策略的模型都将简化您的运营和成本体验。您可以将更多的时间和精力集中在应用程序的特性和功能上，而不是继续追求难以捉摸的完美自动缩放配置。这也使该公司能够发展并接受新租户，而不必担心AWS账单的意外增长。

对于无服务器可能不是一个选项的场景，您需要回到传统的扩展策略。在这些场景中，您需要捕获和发布租户消费指标，并根据这些指标定义扩展策略。