test-repo/docs/zh-cn/appendix/backend-evolution.md

# 后端架构演进：从单机到云原生

::: tip 🎯 核心问题
**代码写好了,怎么让全世界的人都能访问?** 这就像问:你是想开一家路边小摊,还是经营一家跨国连锁餐厅?后端架构的选择,决定了你的"餐厅"能服务多少顾客。
:::

---

## 1. 为什么要了解架构演进?

想象一下,你正在规划一次长途旅行。你可以选择骑自行车、开私家车、坐高铁,或者乘飞机。每种方式都有其适用的场景:自行车适合短距离且想锻炼身体的情况,飞机则适合跨越大陆的长途旅行。

**后端架构的选择也是如此。**

从互联网诞生到现在,后端架构经历了多次重大变革。每一次变革都不是为了"追新潮",而是为了解决当时面临的特定问题:

| 年代  | 核心问题                 | 架构演进            |
| ----- | ------------------------ | ------------------- |
| 1990s | 如何把网站跑起来         | 物理服务器          |
| 2000s | 代码越来越乱怎么维护     | 单体架构 + MVC      |
| 2010s | 系统太大怎么扩展和协作   | 微服务 + 容器化     |
| 2020s | 如何降低运维成本和复杂性 | Serverless + 云原生 |

::: tip 📊 从表格中你能看到什么?
让我们逐行解读这张表:

**1990s → 2000s**:从"能跑就行"到"需要维护"。网站从静态页面变成动态应用,代码量激增,需要更好的组织方式。

**2000s → 2010s**:从"单机"到"分布式"。用户量爆炸式增长,单台服务器扛不住了,需要拆分系统,水平扩展。

**2010s → 2020s**:从"自己运维"到"云服务"。容器和微服务虽然强大,但运维成本太高,Serverless 让开发者只关注业务逻辑。

**核心启示**:架构演进不是技术选型的游戏,而是**解决实际问题**的过程。每个阶段都有其适用的场景,没有"最好的架构",只有"最适合的架构"。
:::

**了解架构演进的意义在于:**

1. **避免重复造轮子**:很多"新"概念其实早在几十年前就有雏形,了解历史能让你站在巨人的肩膀上
2. **做出合理的技术选型**:没有最好的架构,只有最适合当前阶段的架构
3. **理解技术背后的权衡**:每一次架构演进都是在**开发效率**、**系统性能**、**运维复杂度**之间做取舍
4. **预判技术趋势**:历史总是押韵的,理解过去的演进规律有助于把握未来方向

<EvolutionIntroDemo />

---

## 2. 物理服务器时代 (1990s)

### 2.1 什么是物理服务器?

在互联网刚起步时,后端就是一台放在机房里的**物理服务器**(一台真实的电脑)。

::: tip 💡 通俗解释
**物理服务器**就像你家里的台式机,但它:

- 7×24小时不关机
- 放在专门的数据中心(有空调、UPS电源、消防系统)
- 有更快的网络带宽(企业级光纤)
- 有固定的公网IP地址(全世界都能访问)

这就好比你家 vs 餐厅:你家只是偶尔做饭,餐厅则是专业厨房,全天候营业,设备更专业。
:::

### 2.2 核心特点

- **单机部署**:所有应用运行在一台物理机上
- **手动运维**:需要人工上架、布线、安装系统
- **垂直扩展**:性能不够时只能买更强的机器

::: details 🔧 垂直扩展 vs 水平扩展
**垂直扩展**(Scale Up):升级单台服务器的配置(更多CPU、更大内存、更快硬盘)。

**水平扩展**(Scale Out):增加更多服务器,让它们一起工作。

**比喻**:

- 垂直扩展:把小餐厅改成大餐厅,装修更豪华,但只有一个厨师
- 水平扩展:开连锁店,每个店规模不大,但有100家分店

**优缺点**:

