独立博客搭建方案对比

发表于 更新于 分类于 阅读次数： 本文字数： 3.8k 阅读时长 ≈ 13 分钟

前言

最近主网站域名 blog.x2b.net 突然连接变得很慢，由于站点用的 Cloudflare 结合最近 Docker 在中国因未知原因遭到封锁，怀疑又有人在测试对 Cloudflare 投毒。因此决定对所有备用域名，也就是几种部署独立博客的方法进行速度测试，并根据测试结果更改主域名的绑定服务。

创建站点

创建一个独立博客实际是建立一个网站。这需要一些建站相关知识，例如服务器配置、域名配置和应用部署流程等。

此外根据需要，可能需要购买一个独立域名或服务器。对于域名，建议优先选择 .com、.net、.org 或 .cn 这些传统的顶级域名。

本站域名通过 Cloudflare 购买和托管。除了域名解析服务，还使用了 Cloudflare 的 CDN（内容分发网络）、DDoS（分布式拒绝服务攻击）保护和 SSL（安全套接字层）证书等免费服务。

创作发布

我本地笔记全部采用 Markdown 格式，在 Typora 上面书写并管理。接下来是将内容发布到网络上。理想状态是：用 Git 作为版本控制系统，只要将修改提交到 Git 仓库中，新内容自动发布到网站上。

一开始用 GitBook 作为发布系统，但 GitBook 更新得越来越难用，隐约提醒我这不是个好选择。最终在大量测试实践后，形成了现在这套发布流程：完成写作后，运行一个脚本文件。这个脚本会自动构建静态网页并上传到 Git 仓库。一旦脚本执行完毕，所有的网站都会自动同步更新。

整个配置过程有点繁琐。但只要一次配置，持续使用。

博客程序

主流的博客程序主要包括动态网站如 WordPress，以及静态站点生成器例如 Hugo、Hexo 和 Jekyll。

最先尝试用 WordPress，其功能全面且出色，但却存在一个痛点：无法实现从 Git 上自动更新。虽然有 Git 插件可供使用，但没有一个能完美工作。例如，每次更新文章内容，系统都会生成一个新的文章和链接，而非直接在原文章上进行修改。

如果每次写完或修改文章都需要额外操作一次后台文章编辑，长期下去会影响创作热情。经过了解后，我把目光移向静态网站生成器。

静态网页生成器有很多明显的优势：

  1. 高性能：静态网页生成器预先生成页面，无需像动态网站那样每次请求都去服务器获取数据，因此访问速度通常更快。
  2. 安全性：静态网站没有数据库，几乎没有被攻击的风险。
  3. 易于部署和托管：静态文件可以在各种服务上托管，有很多免费的现成服务可供选择。

当然静态网页生成器也有一些缺点：

  1. 动态内容展示困难：静态网站无法像动态网站那样实现实时更新或者实时互动。
  2. 缺乏用户交互：像评论、搜索这类的用户交互功能，实现起来需要额外的工具或者服务，都不如 WordPress 自带的那样好用。
  3. 内容更新不够灵活：每次网站内容更新时，需要重新生成和部署整站。我不确定文章数量增加后会出现什么问题。

最终我选择 Hexo，只是因为其更新频率高，且用户数量看起来多些。这意味着遇到问题时，能更方便地找到解决方案。

性能测试

一旦插件安装好并且配置调整完毕，我们可以在本地进行部署测试性能。打开 Chrome 浏览器，按 F12 打开控制面板关注加载时间。

例如，当某个文件无法获取时，浏览器控制台通常显示红色的错误信息。这表示网站正在尝试加载一个不存在或无法访问的文件。这种情况下，需要检查文件的路径是否正确，或者该文件是否确实存在。

另一个常见的问题是某些 js 文件的加载速度过慢。如果发现这种情况，可以去 hexo 目录中，用文件内容搜索与该文件相关插件。找到后可选择禁用该插件，也可以选择修改插件的代码，以改善加载速度或者修复错误。

下面是常用的分析工具：

  1. https://pagespeed.web.dev/，这个工具可以帮助测试网站的 SEO 友好度。一般来说，使用 hexo 生成的静态网站在这方面都表现良好。主要是测试网络无障碍时的访问速度。
  2. https://www.itdog.cn/http/，这个工具主要用于测试网站在国内的连通性。但它测出的时间可能并不十分准确，因此仅作为国内连通性测试使用。

通过测试，我们可以得到网页访问所消耗的原始时间。

用服务器部署

通过服务器部署有最大自由度，可以不依赖任何第三方服务和平台。但不管本地还是线上环境部署都需要自行准备服务器。

