尘封的博客以及碎碎念

尘封的博客

疫情第三年。也许人们已经忘却了这场风波的源头，但是病毒仍然在世界各地肆虐。截止本文写就，这个名叫 SARS-Cov-2 的病毒引发的名为 COVID-19 的疫情已经造成了约 3 亿人感染，超过 500 万人死亡¹。笔者本人呢，虽然身体暂时安康，但由于客观条件限制，无法进行核酸检测…所以我也不知道自己到底有没有感染 233，只能希望万事顺遂吧。

前几天在整理备份时，发现了这个早已不再更新的博客：上一次更新已经是两年前了。大概翻了翻旧博文，当初的目标实现得潦潦草草，立下的 FLAG 那是一个都没完成。斗转星移，物是人非，当然我还是我，半吊子的我到现在仍然是非常的菜。

Serverless

这个博客最早是部署在 WordPress 上的，后来跟着 Serverless 的大潮一起转到了 Hugo，一直使用到了现在。Hugo 确实挺好用，或者说对于个人博客，静态站点生成器就是比诸如 WP 和 JAM 之流要优秀。凡是能显示网页的托管平台就能接入，也没有站点配置，漏洞修复等等破事。当然这里不是说 php-based 的系统有多么不好，你看 pixiv 和 exhentai 不是用得挺开心的吗（误），只是如果一个网站根本就没有动态资源，那么使用静态系统所能带来的优势会更加明显。

以下是两个站点的加载流程对比，后者就是本站，前者为一个经过高度优化的 WP 站点，均在未缓存状态下加载。(此处省略 connection 部分的耗时，因为本地网络足够快，服务器网络也足够快。)

Host	Ping	Request Sent	TTFB	Content Download
1	2.38 ms	118 µs	134.80 ms	2.72 ms
2	2.01 ms	121 µs	45.14 ms	1.81 ms

可以看到，即使是进行了服务器端缓存的 WordPress，其 TTFB 也要比纯静态页面要高。TTFB 可以简单理解为客户端需要无条件等待的时长，这个值在部分浏览器上显示为 Waiting。如果一个网页需要客户端进行无条件等待超过 500 ms，那么就算网站所在的基础设施平台足够优秀（如 Cloudflare/Google CDN 等），实际体验大概也会比较糟糕。

当然现在的网站不单只有一个网页需要加载，还有大量的 assets，使用 react 等搭建的 WebApp 更是需要时间进行 startup。关于网站优化的内容，Google 出品的页面性能分析工具已经有详尽的分析和建议，本文不再赘述。

Backup

其实无论是静态系统还是动态系统，基础设施炸了那就什么都没了。上到 OVH 下到 BuyVM，稍微有点名气的基础设施提供商都出现过数据丢失/机房爆炸的灾难性事件²；就算是使用了大规模冗余配置的 Google 和 Cloudflare，也时不时会出现“让全球网络流量下降 40%”的服务中断³。所以日常的备份也是很重要的。

说到备份，不知道大家对自己的数据有没有日常备份的习惯呢？个人认为，所有重要数据都应当进行本地备份和加密的云端备份，即使是非重要数据，也应该在可靠的地方多放置一份副本并定期同步。如果是参照数据备份领域经典的 3-2-1 Rule，那么要求就更为严格了：

三份数据副本
两个不同介质
一份离线备份

自从以 Chia 为首的 PoS/PoST 类虚拟货币出现以后，硬盘价格就水涨船高，这一变化的直接影响就是人们买不起硬盘了，也不敢买硬盘了。既然连硬盘都没有了，那备份从何而来呢？即便如此，我们也要清楚的认识到，即使是大量使用企业级硬盘的云服务提供商，也不可避免的会出现数据丢失问题，如阿里云⁴，VULTR⁵；RAID 等技术并不能保证数据不丢失，其只能提高阵列的可用性，避免单点故障造成灾难性影响（RAID0 除外）。

Platform

使用静态网页生成器，一个不可避免的问题就是平台的选择。这个博客刚建好的时候，人们还喜欢用 Google Sites 和 Blogspot 写博客，后来静态页面生成器流行起来以后，大家都在用的是 Github Pages、Firebase Hosting 和 Netlify。近年来涌现了很多高质量的静态网页托管平台，用 Vercel 和 Cloudflare Workers 进行网页托管的也有不少。笔者算是大致都体会过这些平台，总的来说各有千秋，下面是一些主观体会。

Firebase

Firebase Hosting 用的是 Google CDN，这个 CDN 在全世界的延迟体验都很不错，即使是国内也能获得良好的响应速度。CDN 默认是分区自动解析到最近的边缘网络节点，AnyCast 爱好者也可以使用一些特定的 IP 进行 Anycast 托管。需要注意的是，Firebase 的免费层级限制每个月流量只有 10G，超出需要另行付费。

以前用 Firebase 的时候偶尔会有莫名其妙的卡顿，这点和 Google 官方的 Blogspot 表现接近。具体表现为网页加载的时候会间歇性出现 1-2s 的 Waiting，大概是在回源吧 233。当然现在 Google CDN 已经改善了缓存系统，几乎不会出现意外的等待了。

GitHub Pages

Github Pages 使用的是 Fastly CDN。如果我没有记错的话，以前的 Github Pages 是支持 Private Repo 部署的，近年来才逐渐变为仅支持开源项目部署的形式。Fastly CDN 感觉表现中规中矩，速度响应方面没有太多亮点，算是普通的 CDN 提供商吧。可惜由于托管在 Github 上的页面鱼龙混杂，目前该服务在国内访问略有困难。

Vercel

Vercel 给人的感觉是非常的 geek，界面十分清爽，性能也令人满意。网络方面 Vercel 声称用的是自有 CDN，即 Vercel Edge Network，测试结果显示这个网络大概是 Microsoft Azure CDN 和 Google Cloud CDN 的混合，全球访问延迟不错。但是这个 CDN 并不支持 IPv6，所有托管在 Vercel 上的网站都只能使用 IPv4 访问。流量限制为每月 100G，这个限制为硬限制，超了就会 404.

Netlify

Netlify 和 Vercel 感觉像是孪生兄弟，一开始两家不相上下，大家都有大厂青睐，大家都拿到了不菲的风投。随着他们的发展，Vercel 更侧重于服务拓展，而 Netlify 似乎更侧重于企业用户和稳定性。至于网络，Netlify 应该是基于 AWS 和 DigitalOcean 的自建 CDN，大多数区域的延迟属于正常的服务器间延迟。这个 CDN 支持自定义 IP 和区域解析，可以自己设计部分区域的网络路由。

作为较大的静态站点托管提供商，Netlify 和 Vercel 的其他服务项目都是差不多的——无服务器函数，服务器端渲染，每月流量限额等等。如果要问有什么不同，大概只有在对待商业化的态度上。Vercel 的免费层级仅限个人项目，要求商业网站必须使用其付费项目。而 Netlify 则没有对在免费层级上托管商业项目进行限制性表述⁶。

Cloudflare Pages

Cloudflare Workers 和 Cloudflare Pages 是 Cloudflare 提供的无服务器平台。前者主要应用于无服务器函数，后者主要应用于静态页面托管。网络自然是 Cloudflare 的网络，使用 Cloudflare Pages 还可以进一步和自选 IP 结合，以优化全球的访问效果。总的来看没有大的缺点，唯一问题是部署构建速度很慢，每个新部署需要等待至少 2 分钟才能完成初始化。

Ending

就这样，88，我回去睡觉了。