Algolia 通往高可用搜索 API 的狂暴之路（系列之二）

在本系列的上一篇文章中，Algolia 联合创始人兼首席技术官Julien Lemoine 介绍了他们构建高可用基础设施的前3 个步骤。近日，本系列的第二篇文章发表，主要介绍自2013 年9 月API 正式推出至2014 年12 月18 个月间的情况以及所有意料之外的问题，其中包括第一次停机。

步骤4：2014 年1 月——部署会危及高可用性

在这个阶段，他们主要关注如何实现敏捷开发而又不以牺牲稳定性为代价。为此，他们开发了一个测试套件，其中包含6000 多个单元测试和200 多个非回归测试。但还是不够，即使一项新特性通过了所有的测试，仍然可能在生产环境中引入Bug，比如，曾有个Bug 导致了 8 分钟的索引操作中断。多亏他们在设计架构时实现了搜索查询与索引操作的分离，前者才没有受到影响。不过，这个问题让他们确定了其高可用设置中的一些问题：

• 回滚要快，为此，他们实现了通过单行命令回滚；
• 部署脚本需要执行完整性检查，如果有错误，就自动回滚；
• 不能仅仅因为测试通过就部署到生产环境中的所有集群上，他们会按照顺序依次部署测试集群、社区集群（面向免费用户）、付费用户集群。

现在，当有新特性需要测试时，他们会选择一个集群组用于测试，并按照下面的步骤部署：

1. 向所选集群组中所有集群的第一台机器部署；
2. 监控 24 小时，然后向所选集群组中所有集群的第二台机器部署；
3. 监控 24 小时，然后向所选集群组中所有集群的第三台机器部署；
4. 几天后，向生产环境中的所有集群部署。

通过这种方法，他们可以在几个小时内检测到几乎不可能通过单元测试发现的 Bug。

步骤 5：2014 年 3 月——处理高负载的写操作

他们开始解决一个新问题：延迟。他们位于亚洲的集群延迟过高。为了测试市场反应，他们决定将机器部署在 AWS 上。他们并不愿意这样做，因为即使使用 AWS 提供的最好的 CPU，搜索查询的性能仍然比使用 E5-2687W CPU 低大约 15%。不过，为了缩短测试推出时间，他们这样做了。但是，他们尽量确保不引入对 AWS 的依赖，以便后续可以迁移到其它提供商。

同时，欧洲的客户开始抱怨搜索查询延迟增加。他们很快就发现，那与索引操作大幅飙升有关。这初看起来有些不可思议，因为他们在设计时实现了索引操作和搜索查询的分离，但调查之后他们发现，确保集群间一致性的一致性算法在处理写操作时存在瓶颈。当瓶颈出现时，它会阻塞 HTTP 服务器线程，导致搜索查询等待。为了修复这一问题，他们在一致性操作之前实现了一个队列，由它接收写操作，然后将它们批量发送给一致性操作算法。这样，写操作就不会冻结 HTTP 服务器线程了。此后，他们再也没有遇到集群冻结的情况。

步骤 6:2014 年 4 月——网络高可用几乎不可能在一个数据中心里实现

2014 年 4 月初，他们开始收到用户的抱怨。这些用户来自美国东部，但使用加拿大东部的集群，而美国西部的用户则没有受到影响。原来是一场车祸导致了加拿大和美国东部之间的网络路由路径发生了变化，而新路径的带宽不够，不可避免地出现了数据丢失。他们早先没有考虑这种情况，因此，当这种情况出现时，他们只能联系用户并说明情况。

他们认识到，需要基于多提供商、多数据中心和多网络提供商改进高可用性，实现一种真正的分布式基础设施。

步骤 7:2014 年 7 月——首次部署到两个数据中心

他们从最大的客户开始将机器部署到不同的数据中心（相距超过 100 公里）。这两个数据中心为同一个提供商所有。同时，根据先前的经验，他们将硬件进行了升级。虽然 E5-2687W 的 CPU 使用率就未到过 100%，但他们还是升级到了使用下一代 CPU 的 Xeon E5-1650v2。结果，他们的服务性能提高了将近 15%。

步骤 8:2014 年 8 月——在美国部署服务！

2014 年 8 月，他们在美国东部（弗吉尼亚州）和美国西部（加利福尼亚）通过一个新的提供商推出了服务。根据先前的经验，他们使用了同一提供商（不同的网络设备和电源装置）提供的不同的可用区域，并借助更低的延迟和更高的带宽改进了搜索体验。

步骤 9:2014 年 10 月——通过 Chef 实现自动化

随着机器数量不断增加，他们将管理工具改成了 Chef。与使用 Shell 脚本相比，这会节省大量的时间。在配置数以百计的机器时，Chef 非常有用，但也有缺点。他们曾经因为 cookbook 的输入错误而导致部分生产环境的服务器宕机。为了防止这类问题再次出现，他们决定将生产环境使用的 cookbook 分成两个版本：

• 第一个版本为稳定版本，部署到所有集群的第一台和第二台机器上；
• 第二个版本为生产版本，部署到所有集群的第三台机器上。

当修改 cookbook 时，他们首先会将修改应用到生产版本。经过几天的测试后，他们才会将修改应用到稳定版本。

步骤 10:2014 年 12 月——DNS 是架构中的一个 SPoF

随着时间推移，越来越多的用户抱怨他们的服务时断时续，尤其是在亚洲。通过调查他们发现，使用.io TLD 是问题的原因所在。事实证明，同其它顶级域名（.net、.com 和.org）相比，.io TLD 选播网络中的可选地址更少，导致 DNS 服务器过载。用户有时候会在 DNS 解析时遭遇超时。于是，他们将.io TLD 换成了.net TLD，并换了一个允许他们在 algolia.io 和 algolia.net 之间同步的 DNS 提供商，这使他们很容易保持向后兼容。迁移完成后，他们进行了广泛的测试，发现了几个对部分客户有影响的问题。DNS 比他们想象的复杂，他们的测试并不全面。

这个问题让他们认识到，唯一的DNS 提供商是一个SPoF（单点故障点），而他们的迁移行为实际上是非常危险的。因此，他们开始着手制定计划，消除架构中的SPoF。

至此，Julien 已经介绍了他们构建高可用基础设施的前10 个步骤（总共15 个）。接下来，他将重点讨论他们引以为豪的DNS 以及如何提升高可用性。

感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。