- 垂直扩展简单,但有上限(顶级服务器很贵,且有限制)
- 水平扩展理论上无限,但需要解决数据一致性问题
  :::

### 2.3 痛点

- **慢**:每次改代码都要手动上传,然后重启服务器
- **贵**:扩容只能买更大的机器(垂直扩展)
- **难扩展**:一台机器顶住所有请求,CPU满载时就只能排队

<PhysicalServerDemo />

### 2.4 物理服务器时代的优缺点

| 维度         | 评价                                                         |
| ------------ | ------------------------------------------------------------ |
| **优点**     | 完全掌控硬件,性能可预测;没有虚拟化开销;数据物理隔离,安全性高 |
| **缺点**     | 采购周期长(数周);前期投入大(CapEx);资源利用率低;扩容困难     |
| **适用场景** | 金融核心系统、政府涉密系统、对数据主权有严格要求的场景       |

::: tip 💡 CapEx vs OpEx
**CapEx**(Capital Expenditure):资本性支出,一次性投入大量资金购买硬件。

**OpEx**(Operating Expenditure):运营性支出,按使用量付费(如云服务器)。

**比喻**:

- CapEx:买房,一次性付几百万,之后每月只需交物业费
- OpEx:租房,每月交房租,不用一次性掏大钱

**云时代**的启示:Serverless 和云服务让更多公司从 CapEx 转向 OpEx,降低创业门槛。
:::

---

## 3. 单体架构时代 (2000s)

### 3.1 什么是单体架构?

随着框架的出现(Rails / Django / Spring),大家把所有功能都塞进一个应用里。

::: tip 💡 通俗解释
**单体架构**(Monolith)就像一个超级商场:

- 服装区、食品区、电器区都在同一栋楼里
- 所有员工在一个管理系统里工作
- 如果整栋楼停电,所有区域都停止营业

对比微服务就像商业街:每家店独立运营,一家店关门不影响其他店。
:::

<MonolithDemo />

### 3.2 核心特点

- **单一代码库**:所有功能模块在同一个项目中
- **共享数据库**:所有模块共用同一个数据库
- **统一部署**:整个应用作为一个整体打包部署

### 3.3 优点

- **开发简单**:一个项目搞定所有功能
- **部署方便**:把一个大包扔到服务器上就行
- **调试容易**:本地启动就能调试所有功能

### 3.4 痛点:雪崩效应

想象一下,如果"切菜"的师傅不小心切到了手(代码出了Bug),整个后厨都要停下来处理伤口,导致所有客人都吃不上饭。

这就是单体架构最大的风险:**隔离性差**。

::: details 🚨 真实的雪崩案例
某电商公司双十一大促:

- 订单服务因为某个商品的价格计算错误,抛出异常
- 异常没有被正确捕获,导致线程池耗尽
- 所有后续请求(包括商品浏览、搜索、用户登录)都被阻塞
- 整个网站彻底瘫痪,持续1小时

**如果用微服务**:

- 订单服务挂了,但商品浏览、搜索、用户登录仍然可用
- 用户至少可以继续浏览商品,损失降到最低
  :::

### 3.5 单体架构的优缺点与适用场景

| 维度           | 评价                                                                                                                                            |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **优点**       | 开发简单,无需考虑分布式复杂性;调试方便,本地启动即可调试全功能;部署简单,一个包即可运行;事务管理容易,单机数据库即可保证ACID                       |
| **缺点**       | 代码耦合度高,随着业务增长代码膨胀;技术栈单一,难以局部升级;扩展困难,只能整体扩容;故障隔离差,一个模块故障影响全局;团队协作效率低,多人改同一套代码 |
| **适用场景**   | 初创公司MVP验证、小型团队(<10人)、业务相对简单、对交付速度要求高于扩展性的场景                                                                  |
| **不适用场景** | 大型团队并行开发、需要频繁发布不同模块、某些模块需要独立扩容的场景                                                                              |

