sanbuphy
cd2ce9e661
- Rewrite and expand the deployment guide with more detailed explanations - Add interactive tooltips to the deployment overview demo - Include step-by-step instructions for each deployment phase - Add troubleshooting table for common issues - Improve structure with clear section headings and flow
703 lines
30 KiB
Markdown
703 lines
30 KiB
Markdown
# 服务上线之旅：从零开始的完整指南
|
||
|
||
::: 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 进程管理器。让应用持续运行。 |
|