一、背景
之前的Blog使用的Typecho程序,由于是PHP+MYSQL的架构,所以需要一台ECS或者虚拟主机去运行。最初通过阿里云的学生政策,以低价购买了一台2H4G的ECS服务器,等到服务器到期时发现续费价格涨了6倍,无奈放弃了续费,开始了Blog断开连接的6个月。
最初是通过朋友的Blog了解到Jekyll、Hexo等静态Blog框架,最后也是经过各种调研选择了Hexo,Hexo是一款简洁且快速的Nodejs版Blog程序,它的开放式API允许在程序的各个生命周期里注册钩子函数,随意编写各种自定义功能。其最大的两个特点是:支持markdown语法、支持静态站点生成。这两个特点将支持Blog从Typecho以几乎无损的状态迁移至Hexo,同时能够极大的降低Blog的运行成本!
二、架构对比
![]()
相比于Typecho的php+mysql环境,Hexo程序运行在nodeJs上,数据则存储在_posts/*.md
、_config.yml
、db.json
中,运行和维护更加简单。还支持通过hexo generate
命令生成一个静态站点,完全可以单独部署到OSS上。
三、成本分析
3.1 支出成本
因为Typecho必须部署在php+mysql环境,则只能通过虚拟主机
或ECS
部署,这里以阿里云最便宜的机子来举例:
(1) ECS:714/年(阿里云 1vCPU 1GB内存 1M带宽 40G硬盘)
(2) 虚拟主机:500/年(阿里云虚拟主机 独享基础版 5M带宽 5G硬盘 200G流量)
Hexo通过生成静态站点后,可以仅通过对象存储就能搭建静态站点访问。优点是根据实际流量计费,如果月访问量很低,一个月只需要几毛钱。(以我的测试环境计算,一个月仅0.14元)缺点是如果网站被DDOS,则流量费用需要自行承担。在正常情况下相较于Typecho对比,Hexo的成本降低超过99%。
3.2 运维成本
需要自己编写Shell脚本备份相关数据,如果用了BT面板等第三方工具,则可以通过插件自动备份。
(1) node程序:通过远程Git存储代码库进行备份
(2) 静态站点:通过OSS的跨区域复制,可以定时备份网站数据。
3.3 安全成本
需要做好安全防护、WAF防火墙等处理,防止被人攻击、挂马、恶意破坏。
纯静态站点,除非被人破解截获阿里云账号或AccessToken,否则几乎无法破坏。
四、数据转换
4.1 开源转换器
网上有一些这样的开源转换器,因为需要提供一些数据库敏感信息,感觉并不是很靠谱。
![]()
![]()
在Hexo官网看到了这个插件,才发现原来可以通过Rss提取文章HTML结构,之后再反向转换生成markdown结构的文章。感觉有点东西,赶紧试了试,导出了10篇文章后挨个看了下转换效果,很棒!
但还是有2个缺点:
- 不支持下载文章中的图片,仅创建了空文件夹。(因为这次迁移是换域名了,之前的域名不打算续费了,也就导致后续会导致文章图片加载失败)
- Hexo的摘要是通过
<!--more-->
标签控制的,如果不插入more标签则会全文输出。
那没办法了,不过有了 Rss -> HTML -> Markdown 的思路,可以尝试自己写一个。
4.3 自行编写
经过一段时间的鼓捣,最后也成功编写了Typecho迁移器,支持拉取及替换文章中的图片,并自动修改图片引用信息。大体思路是通过cheerio提取img元素,然后下载替换,伪代码如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
| const $ = cheerio.load('html code')
$('img').map(function (index) { let imgSrc = $(this).attr('src')
$(this).attr('src', newFileName) })
Post.create($('body').html())
|
自动插入<!--more-->
测试了很久也无法实现,因为turndown转换markdown时会自动过滤注释标签。也尝试过 截取转换前2段 + more标签 + 截取转换后面的段落 的方式,在某些场景时展示的markdown样式会与原文不一致,最后是通过手动给文章插入<!--more-->
来解决的摘要问题。