本地部署

本地部署是指将文件全部存储在本地，将域名指向本地文件，用户可以直接访问。

直连地址：http://localhost:4000

绑定域名：https://www.x2b.net

优缺点

优点：

  1. 可以完全控制网站内容，实现最大化自由控制。
  2. 没有任何性能限制。
  3. 可以选择自己喜欢的发布方式。

缺点：

  1. 受限于上行带宽，通常不会超过 30Mb。
  2. 无法获得独立 IP 地址，必须通过其他方式绑定域名。
  3. 存在稳定性问题。本地服务器关机时，网站无法访问。

部署方式

  1. 使用一台微型主机，安装 Linux 系统，并部署 k8s。这同时也是一个学习和测试的环境。

  2. 每当用脚本将文档更新提交到 GitHub 后，会触发 Jenkins 任务进行自动构建。Jenkins 会从 GitHub 拉取最新的代码，也就是生成的静态 html 文件，将这些静态文件、Nginx 基础镜像以及配置文件一起打包，上传到 Docker 仓库。由于现在 Docker 官方仓库无法使用，可以选择使用阿里云的个人版免费自建仓库，或者自己搭建的私有仓库。最后，在 k8s 中进行滚动发布，完成部署。

这显然不是最优解，仅为了实践发布流程才引用 CI/CD。通常做法可以参考下面云服务器部署方案。

速度实测

国外首次主页加载时间约 5 秒，其他页面秒开。

国内首次主页加载完成时间超 30 秒。其中 90% 时间都耗在第一次与 cloudflare 建立连接等待响应上，完全无法用。

云主机部署

云主机分为两种类型：独立服务器和 VPS。VPS 只能使用服务商提供的有限功能，但价格相对便宜。建议选择独立服务器，因为可自行安装所需工具用于其他目的。

我选择阿里云香港最低配服务器，加上优惠卷，一年的价格大约 80 人民币。由于网络带宽包年的费用很高，因此选择按量付费方式。

直连地址：http://8.217.87.89/

绑定域名：https://blog.x2b.net

优缺点

优点：

  1. 服务稳定，最低配硬件对于静态网站服务绰绰有余。
  2. 阿里云自带性能监控和报警服务，可以凑合着用。需要也可自行部署监控。

缺点：

  1. 如果选择阿里云国内的服务器，可能会面临 HTTP 端口被封以及备案问题的困扰，但访问速度没话说。
  2. 与此相对，选择国外的服务器无需备案，开箱即用。但网络速度需要优化，而且可能有 IP 被封的问题。

部署方式

  1. 在服务器上选择安装 CentOS 7 并安装好 Docker。

  2. 运行 nginx 容器，将 nginx 的配置和 html 目录挂载出来。

  3. 运行 git 容器，定时拉取同步 GitHub 仓库的内容到 nginx 的网页 html 目录下，自动完成网站内容的更新。

速度实测

直连地址首次完整载入时间在 2 秒左右，还是可以的。

但是套了域名后，国内访问全红无法打开，访问超时，原因未知。

代码托管平台

这类服务的特点是，同时托管网站源代码。通过源代码构建出静态页面，再通过 Pages 服务来发布网站。

Github Pages

GitHub Pages 是一个静态网站托管服务，它直接从 GitHub 存储库中获取 HTML，CSS 和 JavaScript 文件，然后通过一个简单的 URL（通常是 https://<username>.github.io）公开发布。

直连地址：https://hxz393.github.io/

绑定域名：https://mirror-github.x2b.net

优缺点

优点：

  1. GitHub Pages 服务是免费的，可以创建和托管网站而无需支付任何费用。
  2. 虽然 GitHub Pages 提供默认的 github.io 域名，但也可以使用自己的自定义域名。

缺点：

  1. 免费用户每个小时的构建限额是 10 次，且仓库的容量限制为 1GB。所以不能在仓库中存放过多图片和文件。
  2. 据说免费 github.io 域名无法被百度引擎的收录。百度搜了一下，确实搜不到用这类域名的网站。其他搜索引擎没问题。
  3. 配置构建步骤对没有基础的人来说，有点复杂。

部署方式

由于时间久远，具体步骤记得不详细，大致流程如下：

  1. 在 GitHub 新建一个 <username>.github.io 的仓库用于存放静态网页文件。

  2. 在本地 Hexo 配置文件 _config.yml 中，配置好 github url 和 token。

  3. 在本地发布脚本中，配置好提交和发布命令。

  4. 在 GitHub 仓库设置的 Pages 中，配置好自定义域名。

