雲中的高可用保障，且看Auth0的跨供應商多雲架構

Auth0是一個「身份即服務」創業公司，同時也是重度的雲服務使用者。 對於他們來說，服務中斷意味著大量使用者託管應用無法登陸，因此可用性對於他們來說至關重要。 近日，Auth0工程主管Jose Romaniello分享了他們可以豁免大範圍Microsoft Azure宕機的跨供應商多雲架構。

以下為譯文

Auth0是一個「身份即服務」創業公司，它可以讓使用者忽略底層基礎設施，為移動、網路、本地等任何類型堆疊上的應用提供身份驗證、授權及單點登錄功能。

對絕大部分應用來說，身份驗證都至關重要。 因此，在設計時我們使用了多等級冗余的方式，其中一個等級就是託管。 Auth0可以在任何地方運行：私有雲、公有雲，或者是租用機房的實體主機上。 鑒於這個特性，Auth0同時選擇了多個雲服務提供者，並且備份在數個地理位置不同的區域中。

本文將是app.auth0.com 基礎設施一個非常簡單的介紹，同時也包括了app.auth0.com的高可用保證策略。

核心服務架構

核心服務的架構其實非常簡單：

前端伺服器：

由多個x-large VM以及運行在Microsoft Azure上的Ubuntu組成。 存儲：MongoDB，運行在一些做過專門存儲優化的 X-large VM上。 節點內服務路由：Nginx

Auth0的所有元件都備份在各個節點中，並且完全相同。

多雲/高可用性

雲架構

不久前，Azure發生了數個小時的全球性宕機。 在這段時間，Auth0系統的HA策略被啟動，服務非常靈活的切換到了AWS。 大部分服務主要運行在Microsoft Azure（IaaS）上，同時也在AWS上還設置了隨時待命的輔助節點。 Auth0系統使用了搭載容錯移轉路由策略的Route53。 TTL被設置為60秒。 Route53健康檢查會掃描主資料中心，如果這個資料中心沒有回應（3次，間隔10秒），DNS入口則會被迅速切換到備用資料中心。 因此，對於Auth0來說，最大故障時間不會超過2分鐘。 Puppet被部署到每個「push to master」。 puppet的使用允許配置/部署過程獨立于雲供應商特性。 Puppet Master運行在我們建立的伺服器上（當下是TeamCity）。 MongoDB通常會在輔助資料中心做備份，同時輔助資料中心會被設置為唯讀模式。 我們備份了所有登錄所需要的配置，包括應用程式資訊、連接、使用者等。 我們不會對交易資料進行備份，比如token和日誌。 在容錯移轉發生時，仍然可能會發生多條日誌記錄丟失的情況。 在這裡，我們期望通過跨Azure和AWS的即時備份解決。 我們定制了chaos monkey以測試基礎設施彈性，代碼參見HTTPs://github.com/auth0/chaos-mona

自動化測試

我們進行了1000+的單元和集成測試。 我們使用 saucelabs做Lock和JavaScript登錄視窗的跨瀏覽器（桌面/移動端）測試。 我們使用phantomjs/casper來做集成測試。 所有這些測試都會在產品推送到生產環境之前完成。

CDN

Auth0的CDN用例非常簡單，我們需要使用它來服務JS庫和（允許其他供應商等的）其他配置，assset和配置資料會被載入到S3。 因此，我們的定制功能變數名稱（HTTPs://cdn.auth0.com）必須要支援TLS。 最終，我們選擇構建自己的SDN。 我們曾經嘗試過3個知名的CDN供應商，在這個過程中遇到了各式各樣的問題：

