# 阿爾及利亞通往全球 API 的憤怒之路 > 原文： [http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html)  *由 [Algolia](https://www.linkedin.com/in/julienlemoine) 的聯合創始人& CTO Julien Lemoine 做客，這是一個開發人員友好的搜索即服務 API。* 我們為開發人員和開發人員回答的最常見問題是關于 [我們的架構](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 以及我們如何實現如此高的可用性。 他們中的一些人對裸機服務器的高可用性持懷疑態度，而另一些人則對我們如何在全球范圍內分發數據持懷疑態度。 但是，我更喜歡的問題是“初創企業如何建立這樣的基礎架構”。 的確，對于一個年輕的公司，我們當前的架構令人印象深刻： * 我們的高端專用計算機在全球 13 個地區托管，擁有 25 個數據中心 * 我們的主從設置會在至少 3 臺不同的計算機上復制我們的搜索引擎 * 我們每個月處理超過 60 億個查詢 * 我們每個月接收和處理超過 200 億次寫操作 就像羅馬不是一天建成的，我們的基礎架構也不是很好。 本系列文章將探討我們在構建基礎架構時采取的 15 個工具步驟。 我什至將討論我們的中斷和錯誤，以便您了解我們如何使用它們來改進我們的體系結構。 第一部分將重點介紹我們在 2013 年 3 月至 2013 年 8 月處于測試階段時構建服務時所采取的前三個步驟。 # 云端與裸機之爭 在深入探討我們的架構之旅的細節之前，我想談一談對其他基礎架構產生重大影響的選擇。 我們需要決定是否應該使用基于云的基礎架構或裸機。 在技??術討論中經常討論的熱門話題。 對于大多數用例，尤其是在早期階段，云基礎架構是一個很好的解決方案。 它們在提高許多服務的高可用性方面發揮了作用。 在多個可用區（AZ）上運行數據庫或在不同 AZ 上運行多個實例的數據庫同時將其所有狀態存儲在多個 AZ 數據庫中的解決方案就是一個很好的例子。 這是許多工程師使用的標準設置，幾分鐘即可輕松部署。 裸機基礎架構要求您了解并設計一些小細節，以便自己構建高可用性。 這是一種“自己動手”的方法，僅對一小部分用例有意義。 我們經常遇到在單個數據中心中使用裸機部署的情況。 這沒有意義，因為它的容錯性不如在云提供商上進行快速部署，數據中心是單點故障（SPoF）。 對于與硬件相關的企業，裸機硬件仍然是一個有趣的選擇，這正是我們的情況。 通過選擇裸機基礎架構，我們可以購買比云提供商所提供的性能更高的硬件。 除了性能提升之外，成本也要便宜得多。 我們之所以選擇此選項，是因為我們充分意識到我們將需要自己構建高可用性！ # 早期：2013 年 3 月至 8 月 ## 步驟 1：2013 年 3 月 設計了高可用性，未實現！ 目前，我們首次運行了搜索即服務 API 的私人 Beta 版。 在這個時候，我們只能衡量我們的表現。 我們尚未開發產品的高可用性部分。 我們對我們的市場遍及全球充滿信心，因此我們在加拿大/東部和歐洲/西部兩個不同的地方推出了單機，其規格如下： * 32G 內存 * Xeon E3-1245 v2（4 核，8 線程，3.4Ghz-3.8Ghz） * 2 個 Intel RAID 320 系列 120GB 的 Raid-0 每臺計算機根據其位置托管不同的用戶集。 在我們的私人測試版中，性能集中在 100％上，這就是時鐘速度是我們做出決定的主要因素的原因（對于同一代 CPU，時鐘速度與搜索引擎中搜索查詢的速度直接相關）。 從一開始，我們就在一個單獨的過程中完成了索引，其級別為 5。 所有搜索查詢都是在 nginx 內部直接處理的，我們將其設置為零（進程的良好級別越低，它獲得的 CPU 時間就越多）。 此設置使我們能夠通過為搜索分配最高的分配 CPU 優先級來有效地處理流量高峰。 與其他引擎使用的方法相比，此方法效果很好。 我們感到非常驚訝的是，我們的第一批 Beta 測試人員之一在生產中將其替換為以前的解決方案，因為他們對性能和相關性感到非常滿意。 如您所料，我們對此感到非常壓力。 由于未實現高可用性，因此我們擔心會影響它們的潛在停機時間，并解釋說該產品尚未投入生產！ 客戶告訴我們，風險與回報對他們來說是可以接受的，因為如果需要，他們可以回滾到以前的提供商。 附帶說明，這個故事幫助我們在產品推出之前獲得了第一輪資金。 最終成為我們對市場適應性的第一個證明。 更好的是，我們可以稱其為“問題解決方案”！ 我們不能感激那個客戶：) ## 第 2 步：2013 年 6 月 在我們的體系結構中實現高可用性 經過三個月的開發和大量測試（猴子測試方法真的很有趣！），我們在 Beta 中引入了高可用性支持。 您可以在 [體系結構文章](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 中閱讀更多有關它的內容。 這個想法是由三臺相同的機器組成的集群，而不是一臺機器，其中每臺機器都是所有數據的完美副本，并且能夠充當主服務器。 這意味著每個人都可以接受來自 API 用戶的寫入操作。 每個寫操作都會觸發共識，以確保所有計算機都具有所有作業，并以相同順序應用它們。 我們使用了第一個 Beta 的初步結果來設計新的硬件設置。 我們發現以下內容： * 32G 的內存不足，當從多個用戶那里接收大索引作業時，索引最多使用 10G，這只能讓 22G 緩存磁盤 IO * 磁盤空間不足，無法實現高可用性，因為計算機需要在磁盤上保留多個作業才能處理節點故障 * 擁有更多的內存，我們需要遷移到 Xeon E5 系列（E3 僅可尋址 32G 的內存）。 由于時鐘速度很重要，我們決定選擇 Xeon E5 1600 系列，該系列提供了非常好的時鐘速度，并且能夠比 Xeon E3 擁有更多的內存。 通過這些發現，我們的設備演變為三臺具有以下規格的機器： * 64G 內存 * Xeon E5-1650（6 核，12 線程，3.2Ghz 至 3.8Ghz） * 2 個 Intel RAID 320 系列 300GB 的 Raid-0 至此，我們能夠忍受硬件故障！ 但是，我們離提供多個可用區域的云提供商還差得遠。 我們所有的機器都在同一個數據中心中，只有一個提供商，而對基礎架構一無所知。 同時，我們研究了是否應使用硬件或軟件來處理機器之間的負載平衡和檢測失敗。 我們測試了幾種方法，發現所有硬件負載平衡器幾乎都無法使用多個提供程序。 我們最終在 API 客戶端中實施了基本的重試策略。 每個 API 客戶端的開發都能夠訪問三臺不同的計算機。 三個不同的 DNS 記錄代表每個用戶： [USERIDID-1.algolia.io](http://useridid-1.algolia.io) ， [USERID-2.algolia.io](http://userid-2.algolia.io) 和 [USERID-3.algolia.io](http://userid-3.algolia.io) 。 我們的第一個實現是隨機選擇其中一個記錄，然后在失敗的情況下重試另一個記錄。 ## 第 3 步：2013 年 8 月 正式啟動服務 在夏季，我們將 API 客戶端的數量增加到 10 個（JS，Ruby，Python，PHP，Objective-C，Java，C＃，Node.js ...）。 我們決定避免使用自動代碼生成，而是手動開發 API 客戶端。 盡管還有更多工作要做，但我們需要確保網絡代碼對于 HTTPS 保持活動狀態，正確使用 TLS，以正確的超時正確實施重試策略等保持良好狀態。 我們于 2013 年 8 月底在我們的兩個位置（歐洲/西方和加拿大/東方）正式啟動了該服務。 每個位置包含三個相同主機的群集，它們具有以下規格： * 128G RAM * E5-2687W（8 核，16 線程，從 3.1Ghz 到 3.8Ghz） * 2 個 Intel S3500 系列 300GB Raid-0 與以前的配置相比，我們所做的主要更改是增加內存大小并使用更好的 SSD。 基于觀察到 SSD 是索引編制過程中的瓶頸，并且內存不足以將所有用戶的數據緩存在內存中的發現，完成了這兩項更改。 對于 CPU 升級，更大的問題是要確保我們擁有足夠的資源。 在這一點上，我們要重點關注的下一個大項目是為我們的部署實施可用性區域。 我們需要在不同的網絡設備和電源單元上運行三臺機器。 希望我們的提供商對他們的基礎架構以及機器的分配位置保持透明。 它不是完美的，但是我們能夠實現與其他云提供商類似的解決方案。 我們懷疑云提供者所做的事情與我們實施的類似，但尚未找到有關此主題的任何詳細文檔！ ### 下一個 與大多數其他初創公司一樣，我們從粗略的 MVP 開始測試市場。 我們最終不得不做一些認真的工作來開發更加成熟和強大的體系結構。 通過這些最初的幾個步驟，我們從 MVP 過渡到可用于生產的 API。 到目前為止，我們已經介紹了該博客系列 15 個步驟中的 3 個。 在下一個博客中，您將了解生產的前 18 個月以及我們所面臨的所有意外問題，包括首次停機！ *以下是該系列的所有三個部分：[第 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=9899794) 期待其他 12 個步驟：） 優秀的文章！ 感謝分享。 當您說“ ..所有搜索查詢都直接在 Nginx 內部處理..”時，我無法理解。 你能更好地解釋嗎？ 問候！ @Mauro Herrera：當然，我們處理查詢的代碼是用 C ++開發的，并且直接作為模塊嵌入在 nginx 中。 查詢到達后，它會由 nginx 直接處理，而無需與任何其他進程進行通信（唯一的例外是我們的客戶在自定義 API 密鑰中自定義了速率限制，在這種情況下，我們與存儲在 同一臺機器）。 您可以在[我們的體系結構帖子](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html)上獲得更多詳細信息，它們描述了我們所有的堆棧。 “除了性能提高之外，成本也要便宜得多。” 在人們將大量精力轉移到云計算以體現零 CAPEX 和低 OPEX 收益的時代，裸機基礎設施如何降低成本？ 你能解釋一下嗎？ 阿爾戈利亞很棒。 在 Stamplay，我們將他們的搜索 API 集成到了開發平臺中，因此我們的用戶只需單擊幾下便可以將超快速搜索添加到他們的應用程序中，這比他們自己集成 API 的速度要快。 它對我們用戶的應用程序的搜索性能產生了巨大的影響。 如果有人想了解 Stamplay 的 Algolia API 集成的工作原理，我們實際上創建了一個非常有用的教程，以演示如何快速設置和運行它：https://blog.stamplay.com/how-to-create-a- 帶有 AngularJS 條紋阿爾及利亞和 stamplay 教程的書俱樂部應用程序/