test-repo/docs/zh-cn/appendix/deployment.md

# 部署与上线 (Deployment & Release)

> 💡 **学习指南**：本章节不讲复杂的服务器运维，而是通过“交互式体验”，带你从零看懂一个网站是如何从你的电脑“跑”到用户手机里的。

## 0. 全局概览：一个请求的“奇幻漂流”

你有没有想过，当你在浏览器输入网址并回车的那一瞬间，到底发生了什么？
其实，这就像是一次**快递配送**的过程。

不过，根据你要“送”的东西不同，配送路线也会稍微有点不一样。

**为什么会有这些区别呢？**
就像在现实生活中，不同的东西有不同的送法：

1.  **发传单（静态网页）**：
    *   *场景*：公司的介绍页、博客文章。
    *   *特点*：内容是**死**的，印好了就不变了。
    *   *做法*：直接把“传单”贴在离用户最近的宣传栏（CDN）上。谁来看都一样，速度最快，成本最低。

2.  **送乐高积木（SPA 单页应用）**：
    *   *场景*：类似飞书、Notion 这种复杂的网页软件。
    *   *特点*：交互特别多，像个**软件**。
    *   *做法*：先给你寄一个“空盒子”和一大堆“零件”（JS代码），你的浏览器收到后，自己在本地把页面“拼”出来。
    *   *好处*：一旦加载完，点哪里都很快，因为不需要再找服务器要页面了，只需要要数据。

3.  **送热披萨（SSR 服务端渲染）**：
    *   *场景*：股票大盘、新闻头条、个性化推荐。
    *   *特点*：数据**实时变动**，或者需要**千人千面**。
    *   *做法*：必须在用户下单的那一秒，由办事员（服务器）现场查数据、现场组装好页面，再热乎乎地交给你。
    *   *好处*：数据绝对新鲜，而且搜索引擎（爬虫）最喜欢这种完整的页面。

下面这个互动图，带你体验这三种不同的“配送路线”：

<DeploymentArchitecture />

不管你选择哪种模式，一个**完整的请求**通常都要经过以下这些关卡。
让我们看看它们都是干什么的，以及**为什么**我们缺不了它们：

1.  **用户 (User) —— 寄件人**
    *   *动作*：在浏览器输入网址，回车。
    *   *人话*：就像是你发出了一个“我想看网页”的请求包裹。

2.  **DNS (域名解析) —— 查号台**
    *   *为什么需要？* 电脑只认识数字（IP地址），人脑只记得住单词（域名）。
    *   *人话*：它负责告诉你“baidu.com”这个名字对应的**门牌号 (IP地址)** 到底是哪一家。

3.  **CDN (内容分发) —— 家门口的快递柜**
    *   *为什么需要？* 服务器可能在地球另一边，传一张图片过来太慢了。
    *   *人话*：如果你要的东西（图片、视频）在楼下的快递柜（CDN节点）里正好有备份，直接给你，**不用跑远路**去总仓库取。

4.  **WAF (防火墙) —— 小区保安**
    *   *为什么需要？* 互联网上有很多坏人（黑客）想搞破坏。
    *   *人话*：它站在门口，把带炸弹的、发传单的（恶意攻击）都**拦在外面**，只让正常的客人进去。

5.  **LB (负载均衡) —— 大堂经理**
    *   *为什么需要？* 访问的人太多了，一台服务器累死也干不完。
    *   *人话*：它看着后面开着的 10 个窗口（服务器），把你引导到那个**最空闲**的窗口去办理业务，不让你干等。

6.  **Server (服务器) —— 办事员**
    *   *为什么需要？* 总得有人真正干活，处理你的订单、计算金额。
    *   *人话*：他是真正**处理业务**的人，负责把网页内容拼好，或者把数据算出来给你。

7.  **DB (数据库) —— 档案室**
    *   *为什么需要？* 办事员脑子记不住那么多数据，而且断电了不能忘。
    *   *人话*：这里**永久保存**着你的账号、密码、历史订单等核心机密数据。

弄懂了这个流程，部署就不难了。部署无非就是把这些环节一个个打通。

---

