# CI/CD 自动化导论
::: tip 🎯 核心问题
**代码在本地跑得好好的，怎么让全世界的人都能访问？**
:::

---

## 1. 服务上线的动机

想象一下，你在自己家里做了一桌子菜，非常好吃。但问题是，只有自家人能吃到，邻居、保安、陌生人他们都尝不到。

怎么办？你需要**把菜端到餐厅里**。这就是"服务上线"要做的事——把你写的代码，从个人电脑，搬到一个7×24小时永远开着的"公共电脑"上。这样任何人只要能上网，就能访问你的网站。

<DeploymentOverviewDemo />

服务上线涉及很多环节。就像开餐厅不仅仅是端菜出去，你还需要租店面、装修、办执照、雇服务员等。开发网站也是同理。从代码到用户能访问的网站，中间隔着很多步骤。需要一步步完成构建、部署、配置网络、保证安全等工作。

下面我会把整个流程拆开来讲。每个环节都掰碎、揉细。保证连完全没基础的小白也能看懂。

---

## 2. 构建：把代码变成"构建产物"

### 2.1 构建的动机

新手常问：代码写好了，为什么不能直接放到服务器上让用户访问？

要回答这个问题，先搞清楚你写的代码是什么格式。你可能用 Vue、React、Express、Koa 等框架。这些框架有一个共同特点：**它们不是给浏览器或服务器直接用的**。

举个例子。你写 Vue 代码时，是不是用过 `<template>`、`<script setup>` 这种标签？这种语法只有 Vue 认识。浏览器根本看不懂。浏览器只认识三种语言：HTML（网页结构）、CSS（网页样式）、JavaScript（网页逻辑）。Vue 组件语法对浏览器来说就像天书，完全无法理解。

所以在把代码放到服务器之前，必须做一件重要的事：**把它翻译成浏览器能看懂的语言**。这个翻译过程叫做"构建"（Build）。

### 2.2 构建具体做什么

构建不只是翻译。它还会做很多优化。让网站跑起来更快、更省资源。详细说说它具体都干了哪些活：

**第一步：解析依赖**

写代码时，会用到各种第三方库。比如 Vue、Vue Router、Axios、Vite 等。这些库不可能每次都让用户从 npm 下载。那样太慢了。构建工具会分析代码，把所有依赖找出来。然后把它们"打包"到一起。

**第二步：编译转换**

这是最核心的一步。把 Vue 组件编译成 HTML 和 JavaScript。把 SASS/LESS 编译成 CSS。把 ES6+ 新语法转换成兼容性更好的 ES5 代码。这步完成后，代码就从"开发者能看懂的格式"变成"机器能执行的格式"。

**第三步：压缩混淆**

压缩就是把所有空格、换行、注释删掉。把变量名从英文单词改成单个字母。比如 `userName` 变成 `a`，`calculateTotalPrice` 变成 `b`。这样文件大小大幅减小。用户下载起来就快多了。混淆后的代码人类基本看不懂。也能起到一点"保护代码"的作用。

**第四步：代码分割**

可能写了10个页面。每个页面有自己的代码。但用户可能只访问其中一个页面。为什么要下载其他9个页面的代码？构建工具会把代码分割成多个小块。用户访问哪个页面就下载哪个页面的代码。这就是"按需加载"。能大幅提升首次访问的速度。

**第五步：生成哈希**

这是非常重要的一步。但很多人会忽略。构建完成后，文件名会变成类似 `app.abc123.js`、`vendor.def456.css` 这样的格式。后面那串字母数字混合的字符串叫"哈希"。

哈希的作用是：当代码有任何改动时，哈希值就会变化。浏览器就知道"这个文件变了，需要重新下载"。没变的文件，浏览器继续使用缓存。不用重复下载。这样既能保证用户看到最新代码，又能充分利用缓存提升速度。

<DeploymentBuildDemo />

### 2.3 执行构建的方法

大多数现代前端项目都已经配好构建工具。只需要记住一个命令：

```bash
# 如果用 npm
npm run build

# 如果用 yarn
yarn build

# 如果用 pnpm
pnpm build
```

运行完后，去项目根目录找一个叫 `dist` 的文件夹（有时也叫 `build` 或 `.output`）。里面就是构建好的所有文件。这些文件就是最终要上传到服务器的东西。不需要再做任何修改。直接拖到服务器上就行。

### 2.4 构建产物里有什么

