用了 IPFS 后,我的博客流量在一周内涨了 50 倍!

阅读数:2084 2019 年 9 月 16 日 20:23

用了IPFS后,我的博客流量在一周内涨了50倍!

有趣的事实:如果您正在阅读本文,那么您使用的正是我们的分布式 Web。 自 2019 年 2 月中旬开始,With Blue Ink 博客已开始通过 IPFS 与 Cloudflare 分布式 Web 网关提供服务。

去年 11 月,我曾在博文中提到如何利用 IPFS 运行静态网站。我已经为自己和家人架设起几款应用,体验相当不错。接下来,当然就是把整个博客迁移过去啦。不过整个迁移过程还是遇到了几个问题,下面我会详尽介绍其中部分重要问题。总之,过程要比我预期的长一些,直到大概一个月之前,我才切换了 DNS 交换机并正式关闭托管这套博客的单实例虚拟机。

其实刚刚迁移的时候,我对这一切也不是特别有信心。好在接下来的一个月中,实际运行情况还是相当理想的。

Hacker News + Reddit 效应

自从迁移到 IPFS 之后,我先后经历了不少状况。

大概在一周之前,我发布了一篇关于 Unicode 字符串标准化重要意义的博文。这篇文章获得了读者朋友的热烈欢迎,并很快在 Hacker News 首页的排名中上升到第四位,甚至在 r/ 编程频道登上榜首,也被不少热门时讯列为推荐文章。(这里要感谢大家的热爱与支持!)

随后,我在周一发布了一个新的开源项目——Hereditas。该项目也在 Reddit 上得到了很多技术人员的喜爱。

通过下图可以看到,之前几个月我的博客月均浏览量不足 3000 次:
用了IPFS后,我的博客流量在一周内涨了50倍!

博客月均浏览数据
但突然之间,也就是 3 月 13 号星期三,流量迅速提升至一周之前的 5060%。一天之内,With Blue Ink 的单日浏览量就几乎达到了以往月平均浏览量的两倍。

虽然流量显著增加,但通过下图可以看到,为网站提供服务的主 IPFS 节点在 CPU 使用情况方面并没出现多大波动:
用了IPFS后,我的博客流量在一周内涨了50倍!

主 IPFS 节点在 CPU 使用情况
没什么波动。

由于通过 IPFS 分发内容并经由 Cloudlfare CDN 提供服务,With Blue Ink 在面对 5000% 的流量峰值时几乎没有发生任何性能与可用性层面的影响。

不仅如此:测试表明,全世界的用户在访问本网站时,一直拥有着非常理想的速度体验。

遇见 Hugo

With Blue Ink 是一个静态网站。我通过大量 Markdown 文件的方式编写内容,并利用 Hugo 生成对应的 HTML 页面。整个网站(内容、主题、脚本等)都是开源的,且发布在 GitHub 的 ItalyPaleAle/WithBlueInk 当中。

三年前我刚开设自己的博客时,我选择的是另一款流行的静态网站生成工具——Jekyll。但在尝试迁移至 IPFS 时,我发现必须得用 Hugo 代替 Jekyll,因为 Jekyll 不支持相对 URL。使用 Jekyll 时,所生成的全部 URL 都是固定的,或者至少是以固定 URL 开头;这在 IPFS 浏览机制中行不通,因为这里的基础 URL 以动态形式存在。

迁移至 Hugo 还带来了其它一些助益。首先,Hugo 是一款由 Go 语言写成的小应用,或者说 Ruby gem,其速度要明显快于 Jekyll。除了在网站构建速度方面大幅提升之外(几乎能够即时完成),Hugo 所提供的单一自包含二进制文件也能够在 CI 环境当中带来更快的安装速度。我的 CI 构建流程从原本的五分钟缩短到了不足一分钟。此外,Hugo 拥有一系列强大而有趣的功能,其技术社区也在积极提供维护支持。

遇见 IPFS

IPFS 的全称为 InterPlanetary 文件系统,这是一种以对等方式分发不可变内容的协议与网络。

如果大家不熟悉 IPFS,不妨将其理解成一种分布式的 CDN。一旦启动了 IPFS 节点,我们就可以在 IPFS 网络上发布文档,而来自世界各地的其他用户都能够从我们这里直接请求该文档。最赞的一点是,每一位向我们请求文档的访问者,同时又会快速将其分发给其他人。这意味着在使用 IPFS 时,文档的访问量越大,其复制次数也就越高,其他人下载时的速度也就越快。

