Docker on JasperSao的博客

Go 项目反推：Feed 流系统实战——工程化

Wed, 29 Jul 2026 00:00:00 +0800

承接 Go 项目反推：Feed 流系统实战——SSE 实时推送与分片上传，这一篇回到工程全景，梳理 feedsystem_video_go 的容器编排、配置管理、性能分析、持续集成与本地启动流程。

Docker Compose（容器编排）

什么是 Docker Compose

把所有服务打包成容器，一键启动。

没有 Docker Compose：

手动启动MySQL → 手动启动Redis → 手动启动RabbitMQ → 手动启动Backend → 手动启动Worker → 手动启动Frontend
每次都要敲6条命令，还要记住启动顺序

有 Docker Compose：

docker compose up -d
一键启动所有服务

这个项目的 Docker Compose

services:
 mysql: # 数据库
 redis: # 缓存
 rabbitmq: # 消息队列
 backend: # API进程
 worker: # Worker进程
 frontend: # 前端

相关文件：~/dev/projects/feedsystem_video_go/docker-compose.yml

depends_on + healthcheck（保证启动顺序）

depends_on 是什么

告诉 Docker：某个服务依赖其他服务，要等依赖的服务启动后才能启动自己。

backend:
 depends_on:
 mysql:
 condition: service_healthy  # MySQL健康了才启动backend
 redis:
 condition: service_healthy  # Redis健康了才启动backend
 rabbitmq:
 condition: service_healthy  # RabbitMQ健康了才启动backend

healthcheck 是什么

判断服务是否"健康"（真正能接受连接）。

mysql:
 healthcheck:
 test: ["CMD-SHELL", "mysqladmin ping -h 127.0.0.1 -uroot -p123456"]
 interval: 5s  # 每5秒检查一次
 timeout: 5s  # 超时5秒
 retries: 20 # 重试20次

MySQL 启动后，每 5 秒 ping 一次，连续 ping 成功才算"健康"。

为什么要 healthcheck

没有healthcheck：
 MySQL容器启动了 → backend立刻启动
 但MySQL还没初始化完 → backend连接失败 → 崩溃

有healthcheck：
 MySQL容器启动了 → 等MySQL真正能接受连接 → backend再启动

所有服务的 healthcheck

服务	healthcheck 测试	作用
mysql	`mysqladmin ping`	确认 MySQL 能接受连接
redis	`redis-cli ping`	确认 Redis 能接受连接
rabbitmq	`rabbitmq-diagnostics ping`	确认 RabbitMQ 能接受连接
backend	`wget http://127.0.0.1:8080/healthz`	确认 API 进程正常
worker	`pgrep worker`	确认 Worker 进程存在
frontend	`wget http://127.0.0.1:80/`	确认前端能访问

配置管理（优先级）

配置文件位置

~/dev/projects/feedsystem_video_go/backend/configs/
├── config.yaml # 本地开发用（MySQL端口3306）
├── config.compose-local.yaml # Docker Compose本地用（MySQL端口3307）
└── config.docker.yaml # Docker部署用（容器内部通信）

三个配置文件的区别

文件	MySQL 端口	用途
config.yaml	3306	本地开发，MySQL 装在本机
config.compose-local.yaml	3307	Docker Compose，MySQL 容器映射到 3307
config.docker.yaml	3306	Docker 部署，容器内部通信

配置加载优先级

环境变量 > .env文件 > YAML文件

来源	举例	优先级
环境变量	`export MYSQL_DATABASE=feedsystem`	最高
.env 文件	`MYSQL_DATABASE=feedsystem`	中
YAML 文件	`database.dbname: feedsystem`	最低

为什么要这样设计

开发环境：
 用YAML文件，配置写死在代码里，方便开发

Docker部署：
 用环境变量覆盖，不用改配置文件

 docker run -e MYSQL_DATABASE=feedsystem -e JWT_SECRET=*** ...

环境变量覆盖的好处

场景	做法
本地开发	用 YAML 文件的默认配置
Docker 部署	用环境变量覆盖数据库地址、密码等
生产环境	用环境变量覆盖，敏感信息不写进代码

启动时指定配置文件

# 本地开发
cd backend && CONFIG_PATH=configs/config.yaml go run ./cmd

