读懂 C4 二级容器架构：Cloudflare、网关、队列与监控——Vibecoding 时别被 AI 牵着鼻子走

在 C4 模型中，第一级（系统上下文，System Context）只告诉你谁在使用系统、系统与谁通信。第二级——容器级（Container）——则深入内部：系统由哪些容器组成，它们之间如何通信。Facebook 页面 Code Web Không Khó 的这篇讲解，沿着这条轴线从外到内读一张真实的 Web 架构图：门口的 Cloudflare、按子域名分流的网关、带实时 API 与队列的后端、PostgreSQL – MinIO – Redis 数据层，以及一套完全运行在内网端口上的 Prometheus – Grafana – Loki 监控系统。读懂这张图，就等于读懂了整个系统——这也是与 AI 协作而不被 AI 牵着鼻子走的前提。

快速回答

• C4 第二级（容器级）把系统内部拆解成一个个容器——可独立运行的应用、服务与数据存储——并说明它们之间的通信方式；这是第一级（系统上下文：谁在用系统、系统连接哪些外部系统）之后的下一步。
• 示例架构中，请求的流向由外而内：互联网 → Cloudflare（拦截机器人与恶意请求，只开 HTTPS 443 端口，生产环境关闭 HTTP 80 端口）→ 内网 LAN → 网关（Nginx 或 Kong）作反向代理 → 内部各前端与服务 → 数据层 → 监控系统注视着一切。
• 网关按子域名分流：主域名进用户前端（User Frontend）；admin 子域名进管理前端（Admin Frontend）；app 子域名进应用（App）；外加一个独立的 Link Base 服务；以及一条专供 AI 与系统交互的 MCP 通道（经 mcp 子域名）。
• 后端由 API 加队列组成：API 用 Express + Socket 编写，处理实时需求（聊天、通知、订单状态即时更新——也可以换成 Go + Gin），BullMQ 队列（Queue）则把任务排队处理，避免大量用户同时涌入时服务器崩溃，也保证任务不丢失。
• 数据层与监控：PostgreSQL 存主要数据（用户、订单、产品）；MinIO 像自托管的 S3 一样存文件、图片、视频；Redis 做缓存。监控系统——Prometheus（量测性能）、Grafana（仪表盘）、Alertmanager（通过机器人报警）、Loki（收集日志）——运行在内网端口上，外界无法访问。

什么是 C4 第二级（容器级）？

C4 模型是一种以多个缩放级别绘制软件架构的方法。第一级——系统上下文——是最外层的视角：用户是谁、你的系统在哪里、它与哪些外部系统通信。第二级——容器级——则放大到你的系统内部：里面有哪些容器——每个容器是一个可独立运行的单元，如 Web 应用、API、数据库或后台服务——它们用什么方式、朝什么方向相互通信。

第二级的价值在于直观：一眼看图就能构想整个系统——请求从哪里进来、在哪里分叉、数据存在哪里、哪一部分在监视哪一部分。据原作者说，这也是在 vibecoding 时代与 AI 协作的基础：能读懂架构的人才能掌控系统，而不是任由 AI 自己画、自己决定。

如何从外到内读这张架构图？

这篇讲解沿着一个请求的实际路径，分七个环节来读：

环节	组件	在示例架构中的角色
1. 互联网大门	Cloudflare	第一道「城墙」：从外部拦截机器人与恶意请求，不让流量直达服务器；请求经 HTTPS 443 端口进入，生产环境彻底关闭 HTTP 80 端口
2. 内部网络	LAN（图中白色框）	所有内部服务都通过这张局域网互相通信，外人无法干预——用作者的话说，这是系统最坚固的一堵墙
3. 守门人	网关——Nginx（或 Kong）	反向代理，按子域名把请求分发到正确的内部服务
4. 后端	API（Express + Socket）+ 队列（BullMQ）	API 处理业务与实时需求；队列把任务排队，让系统在流量突增时不崩溃、不丢活
5. 数据层	PostgreSQL + MinIO + Redis	主要数据、文件/图片/视频与缓存——后端的一切操作都存到这一层
6. 监控	Prometheus + Grafana + Alertmanager + Loki	量测性能、绘制仪表盘、报警与收集日志；运行在内网端口，外界进不来
7. 对外输出	Discord / Google Drive / 备份	通知推送到外部平台；数据与备份被推出服务器，服务器倒了数据还在

