# SeatGeek 如何使用 AWS Serverless 在多租户 SaaS 应用中控制授权、身

SeatGeek如何利用AWS无服务器架构控制多租户SaaS应用中的授权、认证和速率限制

关键要点

SeatGeek利用AWS无服务器架构来简化其多租户SaaS应用的授权和认证流程。通过使用Amazon API Gateway、Lambda和DynamoDB，SeatGeek实现了中心化的API授权与速率限制。实现了高效的跨租户隔离，防止了噪声邻居问题，为每个租户提供了有效的资源使用限制。

SeatGeek 是一个为网络和移动用户提供的售票平台，提供体育赛事、音乐会和戏剧演出的票务购买和转售服务。2022年，SeatGeek平均每天可提供4700万个票务，且其移动应用程序的下载量超过3300万次。

蘑菇加速器最新版本

过去，SeatGeek在内部使用了多种身份和访问工具。各个应用程序独立管理授权，导致了额外的管理负担，以及对标准化的需求。SeatGeek希望通过对授权层进行抽象和标准化来简化提供给客户和合作伙伴的API。与此同时，他们还希望引入集中式API速率限制，以防止在其多租户SaaS应用中出现噪声邻居问题。

本文将带您了解SeatGeek的发展历程，并探索他们实现的解决方案架构。截至本文发布时，许多B2B客户已采用这一解决方案查询数TB的业务数据。

建设多租户SaaS环境

多租户SaaS环境通过在多个租户之间共享底层资源，实现高性能和成本效益的应用程序。虽然这是一个优势，但重要的是要实现跨租户隔离实践，以遵守安全、合规性和性能目标。因此，每个租户只能访问其授权的资源。噪声邻居问题也是一个需要考虑的因素，它发生在某个租户过度占用共享容量时，从而导致其他租户的性能问题。

认证、授权和速率限制是安全和稳定的多租户环境的关键组成部分。如果没有这些机制，系统将面临未授权访问、资源过载和拒绝服务攻击的风险，从而危及安全性和稳定性。在工作流程的早期验证访问请求可以帮助消除各个应用程序实现类似复杂验证技术的需求。

SeatGeek在解决这些问题时有几个标准：

他们希望利用现有的Auth0实例。SeatGeek不想增加任何额外的基础设施管理负担；同时，他们更倾向于使用无服务器服务来以尽可能少的工作量将受管组件“拼接”在一起，实现业务需求。他们希望这个解决方案在需求和采用量增加时能够尽可能无缝地扩展；同时，SeatGeek也不想为闲置或过度配置的资源付费。

探索解决方案

SeatGeek团队利用一系列Amazon Web Services (AWS) 无服务器服务来满足上述标准并实现预期的商业成果。Amazon API Gateway担当SeatGeek云环境的API入口点。API Gateway使SeatGeek能够使用自定义的AWS Lambda授权器与Auth0集成，并为其租户定义限流配置。由于解决方案中使用的所有服务都是完全无服务器的，因此它们无需基础设施管理，能够根据需要自动扩展和缩减，并提供按需付费的定价。

SeatGeek在API Gateway中创建了一组分层使用计划青铜、白银和黄金以引入速率限制。每个使用计划都有预定义的每秒请求限制配置。API Gateway为每个租户生成唯一的API密钥。Amazon DynamoDB用来存储由Auth0管理的现有租户ID与API密钥由API Gateway管理之间的关联。这使得API密钥管理对SeatGeek的租户保持透明。

每个新租户都经过一个入驻工作流。这是一个由Terraform管理的自动化过程。在新租户入驻期间，SeatGeek在Auth0中创建一个新租户ID，在API Gateway中创建一个新的API密钥，并在DynamoDB中存储它们之间的关联关系。每个API密钥还与某一使用计划相关联。

一旦入驻完成，新租户可以开始调用SeatGeek的API见图1。

流程说明

租户使用机器对机器授权通过Auth0进行身份验证。Auth0返回一个JSON Web令牌，表示租户认证成功。该令牌包括下游授权所需的声明，例如租户ID、过期日期、范围和签名。租户向SeatGeek API发送请求。请求中包括在第一步中获得的令牌及特定于应用的参数，例如获取过去12个月的订单数据。API Gateway提取令牌并将其传递给Lambda授权器。Lambda授权器从Auth0检索令牌验证密钥。密钥被缓存于授权器中，因此在每个授权器启动环境中仅发生一次。这使得令牌验证可以在本地进行，而无需每次都调用Auth0，从而减少延迟并防止向Auth0发出过多请求。Lambda授权器进行令牌验证，检查令牌的结构、过期日期、签名、受众和主题。如果验证成功，Lambda授权器将从令牌中提取租户ID。Lambda授权器使用在第5步提取的租户ID从DynamoDB中检索相关联的API密钥，并将其返回给API Gateway。API Gateway使用API密钥检查发起请求的客户端是否超出基于与API密钥相关的使用计划的速率限制阈值。如果超出速率限制，则返回HTTP 429“请求过多”给客户端。否则，请求将被转发到后端进行进一步处理。可选情况下，后端可以执行额外的应用特定的令牌验证。

架构优势

SeatGeek实现的架构提供了几个优势：

中心化授权： 使用Auth0与API Gateway和Lambda授权器相结合，实现了API认证的标准化，减轻了各个应用程序实现授权的负担。多层缓存： 每个Lambda授权器启动环境在内存中缓存令牌验证密钥，以实现本地令牌验证。这减少了令牌验证时间，并有助于避免向Auth0发出过多流量。此外，API Gateway可以为Lambda授权器响应配置最长达5分钟的缓存，因此在该时间段内相同的令牌将不会被重新验证。这降低了Lambda授权器和DynamoDB的总体成本和负载。防止噪声邻居： 使用计划和速率限制防止任何特定租户占用共享资源，从而对其他租户造成负面性能影响。简单管理与降低总拥有成本： 使用AWS无服务器服务消除了基础设施维护负担，使SeatGeek能够更快地提供商业价值。这也确保他们不会为过度配置的能力支付费用，其环境能够自动按需扩展和缩减。

结论

在本文中，我们探讨了SeatGeek如何使用AWS无服务器服务如API Gateway、Lambda和DynamoDB集成外部身份提供者Auth0，并实现每个租户的速率限制及多层次的使用计划。利用AWS无服务器服务使SeatGeek避免了不必要的基础设施管理工作，从而加快了解决方案的构建，以满足业务需求。