【.com原稿】现如今，对于绝大多数应用来说，认证都是至关重要的。Auth0可以为任何堆栈上的各种（移动、Web和本地）应用程序提供身份验证、授权和单点登录服务。我们从头开始设计Auth0以在任何地方运行：我们的云、您的云，甚至您自己的私有基础设施。在本文中，我们将详细探讨我们的公共SaaS部署，并简要描述auth0.com背后的基础架构以及我们用来保持其平稳运行的高可用性策略。我们在2014年写了关于Auth0的架构，从那时起Auth0发生了很大变化，这里有一些关键要点：我们从每月处理数百万次登录到每月超过15亿次登录，为包括FuboTV、Mozilla、JetPrivilege等。·我们实施了新功能，例如自定义域、扩展的bcrypt操作和大大改进的用户搜索等。·为了扩展我们的组织并应对流量的增加，我们将产品的服务数量从不到10个增加到30个以上。云资源的数量也显着增长，我们过去在一个环境中有几十个节点（美国），现在我们在四个环境（美国、US-2、欧盟和澳大利亚）中拥有1000多个节点。·我们决定为我们的每个环境使用单一的云提供商，并将所有公共云基础设施迁移到AWS。核心服务架构图1：Auth0.com的核心服务架构我们的核心服务由以下不同层组成：核心应用程序：运行我们堆栈的不同服务（身份验证、管理API和多因素身份验证API等）。·数据存储：MongoDB、Elasticsearch、Redis和PostgreSQL集群，针对不同应用和功能特性存储大量数据集。传输/队列：Kinesis流和RabbitMQ、SNS和SQS队列。·基础服务：用于速率限制、bcrypt集群和特征标志等服务。路由：AWS负载均衡器（AWS的ALB、NLB和ELB）和一些运行Nginx作为代理的节点。高可用性在2014年，我们使用了多云架构（使用Azure和AWS，以及谷歌云上的一些额外资源），这多年来一直为我们服务。随着使用量（和负载）的快速增加，我们发现自己越来越依赖AWS资源。最初，我们将环境中的主要区域切换到AWS，将Azure作为故障转移区域。随着我们开始使用更多AWS资源（例如Kinesis和SQS），我们开始在将相同的功能放入这两个提供程序中时遇到麻烦。随着我们移动（和扩展）得更快，我们选择继续支持Azure，但功能对等性有限。如果AWS上的一切都出现故障，我们仍然可以使用Azure集群来支持身份验证等核心功能，但我们一直在努力的新功能并不多。在2016年发生几次严重中断后，我们决定最终将重点放在AWS上。我们停止了所有与保护服务和自动化平台无关的工作，而是专注于：在AWS内提供更好的故障转移机制，使用多个区域，每个区域至少有3个可用区。增加AWS特定资源的使用，例如自动扩展组（而不是使用固定节点集群）和应用程序负载平衡系统(ALB)。编写更好的自动化：我们改进了自动化以完全接受基础架构即代码，使用TerraForm和SaltStack来配置新的Auth0环境（并替换现有环境）。这使我们能够从每秒处理约300次登录的部分自动化环境升级到每秒处理超过3400次登录的全自动环境；使用新工具可以更轻松地扩大规模（必要时缩小规模）。我们实现的自动化水平并不完美，但它使我们扩展到新领域和创建新环境变得极其容易。编写更好的剧本：随着时间的推移，我们发现除了自动化之外，我们还需要更好的剧本来理解、管理和响应与我们日益庞大的服务网格相关的事件。这极大地提高了可扩展性和可靠性，同时加快了新员工的入职。例如，看看我们的美国环境框架。我们有这样的整体结构，如下图：图2：Auth0US环境架构下图是单个可用区内部的结构：图3：Auth0单个可用区本例中，我们使用两个AWS区域：us-west-2（我们的主要区域）·us-west-1（故障转移区域）通常，所有请求都流向us-west-2，它由三个独立的可用区提供服务。这就是我们实现高可用性的方式：所有服务（包括数据库）在每个可用区(AZ)中都有运行实例。如果一个可用区由于数据中心故障而宕机，我们仍然有两个可用区来处理请求；如果整个区域出现故障或出现错误，我们可以告诉Route53故障转移到us-west-1，恢复操作。我们在服务故障转移方面有不同程度的成熟度：一些服务（比如usersearchv2，它在Elasticsearch上构建了一个缓存）功能正常，但数据略显陈旧，但核心功能按预期工作。在数据层，我们使用：MongoDB的跨区域集群。·PostgreSQL的RDS复制。Elasticsearch的按区域集群，定期运行自动快照和恢复以解决缺乏跨区域集群的问题。我们每年至少进行一次故障转移演练，并且我们有剧本和自动化，可以帮助新的基础架构工程师尽快了解如何进行以及其影响。我们的部署通常由Jenkins节点触发；根据服务的不同，我们使用Puppet、SaltStack和/或Ansible来更新单个节点或一组节点，或者我们更新AMI以为不可变部署创建新的自动缩放组。我们为新旧服务部署了不同类型的环境；事实证明，这在很大程度上是低效的，因为我们需要为应该是统一的系统维护自动化、文档和监控。我们目前正在为一些核心服务推出蓝/绿部署，我们打算为每个核心的支持服务实施相同的设置。自动化测试除了每个项目的单元测试覆盖率外，我们还有多个在每个环境中运行的功能测试套件。我们在部署到生产环境之前在暂存环境中运行它，然后在部署之后在生产环境中运行它以确保一切正常。我们的自动化测试亮点：不同项目中的数千个单元测试。·使用每分钟运行一次的Pingdom探测器检查核心功能。在每次部署前后结合使用基于Selenium的功能测试和基于CodeceptJS的功能测试。功能测试套件测试不同的API端点、身份验证流程和身份提供者等。CDN在2017年之前，我们运行自己定制的CDN，在多个区域运行Nginx、Varnish和EC2节点。2017年之后，我们改用CloudFront，这给我们带来了几个好处，包括：更多的边缘位置，这意味着我们的客户延迟更低。·降低维护成本。·更容易配置。但同时也有几个缺点，比如我们需要运行Lambdas来执行一些配置（比如给PDF文件添加自定义标题等）。但是，优点绝对大于缺点。扩展我们提供的功能之一是能够通过身份验证规则或自定义数据库连接将自定义代码作为登录事务的一部分运行。这些功能由Extend(https://goextend.io/)提供支持，这是一个从Auth0演变而来的可扩展平台，现在被其他公司使用。使用Extend，我们的客户可以使用这些脚本和规则编写他们想要的任何服务，扩展配置文件，指定属性，发送通知等。我们有专用于Auth0的Extend集群，它使用EC2自动缩放组、Docker容器和自定义的组合代理来处理来自我们用户的请求，每秒处理数千个请求，并快速响应负载变化。有关如何构建和运行的更多信息，请参阅这篇关于如何构建您自己的无服务器平台的文章(https://tomasz.janczuk.org/2018/03/how-to-build-your-own-serverless-platform.html）。监控我们使用不同工具的组合来监控和调试问题：CloudWatchDataDogPingdomSENTINL我们的绝大多数警报来自CloudWatch和DataDog。我们经常通过TerraForm配置CloudWatch警报。CloudWatch监控的主要问题是：来自主负载均衡系统的HTTP错误。?目标组中的不健康实例。·SQS处理延迟。CloudWatch是一款出色的工具，可根据AWS生成的指标（例如来自负载均衡器或自动缩放组的指标）监控警报。CloudWatch警报通常发送到PagerDuty，然后从PagerDuty发送到Slack/Mobile。DataDog是我们用来存储时间序列指标并对其进行操作的服务。我们从Linux系统、AWS资源和现成服务（如Nginx或MongoDB）以及我们构建的自定义服务（如管理API）发送指标。我们有许多DataDog监控的指标，仅举几例：$environment上$service的响应时间增加。·$instance中的$volume($ip_address)空间不足。·$environment/$host上的$process($ip_address)问题。增加$environment上$service的处理时间。·$host($ip_address)上的NTP漂移/时钟问题。·MongoDB副本集在$environment上发生变化。从上面的示例中可以看出，我们同时监控低级指标（例如磁盘空间）和高级指标（例如MongoDB副本集更改，如果主要定义发生更改，它会提醒我们）。我们已经做了很多工作来设计一些非常复杂的指标来监控一些服务。DataDog警报的输出非常灵活，我们一般将它们全部发送到Slack，只将“引人注目”的警报发送到PagerDuty，例如错误尖峰，或者我们确定对客户有影响的大多数事件。就日志记录而言，我们使用SumoLogic和Kibana；我们使用SumoLogic来存储我们的审计跟踪记录和AWS生成的许多日志，我们使用Kibana来存储来自我们自己的服务和其他“现成”服务（例如Nginx和MongoDB日志）的应用程序。未来场景我们的平台已经发生了重大变化，以处理对我们的客户很重要的额外负载和众多使用场景，但我们仍有优化空间。不仅我们的平台在发展，我们的工程部门也在发展：我们有许多新团队构建自己的服务，需要有关自动化、工具和可扩展性的指导。考虑到这一点，我们实施了这些计划，不仅扩展了平台，而且巩固了我们的工程实践：·构建类似PaaS的平台：如前所述，今天我们有不同的自动化和部署流程，这导致混乱和集合为工程师设置进入壁垒，因为在不接触大量代码库的情况下很难进行实验和扩展。我们正在为目前在ECS上运行的平台开发概念验证(PoC)代码，工程师可以配置YAML文件，只需部署它、获取计算资源、监控、日志记录和备份等。所有这些都无需显式配置。这项工作处于早期阶段，可能会发生很大变化。然而，鉴于我们不断增长的规模和可扩展性限制，我们认为我们正朝着正确的方向前进。对每个新的合并请求实施冒烟测试：除了单元测试（已经在每个新的PR上运行）之外，我们希望尽可能对临时环境进行集成测试。·将我们的日志记录解决方案集中到一个提供商中。这可能意味着离开Kibana并只使用SumoLogic，但我们仍然需要评估功能集和数据量等。自动化指标：我们的许多指标现在都是手动的-在部署时添加与指标相关的代码调用，并使用DataDog接口构建仪表板和监视器。如果我们使用标准格式和命名，我们可以实现自动构建仪表板/监视器、从日志中提取指标而不是显式添加代码调用等任务。确保我们为每个核心服务提供自动缩放和蓝/绿部署。这应该是我们新平台的默认特性，但是在构建和测试的时候，我们需要完善核心服务的扩展/部署/回滚机制，在这方面还存在不足。【原创稿件，转载请注明原作者及出处为.com】【责任编辑：关冲电话：（010）68476606】