打开 dist 文件夹，会看到里面主要是三类文件：

- **HTML文件**：通常叫 `index.html`。这是入口文件。浏览器首先加载的就是它。
- **JS文件**：所有 JavaScript 代码。可能是1个也可能是好几个。
- **CSS文件**：所有样式代码。可能内联在 HTML 里，也可能是单独的 CSS 文件。

如果是比较复杂的后端项目（比如 Node.js），构建产物可能是一个可执行文件，或者一个 Docker 镜像。但原理是一样的：把代码变成服务器能直接运行的形式。

---

## 3. 服务器：找一台永远不关门的"房子"

### 3.1 服务器到底是什么

很多人第一次听到"服务器"，觉得是什么高大上的神秘设备。其实没那么复杂。**服务器就是一台电脑**。一台永远不关机、一直插着网线的电脑。

可能有人问：我自己家里不是有电脑吗？为什么要额外花钱租服务器？

这个问题问得好。帮你分析一下：

首先，你家的电脑不可能24小时开着。你要出门、要睡觉、偶尔还会死机重启。但服务器不一样。它专门用来干这个。可以365天全年无休地运行。网站随时都能访问。

其次，你家的网络也不行。家用宽带的上传速度通常很慢。而且家用宽带的 IP 是动态变化的。今天是这个 IP，明天可能就变成另外一个了。根本没法用来做网站服务器。服务器用的是数据中心的高速网络。IP 固定，网速飞快。

第三，你家的电脑没有"公网IP"。什么叫公网IP？就是全世界独一无二的地址。只有有这个地址，别人才能在互联网上找到你的电脑。你家电脑的 IP 通常只能在你家局域网里用。外面的人根本找不到你。服务器就不同了。它有一个固定的公网 IP。全世界的人都能通过这个 IP 找到它。

<DeploymentServerDemo />

### 3.2 选服务器的实现

选服务器主要看三个指标：**CPU核数**、**内存大小**、**硬盘空间**。这三个指标越高，服务器性能越好，价格也越贵。

对于刚入门的新手，完全没必要买特别贵的配置。记住一个简单的选法：

- **个人项目、学习练手**：1核2G内存，足够了。一个月大概几十块钱。
- **小型商业项目**：2核4G内存。能承载每天几千到几万访问量。
- **中型项目**：4核8G或更高。需要专业团队来运维了。

还有一个要考虑的点：**地域**。如果用户主要在中国，就买国内的服务器（阿里云、腾讯云），访问速度快。如果用户主要在海外，就买国外的服务器（AWS、Google Cloud、DigitalOcean），或者买香港的服务器。速度快而且不用备案。

### 3.3 国内还是国外

这是个很重要的问题。很多人刚开始没想清楚。后期会遇到麻烦。

**买国内服务器**的好处是速度快、延迟低。缺点是需要备案（提交网站信息给国家相关部门审核）。通常要等一周到一个月。而且国内服务器价格相对贵一些。

**买国外服务器**的好处是不用备案。买了就能用。价格也可能更便宜。缺点是中国大陆用户访问速度可能慢一些。如果是香港或新加坡机房会好很多。

建议是：如果是个人项目、学习展示用的网站，买香港或海外的服务器。省去备案的麻烦。如果是做正规商业项目，需要长期运营，就买国内服务器。老老实实备案，后期会省很多麻烦。

### 3.4 主流云厂商对比

| 厂商 | 适合人群 | 特点 | 新用户价格 |
|------|---------|------|-----------|
| 阿里云 | 国内业务 | 市场占有率第一，生态完善 | 首年几十到一百多 |
| 腾讯云 | 小程序、游戏 | 小程序云开发支持好 | 首年优惠力度大 |
| 华为云 | 企业用户 | 政府、政务项目首选 | 价格偏高 |
| DigitalOcean | 开发者 | 简单好用，价格透明 | $4/月起 |
| Vercel | 前端项目 | 零配置，直接推送就上线 | 免费额度够用 |

新手最推荐 **阿里云** 或 **腾讯云** 的学生机/新用户优惠。通常一年只需要几十块钱。性价比极高。如果做的是纯前端项目，想省事，也可以直接用 **Vercel** 或 **Netlify**。连服务器都不用买。把代码推送上去就自动部署好了。

### 3.5 拿到服务器后该做什么

买完服务器后，会收到一封邮件。里面包含几个重要信息：

