自从使用 Cloudflare Workers 来部署后，笔者编写博客的工作流就变成了：

1. 编写博文，放置于项目仓库中（使用 Git 进行版本控制）。
2. 提交 Git commit 并 push 到远端 GitHub 仓库存档。
3. 在本地使用 Hugo 生成静态网站文件。
4. 最后使用 make deploy （笔者自己写的 Makefile，其实是调用了 Cloudflare Workers 的 wrangler 工具的 wrangler publish）将新生成的静态页面部署到 Cloudflare Workers 上。

每次发布文章都需要做这四个步骤。而第一步的内容编写和第二步的版本控制，是无法进行缩减的。那么能否将后两步再优化一下，使得发布博客流程更加简单且稳定¹？

这就让笔者想到了工作中日常使用的 CI/CD 流程，在 GitHub 上注册一个 webhook，监听 GitHub 仓库的变更，随即触发 CI 任务构建与 CD 部署，后两步不就不再需要作者操作了么？

在一次偶然的与 @miaotony 的闲聊中，得知 Cloudflare 原来还出了服务，名为 Cloudflare Pages （仍处于 Beta 阶段，但已经可用）。其与 GitHub Pages 不同的是：GitHub Pages 的仓库内容已经是生成好的网页文件²，而 Cloudflare Pages 中自带了 CI/CD 流程³ 。而这个 CI/CD 流程，恰恰是能够替代上述发布流程中的后两步的服务。进而阅读了下 Cloudflare Pages 的文档，由于其属于纯静态页部署，可以直接使用 CDN 分发，因此其在免费套餐中不限制访问带宽，也不限制请求次数。这简直就是博客 Hosting 的完美服务啊，于是笔者的博客切换到 Cloudflare Pages 就这样提上了日程。

对于引流设计，在切换到 Cloudflare Pages 上后，引流设计没有太大的变动：仅仅是后端服务变化，涉及一个 DNS 记录解析变更。整个过程近乎可以平滑切流，用户应该对本次变更完全无感。

由于博客内容仍然使用笔者的 GitHub 仓库，因此不再需要做博客内容迁移，只需要在 Cloudflare Pages 上配置构建、发布规则和自定义域名即可访问。

至此，笔者编写博客的流程已经缩减成了如下两步：

1. 编写博文，放置于项目仓库中（使用 Git 进行版本控制）。
2. 提交 Git commit 并 push 到远端 GitHub 仓库存档。

Cloudflare Pages 在收到了 GitHub 的 webhook 后，会进行如下步骤：

1. 用指定的构建命令 hugo 生成静态网页。
2. 将构建产物发布于 Cloudflare 全球网络中。

这样，笔者的博客就完成了上线和更新 🎉

为什么要迁移？

在过去五年里（2016-2020），笔者的博客流量一直由一个 1 核 1 GB 特别寒酸的 云服务器承载。使用的 WordPress 来作为博客内容管理发布平台。由于这台机器承载能力日显不足，以及出口带宽有限 1Mbps 小水管 ，后来我在这个服务器前挂了个 CDN 服务。然而 CDN 服务的缓存命中率也较为有限（常年在 15~20%）也可能是我当年太菜了不会配置 ， 特别是在登入 WordPress 后台时，博客系统垃圾的性能毕显无遗。博客文章的打开速度越来越慢，甚至要 3s 以上才能够加载完全，瞬间能够消减读者的阅读欲望；博客后台登录也是噩梦般的体验，极大减少了笔者发表内容的积极性。基于以上背景，笔者决定重构博客系统的架构，希望达到以下目标：

1. 弃用功能繁多而臃肿的 CMS 系统（WordPress），而采用定制性高、完美支持 Markdown 的静态页面生成器，易于文章编写和分发。
2. 不再使用云服务器部署，采用 Serverless 服务。
3. 境内境外采用双路 CDN 分发的方式，提高用户侧的网页加载速度。

新博客技术选型