网关如何按子域名分流？

经过 Cloudflare 后，所有请求都到达网关——示例架构中用的是 Nginx，作者表示也可以用 Kong 替代。网关承担反向代理的职责，按子域名把请求路由到正确的内部服务：

• 主域名 → 用户前端（User Frontend），最终用户到达的地方。
• admin 子域名 → 管理前端（Admin Frontend）。
• app 子域名 → 应用（App）。
• Link Base → 一个独立服务。
• mcp 子域名 → 专供 AI 的 MCP 通道，让 AI 能与系统交互。

据作者说，MCP（Model Context Protocol）是一个值得关注的趋势：在第二级架构图里就为 AI 预留一个容器和一条专属入口，说明这个系统在设计时就假定 AI 是系统的一个特殊「用户」，而不是事后外挂的附加件。

后端里有什么：实时 API 与队列？

示例后端有两个主要部分。第一是用 Express + Socket 编写的 API：Socket 层服务于聊天、通知、订单状态即时更新等实时需求；作者也注明，如有需要可换成 Go + Gin。第二是使用 BullMQ 的队列（Queue）来处理任务队列。

作者用炸鸡店打比方：100 个人同时进店，就排队——先到先做，后到后做。队列按顺序处理多个任务，并有保证排队任务不丢失的技术。没有队列，100 个人同时涌入，服务器就崩了。这正是队列在二级架构图中单独成为一个容器、而不并入 API 的原因：它的角色、处理节奏和故障方式，与直接应答请求的那部分完全不同。

数据层由哪些部分组成？

后端的一切操作都存到由三个容器组成的数据/基础设施层：

• PostgreSQL：存主要数据——用户、订单、产品。
• MinIO：存文件、图片、视频——就像一个自托管的 S3。作者分享了一个技巧：用户请求一张图片时，请求经网关直达 MinIO，网关会把这张图片缓存下来；下次加载非常快，因为图片实际上已经变成缓存的静态内容。
• Redis：缓存——临时存放常用数据以便快速加载。

这种三分方式对应了数据的三种不同性质：需要完整性的关系型数据（PostgreSQL）、需要廉价且自主可控的对象存储的大文件（MinIO），以及需要速度的临时数据（Redis）。

监控系统是如何组织的？

示例架构中的监控运行在内网端口上——外界无法访问——由四个组件构成：

• Prometheus：直接接入 PostgreSQL、Redis、Node 等众多组件，量测性能。
• Grafana：绘制仪表盘，查看 CPU、内存、请求量等指标。
• Alertmanager：一旦出问题，就把通知推送到机器人，让运维人员立刻知道。（在作者的图 2 中，这一层还包括用于分布式追踪的 Tempo，Alertmanager 的警报通过 Telegram Bot API 推送。）
• Loki：收集系统的全部日志。作者强调的实际价值是：当用户报告了一个原因不明的错误时，你在 Loki 里搜索，让 AI 读那段日志本身——AI 就能找出 bug 并帮你修好。

这里值得学的一点是：监控被画成一层横向监视所有其他容器的层面，而不是后端的一个附属功能——而把它锁在内网之后，是这张架构图中有意为之的安全决策。

与 AI 协作时，如何让架构始终保持正确？

这是作者最想传达的信息。当你搭起这样一套架构后，下一个问题立刻出现：每天用提示词与 AI 协作时，怎样让这套架构始终保持更新、而不被 AI 随时间越画越乱？

