摘要：Auth0的業(yè)務(wù)對服務(wù)可用性有著苛刻的要求，但卻是個不折不扣的重度云用戶，因此他們不得不使用一個可以避免豁免云服務(wù)宕機(jī)的架構(gòu)，這里一起展開。
Auth0是一個“身份即服務(wù)”創(chuàng)業(yè)公司，同時也是重度的云服務(wù)用戶。對于他們來說，服務(wù)中斷意味著大量用戶托管應(yīng)用無法登陸，因此可用性對于他們來說至關(guān)重要。近日，Auth0工程主管Jose Romaniello分享了他們可以豁免大范圍Microsoft Azure宕機(jī)的跨提供商多云架構(gòu)。
以下為譯文
Auth0是一個“身份即服務(wù)”創(chuàng)業(yè)公司，它可以讓用戶忽略底層基礎(chǔ)設(shè)施，為移動、網(wǎng)絡(luò)、本地等任何類型堆棧上的應(yīng)用提供身份驗證、授權(quán)及單點登錄功能。
對絕大部分應(yīng)用來說，身份驗證都至關(guān)重要。因此，在設(shè)計時我們使用了多等級冗余的方式，其中一個等級就是托管。Auth0可以在任何地方運行：私有云、公有云，或者是租用機(jī)房的實體主機(jī)上。鑒于這個特性，Auth0同時選擇了多個云服務(wù)提供商，并且備份在數(shù)個地理位置不同的區(qū)域中。
本文將是app.auth0.com 基礎(chǔ)設(shè)施一個非常簡單的介紹，同時也包括了app.auth0.com的高可用保證策略。
核心服務(wù)架構(gòu)
核心服務(wù)的架構(gòu)其實非常簡單：
前端服務(wù)器：
由多個x-large VM以及運行在Microsoft Azure上的Ubuntu組成。
存儲：MongoDB，運行在一些做過專門存儲優(yōu)化的 X-large VM上。
節(jié)點內(nèi)服務(wù)路由：Nginx
Auth0的所有組件都備份在各個節(jié)點中，并且完全相同。
多云/高可用性
云架構(gòu)
不久前，Azure發(fā)生了數(shù)個小時的全球性宕機(jī)。在這段時間，Auth0系統(tǒng)的HA策略被激活，服務(wù)非常靈活的切換到了AWS。
大部分服務(wù)主要運行在Microsoft Azure（IaaS）上，同時也在AWS上還設(shè)置了隨時待命的輔助節(jié)點。
Auth0系統(tǒng)使用了搭載故障轉(zhuǎn)移路由策略的Route53。TTL被設(shè)置為60秒。Route53健康檢查會掃描主數(shù)據(jù)中心，如果這個數(shù)據(jù)中心沒有響應(yīng)（3次，間隔10秒），DNS入口則會被迅速切換到備用數(shù)據(jù)中心。因此，對于Auth0來說，大故障時間不會超過2分鐘。
Puppet被部署到每個“push to master”。puppet的使用允許配置/部署過程獨立于云提供商特性。Puppet Master運行在我們建立的服務(wù)器上（當(dāng)下是TeamCity）。
MongoDB通常會在輔助數(shù)據(jù)中心做備份，同時輔助數(shù)據(jù)中心會被設(shè)置為只讀模式。
我們備份了所有登錄所需要的配置，包括應(yīng)用程序信息、連接、用戶等。我們不會對事務(wù)數(shù)據(jù)進(jìn)行備份，比如token和日志。
在故障轉(zhuǎn)移發(fā)生時，仍然可能會發(fā)生多條日志記錄丟失的情況。在這里，我們期望通過跨Azure和AWS的實時備份解決。
我們定制了chaos monkey以測試基礎(chǔ)設(shè)施彈性，代碼參見https://github.com/auth0/chaos-mona
自動化測試
我們進(jìn)行了1000+的單元和集成測試。
我們使用 saucelabs做Lock和JavaScript登錄窗口的跨瀏覽器（桌面/移動端）測試。
我們使用phantomjs/casper來做集成測試。
所有這些測試都會在產(chǎn)品推送到生產(chǎn)環(huán)境之前完成。
CDN
Auth0的CDN用例非常簡單，我們需要使用它來服務(wù)JS庫和（允許其他提供商等的）其他配置，assset和配置數(shù)據(jù)會被加載到S3。因此，我們的定制域名（https://cdn.auth0.com）必須要支持TLS。終，我們選擇構(gòu)建自己的SDN。我們曾經(jīng)嘗試過3個知名的CDN提供商，在這個過程中遇到了各式各樣的問題：
在我們還沒有自己CDN域名時，我們就嘗試了個CDN服務(wù)。也是那個時候，我們認(rèn)識到必須擁有自己的SSL/TLS域名。在那個時候，如果需求使用自己的SSL和定制域名，這個CDN服務(wù)開銷非常大。而在與S3和gzip搭配使用時，我們更遇到了一些配置問題。鑒于S3不能同時服務(wù)同一個文件的兩種版本（zipped和非zipped），同時這個CDN也不具備內(nèi)容協(xié)商機(jī)制（content negotiation），因此對一些瀏覽器并不是很好。因此，我們轉(zhuǎn)移到了另一個CDN服務(wù)，一個非常便宜的CDN服務(wù)。
在使用第二個CDN服務(wù)時，我們遇到了太多問題，甚至有些問題根本找不到根結(jié)所在。該服務(wù)提供商只提供遠(yuǎn)程支持，因此我們需要花費大量的時間來尋求答案。有些問題看起來是S3引起的，而有些看起來則是路由問題，總之我們遇到了各種各樣的問題。
在經(jīng)歷了第二個CDN服務(wù)，我們發(fā)現(xiàn)一味的省錢并不能解決問題，因此我們又換了一個CDN服務(wù)。鑒于這個CDN服務(wù)被GitHub等高負(fù)載應(yīng)用選擇，我們認(rèn)為它應(yīng)該能符合我們的需求。然而，隨后我們便發(fā)現(xiàn)，我們的需求和GitHub有非常大的區(qū)別。因為，對于GitHub來說，如果CDN服務(wù)宕機(jī)，用戶只是看不到一個README.md的鏡像而已，然而對于我們這種身份即服務(wù)來說，應(yīng)用服務(wù)的用戶將無法登錄。
終，我們選擇建立自己的CDN，使用Nginx、varnish和S3。它托管在AWS的每個region上，到目前為止，運行的非常不錯，沒有發(fā)生任何宕機(jī)。我們使用基于Route53延時的路由機(jī)制。
沙箱（用于運行未經(jīng)驗證的代碼）
Auth0的一個特性就是允許用戶運行自定義代碼作為登錄事務(wù)的一部分，用戶可以根據(jù)需求編寫自己的驗證規(guī)則。當(dāng)然，對于一些常用的規(guī)則，我們也構(gòu)建了公共的知識庫。
沙箱由 CoreOS、Docker等組件構(gòu)成。
根據(jù)需求，為租戶Docker分配實例池中的資源。
每個租戶都會分配獨立的Docker實例，同時使用了基于空閑時間的回收策略。
使用控制器執(zhí)行回收策略，并使用代理服務(wù)器將請求路由到對應(yīng)的容器。
更多的沙箱設(shè)計可以在2014年11月份的 演講視頻和 講義中查看。
監(jiān)視
開始時，我們使用了pingdom（在現(xiàn)在也沒完全拋棄），但是隨后我們發(fā)現(xiàn)了定制自己健康檢查系統(tǒng)（可以基于node.js做任何健康測試）的必要性。下面的操作會運行在我們所有的AWS region上：
使用專為服務(wù)開發(fā)的沙箱。我們可以從一個HTTP API中調(diào)用沙箱，并將node.js腳本作為一個HTTP POST發(fā)布。
對所有組件進(jìn)行監(jiān)視，同時還會對服務(wù)做綜合事務(wù)，比如登錄事務(wù)。
如果健康檢查通不過，我們會從Slack獲取通知，我們擁有兩個Slack頻道——#p1和#p2。如果錯誤發(fā)生了1次，#p2頻道的同事會收到消息，如果錯誤連續(xù)發(fā)生兩次，警告則會通過#p1頻道發(fā)布，我們所有的開發(fā)運營人員都會收到SMS（通過Twillio）。
我們使用statsd以獲得更好的性能統(tǒng)計，并將度量發(fā)送給Librato。
我們同樣基于派生度量設(shè)置提醒，比如某個值一段時間內(nèi)增加或者減少多少。舉個例子，我們有一個記錄登錄的度量：if Derivate(logins) > X，然后給Slack發(fā)送一條警報。
后，我們還使用NewRelic為基礎(chǔ)設(shè)施組件做監(jiān)視。
在登錄服務(wù)上，我們使用了ElasticSearch、Logstash和Kibana。在這里，我們使用Nginx和MongDB來儲存日志。我們還使用 logstash解析Mongo日志來識別比較慢的查詢。
網(wǎng)站
所有相關(guān)的網(wǎng)站，比如auth0.com、博客等，都與應(yīng)用和運行時完全無關(guān)，它們運行在Ubuntu + Docker VM上。
未來
我們正遷移到CoreOS和Docker。我們一直想轉(zhuǎn)移到一個模型，基于這個模型，我們可以從整體上管理集群，而不是單獨做每個節(jié)點的配置管理。而毫無疑問的是，Docker可以幫助我們解決一部分基于鏡像部署的操作。
在AWS和Azure之間做MongoDB的跨數(shù)據(jù)中心備份。當(dāng)下，我們正在測試延時。
對于所有搜索相關(guān)的特性，我們正在遷移到ElasticSearch。在這個情景中，鑒于多租戶的特性，MongoDB的表現(xiàn)并不是很好。
原文鏈接： Auth0 Architecture - Running In Multiple Cloud Providers And Regions
本站文章版權(quán)歸原作者及原出處所有 。內(nèi)容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負(fù)責(zé)，本站只提供參考并不構(gòu)成任何投資及應(yīng)用建議。本站是一個個人學(xué)習(xí)交流的平臺，網(wǎng)站上部分文章為轉(zhuǎn)載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對作者和來源進(jìn)行了通告，但是能力有限或疏忽，造成漏登，請及時聯(lián)系我們，我們將根據(jù)著作權(quán)人的要求，立即更正或者刪除有關(guān)內(nèi)容。本站擁有對此聲明的最終解釋權(quán)。
