我们将数百个客户网站置于 CDN 后面，效果非常好

在 我工作的代理机构，我们最近将所有约 1100 个网站置于 CDN 后面。似乎正在奏效。不幸的是，我不知道我们为什么要这样做或如何做到这一点。因此，在这篇文章的第一部分，我强迫我们的 CTO Joshua Lynch 向我解释这个过程。这无意中导致 Josh 建议我在自己的网站上尝试一下，我将在文章的后半部分讲述这个过程。

我了解到三件令人惊讶的事情

1. 就我们而言，使用 CDN 最大的好处实际上不是性能或安全，而是“DNS 抽象层”，我将在下面解释这个概念。
2. 迁移到 CDN 对我们来说是一个艰难的过程，但这仅仅是因为我们拥有很高的域名与员工比例。对于单个网站来说，这将是小菜一碟。
3. 不用担心媒体文件 404；不需要更改网址。换句话说，我们不必担心丢失帖子内容中的图像等问题。

感到惊讶吗？我也是。不多说，Josh 将解释所有内容。

面试

从“起点 A 到终点 B”是什么？换句话说，我们以前在做什么，现在在做什么？

起点 A 是使用一家科技公司的私有托管，没有 CDN。终点 B 是使用 WP Engine 托管，位于 CloudFlare 的 CDN 后面。

起点 A 的问题出在我们的托管上，还是缺少 CDN 上？

两者都有，算是吧。我们停机的主要原因是恶意流量，我们的托管环境无法处理。此外，我们的服务器响应时间始终徘徊在两秒左右。响应时间应该低于半秒，两秒应该接近完整的页面加载时间！

这与其他业务因素相结合，迫使我们更换主机，但是缺少 CDN 使此过程比现在更困难，现在我们使用的是 CDN。如果我们将来需要再次迁移，将会容易得多。

等等，为什么？CDN 与迁移主机有什么关系？

迁移到新服务器需要更改 DNS。由于我们的域名与员工比例很高，这会导致大量手动工作。当我们的客户管理他们自己的 DNS 设置时，情况会更加困难。

通过将所有网站置于 CDN 的名称服务器上，我们在域名和托管之间获得了一个抽象层——一个非常好的抽象层。与我们大多数域名注册的 GoDaddy 不同，CloudFlare 具有用于管理 DNS 的 API，以及易于使用的界面，可以用于浏览器自动化。如果我们将来需要再次更换主机，可以通过 CloudFlare 很容易地更改 DNS 设置。它将完全自动化，并且对我们的客户完全透明，即使是那些管理自己域名的客户。

我一直认为使用 CDN 的目的是更快地提供文件。

对于一些媒体含量更高的网站来说，这是真的，但对我们来说不是。我们的大部分内容在媒体文件方面都很轻量级。对我们来说，使用 CDN 的真正价值在于 DNS 抽象层。

这并不是说我们没有性能提升。我们对 DDOS 攻击的抵抗力更强，因为到达我们主机的大部分请求都少了很多！这是 CloudFlare 的缓存和基于声誉的 DDoS 防护相结合的结果。

为什么选择 CloudFlare 而不是其他 CDN？

有很多 CDN，但很少有产品能与 CloudFlare 直接竞争，而且据我所知，没有一个产品像 CloudFlare 那样经济实惠。由于我们不仅需要 CDN，还需要上述好处，因此 CloudFlare 是显而易见的选择。

就个人而言，我自己的 WordPress 多站点网站多年来一直使用 CloudFlare，因此我有经验，对在工作中使用它们充满信心。它们在与我们合作的科技公司中也享有良好的声誉。

那么，它有效吗？有什么数据可以证明吗？

今年早些时候，CloudFlare 重新设计了他们的应用程序，我们失去了查看域名的组合分析的能力，但您可以在 CloudFlare 帐户中查看单个网站的分析，网址为 `https://www.cloudflare.com/a/analytics/example.com`。结果在我们最繁忙的网站上最为明显。

我们最繁忙的域名之一的统计数据，表明只有一小部分请求到达我们的主机。大多数请求通过 CloudFlare 的缓存提供服务。

我们到底是如何做到这一点的？我们必须进入 GoDaddy 帐户，将所有域名的 DNS 设置更改为指向 CloudFlare，没有 API 访问权限，并且可能拥有 300:1 的域名与员工比例？这听起来很糟糕。我怎么会错过这个？

你说得对，这是一个相当大的项目，我们从 2014 年 10 月开始，为迁移托管做准备。幸运的是，通过一些浏览器自动化和手动操作，将我们控制的域名的所有名称服务器更改为 CloudFlare 是最容易的部分。

