# Auth0 體系結構：在多個云提供商和地區中運行 > 原文： [http://highscalability.com/blog/2018/8/27/auth0-architecture-running-in-multiple-cloud-providers-and-r.html](http://highscalability.com/blog/2018/8/27/auth0-architecture-running-in-multiple-cloud-providers-and-r.html)  *此文章由 Auth0 的站點可靠性工程師 Dirceu Pereira Tiegs 撰寫，最初發表于 [Auth0](https://auth0.com/blog/auth0-architecture-running-in-multiple-cloud-providers-and-regions/) 中。* Auth0 為任何堆棧上的任何類型（移動，Web，本機）的應用程序提供身份驗證，授權和單點登錄服務。 身份驗證對于絕大多數應用程序至關重要。 我們從一開始就設計 Auth0，以便它可以在任何地方運行：在我們的云，您的云甚至您自己的私有基礎結構上。 在這篇文章中，我們將更多地討論我們的公共 SaaS 部署，并簡要介紹 [auth0.com](https://auth0.com/) 背后的基礎架構以及我們用來使其保持高可用性和正常運行的策略。 從那時起，Auth0 發生了很多變化。 這些是一些亮點： * 我們從每月處理幾百萬個登錄到每月處理 1.5+十億個登錄，為成千上萬的客戶提供服務，包括 [FuboTV](https://auth0.com/learn/sports-centric-streaming-service-fubotv-sees-50-roi-just-auth0s-security/) ， [Mozilla](https://auth0.com/blog/auth0-mozilla-partnership/) ， [JetPrivilege](https://auth0.com/learn/jetprivilege-case-study/) 和 更多。 * 我們實現了新功能，例如[自定義域](https://auth0.com/docs/custom-domains)，[擴展的 bcrypt 操作](https://auth0.engineering/bcrypt-as-a-service-9e71707bda47)，極大地[改進的用戶搜索](https://auth0.com/docs/users/search/v3)等。 * 組成我們的產品以擴展我們的組織并處理流量增長的服務數量從不到 10 種增加到 30 多種。 * 云資源的數量也大大增加。 我們曾經在一個環境（美國）中有幾十個節點，現在在四個環境（美國，US-2，歐盟，非盟）中有超過一千個節點。 * 我們加倍決定在每個環境中使用一個云提供商，并將所有公共云基礎架構移至 AWS。 ## 核心服務架構  核心服務由不同的層組成： * 核心應用程序：自動擴展運行我們堆棧中不同服務（身份驗證，管理 API，多因素身份驗證 API 等）的服務器組。 * 數據存儲：MongoDB，Elasticsearch，Redis 和 PostgreSQL 的集群，存儲用于不同應用程序和功能的各種數據集。 * 傳輸/隊列：Kinesis 流和 RabbitMQ，SNS 和 SQS 隊列。 * 基本服務：限速，bcrypt 群集，功能標記等服務。 * 路由：AWS 負載均衡器（AWS 的 ALB，NLB 和 ELB）和一些運行 NGINX 作為代理的節點。 ## 高可用性 2014 年，我們使用了多云架構（使用 Azure 和 AWS，并在 Google Cloud 上提供了一些額外的資源），多年來一直為我們服務。 隨著使用量（和負載）的迅速增加，我們發現自己越來越依賴 AWS 資源。 首先，我們將環境中的主要區域切換到 AWS 中，并將 Azure 保留為故障轉移。 隨著我們開始使用更多的 AWS 資源（例如 Kinesis 和 SQS），我們開始難以在兩個提供商中保持相同的功能集。 隨著我們對移動（和擴展）速度的需求增長，我們選擇繼續以有限的功能奇偶校驗來支持 Azure：如果 AWS 上的所有事情都失敗了，我們仍然可以使用 Azure 群集來支持核心身份驗證功能，但是沒有太多新功能 我們一直在發展。 在 2016 年發生嚴重故障后，我們決定最終在 AWS 上融合。 我們停止了與保持服務和自動化平臺無關的所有工作，而是專注于： * 使用多個區域以及每個區域至少 3 個可用區，從而在 AWS 內部提供更好的故障轉移故事。 * 越來越多地使用 AWS 特定資源，例如自動擴展組（而不是使用固定的節點集群），應用程序負載平衡器（ALB）等。 * 編寫更好的自動化程序：我們改進了自動化程序，完全使用 TerraForm 和 SaltStack 來將基礎架構作為代碼包含在內，以提供新的 Auth0 環境（并替換現有環境）。 這使我們從每秒約 300 次登錄的部分自動化環境發展到每秒約 3.4 千次登錄的完全自動化環境。 使用新工具可以更輕松地按比例放大和縮小。 我們實現的自動化水平不是完美的，但是它使我們能夠以更便捷的方式發展到新地區并創建新環境。 * 編寫更好的劇本：我們花了更多的時間和精力，除了自動化之外，還需要更好的劇本，以了解，管理和響應與我們不斷增長的服務網格有關的事件。 這極大地提高了可擴展性和可靠性，同時還使我們能夠更快地招聘新員工。 [](https://twitter.com/intent/tweet?text=%22Writing+better+automation+let+us+grow+from+partially+automated+environments+doing+%7E300+logins+per+second+to+fully+automated+environments+doing+more+than+%7E3.4+thousand+logins+per+second%22%20via%20@auth0%20http://auth0.com/blog/auth0-architecture-running-in-multiple-cloud-providers-and-regions/) > 編寫更好的自動化軟件，使我們從每秒進行 300 次登錄的部分自動化環境發展到每秒進行 3.4 千多次登錄的全自動化環境 讓我們看一下我們的美國環境架構。 我們具有以下一般結構：  這是單個可用區內部的結構：  在這種情況下，我們使用兩個 AWS 區域：us-west-2（我們的主要區域）和 us-west-1（我們的故障轉移）。 在正常情況下，所有請求都會發送到 us-west-2，由三個單獨的可用區提供服務。 這就是我們實現高可用性的方式：所有服務（包括數據庫）在每個可用性區域（AZ）上都具有正在運行的實例。 如果由于數據中心故障而使一個可用區關閉，我們仍然有兩個可用區來處理來自其的請求。 如果整個區域宕機或有錯誤，我們可以更新 Route53 以故障轉移到 us-west-1 并恢復操作。 > We achieve high availability by running all services instances on every AWS availability zone 對于服務故障轉移，我們有不同的成熟度級別：某些服務（例如用戶搜索 v2（在 Elasticsearch 上構建緩存））可能會起作用，但是數據有些陳舊； 盡管如此，核心功能仍能按預期運行。 在數據層中，我們使用： * MongoDB 的跨區域集群。 * PostgreSQL 的 RDS 復制。 * 具有自動快照和恢復功能的 Elasticsearch 每個區域的群集定期運行，以解決缺乏跨區域群集的問題。 我們每年至少執行一次故障轉移，并且我們有劇本和自動化工具可以幫助新的基礎架構工程師迅速掌握如何進行故障轉移以及所帶來的影響。 我們的部署通常由 Jenkins 節點觸發； 根據服務的不同，我們可以使用 Puppet，SaltStack 和/或 Ansible 來更新單個或一組節點，也可以更新 AMI 并為不可變的部署創建新的自動伸縮組。 對于新舊服務，我們有不同類型的部署，并且由于我們需要維護自動化，文檔和監視應統一的內容，因此這種方法在很大程度上無效。 我們目前正在為某些核心服務推出藍色/綠色部署，并且我們打算為每個核心和支持服務實施相同的部署。 ## 自動化測試 除了每個項目的單元測試范圍外，我們還有在每個環境中運行的多個功能測試套件； 我們在部署到生產之前在臨時環境上運行它，并在完成部署后在生產中再次運行它們以確保一切正常。 亮點： * 我們在不同的項目中有成千上萬的單元測試。 * 我們使用每分鐘運行一次的 Pingdom 探針來檢查核心功能。 * 在每次部署之前和之后，我們混合使用基于 Selenium 和 CodeceptJS 的功能測試。 功能測試套件可測試不同的 API 端點，身份驗證流程，身份提供者等。 > 除了涵蓋每個項目的單元測試外，我們還有在每個環境中運行的多個功能測試套件：在部署到生產之前進行過渡，在完成部署之后再次進行生產。 ## CDN 直到 2017 年，我們在多個區域中使用 NGINX，Varnish 和 EC2 節點運行了自己的定制 CDN。 從那時起，我們過渡到 CloudFront，這給了我們很多好處，包括： * 更多的邊緣位置，這意味著對我們的客戶的延遲減少。 * 降低維護成本。 * 易于配置。 有一些缺點，例如我們需要運行 Lambda 來執行一些配置（例如向 PDF 文件添加自定義標頭之類的事實）。 盡管如此，上行空間肯定可以彌補這一點。 ## 延伸 我們提供的功能之一是能夠通過 [*身份驗證規則*](https://auth0.com/docs/rules/current) 或 [*定制數據庫連接* [](https://auth0.com/docs/connections/database/custom-db) 。 這些功能由 [*Extend*](https://goextend.io/) 提供支持，這是一種基于 Auth0 的可擴展性平臺，現在也被其他公司使用。 借助 Extend，我們的客戶可以在這些腳本和規則中編寫他們想要的任何內容，從而允許他們擴展配置文件，規范化屬性，發送通知等等。 我們有專門針對 Auth0 的擴展集群； 他們結合使用 EC2 自動擴展組，Docker 容器和自定義代理來處理來自我們租戶的請求，每秒處理數千個請求，并快速響應負載變化。 有關如何構建和運行它的更多詳細信息，請查看有關[如何構建自己的無服務器平臺](https://tomasz.janczuk.org/2018/03/how-to-build-your-own-serverless-platform.html)的文章。 ## 監控方式 我們使用不同工具的組合來監視和調試問題： * CloudWatch * 數據狗 * 平度 * 森丁 我們的絕大多數警報來自 CloudWatch 和 DataDog。 我們傾向于通過 TerraForm 配置 CloudWatch 警報，而我們在 CloudWatch 上保留的主要監視器為： * 來自主要負載均衡器的 HTTP 錯誤。 * 目標組中的不正常實例。 * SQS 處理延遲。 CloudWatch 是基于 AWS 生成的指標（如來自負載平衡器或自動伸縮組的指標）的警報的最佳工具。 CloudWatch 警報通常轉到 PagerDuty，從 PagerDuty 轉到 Slack / phone。 DataDog 是我們用來存儲時間序列指標并對其采取行動的一項服務。 我們從 Linux 盒子，AWS 資源，現成的服務（例如 NGINX 或 MongoDB）以及我們已經構建的自定義服務（例如我們的 Management API）發送指標。 我們有許多 DataDog 監視器。 一些例子： * `$service`中`$environment`中的響應時間增加。 * `$instance`（`$ip_address`）中`$volume`上的空間不足。 * `$environment` / `$host`（`$ip_address`）上的`$process`問題。 * 增加`$environment`上`$service`的處理時間。 * NTP 漂移/ `$host`（`$ip_address`）上的時鐘問題。 * `$environment`上的 MongoDB 副本集更改。 從上面的示例中可以看到，我們具有針對低級指標（如磁盤空間）和高級指標（如 MongoDB 副本集更改）的監視器，它們會在主節點定義發生更改時向我們發出警報， 例）。 我們要做的更多，并且圍繞某些服務有一些非常復雜的監視器。 DataDog 警報的輸出非常靈活，我們通常將它們全部發送到 Slack，僅將那些應該“喚醒人們”的人發送給 PagerDuty（例如錯誤尖峰，或者我們確信會對客戶產生影響的大多數事情） 。 對于日志記錄，我們使用 Kibana 和 SumoLogic。 我們正在使用 SumoLogic 來記錄審計跟蹤和許多 AWS 生成的日志，并且我們使用 Kibana 來存儲來自我們自己的服務以及 NGINX 和 MongoDB 等其他“現成”服務的應用程序日志。 ## 未來 我們的平臺進行了相當多的改進，以處理對客戶而言很重要的額外負載和各種用例，但我們仍有更多的優化空間。 不僅我們的平臺在增長，而且我們的工程組織也在擴大規模：我們有許多新團隊在構建自己的服務，并且需要有關可伸縮性的自動化，工具和指南。 考慮到這一點，這些舉措使我們不僅可以擴展我們的平臺，還可以擴展我們的工程實踐： * 建立一個 PaaS 風格的平臺：如前所述，今天我們有不同的自動化和部署流程。 這會引起混亂，并給工程師帶來了進入的障礙，因為如果不接觸太多的存儲庫就很難進行試驗和擴展。 我們正在為一個平臺（當前在 ECS 之上運行）開發 PoC，工程師可以在其中配置 YAML 文件并進行部署，以獲取計算資源，監視，日志記錄，備份等等。 所有這些都無需顯式配置。 這項工作尚處于初期階段，可能還會改變很多（EKS？）。 但是，鑒于我們不斷增長的規模和可伸縮性限制，我們認為我們正在朝著正確的方向發展。 * 為每個新的請求請求實施冒煙測試：除了單元測試（已在每個新 PR 上運行）之外，我們還希望在臨時環境中運行集成測試。 * 將我們的日志記錄解決方案集中到一個提供商中。 這可能意味著離開 Kibana 并僅使用 SumoLogic，但是我們仍然需要評估功能集，數據量等。 * 自動化指標：我們太多的指標故事現在是手動的：在部署時將與指標相關的調用添加到代碼中，以及使用 DataDog 界面構建儀表板和監視器。 如果使用標準格式和命名，則可以執行以下操作：自動構建儀表板/監視器，從日志中提取指標，而不是顯式地添加對代碼的調用等。 * 確保我們在每個核心服務上都有自動擴展和藍色/綠色部署。 這應該從我們的新平臺中直接獲得，但是在構建和測試該平臺時，我們需要針對仍缺乏這方面的核心服務來改進可伸縮性/部署/回滾的過程。