通过 IPFS 实现的文件分发既快捷又极具弹性。由于采用分布式加点对点机制,IPFS 网络能够为审查及 DDoS 提供充足的弹性。

此外,IPFS 上的所有文档都由关于其内容的哈希进行解析,因此具备防篡改特性:如果有人要更改文件中的任何字节,整个哈希值就会发生变化,而地址也将随之改变。

IPFS 的问题在于,这只是一项内容分发协议,而非存储服务。它更像是 CDN,而非 NAS。我仍然需要使用服务器——目前使用三套服务器,共同配置在 IPFS Cluster 集群当中。好在我使用的都是 Azure 上提供的体积小巧且成本低廉的 B1ms 虚拟机(配备 1 个 vCPU 与 2 GB 内存),且运行在世界三个不同区域当中。
用了IPFS后,我的博客流量在一周内涨了50倍!

亚洲、欧洲和美国 IPFS 使用情况
在 IPFS 的帮助下,这套简单而且成本相对低廉的解决方案足以实现“100%”正常运行时间并具备 DDoS 弹性。网站内容会被自动复制到集群中的全部节点当中,而这些节点又会立即开始传播,并通过各虚拟机的跨地区分布快速将内容交付到世界各地用户的面前。

关于网站架构

我的这套博客采用了相对简单的架构:
用了IPFS后,我的博客流量在一周内涨了50倍!

博客网站架构
将新代码推送至 GitHub 上的主分支,即会触发 Azure Pipelines 中的自动构建操作,即克隆源代码并运行 Hugo 以更新网站内容(整个过程都是免费的!)。大家可以在 repo 当中参阅 azure-pipelines.yaml 文件的配置。 在构建完成之后,Azure Pipelines 会触发自动任务发布。发布流水线分为以下两个阶段:
  1. 将各文件复制到同一 IPFS 虚拟机当中,而后通过 SSH 调用 ipfs-cluster-ctl pin add 命令将各文档添加至集群内,再复制到各个节点处。
  2. 对 Cloudflare API 执行 REST 调用以更新 DNSLink。DNSLink 实际上是一条 TXT DNS 记录 _dnslink.withblue.ink,用于包含网站的 IPFS 哈希。

虽然第一阶段可以自动完成,但到了第二阶段,作为管理员的我仍然需要进行手动批准。这种方式,让我可以执行测试并确保网站通过 IPFS(利用其完整哈希)实现成功加载,而后向任何访问 withblue.ink 的用户发布最新内容。

在发布流水线完成之后,任何运行有 IPFS 守护程序的用户都可以访问此网站的 IPFS 地址:/ipns/withblue.ink 这很简单,也很好记。不过,这种访问方式只适合运行有 IPFS 守护程序、或者知道如何使用网关(例如 gateway.ipfs.io )的用户。

如果大家想要尝试 IPFS,可以使用 Firefox 与 Chrome 上的 ipfs-companion 扩展。配合外部或者内置网关,它能帮助大家轻松浏览 IPFS 网络。

大多数用户使用的仍然是 HTTP 以及普通的网络浏览器,这时候就要靠 Cloudflare 出来帮忙了。利用其免费分布式 Web 网关,Cloudflare 网络中的边缘节点可以充当 IPFS 网关并提供通过 IPFS 网络发布的文档。只要允许 Cloudflare 管理我们的 DNS,整个设置过程就非常简单;另外,CNAME 扁平化机制甚至允许我们使用 root 域名(例如 withblue.ink,不用加 www)!

从真实经验中学习

我使用 IPFS 已经有六个月了,用来支持本博客大概是一个月多点。总体来讲,我的体验相当不错。在这里,我要向各位打算亲自试试的 IPFS 分享一些心得。

进展顺利的部分

  • 总体来讲,使用 IPFS 能够带来不少有趣的助益。通过 IPFS 网络,文档获得了“100%”正常运行时间。只要至少还有一位访问者(近期浏览过网站)能够提供正常内容,任何用户就都能继续完成浏览;即使没有,我的三台服务器也能够通过 IPFS 将博客内容呈现给用户。
  • 速度:通过 IPFS 访问网站的用户越多,内容的交付速度就越快。
  • 网站应该能够天然抵御 DDoS 攻击。