::: tip 🎯 初学者建议
如果你正在学习后端开发,**强烈建议从单体架构开始**:

1. **先学会走路**:理解HTTP、数据库、基本的MVC架构
2. **再考虑跑步**:当项目真的遇到扩展性问题,再考虑微服务
3. **避免过度设计**:很多公司的"微服务"其实是"分布式单体",更难维护

**学习路径**:

- 阶段1:用 Spring Boot / Django / Rails 写一个完整的单体应用
- 阶段2:遇到性能瓶颈时,尝试拆分出1-2个服务
- 阶段3:当团队规模>50人,系统真的复杂了,再全面微服务化
  :::

### 3.6 单体架构的技术栈

| 语言/框架                  | 特点                         | 代表企业              |
| -------------------------- | ---------------------------- | --------------------- |
| **Java + Spring**          | 企业级开发首选,生态完善      | 阿里巴巴、京东        |
| **PHP + Laravel/ThinkPHP** | 快速开发,适合中小型项目      | 早期 Facebook、微博   |
| **Python + Django/Flask**  | 开发效率高,适合快速原型      | Instagram、Pinterest  |
| **Ruby on Rails**          | 约定优于配置,初创公司最爱    | GitHub、Twitter(早期) |
| **Node.js + Express**      | 前后端统一语言,I/O密集型场景 | Netflix、Uber         |

---

## 4. 容器化与微服务 (2010s)

### 4.1 为什么需要微服务?

单体架构的痛点在2010年代集中爆发:

- **代码太庞大**:一个项目几百万行代码,新人入职要花一个月才能看懂
- **部署太慢**:构建一次要30分钟,发布一次要小心翼翼
- **协作太难**:100个开发者改同一个项目,代码冲突每天发生
- **扩展太贵**:只需要扩展"聊天服务",却要复制整个应用

**微服务的核心思想**:把大应用拆成多个小服务,每个服务:

- 独立开发、独立部署
- 有自己的数据库
- 通过API通信

<ContainerDockerDemo />

::: tip 💡 Docker是什么?
**Docker**就像是"集装箱":

- 每个集装箱里有独立的货物(代码 + 依赖库 + 运行环境)
- 无论运到哪里(哪台服务器),打开集装箱就能直接开工
- 不用担心"我这台机器没有Python 3.9"、"那个机器缺少某个库"

**比喻**:

- 没有 Docker:每次搬家,要把家具、电器、衣服一件件搬上卡车,到了新家再一件件摆好
- 有 Docker:所有东西打包进集装箱,卡车直接运走,到了新家放下就能用

**核心价值**:"一次构建,到处运行"。
:::

### 4.2 技术栈时间线

<TechStackTimelineDemo />

### 4.3 微服务架构

为了解决单体的问题,我们把大厨房拆成了很多个小厨房(服务):

- 专门负责用户的服务
- 专门负责订单的服务
- 专门负责支付的服务

<MicroservicesDemo />

### 4.4 Kubernetes 编排

当集装箱数量到达成百上千,就需要一个"港口调度系统":

- **Kubernetes (K8s)**:负责把容器安排到合适的机器上(调度、扩缩容、滚动更新)
- **Service Mesh**:负责服务之间的交通规则(熔断、限流、重试、可观测)

<KubernetesDemo />

::: tip 💡 什么是"编排"?
**编排**(Orchestration)是指自动管理大量容器的系统。

**比喻**:

- 没有 K8s:你手动管理100个容器,哪个挂了要手动重启,哪个流量大了要手动加机器
- 有 K8s:你告诉它"我要这个服务一直有10个实例运行",它会自动完成:
  - 哪台服务器资源充足,就把容器调度到那里
  - 容器挂了,自动重启
  - 流量大了,自动扩容到20个实例
  - 更新代码时,滚动更新(先停1个旧实例,启动1个新实例,逐个替换)

**关键点**:微服务不是"拆开就好",真正的难点在于**治理和运维**。
:::