我们在浏览器自动化中做了什么，又在手动操作中做了什么？

Fake 是一款易于使用的浏览器自动化工具，它将域名添加到 CloudFlare，并收集名称服务器分配（如果我没记错的话，您无法通过编程方式将新域名添加到 CloudFlare）。对于我们位于 GoDaddy 的域名，我们的劳动力队伍将名称服务器更改为 CloudFlare 分配的服务器，这些服务器是在 Fake 添加和记录域名时分配的。

你说那只是最容易的部分？

是的！在客户控制名称服务器的情况下，这通常是协调任何 DNS 记录更改的挑战，但好处是我们可以管理未来的 DNS 记录更改。

具体来说，这方面的挑战是什么？

人们很难理解域名系统和记录。域名注册商通过难以使用的用户界面和使用不同的（但准确的）术语来描述同一事物，使问题更加复杂。如果您像我们的客户一样忙碌，并且不了解某些东西，那么您将难以优先考虑和完成它。

一个很大的挑战是，在您将域名添加到 CloudFlare 后，您有 14 天的时间更改名称服务器，否则您必须重新将域名添加到 CloudFlare 帐户（并且您可能无法获得相同的名称服务器分配）。这让我想到下一个挑战：CloudFlare 试图为同一帐户内的域名分配相同的名称服务器，但这不能保证。因此，我们必须精心设计电子邮件活动，列出客户需要更新的正确域名以及他们应该切换到的匹配名称服务器，并强调在 14 天期限内更改的重要性！我相信这需要三轮名称服务器分配，每一轮都有两到三封电子邮件活动提醒客户更改，才能让大部分客户完成更改。

您向谁发送电子邮件，又是如何发送的？我们是否有每个客户的技术/营销代表的列表？还是说这是一个 CRM 问题？

我们从 CRM 和 Whois 查询中导出了联系人！

天哪。这花了多长时间？

我的记忆已经很模糊了，当时我们没有进行时间跟踪，所以我只能估计工时是数十小时，甚至可能超过 100 小时。除了我们通过 GoDaddy 管理的所有域名外，我们还成功地将几乎所有客户控制的域名都切换了过来。

所以，一旦我们将所有域名指向 CloudFlare，接下来发生了什么？CloudFlare 仍然指向我们的旧主机，对吗？

没错，因此我们将 CloudFlare 中的所有域名指向 WP Engine。当需要时，我们可以使用 CloudFlare 的 API 在几分钟内以编程方式更改 A 记录 IP 地址。

等等，什么？我们向 CloudFlare 发出了一个大型 API 调用来更改 A 记录 IP 地址？什么时候？怎么？谁编写了 API 客户端？还是说这是 Fake 引擎以某种方式处理的任务？

我们使用我在当年圣诞节假期制作的一些基本桌面脚本向 API 发出了数千个请求。这使我们能够在几分钟内完成数千个记录删除、编辑和添加操作，而不是花费数小时进行手动更改或 Fake 自动化。

我仍然感到惊讶，对我们来说，CDN 更像是 DNS 抽象而不是性能。这有道理，但根据同样的逻辑，我们现在是否与 CloudFlare 紧密耦合？如果需要，迁移到其他平台将是另一项巨大的工作。

这是真的，但 CDN 的存在似乎不太可能成为问题，与托管可能出现的问题相比，CDN 的存在要少得多。此外，CloudFlare 是一个非常稳定的合作伙伴。到明年这个时候，他们可能会进行 IPO。

每当听到有关 CDN 迁移的信息时，我总是听到有关媒体文件网址需要更改或帖子内容中的图像出现 404 错误的麻烦。我们没有遇到这个问题，而且我注意到我们的图像没有指向 CloudFlare。这是怎么回事？

使用 CloudFlare，您不必像使用传统 CDN 那样从其他域名提供媒体文件，因为您将域名的名称服务器更改为 CloudFlare 的名称服务器。然后，CloudFlare 使用 Anycast 将您的域名指向其最近的数据中心，以提供他们已自动缓存的文件。用他们自己的话说

CloudFlare 在全球拥有 76 个数据中心。我们的 CDN 会自动缓存您的静态文件到边缘节点，这样这些文件就存储在更靠近访问者的地方，同时将您的动态内容直接从您的 Web 服务器提供。然后，CloudFlare 使用一种名为 Anycast 的技术将您的访问者路由到最近的数据中心。这样，您的网站平均加载速度会提高一倍，无论访问者身在何处。 https://www.cloudflare.com/features-cdn/

仅仅因为我们难以置信的低员工与客户/域名比例，与大多数代理商相比，这次迁移有多困难？可以说，如果我们只管理一个高流量网站，这将非常容易吗？

