自 2010 年建了这个博客以来，我曾经对它的技术方案折腾过很多次，尤其是最近几年，它基本成了我学习和实践 Web 技术的一个实验平台，每当我决定学习一种新的 Web 技术时，只要情况允许，我就会在这个博客系统上进行测试。

下面是目前这个博客的一些技术细节。

系统架构

目前，这个博客的系统架构如下图所示：

系统使用 Docker 部署，并运行在 K3s 上。

可以看到，后台使用了 Django，前台则使用 Next.js 渲染页面。目前，我基本将 Django 当一个 Headless CMS 系统在用，完全放弃了它的模板系统，所有 HTML 输出都用 Next.js 生成。

为什么用 Next.js

为什么不直接用 Django 生成 HTML 内容呢？主要是随着 Web 尤其是前端技术的发展，我发现使用 React/Vue 等技术来生成前端页面更灵活且更容易维护，当然，如果直接用 React/Vue 生成页面，对搜索引擎将不是很友好，因此支持服务端渲染的 Next.js 等技术就是自然的选择了。

使用 Next.js 之后，前后端之间的职责就更加清晰了，后端只需要提供 API，所有页面渲染部分都由前端完成。

为什么用 Django

使用 Django 主要有这么几个原因：

1. 自带 ORM 以及数据库模型迁移
2. 自带管理后台
3. 有 Celery 等成熟的任务队列工具
4. 支持自定义命令行命令

其中 1 目前并不算稀奇了，比如 Node.js 的 Prisma 就是一个强大的带数据模型迁移的 ORM 框架。不过 Django 在这儿仍然有优势，就是它的 ORM 和框架集成度非常高，写起来更顺畅一些，当然，这一点上仁者见仁，智者见智，也许有人更喜欢使用第三方的 ORM 自行组合，因为那样在细节上更加可控。

关于第 2 点自带管理后台，Django 的后台不能算很优秀，但基本够用，你想做的各种操作都能实现，只是一些操作可能会比较麻烦。它的主要缺点是视图是基于数据模型（表）实现的，如果你想实现一些复杂的比如跨表查询的视图可能很难做到。当然，如果要求不高，那么完全可以使用 Django 这个管理后台，这会为你节省不少开发时间。

目前 Node.js 领域，也有一些流行的 Headless CMS，比如 strapi、PayloadCMS 等，这些方案也提供了管理后台，且看起来更为现代化，如果你专注于 JavaScript 技术栈，可以试一试这些方案。

关于第 3 点任务队列，则主要是为了方便执行一些异步任务。比如当有用户给我留言，或者提交了新评论时，博客系统会给我发一封通知邮件，为了不影响用户体验，发邮件这个操作我希望异步进行，以免阻塞页面加载，对 Django 框架来说，Celery + RabbitMQ 的组合是一个流行的解决方案。

当然，Node.js 框架天然支持异步任务，因此如果只是发送邮件通知等场景，其实完全可以不用 Celery 等方案，直接用 Node.js 的异步来实现即可。但考虑一些复杂的场景，比如某个操作不是给管理员一个人发邮件，而是给一批人发邮件（比如某个热门文章有新回复时，需要邮件通知所有订阅了或回复了这篇文章的用户），或者要异步批量更新大量的数据，怎么保证这些操作都能正确执行，并且不会在短时间突然给服务器增加太大的负载呢？这就是 RabbitMQ 等消息队列的用武之地了。

关于第 4 点自定义命令，则主要是有时需要临时或定期地执行一些耗时的操作，这些操作用命令行执行显然会比较方便，比如在 Django 中，如果要临时执行一些查询或者任务，可以用 python manage.py shell 进入交互控制台，也可以像这样执行自定义的命令：

python manage.py my_custom_command

在这个控制台或者命令行中，可以完整地访问 Django 项目中定义的各个模型，自然也可以通过这些模型操作对应的数据。对一个真实的站点项目来说，可能经常会需要做一些数据整理的工作，比如清除一些无用的老数据，进行一些数据统计等等，如果能通过命令行调用自定义命令，执行这些任务无疑会方便很多。

小结

这个博客的技术方案经历了多次折腾，并且作为一个实验田，预计它将来会经历更多的折腾。🙂

目前它使用的是 Django（后台）+ Next.js（前台）的组合，其中 Django 只提供 API，类似 Headless CMS。

Django 是一个优秀的框架，已经发展了 16 年，非常稳定和强大，足以满足大部分建站需求。