- **IP地址**：一串类似 `123.45.67.89` 的数字。这是服务器在互联网上的门牌号。
- **登录用户名**：通常是 `root`（管理员账号）。
- **登录密码**：初始密码，或者是让你设置密码的链接。

有了这些信息，就可以用 **SSH（Secure Shell）** 远程登录到服务器上。对它进行各种配置。SSH 就像是给服务器发的一条加密的远程控制命令。让自己电脑上就能操作远在天边的服务器。

登录命令是这样的：

```bash
ssh root@123.45.67.89
# 按回车后会让你输入密码。输入正确的密码后就登录成功了。
```

登录成功后，就进入了服务器的命令行界面。看起来和在自己电脑上开了一个终端窗口差不多。可以在这里安装软件、创建文件夹、修改配置。一切操作都和本地电脑一样。

---

## 4. 部署：把代码搬进"房子"

### 4.1 部署是什么

部署就是租好了服务器（房子）之后，把代码（行李家具）搬进去。然后打开门开始营业的过程。

具体来说，部署包括以下几个步骤：

1. **把代码上传到服务器**：把构建产物从本地电脑传到服务器上。
2. **安装依赖**：服务器上可能没有项目需要的各种包。需要安装。
3. **配置环境变量**：比如数据库密码、API密钥等敏感信息。
4. **启动服务**：让应用程序跑起来。开始监听用户的请求。

这四个步骤听起来挺复杂。但其实做起来没那么难。下面会详细介绍每一步怎么做。

<DeploymentServerDemo />

### 4.2 把代码上传到服务器的实现

**方法一：FTP/SFTP 上传**

这是最直观的方式。就像用网盘一样。把文件拖到服务器上。可以在自己电脑上下载一个叫 **FileZilla** 的免费软件。填入服务器的IP、用户名、密码。就能像管理本地文件一样管理服务器上的文件了。

**方法二：Git 拉取**

这是更推荐的方式。先在 GitHub、GitLab 或 Gitee 上创建一个代码仓库。把代码推送到云端。然后在服务器上用 `git clone` 命令把代码拉下来。

这样好处是：后续更新代码只需要在服务器上执行 `git pull` 命令就行。不用每次都手动上传。而且代码存云端也安全。服务器重装了也不怕。

**方法三：CI/CD 自动部署**

这是最专业的方式。也是强烈推荐的方式。通过配置 CI/CD（持续集成/持续部署），只需要把代码推送到 GitHub。CI/CD 系统就会自动帮你完成：拉取代码 → 安装依赖 → 构建 → 部署的全过程。甚至不需要登录服务器。一切都是自动完成的。

### 4.3 部署的具体步骤

假设用最简单的方式——Git 手动部署。一步步演示整个过程：

**第一步：连接到服务器**

```bash
ssh root@123.45.67.89
```

**第二步：安装必要的软件**

如果是 Node.js 项目，需要先安装 Node.js：

```bash
# 以 Ubuntu 系统为例
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install -y nodejs
```

**第三步：拉取代码**

```bash
# 创建放网站的目录
mkdir -p /var/www/my-website
cd /var/www/my-website

# 克隆代码仓库（需要先在GitHub上创建好仓库）
git clone https://github.com/你的用户名/你的仓库名.git .
```

**第四步：安装依赖并构建**

```bash
# 安装项目依赖
npm install

# 构建项目（生成 dist 目录）
npm run build
```

**第五步：用 PM2 启动服务**

为什么要用 PM2？它是一个进程管理工具。可以让网站在后台持续运行。就算服务器重启了也能自动启动。

```bash
# 全局安装 PM2
sudo npm install -g pm2

# 启动网站（假设入口文件是 index.js）
pm2 start index.js

# 设置开机自启
pm2 startup
pm2 save
```

**第六步：配置 Nginx 反向代理**

Node.js 应用通常跑在 3000 或 8080 这样的端口上。但用户访问的是 80 端口（HTTP默认端口）。需要用 Nginx 把 80 端口的请求转发到应用端口。

```bash
# 安装 Nginx
sudo apt install -y nginx

# 创建 Nginx 配置文件
sudo nano /etc/nginx/sites-available/my-website
```

在打开的编辑器里写入以下配置：

```nginx
server {
    listen 80;
    server_name example.com www.example.com;

    # 静态文件（构建产物）直接返回
    location / {
        root /var/www/my-website/dist;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # API 请求转发到 Node.js 后端
    location /api/ {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
```

