【51CTO.com原創稿件】如今，身份驗證對絕大多數應用程序而言至關重要。Auth0 可以為任何堆棧上的各類（移動、Web 和原生）應用程序提供身份驗證、授權和單點登錄服務。

我們設計的 Auth0 一開始就可以在任何地方運行：我們的云、你的云，甚至在你自己的私有基礎設施上。

在本文中我們將詳細探討我們的公共 SaaS 部署，并簡要介紹 auth0.com 背后的基礎設施，以及用來確保它順暢運行的高可用性策略。

我們曾在 2014 年撰文介紹了 Auth0 的架構，自那以來 Auth0 已發生了很大的變化，下面是幾大要點：

·         我們從每月處理數百萬次登錄升級至每月處理逾 15 億次登錄，為成千上萬的客戶提供服務，包括 FuboTV、Mozilla 和 JetPrivilege 等。

·         我們實施了新功能，比如自定義域、擴展的 bcrypt 操作以及大大改進的用戶搜索等。

·         為了擴展我們組織的規模并處理流量的增加，我們產品的服務數量從不到 10 個增加到了 30 多個。

·         云資源的數量也大幅增長，我們過去在一個環境（美國）中有幾十個節點，現在我們在四個環境（美國、美國-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，但功能同等性（feature parity）有限。

如果 AWS 上的一切出現故障，我們仍可以使用 Azure 集群來支持身份驗證等核心功能，但是不支持我們一直在開發的許多新功能。

2016 年出現幾次嚴重宕機后，我們決定最終集中到 AWS 上。我們停止了與確保服務和自動化平臺無關的全部工作，而是專注于：

·         在 AWS 內部提供更好的故障切換機制，使用多個區域，每個區域至少 3 個可用區。

·         增加使用 AWS 特有的資源，比如自動擴展組（而不是使用固定的節點集群）和應用程序負載均衡系統（ALB）等。

·         編寫更好的自動化：我們改進了自動化，完全采用基礎設施即代碼，使用 TerraForm 和 SaltStack 來配置新的 Auth0 環境（以及替換現有環境）。

這讓我們從每秒處理約 300 次登錄的部分自動化環境升級到每秒處理逾 3400 次登錄的全自動化環境；使用新工具更容易向上擴展（必要的話還可以向下擴展）。

我們實現的自動化水平并不***，但讓我們極其方便地擴大到新的區域、創建新的環境。

·         編寫更好的劇本（playbook）：隨著時間的推移，我們發現除了自動化外，還需要更好的劇本，以便了解、管理和響應與我們越來越龐大的服務網格相關的事件。

這極大地提高了可擴展性和可靠性，同時加快了新員工的入職。

比如說，不妨看看我們的美國環境架構。我們有這個總體結構，如下圖：

圖 2：Auth0 美國環境架構

下圖是單一可用區內部的結構：

圖 3：Auth0 單一可用區

在這種情況下，我們使用兩個 AWS 區域：

·         us-west-2（我們的主區域）

·         us-west-1（故障切換區域）

正常情況下，所有請求都流向 us-west-2，由三個獨立的可用區處理請求。

這就是我們實現高可用性的方式：所有服務（包括數據庫）在每個可用區（AZ）上都有運行中的實例。

如果一個可用區因數據中心故障而宕機，我們仍有兩個可用區來處理請求；如果整個區域宕機或出現錯誤，我們可以通知 Route53 故障切換到 us-west-1、恢復操作。

我們在服務故障切換方面有不同的成熟度級別：一些服務（比如在 Elasticsearch 上構建緩存的用戶搜索 v2）可正常運行，但數據稍顯陳舊，不過核心功能按預期運行。

在數據層中，我們使用：

·         面向 MongoDB 的跨區域集群。

·         面向 PostgreSQL 的 RDS 復制。

·         面向 Elasticsearch 的每個區域的集群，自動快照和恢復定期運行，以解決缺少跨區域集群的問題。

我們每年至少進行一次故障切換演練，我們有劇本和自動化，幫助新的基礎設施工程師盡快了解如何演練以及由此帶來的影響。

我們的部署通常由 Jenkins 節點觸發；視服務而定，我們使用 Puppet、SaltStack 及/或 Ansible 來更新單個節點或一組節點，或者我們更新 AMI，為不可變的部署創建新的自動擴展組。

我們為新舊服務部署了不同類型的環境；由于我們需要為應該統一的系統維護自動化、文檔和監控，結果證明這基本上很低效。

我們目前在為一些核心服務推出藍/綠部署（blue/green deployment），我們打算為每個核心的支持服務實施同樣的一套。

自動化測試

除了每個項目的單元測試覆蓋外，我們還有在每個環境中運行的多個功能測試套件。

我們在部署到生產環境之前先在試運行環境上運行，完成部署后再在生產環境中運行，以確保一切正常。

我們的自動化測試要點：

·         在不同的項目中有數千個單元測試。

·         使用每分鐘運行的 Pingdom 探針（probe）來檢查核心功能。

·         在每次部署前后結合使用基于 Selenium 的功能測試和基于 CodeceptJS 的功能測試。功能測試套件測試不同的 API 端點、身份驗證流程和身份提供者等。

CDN

2017 年之前我們運行自己專門定制的 CDN，在多個區域運行 Nginx、Varnish 和 EC2 節點。

2017 年以后，我們改用 CloudFront，它為我們帶來了幾個好處，包括：

