上次更新网站架构 是17年6月的事情了，如果你对 SSG 选型感兴趣，可以看看。

为什么做调整

在使用纯粹 Markdown 格式文档来替换动态程序+富文本模式后，实际维护体验还是很棒的：

TLDR;

  • 继续使用容器化装箱交付方式，但是数据完全抽离，容器无状态。
  • 网站之间的隔离性更好了，使用数据安全性也更好了。
  • 技术栈减少，趋同，维护成本降低。

具体变化

  • 简化掉 WordPress + HHVM + MySQL
    • 首先可以规避掉许多安全升级问题和性能问题；
    • 其次文章数据源趋于一致，未来可以更好的进行分析和处理、以及方便对接各种其他的系统（如果想玩的话）；
    • 再者数据同步、站点重建也变的简单起来；
    • 最后对机器资源的需求也降低了不少。
  • 数据应用分离，进一步简化 Docker 镜像
    • 原本在不使用外部镜像仓库的情况下，镜像同步依赖导出tarball，等同带着系统完全更新，数据分离之后，基础镜像环境只在第一次进行同步，数据使用 多 remote origin 进行同步；
    • 更新速度变的更加的快速，尤其避免了频繁改动时，大量数据跨地区机房进行同步的问题。
  • 添加 traefik 作为服务发现网关
    • 本地开发调整变的十分容易，可以完美模拟外网应用服务；
    • 服务器不再需要 hard code 代码，不需要使用多套编排策略来应对国内外主机上运行不同网站的情况；
    • 除了更新网站证书外，添加删除网站时，不需要再重启 Gateway；
    • 相比之前可以更加容易地进行弹性扩展。
  • 配合 DataBridge 工具使用
    • 原来 WordPress 有价值的路由、标签、页面、媒体进行了全面的兼容；
    • 编写使用纯粹无 Meta Data 的 Markdown文件，描述代码的时候，使用简单的代码标签，呈现时却能使用定制的代码高亮插件，并且支持用户查看编写时的 Markdown 文件；
    • 大量文档存在的时候，支持使用日期文件夹进行分类管理，大幅提升可维护性（试想一个文件夹里有很多篇文章，某团队技术博客就是这么维护的）。
    • 相对完善的日期归档生成。

接下来的计划

  • 挑选外网使用的代码仓库+轻量CI方案，维护更新更进一步。
    • 之前有使用lua做过一个 openresty 的 Web Hook，如果找不到合适的方案，配合 docker-compose 也可以用一阵。
    • 全部搞定之后，就可以去除 GH私仓的服务依赖了。
  • 对数据进行细节处理。
    • 让数据更安全，可用性更高。
    • 博客历史技术文章去水。
  • DataBridge 优化，后续可以考虑开源，为想简化网站架构的同学提供一些思路。

先写到这里，后面想到什么再更新吧。

–EOF