保存退出后，启用这个配置：

```bash
# 启用配置
sudo ln -s /etc/nginx/sites-available/my-website /etc/nginx/sites-enabled/

# 测试配置是否有错误
sudo nginx -t

# 重启 Nginx
sudo systemctl restart nginx
```

现在访问 `http://example.com`（记得先把域名解析到这个服务器IP），应该就能看到网站了！

---

## 5. 域名和 DNS：给网站起个好名字

### 5.1 买域名的动机

有了服务器 IP，为什么还要买域名？

想想看。让你记住一串数字 `123.45.67.89` 是不是很困难？是不是很容易敲错？但让你记住 `baidu.com`、`taobao.com` 这样的名字是不是就简单多了？

域名就是网站的名字。好记、专业。还能体现品牌形象。想象一下。告诉别人"访问我做的网站，IP 是 123.45.67.89"，和"访问 woshishuaige.com"，哪个更像那么回事？

<DeploymentDnsDemo />

### 5.2 DNS 是什么

好。现在买了一个域名。比如叫 `my-awesome-website.com`。但问题来了：电脑只认识 IP 地址。不认识 "my-awesome-website.com" 这种人类语言啊。

这就需要 DNS 出场了。DNS 的全称是 "Domain Name System"。翻译过来就是"域名系统"。可以把它理解成一本巨大的"电话簿"。专门负责把人类好记的域名翻译成电脑能看懂的 IP 地址。

当在浏览器里输入 `my-awesome-website.com` 并回车时。背后发生了这些事情：

1. 浏览器问 DNS："hey，my-awesome-website.com 的 IP 地址是多少？"
2. DNS 查了一下"电话簿"，告诉浏览器："它的 IP 是 123.45.67.89"
3. 浏览器根据这个 IP 地址，找到了服务器，发出了请求

整个过程通常只需要几十毫秒。用户完全感知不到。

### 5.3 配置 DNS 的实现

配置 DNS 通常有两个地方可以操作：

**方式一：在域名购买商那里配置**

在哪里买的域名，就去哪里配置 DNS 记录。最常见的记录类型是 **A 记录**：

- **记录类型**：A
- **主机记录**：通常填 `@`（代表域名本身，如 my-awesome-website.com）或者 `www`（代表 www.my-awesome-website.com）
- **记录值**：服务器 IP 地址，如 `123.45.67.89`

**方式二：使用第三方 DNS 服务**

很多专业玩家不用域名商自带的 DNS。而是用 Cloudflare、阿里云 DNSPod、腾讯云 DNS 这些专业的 DNS 服务商。这些服务通常更稳定、解析速度更快。还自带 CDN、DDoS 防护等增值功能。

### 5.4 DNS 生效要多久

这是很多人关心的问题。答案是：**不一定。通常几分钟到 24 小时**。

DNS 修改后，全球所有的 DNS 服务器需要同步这个变更。这就像往大海里扔一颗石子。波浪需要时间才能传到远方。有些 DNS 服务器更新快，几分钟就生效了。有些比较慢，可能需要等很久。

可以用以下命令检查 DNS 是否生效：

```bash
# Windows
ping 你的域名

# Mac/Linux
ping 你的域名
```

如果 ping 得通，显示的是服务器的 IP。说明 DNS 已经生效了。

---

## 6. HTTPS：给网站装一把"锁"

### 6.1 HTTP 和 HTTPS 的区别

可能注意到了。有些网站地址是 `http://` 开头的。有些是 `https://` 开头的。这个"s"很重要。它代表"安全"（Secure）。

**HTTP（HyperText Transfer Protocol）** 是用来传输网页的协议。可以把它理解成运输数据的卡车。但这辆卡车是**透明的**。里面装的东西所有人都能看见。在 HTTP 网站上输入的密码、填写的个人信息。在传输过程中可能被中间的任何人偷看到。

**HTTPS（HTTP Secure）** 是给这辆卡车加了一个**密封的集装箱**。还配了一把钥匙。只有发送方和接收方有钥匙。中间的人就算截获了也看不懂里面是什么东西。这就是加密传输。

<DeploymentHttpsDemo />

### 6.2 HTTPS 的动机

第一个原因：**安全**。没有 HTTPS，用户在网站上输入的密码是明文传输的。但凡有点技术的人都能截获。这年头，谁敢用没有 HTTPS 的网站？