# Docker Compose本地
cd backend && CONFIG_PATH=configs/config.compose-local.yaml go run ./cmd

API 进程和 Worker 进程为什么要分开

两个进程

cmd/
├── main.go # API进程（处理HTTP请求）
└── worker/
 └── main.go # Worker进程（消费MQ消息）

各自做什么

	API 进程	Worker 进程
职责	处理 HTTP 请求	消费 MQ 消息
入口	`go run ./cmd`	`go run ./cmd/worker`
启动方式	接收 HTTP 请求	订阅 MQ 队列

为什么要分开

1. 职责不同

API进程：用户发请求 → 处理 → 返回响应（要求快）
Worker进程：从MQ取消息 → 更新DB、推送通知（可以慢）

2. 独立扩展

场景：API扛不住了

没分开：只能整体加机器
分开后：只加API机器，Worker不动

场景：Worker扛不住了

分开后：只加Worker机器，API不动

3. 故障隔离

Worker崩了：不影响API，用户还能正常访问
API崩了：不影响Worker，后台任务还在处理

4. 资源分配不同

API进程：需要低延迟，分配更多CPU
Worker进程：可以容忍高延迟，分配更多内存

Docker Compose 里的配置

backend:
 build:
 dockerfile: backend/Dockerfile
 target: api  # 构建API镜像

worker:
 build:
 dockerfile: backend/Dockerfile
 target: worker  # 构建Worker镜像

同一个 Dockerfile，用不同的 target 构建两个镜像。

pprof（性能分析）

pprof 是什么

Go 内置的性能分析工具，帮你找出程序哪里慢、哪里吃内存。

能分析什么

类型	作用
CPU	哪个函数最耗 CPU
内存	哪个函数最耗内存
goroutine	有没有 goroutine 泄漏
阻塞	哪里卡住了

配置

observability:
 pprof:
 enabled: true
 api_addr: localhost:6060  # API进程的pprof端口
 worker_addr: localhost:6061  # Worker进程的pprof端口

启动后，访问 http://localhost:6060/debug/pprof/ 就能看到性能数据。

常用命令

# CPU分析（30秒）
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

# 内存分析
go tool pprof http://localhost:6060/debug/pprof/heap

# goroutine分析
go tool pprof http://localhost:6060/debug/pprof/goroutine

场景举例

用户反馈：API响应慢

1. 用pprof抓CPU分析
2. 发现某个函数占了80%的CPU时间
3. 优化这个函数
4. 响应变快了

CI 流程（持续集成）

CI 是什么

代码推送到 GitHub 后，自动运行检查，确保代码质量。

这个项目的 CI

# .github/workflows/ci.yml
jobs:
 test:
 steps:
 - go vet ./...  # 静态检查
 - go test -race ./...  # 运行测试，检测数据竞争

go vet 是什么

静态分析，找出语法错误和可疑代码，不需要运行程序。

举例：
- 变量声明了但没用
- 格式化字符串参数不对
- 死代码（永远不会执行的代码）

go test -race 是什么

运行测试，同时检测数据竞争。

什么是数据竞争

多个 goroutine 同时读写同一个变量，没有加锁。

// 数据竞争的例子
var count int

go func() { count++ }() // goroutine1写
go func() { count++ }() // goroutine2写

// 两个goroutine同时写count，结果不确定

-race 怎么检测

go test -race ./...

如果发现数据竞争：
 WARNING: DATA RACE
 Write by goroutine 1
 Read by goroutine 2
 ...
 FAIL

CI 流程

开发者推送代码到GitHub
 ↓
GitHub Actions自动触发
 ↓
go vet ./... → 静态检查
 ↓
go test -race ./... → 运行测试 + 检测数据竞争
 ↓
全部通过 → 绿色 ✅
有失败 → 红色 ❌，不允许合并

好处

	没有 CI	有 CI
代码质量	靠人工 review	自动检查
数据竞争	上线后才发现	提交时就发现
合并代码	随便合并	检查通过才能合并

启动脚本（start.sh）

一键启动所有服务

./start.sh

相关文件：~/dev/projects/feedsystem_video_go/start.sh

脚本是什么语言写的

Bash（Shell 脚本），文件扩展名 .sh = Shell 脚本。