基于以上期望，新博客的静态页面生成器选型为 Hugo。生成器选好了，但是毕竟万物基于皮肤，皮肤才是博客的灵魂 大误 。经过几天的搜寻，终于找到了一个令我满意的主题，PaperMod。它基于 Paper 主题修改而来，完美的继承了 Paper 的所有优点。具有恰到好处的渲染样式、简洁的博客界面。除了一点：中国大陆要求 .cn 网站要求备案，且在网站底部需要注明备案号。PaperMod 原主题自然不会有这样的需求，因此笔者稍微对其做了改动，在脚注中加入了备案号信息。修改过的主题位于 Triple-Z/hugo-PaperMod ，有需要的读者可以直接拉取使用（只需在配置中的 params 中填写 BeiAn 内容即可在页脚显示备案号。

对于 Serverless 服务，笔者选择了使用 Cloudflare Workers。主要是其口碑好，且文档全面。对于博客系统来说，它的免费额度已经足够使用（每日 10 万次调用）。使用了 Serverless 服务之后，就再也不需要操心扩缩容来适应流量变化了，只需要准备好足够的💰，待访问量增加后交得起账单即可 :P

流量引流设计

由于 Serverless 选择了 Cloudflare Workers，众所周知，中国大陆访问 Cloudflare 上部署的网站速度会受到一定程度的影响。因此，为了保证网站访问速度，笔者使用了双路 CDN 来同时保证中国大陆和境外的访问体验。

在设计流量走向时，笔者一直在不断调整 DNS 的各种记录种类及相对应的值，其中踩了非常多的坑。最后总结出来，整个过程就是三个字：串葫芦 🤣 。

整体引流设计见下图：

1. 客户端发起 blog.triplez.cn 的 DNS 请求，若客户端在中国大陆，将会获取到一条 CNAME 记录，指向国内某云厂商 CDN ；若客户端在境外，将获取到一条指向 blog.cf.triplez.cn 的 CNAME 记录。
2. 客户端解析 blog.cf.triplez.cn ，会获取到 cf.triplez.cn 的上的 NS 记录，其指向 Cloudflare 的 DNS 解析服务器。
3. 在 Cloudflare 的 DNS 解析服务器上，配置了一条 blog.cf.triplez.cn 的 A 记录解析。这条记录的解析值仅是一个占位符。因为我们的希望是在 Cloudflare 上能够拦截该 DNS 请求，通过 Cloudflare Workers 的 Route 功能（拦截 blog.triplez.cn ）将请求定向至 Cloudflare Workers 中。
4. 对于国内某云厂商 CDN ，回源配置直接配置为 blog.cf.triplez.cn ，且回源 HOST 配置为 blog.triplez.cn 。这样流量导流过程就全部结束了，无论是来自大陆的请求还是来自海外的请求，都可以被正常解析并定向，并根据不同线路提供不同的 CDN 服务。

迁移内容

为了把位于自建 WordPress 的博客中的历史发布内容都迁移到新的 Hugo 上来，笔者做了一下简单的搜索，发现 Hugo 官方推荐了几个 WordPress 工具可用于导出 WordPress 数据。笔者先尝试了 wordpress-to-hugo-exporter 这个导出工具，命令行版本和管理界面导出都试了一下。发现这个工具并不如人意：由于笔者的 WordPress 安装了一些插件（Markdown 解析器等），通过 Markdown 编写的博客都无法被导出插件正常转换为 Markdown 格式，而是一大串 HTML 代码。也就是说，几乎原来所有的文章内容通过它都无法正常导出（还好我本地有 Markdown 源文件备份），导出后只有元数据（Hugo 中 Markdown 内容顶部 --- 中的内容）和文件命名（根据 URL）能被有效使用。

由于以上的问题，内容迁移只能进行人工介入：笔者主动 selected 需要迁移的文章，将其放入新博客中。

此工作还正在进行中，刚好也是对笔者五年来博文的一次梳理 某些不适合发表的博客将不会被选入新博客中 。在此工作完成之前，将不会主动在博客站以及 A2OS 的 BlogRoll 项目中更新 RSS 链接，以免读者重复“被订阅”历史博客内容。

如果屏幕前的你等不及想现在就订阅笔者的博客，也可以点击这里马上订阅：RSS Feed for TripleZ’s Blog 。

上线！

调整了 CNAME 解析之后，博客就上线了哈哈哈！由于后端是 Serverless 的，因此并不需要做什么额外操作，只需要把博文写好，在键盘上敲入 make deploy 就更新了~

Enjoy my new blog 🎉