第二个原因：**浏览器警告**。现在 Chrome、Edge 这些主流浏览器都会对没有 HTTPS 的网站显示"不安全"的警告。用户一看 warning 图标。跑了都来不及。更别说注册、充值了。

第三个原因：**SEO**。Google、百度这些搜索引擎都会优先收录 HTTPS 的网站。SEO 效果会更好。

### 6.3 获取 HTTPS 证书的实现

以前 HTTPS 证书很贵。每年要花几百甚至几千块钱。现在好了。出了一个叫 **Let's Encrypt** 的组织。提供完全免费的 SSL/TLS 证书。而且社区有很多自动化工具帮你安装和续期。

**方式一：使用 Certbot（推荐）**

Certbot 是一个自动申请和配置 Let's Encrypt 证书的工具。非常简单：

```bash
# 安装 Certbot
sudo apt install -y certbot python3-certbot-nginx

# 一键申请证书并配置 Nginx
sudo certbot --nginx -d example.com -d www.example.com
```

运行过程中会问几个问题。比如邮箱（用于证书到期提醒）。回答完后证书就自动配置好了。访问网站会发现地址栏多了一个小锁🔒。

证书有效期是 90 天。但 Certbot 会帮你设置定时任务自动续期。基本不用管它。

**方式二：使用 Cloudflare**

如果使用了 Cloudflare 的 DNS 服务。那 HTTPS 证书根本不用自己配置。Cloudflare 会自动为域名提供 HTTPS 支持。而且连 90 天续期的问题都帮你解决了。

### 6.4 配置 HTTPS 后发生了什么变化

配置好 HTTPS 后，用户访问从原来的 `http://example.com` 变成了 `https://example.com`。这个变化带来了一系列的安全保障：

1. **加密传输**：用户和服务器之间的所有通信都是加密的。
2. **身份验证**：证书可以证明"我真的是这个网站"。防止钓鱼网站。
3. **数据完整性**：能检测到数据是否被篡改。

---

## 7. CI/CD：让机器人帮你干活

### 7.1 CI/CD概述

CI/CD 是两个词的缩写：**C**ontinuous **I**ntegration（持续集成）和 **C**ontinuous **D**eployment（持续部署）。可以理解为一套帮你自动干活的机器人系统。

在没有 CI/CD 的时候。每次要发布新功能。流程是这样的：

1. 打开电脑，登录 GitHub
2. 拉取最新代码
3. 运行测试，看看有没有bug
4. 手动构建项目
5. 登录服务器
6. 拉取最新代码
7. 安装依赖
8. 构建项目
9. 重启服务

这9个步骤。每次发布都要手动做一遍。烦不烦？而且很容易漏掉某一步。比如忘记运行测试、忘记重启服务等。

有了 CI/CD 之后。流程变成了这样：

1. 把代码 push 到 GitHub
2. 喝茶坐等
3. （机器人自动完成上面9个步骤）
4. 网站自动更新了

<DeploymentCicdDemo />

这就是 CI/CD 的魅力：**只需要把代码推上去。剩下的全部自动完成**。

### 7.2 CI/CD 的工作流程

一个典型的 CI/CD 流程是这样的：

**第一步：代码提交（Push）**

完成了新功能的开发。把代码 push 到 GitHub。

**第二步：CI（持续集成）触发**

GitHub 检测到代码变动。通知 CI 系统（GitHub Actions、GitLab CI 等）开始工作。

**第三步：安装依赖和测试**

CI 系统会启动一台虚拟电脑。在上面：
- 安装项目需要的各种依赖
- 运行测试代码，确保没有 bug
- 构建项目，生成产物

如果测试失败。CI 会发邮件通知。这次部署就停了。不会把有问题的代码部署到生产环境。

**第四步：CD（持续部署）执行**

测试全部通过后。CI 系统会：
- 通过 SSH 连接到服务器
- 拉取最新代码
- 安装依赖
- 构建项目
- 重启服务

整个过程可能只需要几分钟。全部自动完成。

### 7.3 配置 GitHub Actions 的实现

GitHub Actions 是 GitHub 自带的 CI/CD 功能。不需要额外付费（免费额度足够个人项目用）。配置起来也非常简单。

在项目根目录下创建 `.github/workflows/deploy.yml` 文件。写入以下配置：