### 4.5 微服务与容器化的优缺点

| 维度           | 评价                                                                                                                                                             |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **优点**       | 服务独立部署,技术栈可异构;故障隔离,单个服务崩溃不影响全局;按需扩展,热点服务单独扩容;团队协作友好,不同团队负责不同服务;代码库更小,易于理解和维护                  |
| **缺点**       | 分布式复杂性高(网络延迟、分布式事务、服务发现);运维成本高,需要专业的DevOps团队;调试困难,问题可能需要跨多个服务追踪;数据一致性难以保证;部署和监控基础设施要求复杂 |
| **适用场景**   | 大型团队(>50人)、业务复杂需要分模块独立演进、某些模块需要独立扩容、需要多语言技术栈、对可用性要求高的系统                                                        |
| **不适用场景** | 小型团队、业务简单、流量小且稳定、没有专业运维团队的情况                                                                                                         |

::: details ⚠️ 微服务的陷阱
**陷阱1:分布式单体**

拆了10个微服务,但它们之间紧密耦合:

- 服务A调用服务B,服务B调用服务C,服务C又调用服务A
- 改一个功能,要同时改5个服务
- 部署时,必须按顺序依次部署,否则系统报错

**这比单体更糟糕**:你拥有了单体的复杂性,又没有享受到微服务的独立部署好处。

**陷阱2:过度拆分**

把只有100行代码的功能也拆成一个独立服务:

- 10个服务,每个只有100行代码
- 服务间通信的开销(网络序列化/反序列化)比实际业务逻辑还重
- 运维成本爆炸:要部署、监控、日志收集10个服务

**正确做法**:从功能内聚的角度拆分,一个微服务应该是一个完整的业务能力(如"订单服务",而不是"订单创建服务"、"订单查询服务")。
:::

### 4.6 微服务技术栈

| 类别         | 技术/工具                          | 作用                 |
| ------------ | ---------------------------------- | -------------------- |
| **容器化**   | Docker, containerd                 | 应用打包与隔离       |
| **编排调度** | Kubernetes, Docker Swarm           | 容器管理与自动扩缩容 |
| **服务发现** | Consul, etcd, ZooKeeper            | 服务注册与发现       |
| **API网关**  | Kong, Zuul, Envoy                  | 统一入口、路由、限流 |
| **配置中心** | Apollo, Nacos, Spring Cloud Config | 集中配置管理         |
| **监控告警** | Prometheus, Grafana, ELK           | 指标监控与日志分析   |
| **链路追踪** | Jaeger, Zipkin, SkyWalking         | 分布式请求追踪       |
| **服务网格** | Istio, Linkerd                     | 流量治理与安全       |

---

## 5. Serverless 与云原生时代 (2020s+)

### 5.1 为什么需要 Serverless?

微服务虽然好,但维护几十个小厨房还是很累。你需要担心:

- 厨房够不够大?(服务器扩容)
- 停电了怎么办?(高可用)
- 容器太多怎么管?(运维成本)

<ServerlessDemo />

::: tip 💡 Serverless 不是真的"没有服务器"
**Serverless**的意思是"你不需要管理服务器",而不是真的没有服务器。

**比喻**:

- **物理服务器时代**:你买地、盖房、装修、雇厨师、买食材...全部自己来
- **云服务器时代**:你租一个已经装修好的餐厅,但自己雇厨师、管理运营
- **Serverless时代**:你只需要设计菜单,云端有共享厨房,有专业厨师,你下单他们做,按次付费

**核心变化**:

- 以前:买服务器 → 配环境 → 部署代码 → 监控 → 扩容 → 维护
- 现在:写代码 → 上传 → 按使用量付费

**就像外卖**:你不需要厨房,只需要设计菜单,有人帮你做。
:::

### 5.2 什么是 Serverless?

**Serverless = FaaS + BaaS**

**FaaS**(Function as a Service,函数即服务):

