1. 课程导论：Docker基础概念回顾、为什么需要鉴权拦截、课程目标与整体架构概览
1.1 Docker 核心概念回顾
在深入后端鉴权拦截之前，有必要快速对齐 Docker 的核心技术栈。Docker 通过容器化技术将应用及其依赖打包成标准单元，实现环境一致性与快速交付。以下表格梳理了本课程频繁使用的核心概念：
| 概念 | 定义 | 本课程中的角色 |
|---|---|---|
| 镜像 (Image) | 只读模板，包含运行应用所需的代码、运行时、库、环境变量和配置文件。 | 作为鉴权服务、API 网关、后端应用的交付单元，通过 Dockerfile 构建。 |
| 容器 (Container) | 镜像的运行实例，拥有独立的文件系统、网络和进程空间。 | 每个鉴权组件（如 JWT 签发服务、拦截中间件）运行在独立的容器中。 |
| Docker Compose | 多容器编排工具，通过 YAML 文件定义和运行多个关联容器。 | 用于一键启动“后端服务 + 鉴权拦截层 + 数据库”的完整环境。 |
| 网络 (Network) | 容器间通信的虚拟网络，支持 bridge、host、overlay 等驱动。 | 鉴权拦截容器与后端业务容器通过自定义 bridge 网络隔离且互通。 |
| 数据卷 (Volume) | 持久化存储机制，独立于容器生命周期。 | 存储鉴权日志、黑名单 Token、密钥文件等状态数据。 |
实践提示： 本课程所有示例均基于 Docker 24+ 和 Docker Compose V2。如果你仍在使用旧版 docker-compose（V1），建议升级以兼容网络和健康检查等特性。
1.2 为什么需要鉴权拦截
后端接口直接暴露在公网或内网中，如果没有鉴权拦截层，任何客户端都可以无限制调用敏感接口。这在微服务架构和容器化部署中尤为危险，因为服务实例可能动态扩缩，传统的 IP 白名单或防火墙难以细粒度控制。
鉴权拦截的核心价值体现在三个维度：
- 安全防护： 阻止未授权访问，防止数据泄露、接口滥用和 CSRF/XSS 攻击。
- 流量治理： 基于用户身份进行限流、配额控制和灰度发布。
- 审计追溯： 记录每次接口调用的用户身份、时间戳和操作内容，满足合规要求。
常见误区： 不要在业务容器内部重复实现鉴权逻辑。将鉴权拦截前置到网关层或独立中间件容器，可以统一策略、降低耦合、提升安全水位。
1.3 课程目标
完成本课程后，你将能够：
- 使用 Docker 容器化部署一套完整的后端鉴权拦截系统（包含 JWT 签发、Token 校验、RBAC 权限控制）。
- 理解并实现三种典型鉴权模式：网关集中拦截、Sidecar 代理拦截、服务内嵌拦截。
- 通过 Docker Compose 编排多服务环境，并配置健康检查、网络隔离和日志持久化。
- 在容器化场景下处理鉴权常见痛点：Token 刷新、黑名单同步、跨服务传递用户上下文。
1.4 整体架构概览
本课程演示的架构采用“API 网关 + 鉴权中间件 + 后端业务服务”三层模型，全部运行在 Docker 容器中。下图展示了核心组件及其调用关系：
请求流转路径如下：
- 外部客户端 发起 HTTP 请求到 API 网关（Nginx 容器）。
- 网关根据路由规则将请求转发至 鉴权中间件 容器（独立部署或作为 Sidecar）。
- 鉴权中间件校验 Token 有效性，必要时查询 Redis（黑名单/缓存）和 数据库（用户权限）。
- 校验通过后，请求携带用户上下文（如 UserID、角色）转发至 后端业务服务 容器。
- 业务服务处理请求，返回响应；鉴权中间件和网关逐级回传。
架构优势： 鉴权逻辑与业务逻辑完全解耦。更换鉴权策略（如从 JWT 切换到 OAuth2）时，只需更新鉴权中间件容器，业务服务无需改动。
1.5 课程实验环境说明
为了确保你能顺利跟随课程操作，建议准备以下环境：
- 操作系统： Linux (Ubuntu 22.04+) 或 macOS (Ventura+)，Windows 用户建议使用 WSL2。
- Docker Engine： 24.0+，支持
docker compose子命令。 - 代码仓库： 每章提供完整的 Dockerfile、docker-compose.yml 和示例代码片段。
- 工具： curl、jq（用于测试接口）、Postman 或 Insomnia（可选）。