没错，大部分复杂性都是由于管理数百个域名和帮助数百个客户更新其注册域名的名称服务器的物流问题造成的。使用单个域名切换到 CloudFlare 非常容易，但您需要小心设置，以防止出现问题。

我将尝试用我自己的话说一下这个过程。

1. 我们有很多网站。对于其中一些网站，我们通过 GoDaddy 控制它们的 DNS 设置。对于其他网站，客户通过其选择的域名注册商保留控制权。
2. 我们使用 Fake、人工操作和 API 调用来管理域名指向和设置。对于我们无法控制的域名，我们必须通过多轮电子邮件与客户进行沟通，这些电子邮件发送到通过 CRM 和 Whois 收集的列表中。
3. 不用担心媒体文件 URL 或任何其他内容，因为使用 CloudFlare 的简单事实是，您更改您的域名服务器以指向它们。
4. 对于单个网站来说，这将是微不足道的。这次迁移的任何明显的困难都来自于我们较高的域名与员工比例。

准确吗？有什么要补充或删除的吗？

没错！您也应该将您的域名切换到 CloudFlare 以查看该过程。

让我看看我是否可以自己解决这个问题。

接受挑战。我通常理解 Josh 解释的过程，我将尝试在我的 WordPress 多站点上进行操作，该站点有两个域名，scottfennell.org 和 scottfennell.com。

我在 CloudFlare 上开设了一个帐户，还登录了我的 BlueHost 帐户，它是我的域名注册商。嗯，这很简单。CloudFlare 提示我输入我的域名，然后播放了一个视频，或多或少地解释了 Josh 在上面解释的内容。

他们在这段大约一分钟长的视频中声称，视频的时长比迁移过程更长。他们是对的。我所要做的就是记下 CloudFlare 为我分配的域名服务器，并在 BlueHost 中更新它们。我完成了。我现在在 CloudFlare 上（或者，一旦更改传播，我就会在 CloudFlare 上）。

我认为更有趣的话题是，所以呢？我的网站速度更快了吗？与我们工作中的大多数网站不同，我的网站有很多大型图像。它基本上是一个高分辨率的照片库。在使用 CloudFlare 之前，此页面未缓存大约需要 3.1 秒才能加载：http://scottfennell.com/turkey/suphan-dagi/。在 CloudFlare 处于活动状态后，大约需要 2.2 秒。包含更多媒体的页面加速得更快，在启用页面缓存的地方，我可以在大约 300 毫秒内完成 DOM 加载。如果您想自己检查网络面板

• 启用了页面缓存：http://scottfennell.com/turkey/
• 未启用页面缓存：http://scottfennell.com/japan/

查看这些分析，在 CloudFlare 后仅几天

一个有趣的副作用：我网站上的一些图片库以随机顺序显示图片。在 CloudFlare 的页面缓存背后，我在每次页面加载时都获得相同的顺序，因为它第一次加载给定 URL 时会缓存输出。同样，在工作中，如果我们的客户期望看到我们更新的工作，但反而被困在 CloudFlare 缓存的版本中，这将造成很多混乱。

我实际上对这个问题感到高兴，因为它为我提供了一些工作保障：我不得不写一个插件！

一个用于清空 CloudFlare 缓存的 WordPress 插件。

这是它看起来的样子

您将获得两个按钮。一个用于清空缓存，另一个用于进入开发模式，在开发模式下，缓存会暂时暂停最多三个小时。如果您有兴趣在不止几个网站上以企业级使用 CloudFlare，我强烈建议您查看他们的 API 并为您的平台构建类似的工具。 Sunny 看起来是 dot org 的一个非常强大的选项，尽管我还没有亲自使用过它。

如果您自己动手，请注意 CloudFlare 在将 API 文档集成到其 Web UI 中所做的出色工作。看看这个，它就坐在那里，等着你打电话

备选方案和后续步骤

我从对我们迁移到 CloudFlare 感到模糊的了解和高兴，到对 CloudFlare 感到非常兴奋。我道歉：我真的无意将这变成一个对 CloudFlare 的狂热吹捧，所以请允许我指出，可能有一些替代方案，特别是来自 Sucuri 的一个替代方案。

除了 CDN 的商业案例外，还有技能发展的机会。如果您像我一样，您在文本编辑器中花了很多时间，很容易与实际在生产中提供代码的过程脱节。花一些时间学习我的 DNS 词汇是一个令人耳目一新的节奏变化。如果这听起来像您，并且您的网站不在 CDN 后面，请暂时从代码中休息一下，并审核 CloudFlare。

---

Scott Fennell 是一位来自阿拉斯加安克雷奇的 WordPress 主题和插件开发人员。