今天是认知日，不写一行微服务代码，但要解决一个根本问题：你到底为什么要学微服务？ 答不清这个，后面学每个组件都会觉得"这不就是加个依赖吗"。
先理解"痛"，才知道微服务为什么存在。
// 一个 Spring Boot 工程里塞下所有功能
mall-app/
├─ controller/ UserController · ProductController · OrderController
├─ service/ UserService · ProductService · OrderService
└─ 共享同一个数据库连接池
团队小、业务简单时，单体是最优解：开发快、调试方便、没有网络开销。别神化微服务。
| 痛点 | 具体表现 |
|---|---|
| 代码膨胀 | 几百人改一个仓库，merge 冲突天天打 |
| 部署耦合 | 改一行代码 → 重新部署整个系统 |
| 扩展浪费 | 只有"下单"要扩容，却把整个系统复制 10 份 |
| 技术锁死 | 想给一个模块换 Go/Rust？做不到 |
| 故障扩散 | 一个 OOM，整个系统全挂 |
同样的需求，换个组织方式。
| 特征 | 对 | 错 |
|---|---|---|
| 按业务能力拆 | 用户 / 商品 / 订单 各一个服务 | controller / service / dao 各一个 ✗ |
| 独立部署 | 每个服务单独上线 | 改一个要全量发版 |
| 数据隔离 | 每个服务独占自己的库 | 所有服务连同一个库 |
治理"一堆微服务"的工具箱——每个组件 = 美食街的一个市政设施。
Spring Boot → 做单个服务（地基）
Spring Cloud → 治理组件的「接口标准」（Spring 官方定规范）
Spring Cloud Alibaba → 阿里的「具体实现」（Nacos/Sentinel/Seata）
代码不动 = 没学会。今天先把地基打好。
在终端逐条验证，缺什么装什么（Docker Desktop 一条龙搞定 Docker + Compose；JDK 17 用 Temurin）。
基于"美食街"类比，画出含 3 业务服务（user/product/order）+ 5 治理组件（Nacos/Gateway/RabbitMQ/Seata/Zipkin）的架构，标注用户请求完整路径，每个组件写一句话职责。
工具任选：手画拍照 / draw.io / Excalidraw / Mermaid。写到 02_case_studies/architecture-diagram.md。
graph TB
U[用户] --> GW[ ___ ]
GW --> US[user-service]
GW --> PS[ ___ ]
GW --> OS[ ___ ]
US -.-> N[ ___ ]
OS -->| ___ | US
OS -.->|Seata| PS
先自己做，别翻上面。答错不可怕，我会判断你错在哪一类。