Auth0为所有技术栈上的任一平台（移动，Web，本机）应用程序提供身份验证，授权和单点登录服务。身份验证对绝大多数应用程序至关重要。我们从一开始就设计了Auth0，以便它可以在任何地方运行：在我们的云上，在您的云上，甚至在您自己的私有基础架构上。
在这篇文章中，我们将更多地讨论我们的公共SaaS部署，并简要介绍auth0.com背后的基础架构以及我们用于保持高可用性并保持运行的策略。
从那以后在Auth0中发生了很多变化。这些是一些亮点：
- 我们从每月处理数百万次到每月15亿次登录，为数千名客户提供服务，包括FuboTV，Mozilla，JetPrivilege等。
- 我们实施了新功能，如自定义域，扩展的bcrypt操作，大大改进的用户搜索等等。
- 为了扩展我们的组织和处理日益增长，服务数量由原有的10个增加到30个。
- 云资源的数量也大幅增长; 我们曾经在一个环境（美国）中拥有几十个节点，现在我们在四个环境（美国，美国-2，欧盟，澳大利亚）上拥有超过一千个节点。
- 我们决定为每个环境使用单一云提供商，并将所有公共云基础架构迁移到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次登录的部分自动化环境发展到每秒执行超过3.4万次登录的全自动环境; 使用新工具可以更容易地向上扩展（并且只要有意义就向下扩展）。我们实现的自动化水平并不完美，但允许我们以更加便捷的方式发展到新的地区并创造新的环境。
- 编写更好的脚本文件：我们看到除了自动化之外，我们还需要更好的脚本文件，以便理解，管理和响应与我们不断增长的服务网格相关的事件。这大大提高了可扩展性和可靠性，同时也允许我们让新人可以更快的上手。
我们来看看我们的美国环境架构。我们有这个总体结构：
