Discourse 全站 CDN 加速

本文翻译自官方论坛,于 2014-10-30。

FastlyCloudFlare 和其他一些 CDN 提供了加速动态内容的模式。

简而言之您在 CDN 那提供您的域名指向的 IP,然后 CDN 就能智能地决定如何处理请求。

  • 静态内容能直接从缓存中分发
  • 动态内容能被发送至站点。

这比在 CDN 指南中概述的只分发静态资料更有优势。

  • 您可以“保护”您的站点不受大流量影响。
  • 动态内容可以使用像 railgun 这样的技术加速。(注意:通常我们的负荷在 1 RTT 内,所以影响很小)
  • SSL 协商可能在环路中非常影响速度。

如果您启用了 CDN 全站加速,您需要遵守 2 条规则

  1. “消息总线(message bus)”必须从源点分发。
  2. 特别注意对站点优化的技术,像 Rocket Loader 这样的东西可以搞坏 Discourse。Discourse 已经是高度优化的了,这样做没有必要。

对服务器来说,对不同域名的“长轮询”请求,在站点设置中设置 长轮询 基本地址至源服务器。

例如,如果您的 CDN 从“http://some-origin.com”获取资源,确保站点设置中填写的是 http://some-origin.com/ 。如果您不这么做,站点就无法正常运行。

如果您在 Discourse 前部署了 Varnish,您可能想要使用同样的技巧,并且让 Varnish 跳过消息总线请求。

无聊的技术要点:

为了让消息总线在不同的域名工作是很有挑战性的。我们的消息总线能知道哪一个用户在轮询,而另一个域名可能没有 cookie 而无法知晓情况。这儿有两个问题。首先,不来一次的 CORS 之舞甚至就没有办法发起标准 AJAX 请求。

其次,我们需要一个机制告诉另一个域名用户是谁,这样我们才能取得正确的信息。

当长轮询的基本地址改变后,Discourse 将分发一个额外的 meta 标签共享一个“跨域名”验证 token。这个 token 将通过自定义头提交回消息总线。这个 token 在 7 天内有效或是在登出后失效。将来我们可能会扩展它使得这个 token 可以被不同的功能使用并自动地再传递后重新指定。

您可以在这看到大部分的实现: https://github.com/discourse/discourse/commit/aa9b3bb35accce498438e22344a3c352a9bc6592