## 1. 域名与 DNS：给你的网站起个名

你想让别人访问你的网站，总不能给人家一串冷冰冰的数字（IP 地址：`123.45.67.89`）吧？
你需要一个好记的名字，比如 `my-cool-site.com`。这就是**域名**。

而 **DNS**，就是负责把这个“好记的名字”翻译成“机器能懂的 IP”的系统。

### 1.1 常见的记录类型

在配置域名时，你会看到很多选项，别晕，最常用的就这俩：

- **A 记录**：最直接的。告诉 DNS，“`my-site.com` 的 IP 是 `1.2.3.4`”。
- **CNAME 记录**：起别名。告诉 DNS，“`www.my-site.com` 也就是 `my-site.com`”。这在接入 CDN 时特别常用。

### 1.2 避坑指南

- **生效慢**：DNS 修改不是立即生效的，全球同步可能需要几分钟到几小时（受 TTL 影响）。
- **配错了**：如果不小心配错了 IP，用户就真的找不到你了。

<DnsFlowDemo />

---

## 2. 服务器：你的网站“住”在哪？

代码写好了，得找个地方跑起来。这个地方就是**服务器**。
你可以把它想象成一台**永不关机、连着公网的电脑**。

### 2.1 怎么选配置？

新手最容易犯两个错：
1.  **买太小**：1核1G 的机器，跑个 Hello World 还行，稍微装点东西就卡死。
2.  **买太大**：一上来就买 8核16G，结果每天只有 10 个人访问，纯属浪费钱。

**建议**：先买个入门款（比如 2核4G），不够了再随时升级。云服务器的好处就是可以弹性伸缩。

### 2.2 最小上云脚本 (Ubuntu)

买好服务器后，通常是空的。你需要装一些基础软件。
把下面这段话复制到服务器终端里运行，就能装好 Nginx（Web服务器）和 Node.js（运行环境）：

```bash
# 1. 更新系统软件库
sudo apt update && sudo apt upgrade -y

# 2. 安装 Nginx (Web服务器) 和 Git (拉代码用)
sudo apt install -y nginx git curl

# 3. 安装 Node.js (这里选了版本 18)
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install -y nodejs

# 4. 安装 PM2 (这是个好东西，能帮你把网站进程“守”住，崩溃了自动重启)
sudo npm i -g pm2
```

<ServerSizerDemo />

---

## 3. HTTPS：给传输管道“加个盖”

以前的网站（HTTP），数据是在网线上“裸奔”的。谁要是拿个工具在中间截获一下，你的密码、聊天记录全都被看见了。
现在的标准是 **HTTPS**，多出来的这个 **S** 就是 **Secure (安全)**。它给数据加了一层加密壳，别人截获了也看不懂。

### 3.1 反向代理 (Reverse Proxy)

这是个听起来很高级，其实很简单的概念。
你的 Node.js 程序跑在 `3000` 端口，但用户习惯访问 `80` (HTTP) 或 `443` (HTTPS) 端口。
你不能让用户自己在网址后面输 `:3000` 吧？

这时候就需要 **Nginx** 出场了。它守在 `80/443` 端口，把用户的请求“接”进来，再“转”给你的 `3000` 端口程序。这就叫**反向代理**。

### 3.2 怎么搞定 HTTPS？

不用花钱买证书！现在有免费的工具叫 **Certbot**。
它能自动帮你申请证书，还自动帮你改 Nginx 配置。

<HttpsNginxDemo />

---

## 4. CDN：让网站“飞”到用户家门口

如果你的服务器在**北京**，而用户在**纽约**。
每一次请求都要跨越半个地球，光是光纤传输就要好几百毫秒，肯定慢。

**CDN (内容分发网络)** 就是解决这个问题的。
它在全球各地建了无数个“小仓库”。当你把图片、CSS、JS 文件放到 CDN 上：
- 北京用户访问，CDN 就近从北京节点给他。
- 纽约用户访问，CDN 就近从纽约节点给他。

**结果**：你的服务器轻松了（流量少了），用户也爽了（速度快了）。

<CdnCacheDemo />

---

## 5. CI/CD：告别“手工搬砖”

