# 阿爾及利亞通往全球 API 步驟的憤怒之路第 2 部分 > 原文： [http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.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 的早期。 這篇博客文章將重點介紹從 2013 年 9 月到 2014 年 12 月我們服務的前 18 個月，甚至包括我們的首次停機！ ## 步驟 4：2014 年 1 月 ### 部署是高可用性的大風險 目前，我們的主要關注之一是確保我們的發展敏捷，同時又不以犧牲穩定性為代價。 因此，我們開發了一個包含 6,000 多個單元測試和 200 多個非回歸測試的測試套件，以確保代碼更改不會引入新的錯誤。 不幸的是，這還不夠。 通過我們所有測試的一項新功能引入了一個生產錯誤，該錯誤導致 [八分鐘的索引停機時間](https://blog.algolia.com/postmortem-todays-8min-indexing-downtime/) 。 值得慶幸的是，由于我們的體系結構旨在將搜索查詢與索引分開，因此不會影響搜索查詢。 此問題幫助我們確定了高可用性設置中的幾個問題： * 回滾需要很快，因此我們開發了使用單個命令行執行回滾的功能。 * 部署腳本需要執行完整性檢查，并在出現錯誤時自動回滾，因此我們將其添加到了部署過程中。 * 我們不應該僅僅因為測試通過 而部署到所有生產集群。 在此問題之后，我們對集群進行了一系列部署。 我們從測試集群開始，然后是社區集群（免費客戶），最后是付費用戶集群。 今天，當要測試一項新功能時，我們的部署有所不同。 我們選擇一組集群進行測試，然后使用以下步驟進行部署： 1. 部署到所選集合的所有群集中的第一臺計算機。 2. 監視 24 小時，然后部署到所選集中所有群集中的第二臺計算機。 3. 監視 24 小時，然后部署到所選集中所有群集中的第三臺計算機。 4. 幾天后，我們部署到了所有生產集群。 使用這種方法，我們能夠在幾個小時內檢測到幾乎不可能通過單元測試發現的錯誤。 由于我們每月有數十億的查詢，因此這種檢測是可能的。 # 第 5 步：2014 年 3 月 ### 管理大量寫操作 當我們在加拿大/東部和歐洲/西部的集群很好地處理了我們的增長時，我們開始解決一個新問題：延遲。 來自亞洲的集群的延遲太高，無法獲得令人滿意的性能。 我們決定首先通過在 AWS 中部署計算機來測試市場。 我們不愿意做出選擇，因為即使使用 AWS 提供的最佳 CPU（當時的 E5-2680），搜索查詢的性能也比 E5-2687W CPU 低 15％！ 我們這樣做是為了減少啟動實驗的時間，但要確保不引入對 AWS 的任何依賴關系。 如果測試成功，這使我們可以輕松地遷移到其他提供商。 在紙上，一切看起來都不錯。 當我們發現他們的虛擬化不支持 AVX 指令時，我們遇到了一個問題，這對我們來說是重要的功能。 我們必須生成沒有 AVX 指令集的二進制文件（這再次降低了搜索查詢的性能）。 在享受我們最近在新加坡推出的服務時，我們開始收到一些來自歐洲客戶的投訴，他們抱怨他們的搜索查詢延遲時間增加。 我們很快發現它與大量的索引操作相關聯，這很奇怪，因為我們確信索引和搜索 CPU 使用率之間的體系結構劃分正常工作。 經過調查，我們發現用于處理寫操作的整個集群的分布式一致性的共識算法存在潛在的瓶頸。 當出現瓶頸時，它將阻塞 HTTP 服務器線程。 然后，這將導致搜索查詢需要等待線程。 我們是無意中設計造成的！ 我們通過在達成共識之前實施隊列來解決此問題。 它使我們能夠收到大量的寫操作，進行批處理，然后將其發送給共識。 共識不再存在于 HTTP 服務器的序列中，因此寫操作無法再凍結 HTTP 服務器線程。 在正常操作期間，除了將作業傳遞給共識以外，隊列什么都不做。 在出現峰值的情況下，它允許我們在達成共識之前進行緩沖和批量處理。 進行此更改后，我們沒有凍結任何群集。 ## 步驟 6：2014 年 4 月 ### 一個數據中心幾乎無法實現網絡高可用性 從 2014 年 4 月開始，我們開始收到使用在加拿大/東部使用集群的美國東部客戶的投訴。 我們在美國西部的用戶沒有受到影響。 我們立即懷疑加拿大和美國東部之間存在網絡問題，并發現我們的提供商正在報告同一問題。 一場車禍使蒙特利爾和紐約之間的一根含 120 根纖維的管道破裂。 所有的交通都在經過芝加哥的不同路徑上進行。 不幸的是，帶寬不足以防止數據包丟失。 中斷不僅影響了我們的提供商，而且影響了加拿大和美國東部之間的所有流量。 這類事故可能會破壞我們經常忘記的互聯網，但仍然可能發生。 那天我們除了幫助每個客戶并通知他們當前的情況外，無能為力。 就在這一天，我們開始了一場大型基礎設施討論。 我們需要依靠更多的提供商，數據中心和網絡提供商來提高高可用性。 更重要的是，我們需要在美國擁有基礎設施。 通過從加拿大為美國服務，我們可以削減成本，但高可用性受到了影響。 我們需要真正分布我們的基礎架構。 我們不能再在一個提供商上擁有多個可用區！ ## 步驟 7：2014 年 7 月 ### 首次在兩個數據中心中部署 我們發現在單個數據中心中進行部署是不夠的。 我們決定從最大的客戶之一開始，在兩個不同的數據中心（它們之間相距 100 公里以上）部署一臺機器。 這兩個數據中心使用的是同一提供程序（相同的自治系統），并且已經提供了高可用性級別，比云提供程序的多個可用性區域略高一點。 這是由于兩個數據中心位置在網絡鏈接和電源單元方面完全不同。 根據我們過去的經驗，我們花了這段時間來設計具有下一代 CPU 和 SSD 的硬件的下一版本： * Xeon E5-1650v2（6 核，12 線程，3.5Ghz-3.9Ghz） * 128G RAM * 英特爾 SSD S3500（2x480G）或 S3700（2x400G）。 我們將 intel S3700 用于每天寫入量較高的計算機，因為它們更耐用 我們所做的更改主要圍繞 CPU。 我們從未在 E5-2687W 上使用 100％的 CPU。 E5-1650v2 是下一代 CPU，并提供了更高的時鐘速度。 結果是，與以前的 CPU 相比，我們的服務速度提高了近 15％。 毫秒很重要！ ## 步驟 8：2014 年 9 月 ### 在美國的存在！ 在與數家提供商進行了數月的討論之后，我們于 2014 年 9 月在美國東部（弗吉尼亞州）和美國西部（加利福尼亞州）與一家新提供商一起啟動了該服務。 由于更好的延遲和帶寬，第一步是改善我們在美國搜索體驗的好方法。 高可用性方面的改進并不大，但是確實有助于我們更靈活地應對加拿大和美國東部之間過去的問題。 我們使用的方法與以前的位置相同：一家提供商內的可用區域不同（不同的網絡設備和電源單元）。 ## 步驟 9：2014 年 10 月 ### 通過廚師進行自動化 隨著我們需要管理的計算機數量的大量增加，我們將管理遷移到了 Chef。 以前，我們使用 Shell 腳本管理計算機，但是與 Chef 進行自動化相比，修復 Heartbleed（OpenSSL 漏洞）等安全問題非常耗時。 Chef 所提供的自動化功能在配置數百臺機器時非常有用，但它也有缺點。 遷移到 Chef 幾個月后，菜譜中的錯字導致某些生產服務器崩潰。 幸運的是，我們能夠盡早發現問題。 由于推出了廚師客戶的 CRON 工作具有非侵略性，因此對生產沒有太大影響。 我們有足夠的時間來做出反應并解決問題。 我們非常幸運遇到此問題，因為該錯誤可能會破壞生產。 為了避免再次發生此類問題，我們決定將生產手冊分為兩個版本： * 第一個版本（穩定版）已部署到所有集群的第一臺和第二臺計算機上 * 第二個版本（生產版本）已部署在所有集群的第 3 臺計算機上 對我們的菜譜進行任何修改時，我們首先將修改應用于生產版本。 經過幾天的測試，我們將修改應用于穩定的食譜版本。 高可用性需要在所有級別上應用！ ## 第 10 步：2014 年 11 月 ### DNS 是體系結構中的 SPoF 隨著時間的流逝，我們開始收到越來越多的用戶反饋，指出我們的服務間歇性地變慢，尤其是在亞洲。 經過調查，我們發現.io TLD 的使用是造成此問題的原因。 事實證明，.io TLD 的任意播網絡的位置少于主要 TLD（.net，.com 和.org）的位置，并且 DNS 服務器超載。 用戶有時在 DNS 解析期間會遇到超時。 我們與 CDN 提供程序討論了此問題，他們都告訴我們最佳實踐是使用.net TLD。 我們需要從.io 遷移到.net！ 在準備發布分布式搜索網絡時，我們決定遷移到另一個 DNS 提供商。 該新提供商提供了鏈接域功能，這意味著它們將處理 [algolia.io](http://algolia.io) 和 [algolia 之間的同步。 net](http://algolia.net) ，這樣我們就可以輕松地保持向后兼容性。 我們從不同的位置對該遷移進行了廣泛的測試，并感到一切正常。 不幸的是，在完成遷移之后，我們發現了一些影響我們某些用戶的問題。 您可以在 [此博客文章](https://blog.algolia.com/black-thursday-dns-issue/) 中閱讀詳細的報告。 DNS 比我們意識到的要復雜得多。 DNS 提供程序有許多不同的行為，我們的測試并未涵蓋所有這些行為（例如，首先使用 IPv6 解析，在 TTL 上使用不同行為等） 這個問題也改變了我們識別 SPoF 的想法。 只有一個 DNS 提供程序是 SPoF，由于沒有回退，因此遷移非常關鍵。 我們開始制定一項計劃，以刪除架構中的任何 SPoF。 ## 下一個 至此，我們已經涵蓋了本系列 15 個步驟中的 10 個。 正如您所看到的，我們推出后的頭 18 個月并非一帆風順。 我們經歷了幾次故障，不得不重新考慮基礎架構的幾個部分。 這些改進的目的是始終確保我們的基礎架構將來幾乎不可能面臨類似的問題。 本博客系列的下一部分和最后一部分將重點介紹 DSN（分布式搜索網絡），它是我們最引以為傲的功能，并提高了我們的高可用性。 兩者都有一個目標：在可靠性和性能方面滿足大型上市公司的期望。 *以下是該系列的所有三個部分：[第 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)*