零依赖 GitHub 进行 Hexo 静态页面灰度发布

最近我更换了我 Hexo 博客的主题，在主题更换过程中，新主题总是大大小小出现一些问题，于是我就想到能不能让主题切换变得像 App 发布一样，进行精准推送，让一部分愿意反馈意见的用户先体验，进行 Bug 反馈，但又不影响大部分正常用户的浏览体验。下面本文将介绍我在更新主题过程中，进行的灰发操作。

一、核心思路：动态路由

大部分博主的主题切换一般都是进行一次性配置，然后直接推送，出现问题本地修复后再推送更新。但是这非常影响正常用户进行资料参考时的体验感。而我的方案是通过在服务器上并行部署新旧版本，配合 Nginx 的智能路由，实现用户流量的切流。旧版本拷贝在 ../www/blog.yujiay.wang/old/ 目录，新版本位于 ../www/blog.yujiay.wang/ 目录，二者完全物理隔离。这种隔离确保即使新版存在严重问题，旧版仍能无缝接管全部流量，免单点故障。

Nginx 作为流量调度中枢，通过预定义的规则（如 Cookie、IP 或 URL 参数）动态分配用户请求。这种设计解耦了部署与发布流程：你可以随时更新新主题内容到 ../www/blog.yujiay.wang/ 目录，而无需立即切换用户可见版本，实现发布节奏的精细控制。

二、Nginx 灰度路由策略

Nginx 的灵活性在于支持多维度分流规则。有三种典型配置方式：

  1. Cookie 分流​（适合定向邀请测试用户）
  2. ​IP 白名单分流​（适合内部团队验证）
  3. ​URL 参数分流（最好只用于临时测试）​
1
2
3
4
map $cookie_gray_flag $blog_version {
    default   "/var/www/blog.yujiay.wang/old";    # 默认旧版
    "new"     "/var/www/blog.yujiay.wang";      # 携带 gray_release=active Cookie 的用户访问新版
}

最终在server配置中应用路由逻辑：

1
2
3
4
5
location / {
    root $blog_root;  # 动态指向目录
    index index.html;
    add_header Cache-Control "no-cache";  # 禁用缓存确保实时切换
}

​
首次进行部署时，需要先上传旧版至 old 目录并验证访问正常，再上传新版至 / 目录。通过 nginx -t 校验配置无误后执行 nginx -s reload 热加载，避免服务中断。当发现问题时，10 秒内即可回滚：将默认路由改回 old 目录并重载 Nginx。新版文件保留在服务器供问题复现，无需重新上传。

动态扩缩灰度比例是平滑上线的关键。初期仅面向 3% 内部用户，逐步扩大到 5%、10% 的高活跃读者，最后覆盖全体用户。在 Nginx中 通过调整 split_clients 比例实现：

1
2
3
4
split_clients $remote_addr $blog_version {
    3%      /;   # 第一阶段：3% 流量
    97%     old;
}

后续只需修改百分比并重载配置，即可动态扩缩范围。

三、为什么此方案更优？

相比 GitHub Pages 等托管方案，本地编译+服务器直传的核心优势在于完全掌控​：

  • ​零依赖​：无需担心GitHub服务中断或Actions额度超限
  • 秒级回滚​：Nginx 重载比 Git 仓库回退更迅速
  • ​物理隔离​：新旧版本文件分离，彻底避免覆盖冲突
    对于日 PV 过万的中型博客，此方案在单台 2C4G 服务器上即可流畅运行。若流量持续增长，可结合 Cloudflare Workers 等边缘计算平台，在全球节点实现更细粒度的灰度控制。

主题升级是对用户体验的重新定义。通过本文的灰度发布方案，不仅掌握了风险可控的切换技术，更建立起一种渐进式演进的思维模式。让改变如细雨般浸润，而非洪水般席卷。

毕竟，好的技术从来不是惊心动魄的豪赌，而是细水长流的艺术。