想起上一次大张阔斧重写网站是刚刚工作的时候了，之后使用Tengine + Redis + HHVM + WordPress个人修改版这个架构一用就是三年多。这阵得闲思考喵生，做个人Review，出于可维护性的角度，选择配合使用Hugo将网站重写掉。

虽说这个事情是这阵执行的，但是战线或许得回到2015年，感兴趣可以参看站点的里程碑。

最近网站可能会有打不开的链接，欢迎反馈～

为何改变

WP复杂性越来越高，虽然之前使用的插件增强+各种入口点hack+各种级别的Cache的方式可以继续让网站愉快的Run下去，但是潜在的问题也越来越多：

  • 需要消耗更多的精力去关注相关安全漏洞，Openresty、HHVM、Redis、MySQL、WP和它的插件们…
  • 需要去关心运维事宜（多节点，多机房存活）。
  • 不能很好的使用Markdown格式作为更新和维护内容的主要格式。
  • 而且因为应用每个级别都使用了缓存，还牵扯到多机的问题，缓存的一些问题需要被关心。

这里面最关键的问题是文章更新和站点运维的问题：

更新文章需要先使用MD编写，然后将输出片段粘到WP的纯文本编辑器内，再进行发布，发布后要清除并重新预热一遍和文章相关的缓存们: 标签、分类、搜索、首页、Feed等等…

  • 文章还是不能很好的使用Markdown来编写和更新，除非去完善WP的MD编辑器，或者使用特定的桌面客户端

在站点经历了若干次服务器小问题在不同机器上来回迁移之后（Raid卡电池鼓包、插座松动、迁移机房），我使用Docker Compose封装了几个不同版本的镜像，来简化每次升级需要人肉各种执行各种初始化脚本的问题，但是在使用这套方案一阵子之后，我发现这只是将部署和测试阶段的麻烦事解决了而已。

  • 部署的问题可以使用Docker来做，但是不应该做这两件事:
    • 做fat container，官方不推崇，这个使用方式和VM别无二致，除了显示声明依赖之外。
    • 构建特别复杂的依赖服务（我这里涉及多个不同架构的站点，所以搞起来更蛋疼了）

思考了一下个人的核心诉求：

  • 性能好，可以让网站打开的更快。
  • 可以低开发成本支持多节点部署，包括配置HTTPS、数据库切换（可以干掉）等。
  • 支持Markdown书写，支持按照年月日归档文章，随时随地编写。
  • 代码高亮要好看。

但是在使用了八年WP做为主力站点之后，Ghost、Hexo、Hugo这类SSG工具何其的便利性相差甚远，且目前看来每一家都有一定的硬伤，文章管理、文章归档、文章搜索、代码高亮…

所以如果要使用SSG工具来完成站点的搭建，并向WP看齐的话，需要做一些额外开发了。

选型阶段

在16年3月的一个漆黑的夜晚，我开始了wp2md的编写，最开始只是为了将个人网站里奇奇怪怪的文章内容都转化为ghost支持的文章，所以选择了wordpress-ghost-export，但是在使用之后发现：

  • 工具输出中文会出现截断现象，导致乱码
  • 工具丢弃的文章信息太多了，可以类比图片有损压缩，这个不能忍
  • Ghost、Hexo、Hugo这类SSG工具要求的文章格式需要额外的meta，但是这个内容并不需要，也不适合和文章管理在一起。

于是在修正了一些原始工具的bug之后，使用node.js做了一个cli工具，来完善导出内容的管理，期望能够做到：导出的数据不被任何一种SSG约束，可以自由的在不同工具中迁移。

目前来看，做的还不错。

Ghost的落选

使用Ghost有两个比较尴尬的点：

  • Ghost对于文章管理太孱弱了。
  • 各种功能，除了修改template helper外，还得给官方的程序打patch。（诸如要实现个CDN支持）
  • 缺乏分类机制和定制页面路由的能力，需要继续魔改代码了。

在折腾了一阵，留下了一个好看的主题之后，不想重蹈之前偶尔合并自己修改代码和官方代码的WP的覆辙，我选择放弃Ghost，追求更简单轻便的方案。

Hexo的落选

对于几十篇到上百篇的站点，Hexo是优选，但是对于1000篇文章的站点，Hexo的性能问题就比较严重了，之前在官方issue反馈过问题，也给出了解决方案：

  • 延迟生成，分批生成。
  • 添加Node使用的内存上限。

在某团和某云的内外部站点使用Hexo进行尝试之后，我选择留下了一个hexo-extend-plugin插件弃坑：

  • Hexo、Node、Npm、Deps都在升级，在Hexo不提供更完善的插件机制的情况下，做Hexo和它插件的增补工具，调试比较费时间，之前甚至做了不同版本，不同hash的文件补丁方案。
  • Server Mode也好，Generator Mode也好，性能实在是不敢恭维，Hexo使用的Box Model的无限继承模式如果不修改，那么这个问题是不会得到有效解决的。

Hugo的胜出

性能怪兽

前面提到性能的问题，同样的数据源（1000篇内容），Hugo不论是使用Server Mode还是Generator Mode都完胜前面的几位。（静态编译的应用优势太大了）

目录管理

除了性能的考虑外，对于文章管理来看，去掉DB依赖，如果遵守一定目录规范来进行文档存储，那么对于文档管理的成本来说差异不大。

Hugo支持直接将目录结构的内容映射为最终生产环节的结构，只要你添加index.slug文件即可，一般这个后缀会是.md。相比较Hexo、Ghost方便许多。

数据库和部署

如果你对全文索引的查询服务不是强依赖、也不需要多机远程连同一数据中心的话，使用DB的意义也不一定比使用文件存储来的高效方便，毕竟一般频率的同步／备份文件操作，使用各种sync软件，各种版本控制工具，接近零成本。

文档归档

这三款软件都需要定制才能实现根据年份／月度的归档呈现，不过因为Hugo的目录管理的特点，实现文档存档的成本是最低的。

代码高亮

很遗憾的是，这三款软件的代码高亮都比较渣。在不考虑使用前端脚本进行代码高亮的情况下。（性能不佳）

服务端渲染的话，Hugo需要联动外部软件来进行代码高亮，Hexo需要安装插件。

但是我们可以利用docker的封装一切的特性+crayon这个称霸WP的程序+Markdown原生支持HTML片段来完成这个事情。（效果如本站）

接下来

接下来除了把剩下没转换完的文章转换掉，还要做什么呢？

  • 做自动化发布／回滚／监控，类似之前的farbox这类的SAAS。
  • Hugo转换生成的文章的继续优化。

先写到这里吧。

-eof- 晓白（或许这个昵称可能不会使用太久了吧）