作者分享的做法是：创建一个 Rules 文件夹，里面放整个项目的软件开发流程。之后 AI 在每一次工作会话中都会遵守这些 Rules——这就是作者让架构始终符合既定标准的方法，而不是让每一次 AI 会话都朝不同方向「重新发明」系统。 作者分享的截图展示了具体实现：项目命令系统中的一个自定义 /architecture-plan 命令，让 AI 以首席软件架构师（Principal Software Architect）的角色生成并更新正式架构文档 architecture.md，其中每条论断都必须有代码库中文件:行级别的证据——不猜、不编。换句话说：二级架构图给人全景，Rules 文件夹则是迫使 AI 同样尊重这幅全景的办法。

总结一下，示例架构闭合成这样一条链：用户 → Cloudflare（拦机器人）→ 网关 Nginx/Kong（按子域名分流）→ 用户/管理/App 前端 + MCP + API + 队列 → 数据层（PostgreSQL + MinIO + Redis）→ 监控（Prometheus + Grafana + Loki）监视一切，输出端则有备份与通知被推向外部（Discord、Google Drive、备份）。

常见问题

C4 第二级和第一级有什么区别？

第一级（系统上下文）从外部看系统：谁在使用它、它连接哪些外部系统。第二级（容器级）放大到这套系统内部：它由哪些容器组成（应用、API、数据库、队列……），以及这些容器之间如何通信。想理解一个请求如何在系统中穿行，你需要第二级。

为什么生产环境只开 443 端口、关闭 80 端口？

按作者的讲解，来自互联网的请求必须先经过 Cloudflare 拦截机器人与恶意请求，再经 HTTPS 443 端口进入系统。在生产环境中，HTTP 80 端口被彻底关闭，只留 443——也就是说，所有连接都必须是经过受保护大门的加密连接，不给攻击者留下未加密的侧门可探。

网关用 Nginx 还是 Kong 更好？

示例架构目前用 Nginx 作反向代理，作者表示用 Kong 也可以。网关在第二级中的核心角色，是按子域名把请求路由到内部正确的前端或服务（主域名 → 用户端，admin → 管理端，app → 应用端，mcp → AI 通道）。选 Nginx 还是 Kong 是实现层面的决定；架构上重要的是，系统只有一个清晰的入口，而不是每个服务各自暴露在互联网上。

队列（BullMQ）解决什么问题？

队列把任务排队，按先到先处理的顺序逐个执行，而不是逼服务器同时处理一切。用作者的比方：就像 100 位顾客同时进炸鸡店，排队让系统在流量突增时不崩溃，同时有技术保证排队中的任务不丢失。在 C4 二级图中，队列是一个独立容器，与直接应答请求的 API 分开。

Rules 文件夹如何防止 AI 把架构「画乱」？

据作者说，Rules 文件夹装着整个项目的软件开发流程。AI 工作时会遵守这些规则，于是已经设计好的架构能在多次提示词会话中保持一致，而不是每次都提出一套不同的结构。这是把架构「锁定」在流程层面的机制，与 C4 架构图互补——图帮人读懂和核查，Rules 帮 AI 从一开始就做对。

结语

读懂容器级（第二级）架构图，就等于在一张图里读懂整个系统：Cloudflare 大门、内网 LAN 边界、按子域名分流的网关、带实时 API 与防过载队列的后端、PostgreSQL – MinIO – Redis 三件套数据层，以及锁在内网端口后注视着一切的监控。在 vibecoding 时代，这张图的价值更大：它是对照 AI 所生成一切的「标准地图」。手握地图的人把 AI 当工具用；没有地图的人只会被 AI 牵着鼻子走——而 Rules 文件夹，正是作者把这张地图变成 AI 每天必须遵守的规矩的办法。

来源：Facebook 页面 Code Web Không Khó 于 2026 年 11 月 9 日发表的讲解帖，内容为如何阅读 C4 模型第二级（容器级）架构图，并附作者自己的系统图；由 Wotech Electronics 编辑整理。文中示例架构、技术选型与运维技巧均为作者的分享。插图：原帖附带照片。