#!/usr/bin/env bash # 声明用bash解释器
set -euo pipefail # 遇到错误立刻停止

Bash 是 Linux/macOS 终端的脚本语言，用来自动化命令行操作。

脚本做的事

1. 启动Redis（如果没有运行）
2. 启动RabbitMQ（通过Docker Compose）
3. 启动Backend（go run ./cmd）
4. 启动Worker（go run ./cmd/worker）
5. 启动Frontend（npm run dev）
6. Ctrl+C停止所有服务

核心逻辑

# 启动Redis
start_redis() {
 redis-server --bind 127.0.0.1 --port 6379
}

# 启动RabbitMQ（通过Docker Compose）
start_rabbitmq_compose() {
 docker compose up -d rabbitmq
}

# 启动Backend
start_backend_bg() {
 cd backend && go run ./cmd &
}

# 启动Worker
start_worker_bg() {
 cd backend && go run ./cmd/worker &
}

# 启动Frontend
start_frontend_bg() {
 cd frontend && npm run dev &
}

# Ctrl+C停止所有服务
trap cleanup INT TERM EXIT
cleanup() {
 kill $BACKEND_PID
 kill $WORKER_PID
 kill $FRONTEND_PID
 docker compose stop
}

环境变量控制

START_REDIS=1 # 是否启动Redis
START_RABBITMQ=1 # 是否启动RabbitMQ
START_BACKEND=1 # 是否启动Backend
START_WORKER=1 # 是否启动Worker
START_FRONTEND=1 # 是否启动Frontend

可以按需启动：

# 只启动Backend和Worker
START_FRONTEND=0 ./start.sh

面试要点总结

Q: Docker Compose 怎么保证启动顺序？

A: depends_on + healthcheck，服务健康了才启动下一个。

Q: 配置优先级？

A: 环境变量 > .env 文件 > YAML 文件。

Q: API 和 Worker 为什么要分开？

A: 职责不同、独立扩展、故障隔离、资源分配不同。

Q: pprof 能分析什么？

A: CPU、内存、goroutine、阻塞。

Q: CI 做了什么？

A: go vet 静态检查 + go test -race 检测数据竞争。

Q: 什么是数据竞争？

A: 多个 goroutine 同时读写同一个变量，没有加锁。用 go test -race 检测。

Q: 为什么要用 healthcheck？

A: 确保服务真正能接受连接，而不是只启动了容器。

Go 项目反推：Feed 流系统实战——从 Docker 到开源贡献

Sun, 19 Jul 2026 00:00:00 +0800

承接 Go 语言基础：从变量到指针、Go 语言进阶：方法、接口与错误处理、Go 语言工程化：模块管理与项目结构、Go 语言并发：从 Goroutine 到 Worker Pool 和 Go Web 开发：从 net-http 到 Gin，这一篇跳出语法学习，反推一个真实的开源项目——feedsystem_video_go（279 star，Go + Vue 3 短视频 Feed 流系统），从跑通项目到提交 PR，走一遍完整的工程实战。

项目概览

这个项目是一个短视频 Feed 流系统，技术栈：

后端：Go + Gin + GORM + RabbitMQ + Redis
前端：Vue 3 + TypeScript
基础设施：Docker Compose 编排 MySQL、Redis、RabbitMQ

核心功能包括用户注册登录、视频发布、点赞评论、关注取关、Feed 流推送。架构上采用 API + Worker 的消息队列模式。

Docker Compose：启动基础设施

项目的三个"帮手"——MySQL、Redis、RabbitMQ——通过 Docker Compose 一键启动：

cd ~/dev/projects/feedsystem_video_go
docker compose up -d mysql redis rabbitmq

docker compose up — 根据 docker-compose.yml 启动服务
-d — 后台运行（detach），不占终端窗口
mysql redis rabbitmq — 只启动这三个，不启动 backend/worker/frontend

镜像 vs 容器

Docker 里有两个核心概念：

镜像 = 打包好的集装箱（里面有程序 + 配置），是静态文件
容器 = 集装箱正在运行的实例

类比：.app 文件是镜像，双击打开后正在运行就是容器。

端口映射

MySQL 默认端口 3306，但本机可能已经装了 MySQL 占用了 3306。所以 docker-compose.yml 里写的是：

ports: "3307:3306"