在我們還沒有自己CDN功能變數名稱時，我們就嘗試了第一個CDN服務。 也是那個時候，我們認識到必須擁有自己的SSL/TLS功能變數名稱。 在那個時候，如果需求使用自己的SSL和定制功能變數名稱，這個CDN服務開銷非常大。 而在與S3和gzip搭配使用時，我們更遇到了一些配置問題。 鑒於S3不能同時服務同一個檔的兩種版本（zipped和非zipped），同時這個CDN也不具備內容協商機制（content negotiation），因此對一些瀏覽器並不是很好。 因此，我們轉移到了另一個CDN服務，一個非常便宜的CDN服務。 在使用第二個CDN服務時，我們遇到了太多問題，甚至有些問題根本找不到根結所在。 該服務提供者只提供遠端支援，因此我們需要花費大量的時間來尋求答案。 有些問題看起來是S3引起的，而有些看起來則是路由問題，總之我們遇到了各種各樣的問題。 在經歷了第二個CDN服務，我們發現一味的省錢並不能解決問題，因此我們又換了一個CDN服務。 鑒於這個CDN服務被GitHub等高負載應用選擇，我們認為它應該能符合我們的需求。 然而，隨後我們便發現，我們的需求和GitHub有非常大的區別。 因為，對於GitHub來說，如果CDN服務宕機，使用者只是看不到一個README.md的鏡像而已，然而對於我們這種身份即服務來說，應用服務的使用者將無法登錄。 最終，我們選擇建立自己的CDN，使用Nginx、varnish和S3。 它託管在AWS的每個region上，到目前為止，運行的非常不錯，沒有發生任何宕機。 我們使用基於Route53延時的路由機制。

沙箱（用於運行未經驗證的代碼）

Auth0的一個特性就是允許使用者運行自訂代碼作為登錄事務的一部分，使用者可以根據需求編寫自己的驗證規則。 當然，對於一些常用的規則，我們也構建了公共的知識庫。

沙箱由 CoreOS、Docker等元件構成。 根據需求，為租戶Docker分配實例池中的資源。 每個租戶都會分配獨立的Docker實例，同時使用了基於閒置時間的回收策略。 使用控制器執行回收策略，並使用代理伺服器將請求路由到對應的容器。

更多的沙箱設計可以在2014年11月份的 演講視頻和 講義中查看。

監視

開始時，我們使用了pingdom（在現在也沒完全拋棄），但是隨後我們發現了定制自己健康檢查系統（可以基於node.js做任何健康測試）的必要性。 下面的操作會運行在我們所有的AWS region上：

使用專為服務開發的沙箱。 我們可以從一個HTTP API中調用沙箱，並將node.js腳本作為一個HTTP POST發佈。 對所有元件進行監視，同時還會對服務做綜合交易，比如登錄事務。

如果健康檢查通不過，我們會從Slack獲取通知，我們擁有兩個Slack頻道——#p1和#p2。 如果錯誤發生了1次，#p2頻道的同事會收到消息，如果錯誤連續發生兩次，警告則會通過#p1頻道發佈，我們所有的開發運營人員都會收到SMS（通過Twillio）。

我們使用statsd以獲得更好的性能統計，並將度量發送給Librato。 示例可見下圖。

我們同樣基於派生度量設置提醒，比如某個值一段時間內增加或者減少多少。 舉個例子，我們有一個記錄登錄的度量：if Derivate(logins) > X，然後給Slack發送一條警報。

最後，我們還使用NewRelic為基礎設施元件做監視。

在登錄服務上，我們使用了ElasticSearch、Logstash和Kibana。 在這裡，我們使用Nginx和MongDB來儲存日誌。 我們還使用 logstash解析Mongo日誌來識別比較慢的查詢。

網站

所有相關的網站，比如auth0.com、博客等，都與應用和運行時完全無關，它們運行在Ubuntu + Docker VM上。

未來

我們正遷移到CoreOS和Docker。 我們一直想轉移到一個模型，基於這個模型，我們可以從整體上管理集群，而不是單獨做每個節點的建構管理。 而毫無疑問的是，Docker可以説明我們解決一部分基於鏡像部署的操作。 在AWS和Azure之間做MongoDB的跨資料中心備份。 當下，我們正在測試延時。 對於所有搜索相關的特性，我們正在遷移到ElasticSearch。 在這個情景中，鑒於多租戶的特性，MongoDB的表現並不是很好。

原文連結： Auth0 Architecture - Running In Multiple Cloud Providers And Regions（編譯/童陽 責編/仲浩）

歡迎訂閱「CSDN雲計算」微信號獲得更多雲資訊。

歡迎關注@CSDN雲計算微博瞭解最新雲計算及大資料資訊。