```yaml
name: Deploy to Production

# 触发条件：每当 main 分支有代码推送时
on:
  push:
    branches: [main]

# 任务列表
jobs:
  # 部署任务
  deploy:
    # 在什么系统上运行
    runs-on: ubuntu-latest
    
    # 具体步骤
    steps:
      # 1. 检出代码
      - name: Checkout code
        uses: actions/checkout@v3

      # 2. 安装 Node.js 环境
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      # 3. 安装依赖并构建
      - name: Install and Build
        run: |
          npm ci
          npm run build

      # 4. 部署到服务器
      - name: Deploy to Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/my-website
            git pull origin main
            npm install
            npm run build
            pm2 restart all
```

这个配置文件告诉 GitHub Actions：

- 当 main 分支有新代码时触发
- 在一台 Ubuntu 电脑上执行任务
- 先安装 Node.js 18
- 然后安装依赖并构建项目
- 最后通过 SSH 连接到服务器，执行一系列部署命令

配置好之后。每次 `git push origin main`。GitHub 就会自动开始部署。非常方便。

---

## 8. 监控和日志：做网站的"守夜人"

### 8.1 监控的动机

网站上线后。理论上应该 7×24 小时不间断运行。但现实世界没有这么美好。服务器可能会宕机。网络可能会抖动。代码可能会有bug。在真实的生产环境中。各种意外情况都有可能发生。

如果没有监控。就只能等用户打电话告诉你"网站打不开了"。这时候往往已经晚了。用户可能已经流失了。

有了监控之后。可以：

- **提前发现问题**：CPU 使用率 90% 了。提前加服务器。
- **快速定位问题**：网站慢了。查监控看是哪里瓶颈。
- **心里有底**：每天多少人访问、访问量什么时候最高。

<DeploymentMonitorDemo />

### 8.2 监控哪些指标

最重要的监控指标就这几个：

| 指标 | 正常范围 | 超过怎么办 |
|------|---------|-----------|
| CPU 使用率 | < 70% | 升级服务器配置或优化代码 |
| 内存使用率 | < 80% | 检查是否有内存泄漏 |
| 磁盘使用率 | < 80% | 清理日志或无用文件 |
| 网站可达性 | 100% | 检查服务是否正常运行 |
| 响应时间 | < 2 秒 | 优化数据库查询或加缓存 |
| 错误率 | < 1% | 查看错误日志定位问题 |

### 8.3 配置监控的实现

**最简单的方案：Uptime Robot**

注册 uptimerobot.com。添加网站URL。它会每 5 分钟自动检查一次网站是否正常。网站挂了会发邮件通知你。免费版本可以监控 50 个网站。对个人项目来说完全够用。

**进阶方案：阿里云/腾讯云监控**

如果服务器是在阿里云或腾讯云买的。它们自带监控功能。配置一下阈值报警就行。

**专业方案：Prometheus + Grafana**

这两个是监控领域的"瑞士军刀"。功能非常强大。可以监控任何能想到的指标。还能做出漂亮的可视化图表。不过配置起来比较复杂。适合有一定经验的开发者。

### 8.4 日志：故障排查流程

监控告诉你"网站出问题了"。但具体是什么问题、为什么出问题。需要靠**日志**来定位。

日志就是程序运行时的"日记本"。记录了程序运行过程中的点点滴滴：

- 哪个用户在什么时候访问了什么页面
- 数据库查询花了多长时间
- 有没有报错，错误信息是什么

**最基础的日志用法**

在服务器上查看应用日志：

```bash
# 查看 PM2 的日志
pm2 logs

# 查看 Nginx 的访问日志
tail -f /var/log/nginx/access.log

# 查看 Nginx 的错误日志
tail -f /var/log/nginx/error.log
```

**进阶的日志方案**

如果项目比较复杂。推荐使用专业的日志收集工具：

- **Loki**：免费开源。和 Prometheus 一家的。
- **ELK（Elasticsearch + Logstash + Kibana）**：功能强大。但配置复杂。
- **Sentry**：专门用于收集应用错误的工具。能自动收集报错信息。

### 8.5 告警：故障通知机制

监控告诉你有问题。但如果没有盯着监控面板看，怎么办？这就需要**告警**了。

告警就是当监控系统检测到异常时。自动通过短信、微信、钉钉、邮件等方式通知你。可以设置不同的告警级别：

- **紧急（网站完全挂掉）**：发短信+打电话。必须马上知道。
- **严重（错误率飙升）**：发钉钉/微信消息。看到就处理。
- **一般（CPU 偏高）**：发邮件汇总。一天看一次就行。