以前发布网站是这样的：
1.  在本地改代码。
2.  用 FTP 软件把文件上传到服务器。
3.  SSH 连上去重启服务。
4.  哎呀，上传漏了一个文件，报错了！赶紧修...

这太累，而且容易出错。
现在我们用 **CI/CD (持续集成/持续部署)**。

### 5.1 它是怎么工作的？

你只需要做一件事：**把代码推送到 Git 仓库**。
剩下的事情，流水线（Pipeline）自动帮你做：
1.  **检测**：自动发现有新代码了。
2.  **安装**：自动在新环境里装依赖 (`npm install`)。
3.  **构建**：自动打包 (`npm run build`)。
4.  **部署**：自动把打好的包发到服务器，并重启服务。

如果中间任何一步出错了（比如测试没过），它会立刻停下来报警，绝不会把烂代码发到线上。

<CicdPipelineDemo />

### 5.2 进阶：如何“丝滑”回滚？

万一新版本上线后发现有重大 Bug，怎么办？
**蓝绿部署** 或 **滚动更新** 可以帮你。简单说，就是新老版本共存一小会儿，没问题了再全切过去。有问题？一键切回老版本，用户甚至感觉不到。

<RollbackSwitchDemo />

---

## 6. 监控与备份：做个“心里有数”的管理员

网站上线了，不是结束，只是开始。
你不能等用户打电话骂你“网站打不开了”，你才知道出事了。

### 6.1 监控 (Observability)

你需要给服务器装上“摄像头”和“报警器”：
- **日志 (Logs)**：记录程序运行的每一句话。报错了查日志，一查一个准。
- **指标 (Metrics)**：CPU 用了多少？内存剩多少？QPS（每秒请求数）是多少？
- **告警 (Alerts)**：当 CPU 飙到 90%，或者错误率突然升高时，直接发短信/钉钉告诉你。

### 6.2 备份 (Backup)

**数据是无价的**。
一定要设置**自动备份**。哪怕服务器炸了、被黑客删库了，只要有备份，你就能在半小时内“起死回生”。

<ObservabilityBackupDemo />

---

## 7. 遇到问题怎么办？(故障速查)

别慌，按这个表排查：

| 现象 | 可能原因 | 怎么办？ |
| :--- | :--- | :--- |
| **打不开网站** | 域名没解析好？服务器挂了？防火墙拦住了？ | 1. `ping 域名` 看看通不通。<br>2. 检查云厂商防火墙是不是没开 80/443 端口。 |
| **HTTPS 报错** | 证书过期了？没配置好？ | 运行 `certbot renew` 试着续期一下。 |
| **改了没生效** | 浏览器缓存？CDN 缓存？ | 强制刷新浏览器 (Ctrl+F5)；去 CDN 控制台点“刷新缓存”。 |
| **发布失败** | 依赖装不上？代码写错了？ | 去看 CI/CD 的日志，最后几行通常就是原因。 |

---

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

| 缩写 | 全称 | 人话解释 |
| :--- | :--- | :--- |
| **DNS** | Domain Name System | **域名解析**。把网址变成 IP。 |
| **CDN** | Content Delivery Network | **加速网络**。把资源存到离用户最近的地方。 |
| **HTTPS** | HyperText Transfer Protocol Secure | **安全协议**。给数据传输加把锁。 |
| **CI/CD** | Continuous Integration / Deployment | **自动发布**。提交代码后自动跑完测试和上线流程。 |
| **PM2** | Process Manager 2 | **进程管家**。Node.js 的保姆，负责让程序一直跑着。 |

---

## 9. 上线前的最后检查 (Checklist)

在按下“发布”按钮前，心里默念一遍：

- [ ] **域名**：解析通了吗？IP 对吗？
- [ ] **安全**：HTTPS 绿锁有了吗？
- [ ] **加速**：CDN 配好了吗？静态资源快吗？
- [ ] **流程**：自动发布跑通了吗？能一键回滚吗？
- [ ] **后路**：监控报警开了吗？数据库备份了吗？

如果都 OK，恭喜你，你的产品正式面世了！🚀