架构风格

这一课你将能做到

1. 给出一个业务场景，能在 5 分钟内判断适合单体还是微服务，并说出 3 个理由
2. 画出本站的分层架构图，并指出每一层的职责和依赖方向
3. 解释 Serverless 的适用边界，说出至少一个「不该用 Serverless」的场景

为什么要学

「我们要上微服务」是过去十年最危险的架构决策。太多团队在 5 个人、日活 5000 的时候拆了 20 个服务，然后被分布式事务、链路追踪、发布协调活活拖死。

人话：架构风格是房子的结构类型。平房、楼房、别墅各有各的用途。你不能因为别墅高级就在工地上给工人搭别墅住——平房才是对的。

面试场景：「你们为什么用微服务？」「如果现在重来，你会怎么设计？」——面试官在测你对架构演进和权衡的理解。

先建立图像

四种架构风格的结构对比：

【单体】                【分层】
┌──────────────┐       ┌──────────────┐
│   一个进程    │       │  Presentation │
│  所有模块    │       │  ───────────  │
│  共享数据库  │       │   Business    │
└──────────────┘       │  ───────────  │
                       │   Data Access │
                       └──────────────┘

【微服务】              【Serverless】
     API GW                 CDN
    /   |   \                │
  Svc1 Svc2 Svc3          FaaS Function
  |DB| |DB| |DB|         /    |    \
                        DB   Cache  Queue

跟着做

步骤 1：单体架构的模块化

本站阶段一的目录结构，按领域模块化：

com.coderoadmap
├── user          // 用户域
│   ├── api       // 对外接口（DTO/Controller）
│   ├── domain    // 领域对象、领域服务
│   └── infra     // DAO、外部调用
├── course        // 课程域
│   ├── api
│   ├── domain
│   └── infra
├── order         // 订单域
│   ├── api
│   ├── domain
│   └── infra
└── common        // 工具类

关键：编译时还是一个 JAR，但代码层面已按域隔离。这是「可拆分的单体」，是微服务的前置条件。

步骤 2：何时拆微服务——决策树

团队人数 ≥ 10？
  ├─ 否 → 单体（或模块化单体）
  └─ 是 → 领域边界是否清晰？
        ├─ 否 → 先 DDD 梳理边界
        └─ 是 → 部署频率差异大？
              ├─ 否 → 模块化单体
              └─ 是 → 微服务

本站推演：

• 团队 3 人：单体 + 模块化，共享数据库
• 团队 15 人：用户、课程、订单三个域独立部署，各配 1-2 人
• 团队 50 人：每个域再细分（课程检索、课程管理、课程推荐）

步骤 3：前端架构风格选型

本站从 SSR 到 SPA 的演进：

阶段	风格	技术	原因
阶段一	SSR	Thymeleaf	SEO 友好，开发简单
阶段二	混合	Nuxt.js SSR	需要交互性，又要 SEO
阶段三	SPA + BFF	React + Node BFF	纯工具站，SEO 次要，体验优先

讲清楚要点

1. ：Airbnb、Shopify 早期都是单体。单体的问题不是「单体」本身，而是「没有边界感的单体」。模块化的单体可以支撑团队到 50 人。