向SaaS交付模式的转变伴随着最大化成本和运营效率的愿望。在租户活动难以预测的多租户环境中，这尤其具有挑战性。找到一种将租户活动与实际资源消耗相结合的扩展策略是很难的。今天有效的策略明天可能行不通。
这些特性使SaaS非常适合无服务器模式。通过从SaaS架构中删除服务器的概念，组织能够依靠托管服务来扩展和交付应用程序所消耗的精确数量的资源。这简化了应用程序的体系结构和操作足迹，无需继续跟踪和管理扩展策略。这也降低了运营开销和复杂性，将更多的运营责任推给了托管服务。
AWS提供了一系列可用于实现无服务器SaaS解决方案的服务。图1中的图表提供了一个无服务器体系结构的示例。
图1：无服务器SaaS架构
在这里，您将看到无服务器SaaS体系结构的移动部分与经典的无服务器web应用程序体系结构没有什么不同。在这个图的左侧，您可以看到我们的web应用程序是由AmazonS3存储桶托管和提供服务的（可能使用了React、Angular等现代客户端框架之一）。
在此架构中，应用程序利用Amazon Cognito作为我们的SaaS身份提供商。这里的身份验证体验产生了一个令牌，其中包括通过JSON Web令牌（JWT）传递的SaaS上下文。然后将此令牌注入到我们与所有下游应用程序服务的交互中。
与我们的无服务器应用程序微服务的交互是由AmazonAPI网关协调的。网关在这里扮演多个角色。它验证传入的租户令牌（通过Lambda授权器），将每个租户的请求映射到微服务，并可用于管理不同租户层的SLA（通过使用计划）。
您还将看到，我们在这里表示了一系列微服务，它们是实现SaaS应用程序的多租户IP的各种服务的占位符。这里的每个微服务都是由一个或多个实现微服务契约的Lambda函数组成的。根据微服务的最佳实践，这些服务还封装了它们管理的数据。这些服务依赖于传入的JWT令牌来获取和应用租户上下文。
我们还展示了每个微服务的存储。为了符合微服务最佳实践，每个微服务都拥有其管理的资源。例如，一个数据库不能由两个微服务共享。SaaS在这里也增加了一个问题，因为数据的多租户表示可以根据服务的不同而变化。一个服务可以为每个租户（思洛存储器）提供单独的数据库，而另一个服务可能将数据合并到同一个表（池）中。您在这里所做的存储选择是由法规遵从性、噪声邻居、隔离和性能考虑因素决定的。
最后，在图的右侧，您将看到一系列共享服务。这些服务提供了图左侧运行的所有租户共享的所有功能。这些服务代表通常作为独立的微服务构建的公共服务，这些服务是机载、管理和运营租户所需的。
有关一般无服务器良好架构的最佳实践的更多信息，请参阅无服务器应用程序镜头白皮书。
