Auth0为任何堆栈上的任何类型（移动、web、本机）应用程序提供身份验证、授权和单点登录服务。身份验证对于绝大多数应用程序来说都是至关重要的。我们从一开始就设计了Auth0，这样它就可以在任何地方运行：在我们的云上，在你的云上，甚至在你自己的私有基础设施上。在这篇文章中，我们将更详细地讨论我们的公共SaaS部署，并简要介绍auth0.com背后的基础设施以及我们用来保持其高可用性和运行的策略。这是2014年关于Auth0架构的高可伸缩性帖子的更新版本。自那以后，Auth0发生了很多变化。以下是一些亮点：我们从每月处理数百万次登录到每月25亿次登录，服务于成千上万的客户，包括FuboTV、Mozilla、interles等等。我们实现了一些新特性，如自定义域、扩展的bcrypt操作、大大改进的用户搜索等。为了扩大我们的组织和处理流量的增长，组成我们产品的服务数量从不足10个增加到超过30个。云资源的数量也大幅增长；我们过去在一个环境（US）中有几十个节点，现在我们在四个环境（US、US-2、EU、AU）中有一千多个节点。我们加倍努力，决定为我们的每个环境使用一个云提供商，并将我们所有的公共云基础设施迁移到AWS。核心服务架构核心服务由不同的层组成：核心应用程序：自动扩展运行堆栈中不同服务（身份验证、管理API、多因素身份验证API等）的服务器组。数据存储：MongoDB、Elasticsearch、Redis、PostgreSQL的集群，为不同的应用和特性存储各种数据集。传输/队列：Kinesis流和RabbitMQ、SNS和SQS队列。基本服务：速率限制服务、bcrypt集群服务、功能标志等。路由：AWS负载平衡器（AWS的ALB、NLB和ELB）以及一些将NGINX作为代理运行的节点。高可用性2014年，我们使用了一个多云架构（使用Azure和AWS，在Google云上有一些额外的资源），多年来一直很好地为我们服务。随着我们的使用（和负载）迅速增加，我们发现自己越来越依赖于AWS资源。首先，我们将环境中的主区域切换到AWS中，并保持Azure作为故障转移。随着我们开始使用更多的AWS资源，如Kinesis和SQS，我们开始在两个提供者中保持相同的特性集时遇到了困难。随着我们对移动（和扩展）更快的需求的增长，我们选择了以有限的功能对等性来支持Azure：如果AWS上的一切都失败了，我们仍然可以使用Azure群集支持核心身份验证功能，但我们开发的新功能不多。在经历了2016年的几次严重停机之后，我们决定最终向AWS靠拢。我们停止了与保持服务和自动化平台独立相关的所有努力，而是专注于：在AWS内部提供更好的故障切换，使用多个区域和每个区域至少3个可用区域。增加AWS特定资源的使用，如自动伸缩组（而不是使用固定的节点集群）、应用程序负载平衡器（alb）等。编写更好的自动化：我们改进了我们的自动化，完全将基础设施作为代码使用TerraForm和SaltStack来提供新的Auth0环境（同时也替换现有的环境）。这使我们能够从每秒进行约300次登录的部分自动化环境发展到每秒完成约3400次登录的全自动环境；使用新工具可以更容易地扩大（或缩小，只要有意义）。我们所达到的自动化水平并不完美，但它使我们能够以更方便的方式发展到新的地区和创造新的环境。编写更好的剧本：随着更多的时间和精力，我们发现除了自动化之外，我们还需要更好的剧本，以便理解、管理和应对与不断增长的服务网络相关的事件。这大大提高了可扩展性和可靠性，同时也允许我们更快地加入新员工。"编写更好的自动化让我们从每秒大约300次登录的部分自动化环境发展到每秒超过3400次登录的完全自动化环境"在推特上留言例如，让我们看看我们的美国环境架构。我们有这样的总体结构：这是单个AZ内部的结构：在本例中，我们使用两个AWS区域：us-west-2（我们的主）和us-west-1（我们的故障转移）。在正常情况下，所有请求将发送至us-west-2，由三个独立的可用区提供服务。这就是我们实现高可用性的方法：所有服务（包括数据库）在每个可用性区域（AZ）上都有运行实例。如果一个AZ由于数据中心故障而停机，那么我们仍然有两个AZ来处理请求。如果我们可以恢复整个区域的故障转移，那么我们可以恢复整个区域。"我们通过在每个AWS可用性区域运行所有服务实例来实现高可用性"在推特上留言对于服务故障转移，我们有不同的成熟度级别：一些服务，比如usersearchv2（在Elasticsearch上构建缓存）可能可以工作，但是数据稍微陈旧；但是，核心功能仍然可以按预期工作。在数据层中，我们使用：MongoDB的跨区域集群。用于PostgreSQL的RDS复制。每个区域的群集用于Elasticsearch，自动快照和恢复定期运行，以解决跨区域群集的不足。我们每年至少进行一次故障切换，我们有行动手册和自动化来帮助新的基础设施工程师加快速度，了解如何做到这一点以及这会带来什么影响。我们的部署通常由Jenkins节点触发；根据服务的不同，我们要么使用Puppet、SaltStack和/或Ansible来更新单个或多个节点组，要么更新我们的ami并为不可变的部署创建新的自动调整组。我们为新的和旧的服务部署了不同类型的服务，这已经被证明在很大程度上是无效的，因为我们需要维护自动化、文档和监控，以便对应该统一的东西进行监控。我们目前正在为一些核心服务推出蓝/绿部署，我们打算为每个核心和支持服务实现同样的部署。自动化测试除了每个项目的单元测试覆盖率外，我们还有多个功能测试套件在每个环境中运行；在部署到生产环境之前，我们在一个登台环境中运行它，在完成部署之后，我们在生产环境中再次运行它们，以确保一切正常。亮点：我们在不同的项目中有数千个单元测试。我们每分钟都会使用pingcore来检查它的功能。在每次部署之前和之后，我们混合使用基于Selenium和CodeceptJS的功能测试。功能测试套件测试不同的API端点、身份验证流、身份提供者等等。"除了每个项目的单元测试覆盖率外，我们还有多个功能测试套件在每个环境中运行：在部署到生产环境之前进行登台测试，在完成部署后再次在生产环境中运行。"在推特上留言CDN公司直到2017年，我们在多个地区使用NGINX、Varnish和EC2节点运行我们自己的定制CDN。从那时起，我们过渡到CloudFront，这给我们带来了几个好处，包括：更多的边缘位置，这意味着我们的客户延迟更少。降低维护成本。更容易配置。有一些缺点，比如我们需要运行Lambdas来执行一些配置（比如在PDF文件中添加自定义头等等）。不过，好的一面肯定能弥补这一点。延伸我们提供的特性之一是能够通过身份验证规则或自定义数据库连接，在登录事务中运行自定义代码。这些特性由Extend提供支持，Extend是Auth0的一个扩展性平台，现在也被其他公司使用。使用Extend，我们的客户可以在这些脚本和规则中编写任何他们想要的东西，允许他们扩展概要文件、规范化属性、发送通知等等。我们专门为Auth0扩展了集群；它们使用EC2自动伸缩组、Docker容器和自定义代理的组合来处理来自租户的请求，每秒处理数千个请求，并对负载的变化做出快速响应。有关如何构建和运行的更多详细信息，请参阅这篇关于如何构建您自己的无服务器平台的文章。监控我们使用不同工具的组合来监视和调试问题：云表数据狗平度哨兵我们的绝大多数警报来自CloudWatch和DataDog。我们倾向于通过TerraForm配置CloudWatch警报，我们在CloudWatch上保留的主要监视器有：来自主负载平衡器的HTTP错误。目标组中不正常的实例。SQS处理延迟。CloudWatch是基于AWS生成的度量（比如来自负载平衡器或自动调整组的度量）的警报的最佳工具。CloudWatch警报通常发送到PagerDuty，并从PagerDuty发送到Slack/phones。DataDog是一种用于存储时间序列度量并对其进行操作的服务。我们从Linux机器、AWS资源、现成服务（比如NGINX或MongoDB）以及我们构建的定制服务（比如我们的管理API）中发送度量。我们有很多数据狗监视器。几个例子：在$环境上的$service中增加响应时间。$instance（$ip_address）中的$volume上的空间不足。$enviro上的$process问题