告警配置的核心原则是：**分级告警，别把自己烦死**。如果什么鸡毛蒜皮的小事都给你发短信。用不了多久你就会把告警关掉。

---

## 9. 常见问题速查表

| 问题现象 | 可能原因 | 解决方法 |
|---------|---------|---------|
| 网站打不开 | 域名没解析 / 服务器挂了 / Nginx 没启动 | `ping 域名` 看通不通；`pm2 list` 看服务状态；`systemctl status nginx` 看 Nginx |
| 打开是空白页面 | 构建产物路径不对 / 静态文件没正确配置 | 检查 Nginx 的 root 路径是否指向 dist 目录 |
| 404 页面找不到 | 路由没正确配置 / 路径拼写错误 | Nginx 配置里加上 `try_files $uri $uri/ /index.html` |
| 502 Bad Gateway | 后端服务挂了 / 端口没开 | `pm2 list` 看进程是否在运行；检查端口是否正确 |
| 403 Forbidden | 权限不对 / 索引目录没开 | 检查文件权限 `chmod -R 755`；Nginx 配置加上 `autoindex on` |
| HTTPS 证书过期 | 证书到期没续期 | `certbot renew` 手动续期；检查自动续期定时任务 |
| 更新后看不到变化 | 浏览器缓存 / CDN 缓存 | Ctrl+Shift+R 强制刷新；去 CDN 控制台"刷新缓存" |
| 网站打开很慢 | 带宽不够 / 没开缓存 / 没配置 CDN | 升级服务器带宽；配置 Redis 缓存；接入 CDN |
| 数据库连不上 | 数据库没启动 / 密码错了 / 权限问题 | 检查数据库服务状态；核对配置里的连接信息 |

---

## 总结

服务上线是一个系统性的大工程。涉及从代码构建到服务器部署、从网络配置到安全防护、从监控告警到日志分析的方方面面。对于初学者来说。不需要一开始就追求完美。先把最小可用版本（MVP）跑起来。然后在此基础上逐步完善。

整个流程的核心要点可以归纳为以下几点：

### 核心流程

1. **构建** → 用 `npm run build` 把代码变成浏览器能看懂的 HTML/CSS/JS
2. **部署** → 把构建产物上传到服务器。用 Nginx 配置反向代理。
3. **域名** → 购买域名并配置 DNS 解析到服务器 IP
4. **HTTPS** → 用 Let's Encrypt 申请免费证书。保护数据传输安全。
5. **CI/CD** → 配置自动化部署。代码 push 后自动上线。
6. **监控** → 配置监控和告警。出问题第一时间知道。

### 学习路线建议

- **第1天**：用 Vercel/Netlify 部署一个静态网页。体验一下"代码变成网站"的感觉。
- **第1周**：租一台云服务器。手动部署一个 Node.js 项目。配置域名和 HTTPS。
- **第2-4周**：配置完整的 CI/CD 流程。建立监控和告警体系。
- **持续学习**：学习 Docker 容器化、学习 Kubernetes 集群、学习微服务架构。

---

## 名词速查表

| 名词 | 英文 | 用人话解释 |
|------|------|-----------|
| 构建 | Build | 把源代码翻译打包成浏览器能执行的格式 |
| 部署 | Deploy | 把代码放到服务器上让用户能访问 |
| 服务器 | Server | 7×24小时不关机、联网的电脑 |
| 域名 | Domain | 网站的好记名字（如 baidu.com） |
| DNS | Domain Name System | 把域名翻译成 IP 地址的"电话簿" |
| HTTP | HyperText Transfer Protocol | 网页传输协议（不安全，明文传输） |
| HTTPS | HTTP Secure | 加密传输的网页协议（安全） |
| Nginx | Engine X | 高性能 Web 服务器。做反向代理的。 |
| 反向代理 | Reverse Proxy | 站在门口的服务员。把请求转发给后端。 |
| SSH | Secure Shell | 远程登录服务器的加密工具 |
| CDN | Content Delivery Network | 全球分布的服务器网络。加快访问速度。 |
| CI/CD | Continuous Integration/Deployment | 自动化流水线。代码 push 后自动测试部署。 |
| SSL/TLS | Secure Sockets Layer / Transport Layer Security | 加密协议。给 HTTPS 提供安全保障。 |
| PM2 | Process Manager 2 | Node.js 进程管理器。让应用持续运行。 |