意思是：外部访问 3307 → 转发到容器内部的 3306。就像你家门牌号是 3307，但内部房间编号是 3306。项目配置文件里写的也是 3307，Go 程序连接 MySQL 时用的就是 3307。

通过 docker compose ps 可以查看所有容器的运行状态：

NAME IMAGE STATUS PORTS
feedsystem_video_go-mysql-1 mysql:8.0 Up 5 minutes (healthy) 0.0.0.0:3307->3306/tcp
feedsystem_video_go-redis-1 redis:7-alpine Up 5 minutes (healthy) 0.0.0.0:6379->6379/tcp
feedsystem_video_go-rabbitmq-1 rabbitmq:3 Up 5 minutes (healthy) 0.0.0.0:5672->5672/tcp

0.0.0.0 表示"接受任何来源的连接"，即对外部开放。

启动 Go 后端

基础设施就位后，启动后端：

cd backend
CONFIG_PATH=configs/config.compose-local.yaml go run ./cmd

CONFIG_PATH=... — 告诉程序用哪个配置文件（里面写好了 MySQL 3307、Redis 6379、RabbitMQ 5672 的地址）
go run ./cmd — 编译并运行 cmd/main.go 入口程序

日志解读

启动后会看到几段日志：

第一段：依赖下载

go: downloading github.com/gin-gonic/gin v1.11.0
go: downloading gorm.io/gorm v1.31.1

Go 在下载第三方库，类似 npm install，下载一次以后就不需要了。

第二段：连接建立

Loading config from configs/config.compose-local.yaml
Redis connected (cache enabled)
RabbitMQ connected

注意没有 “MySQL connected”，因为 GORM 连接 MySQL 是在后面 AutoMigrate 时才真正连接。

第三段：Gin 路由注册

[GIN-debug] GET /healthz
[GIN-debug] POST /account/register
[GIN-debug] POST /account/login
[GIN-debug] POST /video/publish
[GIN-debug] POST /like/like
[GIN-debug] POST /feed/listLatest

格式是 HTTP方法路由路径，后面的 (4 handlers) 表示这条路由经过几个中间件（如限流 + JWT 鉴权 + 业务处理）。

第四段：消息队列

DLX ready: exchange=dlx.events queue=like.events.dlx
Timeline consumer 已启动, queue=video.timeline.update.queue

DLX = Dead Letter Exchange（死信队列），专门处理失败的消息。

第五段：启动完成

Server is running on port 8080

为什么不把 Go 也放进 Docker？

Docker 适合最终部署，不适合日常开发调试。本地直接 go run 的好处：

日志直接打印在终端，实时可见
改了代码立刻能跑，不用重新打包镜像
出错了能直接看到报错信息

日志不是中间件

日志是 Go 标准库 log 包写出来的，是程序员手动写的"程序进行到哪一步了"的提示。中间件是处理请求的"关卡"，两者没有关系。

核心概念：缓存与消息队列

Redis 缓存

缓存 = 把经常用的数据放在"取用更快的地方"。

类比：冰箱里有水（MySQL，容量大但取用慢），你拿了一瓶放在桌上（Redis 缓存，取用极快），下次喝水直接从桌上拿，不用再去冰箱。

代码里 cache enabled 表示数据会先从 Redis 取，取不到再去 MySQL。

RabbitMQ 消息队列

消息队列是 API 和 Worker 之间的"传话筒"。API 处理完核心逻辑后，把"后续要做的事"发到队列，Worker 从队列里取任务执行。

前后端分离架构

后端和前端是两个完全不同的程序：

后端：Go 写的，负责业务逻辑、读写数据库，监听 8080 端口
前端：Vue 写的，负责页面展示、用户交互，监听 5173 端口

它们通过 HTTP 请求通信：用户在浏览器点"登录" → 前端发请求到 localhost:8080/account/login → 后端处理 → 返回结果 → 前端展示。

就像餐厅里厨房（后端）和前厅（前端）是两个地方，前厅接到顾客点单传给厨房，厨房做完菜传给前厅。

前端用 npm（Node Package Manager）管理依赖，跟 Go 的 go get、Python 的 pip install 是同一个道理：

cd frontend
npm install # 下载依赖
npm run dev # 启动开发服务器

Worker 进程模式

