# 阿尔及利亚通往全球 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 教程的书俱乐部应用程序/