维基媒体的CDN

维基媒体基金会(Wikimedia Foundation)是维基百科(Wikipedia)和其他知名维基项目背后的非营利性组织，运营着大量的网站和服务，跻身世界前20名。我们每月为大约210亿份阅读请求提供服务，并对我们的文章进行5500万次编辑。在正常情况下，90%以上的读取请求由我们的缓存解决方案-我们自己的内容交付网络(CDN)-提供服务。与我们技术堆栈的其他部分一样，CDN基于开放源码软件，并且正在不断发展。在过去的几年中，我们在磁盘HTTP缓存和请求路由方面进行了各种更改。

这个由3部分组成的系列文章将描述一些更改，包括将Varish替换为Apache Traffic Server(ATS)作为CDN的磁盘HTTP缓存组件。ATS使我们大大简化了CDN架构，增加了正常运行时间，并加快了在弗吉尼亚州和德克萨斯州的两个主要数据中心之间切换的过程。

Wikimedia从2个主要数据中心(DC)和3个仅缓存的入网点(POP)提供内容。两个主要数据中心运行所有有状态服务，如数据库、作业队列、应用程序服务器等，以及负载平衡器和HTTP缓存。相反，POP只运行HTTP缓存和在它们之间路由流量所需的负载均衡器。两个主要的DC位于美国，特别是弗吉尼亚州(DC简称：eQiad)和德克萨斯州(DC简称：codfw)。EQIAD数据中心通常提供高速缓存未命中服务，而CoDfw是热备用的。阿姆斯特丹(ESAMS)、新加坡(Eqsin)和加利福尼亚州(Ulsfo)提供仅缓存POP。

我们的工作是公开进行的，仪表盘也不例外。例如，参见上面所示的维基媒体DC的流量模式。CDN每秒可处理高达15万个请求。

该图描绘了截至2018年的CDN架构。为了清楚起见，我们省略了新加坡流行音乐，但它基本上与加州流行音乐一样。

用户通过GeoDNS路由到地理上离他们最近的POP。他们的请求导致缓存查找，在缓存命中的情况下，HTTP响应从POP直接发送回用户，不需要进一步处理。相反，在缓存未命中的情况下，请求将进一步通过CDN发送到下一个缓存POP，如箭头所示。在缓存未命中的情况下，请求最终到达主主DC。

响应通过CDN返回(如果Cache-Control和类似的响应头允许，则存储在它遍历的缓存中)，并最终到达用户。为了保护我们用户的隐私，POP之间的HTTP请求需要加密发送。由于Varish缺乏传出HTTPS支持，我们选择使用IPSec来加密流量。绿色箭头表示通过CDN的标准请求流，白色路径表示待机状态的IPSec连接，以便在给定POP因操作原因需要关闭时使用。

更仔细地观察POP内部发生的情况，我们可以看到每个缓存节点运行三个不同的HTTP服务器：一个用于TLS终止的Nginx实例，一个用于RAM缓存的内存中的Varish实例，以及一个用于磁盘缓存的Varish实例。考虑到Varish也不支持传入的HTTPS，nginx对于服务HTTPS流量是必要的，但是对于本文而言，可以忽略nginx。

(1)负载均衡器通过对客户端IP进行一致哈希来挑选缓存节点。如果缓存命中内存中的Varish，HTTP响应将直接发送回用户。作为优化，响应将返回给用户，而无需通过负载均衡器。此技术称为直接路由，对于请求相对较小、响应相对较大的HTTP流量特别有用。高速缓存未命中由CDN进一步处理。

(2)内存中的Varish对请求URL应用一致的散列，以挑选POP(本地后端)内的另一个缓存节点，并将HTTP请求发送到如此选择的节点的盘上Varish实例。如果进一步未命中缓存，请求处理将在另一个POP(远程后端)中的磁盘上Varish级别继续进行。

(3)该请求被发送到在下一个POP中运行的另一个磁盘上的Varish。在上面的示例中，请求从esams(欧盟，荷兰)发送到eQiad(美国，弗吉尼亚州)。该请求通过IPSec隧道发送。如果在远程磁盘Varish上再次发生缓存未命中，则请求将被发送到下一个远程POP(如果有)，或者它将到达源服务器。

(4)源站对请求进行处理，在我们的示例中，HTTP响应通过位于弗吉尼亚的远程盘上Varish、位于阿姆斯特丹的本地盘上Varish、位于阿姆斯特丹的内存中Varish返回，最终到达用户。如果可缓存，则响应存储在它所遍历的各个缓存中，这样以后对此对象的任何请求都可以从缓存中得到服务。

到目前为止，所描述的体系结构在一段时间内为我们提供了很好的服务，尽管我们确实遇到了各种问题，并确定了需要改进的地方。

一般来说，远程盘上Varish实例的命中率一直很低(1%左右)。正如本文前面详述的那样，步骤(3)只是作为Varish中缺乏TLS支持的一种解决办法，可以使用支持HTTPS的缓存代理来避免。

此外，磁盘上的缓存实例还受到严重的可伸缩性和可靠性问题的影响。Varish支持其缓存内容的各种类型的存储后端。在版本3之前，持久存储后端是我们选择的后端，并且在我们的使用场景中工作得非常好：它工作可靠，并且允许我们将缓存对象存储在磁盘上。此外，缓存是持久的，从这个意义上说，我们可以在不丢失缓存的情况下重新启动Varish。

永久存储后端在Varish版本4中已弃用，在专有版本的Varish中被具有类似功能的称为海量存储引擎的存储后端所取代。因此，自由/开源软件用户可以选择使用文件存储后端，这有两个主要缺点：(1)不支持持久性(2)可伸缩性问题。

值得一提的是，第二个问题发生在生产使用几天之后：大量的请求将导致503个错误，只有重新启动Varish才能恢复正常操作。作为创可贴，我们每周介绍一次cron-job重新启动Varish。不幸的是，事实证明这种重新启动的频率还不够，我们不得不每周重新启动Varish两次，以减少面向用户的停机频率。该问题被证明是文件存储引擎的已知体系结构限制。经过几次调试后，我们得出结论，是时候开始寻找替代方案了。

作为Varish的可行替代品，我们确定了Apache Traffic Server：Apache Software Foundation项目，由许多大型组织使用和开发，包括Apple、Verizon、LinkedIn和Comcast。迁移到ATS将解决我们使用Varish的两个主要痛点：它可靠地支持磁盘上的持久存储，以及传入和传出HTTPS。

在下一篇文章中，我们将描述通过将CDN的磁盘组件迁移到Apache Traffic Server而实现的架构更改。

特色图片来源：北美低轨道卫星索米NPP，NASA/NOAA/GSFC/索米NPP/VIIRS/诺曼·库林，公共领域。

跳回到主导航