这是整个项目最核心的架构设计。Worker 是一个独立进程，和 API 分开启动：

cd backend
CONFIG_PATH=configs/config.compose-local.yaml go run ./cmd/worker

为什么要分开？

想象一个外卖平台：

方案 A：一个人又要接单又要送餐 — 接单时有新订单没人接，送餐时又有新订单没人接，效率低。

方案 B：两个人分工 — 前台专门接单（API），骑手专门送餐（Worker），前台接完单把订单放进"待送餐队列"（RabbitMQ），骑手从队列里取订单去送。

对应到项目：

角色	职责
API 进程	接收用户请求（点赞、评论、发布视频），处理核心业务逻辑，把"后续要做的事"发到消息队列
Worker 进程	监听消息队列，处理异步任务：更新点赞数、计算热度、推送通知

这个项目有四个 Worker：

LikeWorker — 处理点赞/取消点赞事件
PopularityWorker — 更新视频热度
SocialWorker — 处理关注/取关事件
CommentWorker — 处理评论事件

分开的好处

性能：用户点赞时，API 只需要返回"点赞成功"，不需要等热度计算完成
独立伸缩：请求量大时启动多个 API 进程，任务多时启动多个 Worker 进程
故障隔离：Worker 挂了 API 还能正常接收请求，API 挂了 Worker 还能把队列里的任务处理完

一句话总结：API 是"接单的"，Worker 是"干活的"，通过消息队列解耦。

开源贡献实战：修复 JWT 密钥缓存 Bug

跑通项目后，在实际使用中发现了一个真实 Bug。

问题复现

不设置 JWT_SECRET 环境变量，启动后端
注册一个账号
登录成功（页面提示"登录成功"）
但左侧栏仍然显示"未登录"
浏览器控制台报错：invalid or expired token (401)

登录本身成功，但所有需要鉴权的接口全部返回 401。

根因定位

文件：backend/internal/auth/jwt.go

func jwtSecret() []byte {
 secret := os.Getenv("JWT_SECRET")
 if secret == "" {
 b := make([]byte, 32)
 rand.Read(b)
 secret = hex.EncodeToString(b)
 }
 return []byte(secret)
}

问题出在这个函数每次调用都生成一个新的随机密钥：

登录时：GenerateToken() 调用 jwtSecret() → 拿到密钥 A → 用 A 签名 token
验证时：ParseToken() 调用 jwtSecret() → 拿到密钥 B → 用 B 验证
A ≠ B → 签名不匹配 → 返回 401

修复方案

用包级别的变量缓存密钥，保证每个进程只生成一次：

var cachedSecret []byte

func jwtSecret() []byte {
 if cachedSecret != nil {
 return cachedSecret
 }
 secret := os.Getenv("JWT_SECRET")
 if secret == "" {
 b := make([]byte, 32)
 if _, err := rand.Read(b); err != nil {
 log.Printf("FATAL: cannot generate JWT secret: %v", err)
 cachedSecret = []byte("fallback-unsafe-key-change-me")
 return cachedSecret
 }
 secret = hex.EncodeToString(b)
 log.Printf("WARNING: JWT_SECRET not set, generated random key.")
 }
 cachedSecret = []byte(secret)
 return cachedSecret
}

修复方案兼顾安全性（缓存保证签名一致）和灵活性（仍然允许随机密钥兜底）。

走通开源贡献流程

步骤	内容
1. 本地复现	按步骤触发 Bug
2. 阅读源码	从前端 → API → JWT 中间件，定位根因
3. 提 Issue	描述问题，附带复现步骤 → #15
4. Fork + 修复分支	`fix/jwt-secret-caching`
5. 提 PR	关联 Issue → #16

面试话术

在一个 279 star 的开源项目中发现了真实 bug
从前端（Vue/TypeScript）追踪到 API（Gin/Go）再到 JWT 鉴权中间件，定位了根因
提出的修复方案兼顾安全性和灵活性
走通了完整的开源贡献流程

这一篇从"跑通项目"出发，反推了 Docker Compose 编排、Gin 路由注册、Redis 缓存、RabbitMQ 消息队列、Worker 进程模式等工程概念，最后通过一次真实的开源贡献把整条链路串了起来。相比纯语法学习，反推真实项目能更快建立工程直觉。