转载

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

在本系列的第一和第二篇文章中，Algolia联合创始人兼首席技术官Julien Lemoine分别介绍了他们构建高可用基础设施的前3个步骤和自2013年9月API正式推出至2014年12月18个月间的情况以及所有意料之外的问题（其中包括第一次停机）。近日，本系列的第三篇文章发表，主要介绍他们如何从一个“初创企业”的架构转变成一个可以满足大型上市公司需求的架构。

步骤11:2015年2月——全球同步的基础设施

这个月，他们实现了自2014年4月开始就一直为之努力的目标，“将服务扩展到全球，更好地服务于用户”。他们的网络包含12个不同的地点：美国东部（弗吉尼亚）、美国西部（加利福尼亚）、澳大利亚、巴西、加拿大、法国、德国、香港、印度、日本、俄罗斯和新加坡。最重要的是，他们推出了“分布式搜索”特性。借助这个特性，用户只需几次点击就可以在他们的网络中选定需要自动复制数据的地点。用户使用的API保持不变，而查询请求会自动路由到最近的地点。这不仅降低了延迟，还提高了搜索基础设施的可用性。

据Julien介绍，他们的“分布式搜索网络（Distributed Search Network，DSN）”与CDN（内容分发网络）完全不同。他们不是在每个边缘地点缓存常用查询，而是存储一个包含所有数据的完整副本。边缘地点本身都可以响应任何查询。就是说，如果用户选择了三个接入点（美国东部、德国、新加坡），那么位于德国的接入点会响应欧洲用户的查询，位于新加坡的接入点会响应亚洲用户的查询，而位于美国东部的接入点则会响应美国用户的查询。

为了支持这种变化，他们修改了API客户端的重试逻辑。客户端会首先指向主机名 APPID-dsn.algolia.net ，后者会使用DNS将客户端请求路由到最近的地点。如果最近的主机不可用，那么为了能够返回下一个最近的地点，DNS记录会在1分钟内删除那台主机。这就是他们将每条记录的TTL设为1分钟的原因。如果遇到这种故障，那么他们的官方API客户端会通过在 APPID-1.algolia.net 、 APPID-2.algolia.net 和 APPID-3.algolia.net 上重试将流量重定向到“主区域（main region）”。他们认为，这种方法可以实现高性能与高可用性的最佳平衡。

步骤12:2015年3月——提高单个地点的高可用性

对于搜索和国际用户而言，分布式搜索网络极大的提高了可用性。而为了提高主区域的可用性，他们将美国的集群分布在两个完全独立的提供商那里：

两个位置相近的、不同的数据中心；
三台不同的机器——同以前一样，两台位于一个数据中心的不同的可用区域中，一台位于另一个数据中心；
两个不同的自治系统。

这样，他们可以选择将流量路由到另一个提供商。他们在提高单个地点的可用性方面迈进了很大一步。

步骤13：2015年4月——随机出现的文件损坏问题

这个月，他们开始注意到生产环境中随机出现的文件损坏问题，这是由部分SSD的TRIM实现中存在Bug导致的（具体原因参见这里）。这是个棘手的问题，他们花了一个月的时间来跟踪和定位。所幸，他们没有丢失任何客户数据，这主要得益于以下两个方面：

他们存储了数据的三个副本；
更重要的是，他们没有复制索引操作的结果，而是在每台机器上重复了用户的操作。这有效避免了问题向其它机器传播。

他们没有预见到这种问题，但使用独立的机器是他们能够将问题影响最小化的原因。因此，Julien强烈建议，任何需要高可用性的系统都要采用这种独立性。

步骤14：2015年5月——引入多个DNS提供商

他们选择 NSONE 作为一个DNS提供商，因为该提供商提供了很棒的DNS API，允许他们通过API针对每个用户配置查询的路由方式，并且支持 edns-client-subnets ，可以提供更准确的地理位置路由。

这里的挑战在于，他们需要引入第二家DNS提供商，而又不损失NSONE提供的强大功能。他们决定通过修改API客户端重试策略的方式引入。所有的API客户端都会首先连接 APPID-dsn.algolia.net ，如果有问题，它们会在另一个提供商提供的顶级域名上重试。他们选择将AWS Route 53作为第二家提供商。如果有任何问题，API客户端将从 APPID-1.algolianet.com 、 APPID-2.algolianet.com 和 APPID-3.algolianet.com 中随机选择一个重试。这样，他们就在algolia.net域上保留了NSONE所有的地理位置路由特性，同时引入了第二个提供商在algolianet.com域上提供了更高的可用性。

步骤15:2015年7月——每个集群跨三个完全独立的提供商

虽然经过了一系列的扩展，但他们的基础设施并不能完全应对所有问题，这主要是因为Link/Router丢失数据包和路由泄露。在上个步骤中，他们改进了在美国的部署，构建了跨多个数据中心、多个自治系统和多个上游提供商的集群。不过，索引操作需要三台机器中的两台运行正常方可进行。当使用两个提供商时，如果其中一个宕掉，他们就会无法提供索引服务，但搜索服务仍然可用。正是因为这个原因，他们决定实现跨三个完全独立的提供商的集群。这让他们的基础设施超级冗余，但却同时提供了高可用的搜索和索引服务。

总之，构建高可用的架构是需要时间的。所以，作为初创企业，不用在开始的时候就担心基础设施不够完美。但是，应该尽早考虑如何扩展基础设施，Julien甚至建议在Beta测试之前就开始。

感谢徐川对本文的审校。

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