# 阿爾及利亞通往全球 API 第 3 部分的憤怒之路 > 原文： [http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html)  我們為開發人員和開發人員回答的最常見問題是關于 [我們的架構](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 以及我們如何實現如此高的可用性。 他們中的一些人對裸機服務器的高可用性持懷疑態度，而另一些人則對我們如何在全球范圍內分發數據持懷疑態度。 但是，我更喜歡的問題是“初創企業如何建立這樣的基礎架構”。 的確，對于一個年輕的公司，我們當前的架構令人印象深刻： * 我們的高端專用計算機在全球 13 個地區托管，擁有 25 個數據中心 * 我們的主從設置會在至少 3 臺不同的計算機上復制我們的搜索引擎 * 我們每個月處理超過 60 億個查詢 * 我們每個月接收和處理超過 200 億次寫操作 就像羅馬不是一天建成的，我們的基礎架構也不是很好。 本系列文章將探討我們在構建基礎架構時采取的 15 個工具步驟。 我什至將討論我們的中斷和錯誤，以便您了解我們如何使用它們來改進我們的體系結構。 此系列的 [第一篇博客文章](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html) 專注于我們早期的 Beta 版， [第二篇文章](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html) 在服務的前 18 個月，包括我們的首次停機。 在上一篇文章中，我將描述我們如何將“啟動”架構轉換為能夠滿足大型上市公司期望的新事物。 ## 步驟 11：2015 年 2 月 ### 啟動我們的全球同步基礎架構 在這個月中，我們實現了自 2014 年 4 月以來一直致力于的愿景，即“向全球擴展以更好地為我們的用戶服務”。 該網絡由 12 個不同的位置組成：美國東部（弗吉尼亞州），美國西部（加利福尼亞州），澳大利亞，巴西，加拿大，法國，德國，香港，印度，日本，俄羅斯和新加坡。 最重要的是，我們還啟動了“分布式搜索”功能。 使用此功能，只需單擊幾下，您就可以設置網絡中應該自動復制數據的位置。 您將使用與以前相同的 API，查詢將自動從最終用戶的瀏覽器或移動應用程序路由到最近的位置。 這是減少最終用戶延遲并通過全球搜索分布提高我們的高可用性的重要一步。 由于互聯網鏈接的距離和飽和度，從一個位置為國際用戶提供服務會導致非常不同的服務質量。 現在，我們為用戶提供了解決該問題的方法！ 除了減少延遲之外，這還提高了我們搜索基礎架構的高可用性，因為它不再依賴于單個位置。 遍布全球！ 有些人將我們的 DSN（分布式搜索網絡）與 CDN（內容交付網絡）進行了比較，但這是非常不同的。 我們不會在每個邊緣存儲您經常查詢的緩存。 我們存儲您所有數據的完整副本。 我們可以從邊緣位置本身響應任何查詢，而不僅僅是最流行的查詢。 這意味著，當您選擇三個 POP（美國東部，德國，新加坡）時，歐洲的用戶將前往德國，亞洲的用戶將前往新加坡，美國的用戶將前往美國東部。 所有 POP 都將響應查詢，而不必與其他邊緣進行通信。 這在用戶體驗和高可用性方面產生了巨大的差異。 為了支持此更改，我們更新了 API 客戶端中的重試邏輯，以首先定位 [APPID-dsn.algolia.net](http://appid-dsn.algolia.net) 主機名， 使用基于 geoip 的 DNS 將其路由到最近的位置。 如果最接近的主機關閉，則更新 DNS 記錄以在不到一分鐘的時間內刪除該主機，以便返回下一個最接近的主機。 這就是為什么我們在每條記錄上使用 1 分鐘的低 TTL 的原因。 如果發生故障，如果主機關閉并且 DNS 尚未更新，我們將通過 [APPID-1.algolia.net](http://appid-1.algolia.net) 上的重試將流量重定向到主區域。 ， [APPID-2.algolia.net](http://appid-2.algolia.net) 和 [APPID-3.algolia.net [ 我們的官方 API 客戶端中的](http://appid-3.algolia.net) 。 這種方法是我們在高性能和高可用性之間找到的最佳平衡，萬一發生故障，我們只會在一分鐘內降低性能，但 API 仍可以運行&！ ## 步驟 12：201 年 3 月 ### 每個位置的更高可用性 分布式搜索網絡選項可改變游戲規則，以實現高可用性，但僅適用于搜索用戶和國際用戶。 為了提高主要區域的高可用性，我們在兩個完全獨立的提供商中分布了我們的美國集群： * 兩個不同位置的數據中心（例如：Manassas 中的 COPT-6 & Ashburn 中的 Equinix DC-5：彼此之間 24 英里，延遲為 1ms） * 三臺不同的計算機-就像以前一樣（兩臺在不同可用性區域中的第一個數據中心，另一臺在第二個數據中心中的） * 兩個不同的自治系統（所以兩個完全不同的網絡提供商） 這些更改提高了我們對遇到的某些問題（例如提供商和 AWS 之間的對等鏈接的飽和）做出反應的能力。 擁有不同的提供商可以使我們選擇將流量重新路由到其他提供商。 就提高一個位置的高可用性而言，這是一大進步。 ## 步驟 13：2015 年 4 月 ### 隨機文件損壞頭痛 對于我們的制作團隊來說，2015 年 4 月是一個黑色的月份。 由于某些 SSD 的 TRIM 實現中存在錯誤，我們開始觀察生產機器上的隨機文件損壞。 您可以在 [此博客文章](https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/) 中詳細閱讀該問題。 我們花了大約一個月的時間來跟蹤問題并正確識別。 在這段時間里，我們懷疑一切，從我們自己的軟件開始！ 這也是對我們的體系結構的重大考驗。 在磁盤上隨機破壞文件不是一件容易的事。 通知我們的用戶由于磁盤已損壞而需要重新索引其數據也不容易。 幸運的是，我們從未丟失任何客戶數據。 我們的架構中有兩個重要因素使我們能夠面對這種情況而不會丟失任何數據： * 我們存儲了三個數據副本。 在三臺計算機上隨機破壞相同數據的可能性幾乎為零（并且沒有發生）。 * 更重要的是，我們沒有復制索引結果。 相反，我們復制了從用戶那里收到的操作，并將其應用于每臺計算機。 由于一臺受影響的機器無法“污染”另一臺機器，因此這種設計使幾臺機器具有相同損壞的可能性非常低。 設計架構時，我們從未考慮過這種情況！ 即使我們試圖考慮所有類型的網絡和硬件故障，我們也從未想象過內核錯誤甚至固件錯誤的后果。 我們的設計要有獨立的機器，這是我們能夠最小化問題影響的原因。 對于任何需要高可用性的系統，我強烈建議這種獨立性。 ## 步驟 14：2015 年 5 月 ### 引入了多個 DNS 提供商 由于 NSONE 出色的 DNS API，我們決定將其用作 DNS 提供程序。 我們能夠配置我們希望如何通過他們的 API 路由每個用戶的查詢。 我們也非常喜歡他們如何支持 edns-client-subnet，因為這對于提高地理路由的準確性至關重要。 這些功能使 NSONE 成為了出色的提供商，但是我們在架構中僅擁有一個提供商就不會給自己帶來風險。 面臨的挑戰是在不損失 NSONE 的所有強大功能的情況下引入第二個 DNS 提供商。 這意味著不能在同一域上擁有兩個 DNS 提供程序。 我們決定在 API 客戶端中使用重試策略來引入第二個 DNS 提供程序。 所有 API 客戶端首先嘗試與 [APPID-dsn.algolia.net](http://appid-dsn.algolia.net) 聯系，如果有任何問題，他們將在其他域，TLD 和 提供者。 我們決定使用 AWS Route 53 作為我們的第二個提供商。 如果有任何問題，API 客戶端將在 [APPID-1.algolianet.com](http://appid-1.algolianet.com) ， [APPID- 2.algolianet.com](http://appid-2.algolianet.com) 和 [APPID-3.algolianet.com](http://appid-3.algolianet.com) 定位于主群集的 3 臺計算機。 這種方法使我們能夠將 NSONE 的所有有趣的地理路由功能保留在 algolia.net 域上，同時引入第二個提供商以在 algolianet.com 域上提供更高的高可用性。 ## 步驟 15：2015 年 7 月 ### 每個群集三個完全獨立的提供程序 您現在可以考慮使用我們開發的基礎架構，我們現在完全可以應對任何問題……但是實際情況有所不同。 即使使用由具有多個可用區的 Cloud Provider 托管的服務，您也可能會停機。 我們看到兩個主要原因： * 鏈接/路由器開始產生數據包丟失。 我們已經在美國東部和美國西部之間多次看到這種情況，包括大型云提供商的邊界 ISP 路由器，盡管他們甚至沒有意識到這一點。 * 路由泄漏。 這尤其影響了很大一部分 Internet 依賴的大型參與者。 現在，我們在美國改進的設置使我們能夠構建跨多個數據中心，多個自治系統和多個上游提供商的集群。 就是說，為了接受索引操作，我們需要配置大多數計算機，這意味著三臺計算機中的兩臺。 當使用兩個提供程序時，如果我們的一個提供程序出現故障，盡管搜索仍然可用，但我們可能會失去索引服務。 這就是為什么我們決定進一步在三個完全獨立的提供商（在相互靠近的位置上依賴于不同上游提供商和自治系統的位置的不同數據中心）中托管群集的原因。 這種設置使我們能夠通過超冗余基礎架構提供高可用性的搜索和索引。 我們提供所有這些以及相同的易于使用的 API！ ## 建立高度可用的架構需要時間 我希望我們的旅程細節能夠啟發人心，并提供有關我們的開始方式和今天的狀況的有用信息。 如果您是一家初創企業，請不要擔心一開始就沒有完善的基礎架構。 這是意料之中的！ 但是您應該考慮您的體系結構以及如何盡早擴展它。 我什至建議您在 Beta 版之前進行操作！ 盡早設計**架構是我們的秘密武器**。 一旦市場適應，我們就可以專注于執行。 即使在今天，我們在可伸縮性/可用性方面仍具有一些功能，這些功能在很早之前就已設計并尚未實現。 但是他們肯定會在不久的將來到來的:) *以下是該系列的所有三個部分：[第 1 部分](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html)，[第 2 部分](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html)，[第 3 部分](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html)* *[關于 HackerNews](https://news.ycombinator.com/item?id=9956097)*