Auth0是一家認證、授權和SSO服務提供商。近期，Auth0完成將自身架構從三家云提供商（即AWS、Azure和Google Cloud）轉向AWS一家，這是因為它的服務越來越依賴于AWS服務?，F(xiàn)在，Auth0的系統(tǒng)分布在4個AWS域（Region）中，其中服務是跨區(qū)（Zone）復制的。

Auth0在設計上支持運行在本地部署和云上。在過去的四年中，其系統(tǒng)擴展到每月服務超過15億次登錄操作，所提供的服務也從10種增加到30種。同時，服務器數(shù)量從單個AWS域中的數(shù)十臺，增長到跨四個AWS域中的一萬多臺。其架構中包括了一個以提供各種服務自動擴展組為后端的路由層，以及一個使用MongoDB、Elasticsearch、Redis和PostgreSQL的存儲層，該存儲層支持Kinesis流處理系統(tǒng)和RabbitMQ、SNS、SQS等消息隊列。

最初，Auth0架構是跨Azure和AWS的，還有一小部分部署在Google Cloud上。Azure在一開始是作為主域，而AWS則用于故障轉移。之后，二者的角色發(fā)生了互換。由于云間的故障轉移是基于DNS的，這意味著TTL必須非常低，以使得客戶在故障轉移發(fā)生時可以快速切換。據(jù)Auth0產(chǎn)品經(jīng)理Dirceu Tiegs在企業(yè)技術博客上撰文介紹，“當我們開始使用更多的AWS資源時，例如Kinesis和SQS等，為保持兩個云服務提供商提供對等的特性，我們遇到了一些麻煩”。Azure確實曾提供類似于SQS的服務，稱為Azure Service Bus。雖然博客中并未提及哪些AWS服務在Azure中缺失對等服務，但是存在一些情況使得特定AWS域中缺少服務。為此，Auth0技術團隊曾撰文介紹他們是如何使用替代服務的。

Auth0在2016年曾發(fā)生了一次掉線故障，它們部署在AWS上的VPN終端開始丟棄來自于Azure和GCE的網(wǎng)絡包。當時，Auth0的數(shù)據(jù)庫集群使用了所有三家云服務提供商。由于存在上述問題，導致AWS的主數(shù)據(jù)庫節(jié)點不能接收到來自于Azure的心跳網(wǎng)絡包。隨后團隊恢復嘗試服務，所有集群節(jié)點將自身標記為后備節(jié)點，服務因而受到了影響。DNS配置錯誤是導致問題的一個原因。由此，團隊最終決定將AWS作為首要的云服務提供商，最小化部署在Azure的認證服務支持，只是在AWS宕機時使用。

 在Auth0的AWS架構中，包括數(shù)據(jù)庫在內的所有服務運行在同一個域（Region）的三個可用區(qū)（AZ，Availability Zone）中。如果一個AZ發(fā)生故障，那么其它兩個AZ將會繼續(xù)提供服務。如果整個域發(fā)生故障，那么AWS的DNS服務Route53就會更新網(wǎng)絡域名去指向另一個可用的域。一些服務相比于其它服務需要有更高的可用性保證。例如，盡管基于Elasticsearch的用戶搜索服務可能會使用到一些過期的數(shù)據(jù)，但是所有核心功能并不會受此影響。數(shù)據(jù)庫層在組成上包括了跨域的MongoDB集群、用于PostgreSQL的RDS復制以及部署在每個域中的Elasticsearch集群。

Auth0在2017年之前運行著自己的CDN，之后轉移到使用CloudFront。企業(yè)自開發(fā)的CDN以Amazon S3為支持，使用Varnish和nginx構建。轉移到CloudFront使得企業(yè)降低了維護工作，并且更易于配置。

Auth0的監(jiān)控最初使用Pingdom實現(xiàn)，此后企業(yè)開發(fā)了自己的健康檢查系統(tǒng)，該系統(tǒng)運行node.js腳本，并通過Slack發(fā)布通知。企業(yè)當前的技術棧包括了Datadog、CloudWatch、Pingdom和Sentinel。時序度量由Datadog采集并發(fā)送給Slack，其中一小部分發(fā)送給PagerDuty。Slack還用于實現(xiàn)符合ChatOps協(xié)作模型的任務自動化。日志處理流水線使用Amazon Kinesis、Elasticsearch和Kibana收集應用日志。Sumologic用于記錄審計跟蹤數(shù)據(jù)和AWS生成的日志。