·         更多的邊緣位置，這意味著為我們的客戶縮短了延遲。

·         降低維護成本。

·         配置起來更輕松。

但同時也有幾個缺點，比如我們需要運行 Lambdas 來執行一些配置（比如將自定義標頭添加到 PDF 文件等等）。不過，好處絕對壓倒缺點。

Extend

我們提供的功能之一是能夠通過身份驗證規則或自定義數據庫連接，運行自定義代碼，作為登錄事務的一部分。

這些功能由 Extend（https://goextend.io/）提供支持，Extend 是一個可擴展性平臺，由 Auth0 發展而來，現在還被其他公司所使用。

有了 Extend，我們的客戶就可以用那些腳本和規則編寫所需的任何服務，擴展配置文件、規范屬性和發送通知等。

我們有專門針對 Auth0 的 Extend 集群，它們結合使用 EC2 自動擴展組、Docker 容器和自定義代理，以處理來自我們用戶的請求，每秒處理數千個請求，并快速響應負載變化。

想了解這如何構建和運行的更多信息，請參閱這篇介紹如何構建自己的無服務器平臺的文章（https://tomasz.janczuk.org/2018/03/how-to-build-your-own-serverless-platform.html）。

監控

我們結合使用不同的工具來監控和調試問題：

·         CloudWatch

·         DataDog

·         Pingdom

·         SENTINL

我們的絕大多數警報來自 CloudWatch 和 DataDog。

我們往往通過 TerraForm 來配置 CloudWatch 警報，用 CloudWatch 來監控的主要問題有：

·         來自主負載均衡系統的 HTTP 錯誤。

·         目標組中不健康的實例。

·         SQS 處理延遲。

CloudWatch 是基于 AWS 生成的指標（比如來自負載均衡系統或自動擴展組的指標）來監控警報的***工具。

CloudWatch 警報通常發送給 PagerDuty，再從 PagerDuty 發送給 Slack/手機。

DataDog 是我們用來存儲時間序列指標并采取相應操作的服務。我們發送來自 Linux 系統、AWS 資源和現成服務（比如 Nginx 或 MongoDB）的指標，還發送來自我們構建的自定義服務（比如 Management API）的指標。

我們有許多 DataDog 監控指標，舉幾個例子：

·         $environment 上的 $service 響應時間增加。

·         $instance 中的 $volume（$ ip_address）空間不足。

·         $environment / $ host 上的 $process（$ ip_address）出現問題。

·         $environment 上的 $service 處理時間增加。

·         $host（$ip_address）上出現 NTP 漂移/時鐘問題。

·         $environment 上的 MongoDB 副本集變更。

從上面例子中可以看出，我們監控低級指標（如磁盤空間）和高級指標（如 MongoDB 副本集變更，這提醒我們主節點定義是否發生了變化）。我們做了大量的工作，設計了一些相當復雜的指標來監控一些服務。

DataDog 警報的輸出非常靈活，我們通常將它們全部發送給 Slack，只把那些“引人注意”的警報發送給 PagerDuty，比如錯誤高峰，或者我們確信對客戶產生影響的大多數事件。

至于日志記錄方面，我們使用 SumoLogic 和 Kibana；我們使用 SumoLogic 來記錄審計跟蹤記錄和 AWS 生成的許多日志，我們使用 Kibana 存儲來自我們自己的服務和其他“現成”服務（如 Nginx 和 MongoDB）的應用程序日志。

未來設想

我們的平臺經歷了很大的變化，以處理額外負載和對客戶來說很重要的眾多使用場景，但我們仍有優化的空間。

不僅我們的平臺在擴大，我們的工程部門規模也在擴大：我們有許多新團隊構建自己的服務，而且需要自動化、工具和可擴展性方面的指導。

有鑒于此，我們落實了這些計劃，不僅擴展平臺，還夯實工程實踐：

·         構建類似 PaaS 的平臺：如前所述，今天我們有不同的自動化和部署流程，這導致了混亂，給工程師設置了門檻，因為很難在不接觸眾多代碼庫的情況下進行試驗和擴展。

我們正在為目前在 ECS 上運行的平臺開發概念證明（PoC）代碼，工程師們可以配置 YAML 文件，只需部署它，即可獲取計算資源、監控、日志記錄和備份等。

所有這一切都無需明確配置。這項工作還處于早期階段，可能會發生很大變化。然而，鑒于我們不斷擴大的規模和可擴展性方面的限制，我們認為我們的方向正確。

·         針對每個新的合并請求實施冒煙測試（smoke test）：除了單元測試（已經在每個新的 PR 上運行）外，我們希望盡可能在短暫環境上進行集成測試。

·         將我們的日志記錄解決方案集中到一家提供商。這可能意味著遠離 Kibana，只使用 SumoLogic，但我們仍需要評估功能集和數據量等。

·         自動衡量指標：現在我們的指標好多都是手動的――部署時添加與指標有關的代碼調用，以及使用 DataDog 接口來構建儀表板和監控器。

如果我們使用標準格式和命名，可以實現一些任務，比如自動構建儀表板/監控器，從日志提取指標而不是明確添加代碼調用等。

·         確保我們針對每個核心服務都有自動擴展和藍/綠部署。這應該是我們新平臺的默認功能，但在構建和測試時，我們需要為這方面仍然不足的核心服務改進擴展/部署/回滾機制。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】

【責任編輯：關崇 TEL：（010）68476606】