速度实测

首页首次载入时间在 5 秒左右。

Gitlab Pages

Gitlab 线上版在国内用的人不多，一般都用来搭建私服 Git 仓库。

直连地址：https://hxz393.gitlab.io/

绑定域名：https://mirror-gitlab.x2b.net/

优缺点

优缺点基本和 GitHub 保持一致，不过开通 Gitlab Pages 需要通过信用卡认证身份，导致用的人不多。

部署方式

和 GitHub 比起来复杂一点：

  1. 创建一个存放源代码的私有仓库，并在 Hexo 配置好发布地址。

  2. 在项目根目录下，添加一个 .gitlab-ci.yml 文件配置流水线，内容如下：

    image: node:18.16.0

cache:
  paths:
    - node_modules/

before_script:
  - npm install hexo-cli -g
  - test -e package.json && npm install
  - hexo generate

pages:
  script:
    - hexo generate
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH

  3. 在项目 Pages 页面配置好绑定域名和 HTTPS 证书。

速度实测

首页首次载入时间在 3 秒左右，很满意。

Gitee Pages

Gitee Pages 是由码云提供的和 Github Pages 一模一样的服务。由于 Gitee 服务器位于中国，所以 Gitee Pages 的访问速度在国内非常快。然而，Gitee Pages 的使用需要多次进行实名认证。

仓库地址同步：https://gitee.com/hxz393/x2b

不想实名认证，所以没测试实际使用。

网站托管平台

这类服务的特点是，需要与代码托管平台集成。专门针对网站托管优化，提供一些额外的服务，功能定制方面比代码托管平台类丰富。

Cloudflare Pages

Cloudflare Pages 本应是技术栈最完善的静态网站托管服务，但在国内体验一言难尽。

直连地址：https://x2b-net-source.pages.dev/

绑定域名：https://mirror-cloudflare.x2b.net

优缺点

优点：

  1. 一站式解决方案。网站加速、防火墙、CDN、路由规则等功能应有尽有，而且完全免费。
  2. 为每次构建生成一个 url 地址，可以快速预览。

缺点：

  1. 在国内用 Cloudflare 的服务，等于做负优化。

部署方式

  1. 在账户主页 Workers 和 Pages 中新建应用。
  2. 绑定 GitHub 网站源码存放仓库。
  3. 配置构建命令和输出目录。
  4. 绑定自定义域名。

速度实测

直连地址访问在 3 秒左右，但 pages.dev 域名被污染，时不时会跳到一些危险站点，不推荐使用。

套了域名后，国内访问全红，原因未知。有时候能打开，但等待速度超过 30 秒，完全不能使用

Netlify

Netlify 是网站部署和自动化平台，在国外比较流行，常用于制作演示 Demo。

直连地址：https://x2b.netlify.app/

绑定域名：https://mirror-netlify.x2b.net

优缺点

优点：

  1. 使用简单，跟着官方步骤操作，不到五分钟就配置好了。

缺点：

  1. 国外的服务都有被墙的风险，最好还是绑定个域名使用。服务不能用时，可以把域名切换到其他同类服务上。

部署方式

略过。自从配置好后，我再没有也不需要登录 Netlify 去做任何操作。

速度实测

首页首次载入时间在 2 秒左右，非常快。

Vercel

Vercel 提供和 Netlify 一样的服务。由于 Vercel 又是 Next.js 的创造者，如果网站用到 Next.js，可以优先选择它。

直连地址：https://x2b.vercel.app/

绑定域名：https://mirror-vercel.x2b.net

优缺点

优点：

  1. Netlify 有的它都有。

缺点：

  1. 已经被墙。

部署方式

和 Netlify 一样，绑定 GitHub 源码仓库，选好网站渲染构架和构建命令，再配置绑定域名就完成了。

不过每次构建完会往 GitHub 账号发送消息提醒，不知道在哪里关闭。

速度实测

直连地址无法访问，套了域名之后可以访问，但会出现和 Cloudflare Pages 一样的问题。不推荐使用。

最后

本想做个总结对比表格，目前来看能用的也就 Gitlab Pages 和 Netlify，免费服务且用且珍惜。

另有一个想法，但不知道如何实现。我是想让一个主域名来对应后端多个免费托管服务，可以通过用户来源选择最快的服务，如果其中一个服务不能访问，能快速切换到可用服务。

我能想到的是把主域名指向一台固定服务器，通过 Nginx 来做后端负载均衡。但这台服务器又无法避免单点故障，且多一层转发多很多延迟。这个功能应该在域名解析层实现才划算，就是不知道有没有这样的服务。