- 你只写函数(如"用户注册时发送欢迎邮件")
- 云厂商负责运行这个函数,自动扩缩容
- 典型代表:AWS Lambda、阿里云函数计算

**BaaS**(Backend as a Service,后端即服务):

- 登录 → Auth0 / Supabase Auth
- 支付 → Stripe
- 数据库 → Supabase / Firebase / DynamoDB
- 消息 → Kafka / SQS

::: tip 🎯 Serverless 适用场景
**最佳场景**:

1. **潮汐流量**:外卖软件,中午流量大,半夜没人。Serverless会自动在中午分配1000台机器,半夜缩减到0台
2. **事件驱动**:"用户上传图片后,自动压缩图片"
3. **快速验证**:小团队、MVP、黑客松项目

**不适合场景**:

1. **长时间运行的任务**:视频转码(可能跑1小时,函数最大执行时间通常只有15分钟)
2. **需要低延迟的应用**:高频交易(冷启动延迟可能几十毫秒到几秒)
3. **需要精细控制底层**:操作系统内核调优、GPU直接访问
   :::

### 5.3 Serverless 与云原生的优缺点

| 维度           | 评价                                                                                                                                                                       |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **优点**       | 零运维成本,开发者只需关注业务代码;自动扩缩容,完美应对流量峰值;按需付费,无流量时成本接近零;快速上线,几分钟即可部署全球;高可用内置,云服务自动处理故障转移                    |
| **缺点**       | 冷启动延迟(几百毫秒到数秒);运行时长限制(通常5-15分钟);调试困难,本地难以完全模拟云环境;供应商锁定风险;不适合长时间运行或计算密集型任务;成本在高频持续流量下可能反超传统方案 |
| **适用场景**   | 事件驱动处理(图片处理、消息通知);潮汐流量应用(活动页、促销);快速原型验证和MVP;低频API或后台任务;无专职运维团队的小团队                                                     |
| **不适用场景** | 需要持续低延迟的应用;长时间计算任务;对冷启动敏感的场景(高频交易);需要精细控制底层基础设施的场景                                                                            |

::: details 💰 成本对比:何时Serverless更贵?
**场景1:低频访问**

- 传统服务器:每月$20(不管有没有人访问)
- Serverless:100万次请求 × $0.0002/次 = $20(仅在有流量时付费)
- **结论**:低频场景,Serverless更省钱

**场景2:高频持续访问**

- 传统服务器:每月$20
- Serverless:1亿次请求 × $0.0002/次 = $20,000
- **结论**:高频持续场景,传统服务器更省钱

**场景3:潮汐流量**

- 传统服务器:为了应对峰值,需要$100/月的服务器(平时资源利用率只有10%)
- Serverless:峰值时$20,平时几乎$0
- **结论**:潮汐流量场景,Serverless节省成本

**启示**:不要盲目上Serverless,要根据实际流量特征做成本测算。
:::

### 5.4 Serverless 技术栈与平台

| 类别         | 技术/平台                | 特点                         |
| ------------ | ------------------------ | ---------------------------- |
| **FaaS平台** | AWS Lambda               | 最早的FaaS服务,生态最成熟    |
|              | Azure Functions          | 微软云集成度高,.NET友好      |
|              | Google Cloud Functions   | 与GCP服务深度集成            |
|              | 阿里云函数计算           | 国内生态完善,冷启动优化好    |
|              | 腾讯云云函数             | 与微信生态整合               |
|              | Vercel/Netlify Functions | 前端开发者友好,边缘部署      |
| **BaaS服务** | Firebase                 | Google的移动端后端方案       |
|              | Supabase                 | PostgreSQL的Firebase开源替代 |
|              | AWS Amplify              | AWS的移动和Web应用开发平台   |
| **部署工具** | Serverless Framework     | 多云部署,社区活跃            |
|              | Terraform                | 基础设施即代码               |
|              | Pulumi                   | 用编程语言定义基础设施       |

