本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 [署名 4.0 国际 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/deed.zh) 本文作者: 苏洋 创建时间: 2017年06月28日 统计字数: 2817字 阅读时间: 6分钟阅读 本文链接: https://soulteary.com/2017/06/28/welcome-to-hugo.html ----- # 使用 Hugo 重建站点 想起上一次大张阔斧重写网站是刚刚工作的时候了，之后使用`Tengine + Redis + HHVM + WordPress个人修改版`这个架构一用就是三年多。这阵得闲思考喵生，做个人Review，出于可维护性的角度，选择配合使用Hugo将网站重写掉。 虽说这个事情是这阵执行的，但是战线或许得回到2015年，感兴趣可以参看站点的[里程碑](https://soulteary.com/about-site/)。 **最近网站可能会有打不开的链接，欢迎反馈～** ## 为何改变 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](https://github.com/soulteary/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](https://github.com/soulteary/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- 晓白（或许这个昵称可能不会使用太久了吧）