不过必须承认,大多数用户并不会通过 IPFS 访问我的博客,而更多采用 Cloudflare 网关通过 HTTP(S)进行浏览。但这种方式的效果同样令人满意:

  • 由于 IPFS 中的各个文档皆具有不可变属性,因此 Cloudflare 会在全球范围内各个边缘节点中广泛进行网站缓存。只要 DNSLink 相同,就不需要 CDN 接入上游服务器以检查新内容。来自全球各个位置的延迟测试也表现出一致且快速的页面加载时间。在博客首页,所有内容(包括图像)在 3 秒之内即可全部加载完毕,而且身处世界任意角落基本都不会对这一速度表现造成影响——绝对令人印象深刻。
  • 设置非常简单。除了将 CNAME 指向 Cloudflare 网关并要求其为我的域名启用 TLS 证书之外,其它就没什么需要额外操作的了。无需配置高可用性、负载均衡、跨服务器内容复制等具体选项。
  • Cloudflare CDN 还能够提供其它重要功能,包括支持 HTTPS 与 HTTP/2.0、gzip 压缩响应等。

我的经验 / 改进空间

这个月,HTTP 迎来自己三十岁的生日,但 IPFS 则是一项还很年轻的技术。在使用 IPFS 的过程中,我发现很多情况跟我以往熟知的不同,也有一些传统方案无法正常起效。

  • IPFS 并非无服务器;它也绝对不是免费的。您至少需要一台服务器进行数据发布。好消息是,这台服务器的配置不用太高,能超频的单核虚拟机基本上足以提供必要的 CPU 资源;但如果大家同时也要运行 IPFS Cluster,则需要 2 GB 内存。像我这样的三节点结构实际上有点性能过剩(但这是段非常重要的学习经历,也相当有趣)。
  • 网站中的所有 URL 都必须是相对的。简单解释一下,这是因为用户可以通过多条基础 URL 访问您的网站(在我的示例中为 https://withblue.ink/, https:///ipns/withblue.ink 或者 https:///ipfs/),但您不能在 HTML 页面中使用绝对 URL。这也是我不得不从 Jekyll 转换至 Hugo 的主要原因。
  • 正如前文提到,大多数用户不会直接通过 IPFS 浏览网站,而是经由 Cloudflare CDN。这意味着我们的正常运行时间,实际上取决于 Cloudflare 的正常运行时间。虽然到目前为止,Cloudflare 的表现一直不错,但他们的免费服务并没有任何 SLA。另外,我甚至不确定 IPFS 网关有没有 SLA。同样遗憾的是,我不清楚有多少访问者在使用 IPFS 的数据,估计是没有多少。
  • 在使用 Cloudflare IPFS 网关时,某些特定功能会无法使用,具体包括:
  1. 无法设定自定义 HTTP 标头。这会影响到两种实际场景:其一,我们希望启用 HSTS(也没有任何办法能够实现);其二,我们希望手动设置 Content-Type(IPFS 网关会通过文件扩展名确定内容类型并使用某些启发式方法)。
  2. 无法实现自定义 404 页面。
  3. 无法实现服务器端分析,即使通过 Cloudflare 也不行。大家只能选择使用 Google Analytics 这类托管解决方案。
  • 我注意到的另一个问题在于,当变更 DNSLink 值时,Cloudflare IPFS 网关对缓存内容的清理并不可靠。用户可能需要等上几个小时才能看到最新的内容。这也是我迄今为止遇到的最麻烦的问题。
  • 在更新 DNSLink 值之后,可能会出现冷启动时间问题,即首页需要额外的几秒才能加载完成。但根据我的经验,实际情况并不严重。之所以会这样,是因为 Cloudflare 网关中的 IPFS 客户端需要遍历 DHT 以查找提供内容交付服务的节点。一旦内容复制完成,速度就会越来越快,问题也终将彻底消失。
  • 最后,我在运行 IPFS 节点时也遇到过一个问题,其在网络运行当中会占用相当高的带宽资源(但与内容交付无关!)。IPFS 0.4.19 版本显著改善了这个问题,但我的 Azure 虚拟机每月仍有大概 160 GB 的出站流量(IPFS 为 0.4.18 版本时,出站流量超过 400 GB)。

以上提到的这些问题,包括缓存、冷启动时间、服务器端分析、自定义 HTTP 标头以及 404 页面等,都可以通过采用自定义 IPFS 网关代替 Cloudflare 的方式解决。实际上,ipfs.io 官方网站采取的也是这种方法;如果 Cloudflare 的缓存问题长期没有改善,我也会考虑同样的解决思路。

原文链接:
https://withblue.ink/2019/03/20/hugo-and-ipfs-how-this-blog-works-and-scales.html

评论

发布