---

## 6. 各架构阶段对比与选型指南

### 6.1 架构演进全景对比

<ArchitectureComparisonDemo />

| 维度             | 物理服务器             | 单体架构           | 微服务+容器              | Serverless         |
| ---------------- | ---------------------- | ------------------ | ------------------------ | ------------------ |
| **团队规模**     | 1-5人                  | 5-50人             | 50-500人                 | 1-20人             |
| **部署复杂度**   | 极高                   | 低                 | 极高                     | 极低               |
| **运维成本**     | 高                     | 中                 | 很高                     | 低                 |
| **扩展性**       | 差                     | 垂直扩展有限       | 水平扩展优秀             | 自动扩展           |
| **技术栈灵活性** | 无                     | 单一               | 多样化                   | 受限               |
| **冷启动**       | 无                     | 无                 | 容器启动时间             | 有延迟             |
| **适用场景**     | 遗留系统、特殊合规要求 | 初创公司、业务简单 | 大型互联网公司、复杂业务 | 快速验证、事件驱动 |

### 6.2 技术选型决策树

```
开始选型
    │
    ├─ 团队有专业运维人员?
    │   ├─ 是 → 考虑微服务或物理机
    │   └─ 否 → 继续判断
    │
    ├─ 需要快速上线验证想法?
    │   ├─ 是 → Serverless 或单体
    │   └─ 否 → 继续判断
    │
    ├─ 团队规模 > 50人?
    │   ├─ 是 → 考虑微服务
    │   └─ 否 → 继续判断
    │
    ├─ 流量有明显峰谷特征?
    │   ├─ 是 → Serverless
    │   └─ 否 → 单体架构(推荐初创)
    │
    └─ 特殊要求(合规、遗留系统)?
        └─ 是 → 物理服务器
```

::: tip 🎯 初学者选型建议
**如果你是个开发者或小团队:**

1. **阶段0 (学习)**:本地跑单体应用,理解HTTP、数据库、基本架构
2. **阶段1 (MVP)**:部署单体应用到云服务器(如阿里云ECS、AWS EC2)
3. **阶段2 (增长)**:当团队>10人、业务变复杂,考虑拆分出1-2个微服务
4. **阶段3 (成熟)**:当团队>50人、流量百万级,全面微服务化

**关键原则**:不要一开始就上微服务,那是"过早优化"。让架构随业务成长而演进。
:::

### 6.3 不同场景下的推荐架构

#### 场景一:独立开发者/兼职项目

- **推荐架构**:Serverless (Vercel/Netlify) 或 单体应用
- **理由**:几乎零运维成本,按需付费,快速上线
- **示例技术栈**:Next.js + Vercel + Supabase

#### 场景二:初创公司MVP验证

- **推荐架构**:单体架构 + 云服务器
- **理由**:开发速度快,团队可以专注于业务逻辑而非基础设施
- **示例技术栈**:Spring Boot / Django / Rails + RDS + ECS

#### 场景三:成长型公司(10-50人团队)

- **推荐架构**:模块化单体 或 轻量级微服务
- **理由**:开始面临代码耦合问题,但还不需要完整的微服务复杂度
- **示例技术栈**:Spring Cloud / Go Micro + Kubernetes

#### 场景四:大型互联网公司

- **推荐架构**:微服务 + 服务网格 + 中台架构
- **理由**:团队规模大,业务复杂,需要独立的发布节奏和技术栈
- **示例技术栈**:自研RPC框架 + Istio + 自建PaaS平台

#### 场景五:事件驱动/潮汐流量应用

- **推荐架构**:Serverless + 事件总线
- **理由**:流量波动大,需要极致的成本优化和自动扩缩容
- **示例技术栈**:AWS Lambda + API Gateway + EventBridge

---

## 7. 总结与学习路线

### 7.1 核心要点

后端架构的演进,本质上是在做**加法**和**减法**:

