本博客最近的一些变化

共 1661 字 约 5 分钟 2 周前 6 评论

最近把荒废多年的博客捡起来修缮了一番,在这篇文章里记录一下。

使用 Waline 评论系统

很多年前,我用自己写的博客系统换掉了 WordPress,在那之后短暂用过多说,其余时间都在用 Disqus 作为博客的评论系统。Disqus 作为第三方社会化评论的鼻祖,早些年体验和口碑都非常不错,但前几年它被营销科技公司 Zeta 收购,多了不少乱七八糟的广告,付费去广告的费用也不便宜。另外最近几年 Disqus 在国内基本不可用,我之前通过解析接口和自己写界面搞了一个评论基础模式,凑合着用。几个月前我发现,Disqus 评论框在我手机默认浏览器默认输入法下完全无法输入,刚开始以为是 CSP 拦了一些 JS 导致的问题,后来发现并不是。在我的认知里,核心功能主流环境无法使用就算不是 P0 也不至于几个月都没修复,所以尽管很感谢 Disqus 让我免费用了这么多年,还是下定决心换掉。

为什么换成 Waline,主要原因是跟作者很熟,遇到问题直接问。其次 Waline 项目用到的技术比较现代,代码结构很清晰,万一后续有什么需求要改代码,上手成本也不会太高。迁移过程非常顺利,参考 Waline 官方文档都能搞定,以下是一些小提示:

官方「快速上手」文档中描述的是 Vercel 部署服务端 + LeanCloud 数据库的方式,我采用的是本地部署 + MySQL 数据库,这部分文档在「部署」和「多数据库服务支持」里,藏得有点深。

在 Disqus 后台可以导出所有数据,操作后等一会儿就会收到包含下载链接的邮件。在 Waline 的数据迁移助手页面,可以把 Disqus 导出的 xml 格式转成 Waline 格式。我选择迁移至「Waline MySQL/PostgreSQL/SQLite」存储服务,得到了一个 csv 文件,刚开始我一直以为要通过 Waline 后台来导入 csv,失败多次后猛然想起来,直接 MySQL 中导入即可。

Waline 的客户端部分(JS + CSS),可以通过 CDN 引入,也可以直接在项目中导入。这两种方式对于追求高性能的本博客来说都不太合适,我目前使用 Dynamic imports 来加载 Waline JS,用动态创建 link 标签的方式来加载 Waline CSS,实现了 Waline 的按需加载。

Waline 提供了一个很小的 JS 文件用来显示某篇文章的评论数,而我选择把评论数存在数据库里,这样能再快一些。Waline 提供了完整的 APIHooks,无论是通过 API 定期更新,还是通过评论的新增 / 删除 Hook 触发更新,都非常方便。考虑到本博客评论不多,一个 10 分钟运行一次的定时任务就足够了。

另外,我还对 Waline 静态资源做了代理,统一通过我的 CDN 域名来访问,评论数据接口我也做了代理,通过主域来访问,这样也有一些加速效果。如果你觉得还不够极致,可以参考作者「静态博客如何高性能插入评论」一文,将评论模块彻底静态化。

使用阿里云低价服务器

早些年,我这个博客在国内国外都有部署,一年的费用超过千元。后来,我砍掉了国外部署,花费降至几百。如今,这个博客跑在 ¥99 一年的阿里云长效特价服务器上(2 核 2G,3M 固定带宽,40G ESSD Entry 盘,能低价续费到 2027 年),CDN 也换成了每个月可以白嫖 20GB 流量的多吉云(DogeCloud),加上域名每年花费不到二百,可以说非常省钱了。

腾讯云同样的价格只能买到轻量云主机(PS:京东云最近有活动,同样的轻量云主机只要一半甚至 1/4 的价格),但轻量云主机可玩性还是差了一些。阿里云这次没有限制新用户才能参与活动,确实挺良心。唯一的问题是这个小内存机器(装完 Ubuntu 后默认可用 1.63G),非常容易死机,具体表现为云盘读写 BPS 和 IOPS 居高不下,系统无响应、SSH 连不上,只能去阿里云控制台强制重启。

aliyun iops

为了尽可能减少因为内存用完导致的死机,建议装完系统后做一些调整:

首先,既然物理内存本来就不大,需要尽可能减少运行的服务。上篇文章提到我将一些服务跑在远程的树莓派上,目前这台机器只跑了 MySQL、博客、Waline 评论、frps 这几个服务。另外,阿里云默认会安装云助手 Agent 等服务,如果对自己的安全知识有信心,可以都卸载掉,能省不少内存。

其次,阿里云默认给 kdump 内核崩溃转储机制预留了一些内存,打开 /etc/default/grub 文件可看到这样一行配置:

GRUB_CMDLINE_LINUX=" vga=792 console=tty0 console=ttyS0,115200n8 net.ifnames=0 noibrs iommu=pt crashkernel=0M-1G:0M,1G-4G:192M,4G-128G:384M,128G-:512M nvme_core.io_timeout=4294967295 nvme_core.admin_timeout=4294967295"

1G-4G:192M 表示这台 2GB 内存的机器,会分配 192MB 给 kdump。对我来说,完全不需要它在内核崩溃时生成用于调试的转储文件,去掉 crashkernel=xxx 这一段内容再执行 sudo update-grub,重启后可用内存增加到 1.82G。

还有,阿里云默认禁用了 Swap,这个配置的机器最好加上,也能减少内存用爆引发的死机。配好 Swap 后还需要修改 /etc/sysctl.conf 文件,注释或修改 vm.swappiness = 0 这一行,改完后重启系统或者通过 sudo sysctl vm.swappiness=60 让修改生效(60 是默认值,也可以改成其他)。

最后,既然是为了省钱,机器偶尔挂掉也能理解,建议再加个第三方监控,便于及时去后台重启。我一直在用 UptimeRobot 的监控服务,免费版就够用了。也可以用 Uptime Kuma 自己搭一套监控,不过切记要部署在其他机器上。

其他还有一些排版、样式、HTTP 配置上的变化,这里就不列举了。

本文链接:https://imququ.com/post/recent-changes-to-my-blog.html参与评论 »

--EOF--

Comments

Waline 评论加载中...