| 时代           | 架构   | 开发者要做的事   | 运维要做的事       |
| :------------- | :----- | :--------------- | :----------------- |
| **物理时代**   | 单机   | 写脚本、手动部署 | 维护机房与硬件     |
| **单体时代**   | 一整块 | 写所有业务逻辑   | 维护几台大服务器   |
| **微服务时代** | 拆分   | 关注单一业务     | 维护K8s集群(很累!) |
| **Serverless** | 函数   | 只写核心函数     | 喝茶(云厂商全包了) |

**关键洞察**:

- 架构演进不是"新技术取代旧技术",而是**适用场景的变化**
- 没有银弹,每个架构都有其适用的边界
- 选择架构要考虑:团队规模、业务复杂度、流量特征、运维能力

### 7.2 学习路线建议

根据你的职业阶段,推荐以下学习路径:

#### 阶段一:打好基础(0-1年)

**目标**:理解后端核心概念,能独立开发单体应用

- 掌握一门后端语言(Java/Python/Go任选其一)
- 学习HTTP协议和RESTful API设计
- 掌握关系型数据库(MySQL/PostgreSQL)
- 了解缓存基础(Redis)
- 学习Git和基础Linux命令
- **实践项目**:用单体架构完成一个CRUD应用(如博客系统、待办事项)

#### 阶段二:扩展能力(1-3年)

**目标**:理解分布式系统,能参与微服务开发

- 深入学习微服务架构和拆分策略
- 掌握Docker和Kubernetes基础
- 学习消息队列(Kafka/RabbitMQ)
- 了解分布式事务和一致性
- 掌握监控和日志(Prometheus/ELK)
- **实践项目**:将单体应用拆分为3-5个微服务,使用Docker部署

#### 阶段三:专业深化(3-5年)

**目标**:能设计大型系统,具备技术选型能力

- 深入理解云原生架构(Service Mesh、Serverless)
- 掌握容量规划和性能调优
- 了解多活架构和灾备设计
- 学习DDD(领域驱动设计)
- 培养技术判断力和架构思维
- **实践项目**:设计一个支持百万级用户的系统架构,包含高可用、弹性伸缩等方案

### 7.3 持续学习资源推荐

**书籍**:

- 《设计数据密集型应用》(DDIA)- 分布式系统必读
- 《云原生模式》
- 《微服务设计》
- 《领域驱动设计》

**在线资源**:

- AWS/Azure/阿里云官方架构文档
- CNCF(云原生计算基金会)项目文档
- 各大公司技术博客(Netflix Tech Blog、阿里技术公众号等)

---

## 8. 名词速查表(Glossary)

| 名词              | 全称                              | 解释                                              |
| :---------------- | :-------------------------------- | :------------------------------------------------ |
| **Backend**       | -                                 | 服务器端系统,负责处理业务逻辑、数据存储和对外接口 |
| **CGI**           | Common Gateway Interface          | 早期动态网页技术,通过脚本处理请求并返回结果       |
| **Monolith**      | -                                 | 单体架构,把所有业务逻辑打包在同一个应用中         |
| **Microservices** | -                                 | 微服务架构,把业务拆分成多个独立服务               |
| **Container**     | -                                 | 容器化技术,把应用和依赖打包成可移植单元           |
| **K8s**           | Kubernetes                        | 容器编排平台,用于调度、扩缩容和治理容器           |
| **Service Mesh**  | -                                 | 服务网格,负责微服务间通信治理、观测与安全         |
| **Serverless**    | -                                 | 无服务计算,开发者只写函数,平台自动运行与扩缩容    |
| **BaaS**          | Backend as a Service              | 即插即用的后端云服务(认证、数据库、支付等)        |
| **CI/CD**         | Continuous Integration / Delivery | 持续集成与持续交付,自动化测试与部署流程           |
| **Observability** | -                                 | 可观测性,利用日志/指标/追踪理解系统运行状态       |