第 14 章 · 集群与高可用
单台服务器再好也会宕机。本章把「集群」拆开讲:负载均衡怎么做、双机热备怎么实现、共享存储怎么挂、集群怎么监控、Kubernetes 是什么。学完你能看懂绝大多数中小公司的服务器架构图,也能自己搭一套「两台机器扛住一台的故障」。
本章目录
14.1 集群三问 14.2 负载均衡方案 14.3 Nginx upstream 14.4 Keepalived 双机热备 14.5 共享存储 NFS 14.6 集群监控 14.7 Kubernetes 入门 14.8 架构选型 自测题14.1集群三问:为什么、是什么、怎么搭
- 为什么集群:单点故障(一台挂了服务全断)、性能上限(一台扛不住流量)、扩展性(加机器就能加容量)。
- 三个目标:高可用(挂了自动切换)、负载均衡(流量分摊)、可扩展(加节点扩容)。
- 三个组件:入口(LB 负载均衡)→ 工作节点(跑业务的多台)→ 状态层(数据库/存储,集群中最难的部分)。
新手最容易搞反的认知
集群 ≠ 把服务装到多台机器就完事。难点排序:无状态服务(Web)最容易集群 → 有状态服务(数据库)最难集群。先把无状态的 Web 做成多副本 + 负载均衡,再谈数据库高可用(主从/双主),这是正确顺序。
14.2负载均衡方案:从便宜到专业
| 方案 | 层级 | 特点 |
|---|---|---|
| DNS 轮询 | 应用层(域名解析) | 一个域名解析到多台 IP;零成本但不感知故障(一台挂了仍有流量过去) |
| Nginx/HAProxy 反向代理 | 应用层(L7) | 最常用:按 URL 分发、健康检查、会话保持;中小公司主力 |
| LVS(Linux Virtual Server) | 内核层(L4) | 高性能四层转发(DR/NAT/TUN 模式),阿里 SLB 底层技术之一 |
| 云厂商 LB(SLB/ALB) | 托管 | 云上最省心:自带健康检查、证书、弹性 |
学习顺序:先 Nginx upstream(本章 14.3)→ 再理解 LVS 概念 → 生产用云 LB 或自建 Nginx/HAProxy 双机。LVS 需要单独成章深学,入门阶段会用 Nginx 即可。
14.3Nginx upstream:把流量分给多台后端
upstream web_backend {
least_conn; # 最少连接;默认轮询;ip_hash 会话保持
server 10.0.0.11:80 weight=2; # weight 权重(机器强的多分)
server 10.0.0.12:80;
server 10.0.0.13:80 backup; # backup:前两台挂了才启用(高可用)
keepalive 32;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://web_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
# 健康检查(Nginx 开源版用被动检查:连续失败自动摘除)
# max_fails=3 fail_timeout=30s;(加在 server 行尾)
sudo nginx -t && sudo systemctl reload nginx
# 在后端每台 echo "我是后端1/2/3",多刷新几次页面观察轮询效果
curl -s http://example.com
# 停掉一台后端,流量应自动只去存活机器(被动健康检查生效)
14.4Keepalived:双机热备与 VIP(负载均衡自己不挂)
负载均衡器本身是单点 —— Keepalived 用 VRRP 协议让两台 LB 共享一个虚拟 IP(VIP):主节点活着 VIP 归它,主节点挂了 VIP 秒级漂移到备机。业务方永远访问 VIP,完全无感。
vrrp_instance VI_1 {
state MASTER # 备机写 BACKUP
interface eth0
virtual_router_id 51 # 两台必须一致
priority 100 # 主 100,备 90(谁高谁是主)
advert_int 1
authentication {
auth_type PASS
auth_pass 你的密码
}
virtual_ipaddress {
10.0.0.200 # VIP:业务访问这个 IP
}
}
# 安装:apt install keepalived(Rocky: dnf install keepalived)
# 启动:systemctl enable --now keepalived;ip addr 看 VIP 在哪台
高可用的另一半:业务层
Keepalived 只保证「入口 IP 不丢」。业务数据要同步:Web 无状态(随便切)、数据库需要主从复制(进阶课题)——数据库高可用是集群最深的坑,先学会主从复制(binlog 同步),再谈自动切换(如 MHA/ProxySQL 等)。
14.5共享存储:NFS(多台机器读同一份数据)
多台 Web 节点要读同一批上传文件/静态资源时,用 NFS 把存储节点的目录共享出去:
# 服务端:安装并导出目录
sudo apt install nfs-kernel-server # Rocky: dnf install nfs-utils
sudo mkdir -p /data/share && sudo chown nobody:nogroup /data/share
echo "/data/share 10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash)" \
| sudo tee -a /etc/exports
sudo exportfs -ra && sudo systemctl enable --now nfs-server
# 客户端:挂载(写 fstab 永久挂载,见第 3 章)
sudo apt install nfs-common # Rocky: dnf install nfs-utils
sudo mkdir -p /data/web/uploads
sudo mount -t nfs 10.0.0.20:/data/share /data/web/uploads
df -h | grep nfs # 验证挂载
注意:NFS 是共享存储的入门方案;高并发/强一致场景用分布式文件系统(Ceph/GlusterFS,进阶)或对象存储(云 OSS/S3)。
14.6集群监控:Prometheus + Grafana(监控多台的标准答案)
- Prometheus:抓取各机器/服务的指标(node_exporter 采集 CPU/内存/磁盘/网络),存时序数据库,带告警规则(Alertmanager 推通知)。
- Grafana:把指标画成漂亮大盘,接 Prometheus 数据源。
# 每台被监控机器装采集器:
sudo docker run -d --name node-exporter -p 9100:9100 \
-v /proc:/host/proc -v /sys:/host/sys --net=host \
prom/node-exporter
# 监控服务器起 prometheus + grafana(compose.yml 三服务,第 13 章)
# prometheus.yml 里 scrape_configs 加 targets: ["服务器IP:9100"]
# Grafana 登录后:数据源加 http://prometheus:9090,导入仪表盘模板 1860(node exporter 经典模板)
这就是「随时随地看全集群状态 + 告警」的现代答案,也是你羡慕的监控能力的最终形态。
14.7Kubernetes(K8s):集群的「操作系统」入门认知
机器多了、服务多了,人工管理开始失控 —— K8s 把「部署、伸缩、自愈、服务发现」自动化。入门只需要先懂 5 个词:
| 概念 | 一句话 |
|---|---|
| Node | 集群里的一台机器(工作节点) |
| Pod | K8s 的最小调度单位(一个或多个容器,共享网络) |
| Deployment | 声明「要几个 Pod、镜像是什么」,自动滚动更新与自愈 |
| Service | 给一组 Pod 一个稳定访问入口(负载均衡 + 服务发现) |
| Ingress | 集群入口,按域名/路径把外部流量路由到 Service |
学习路线建议
K8s 不要现在深学:先把 Docker 用熟(第 13 章)、把「3 台虚拟机搭单节点 K8s」当成第 14 章之后的进阶项目,配合官方文档与认证(CKA,第 16 章)。先理解「它解决什么问题」,比先记一堆 yaml 重要。
14.8架构选型速查(按你的规模)
| 规模 | 推荐架构 |
|---|---|
| 1 台小服务器 | 单机 LNMP/Docker + 备份 + 监控告警(第 12/10 章) |
| 2–5 台 | Nginx 负载均衡(可 Keepalived 双机)+ 两台 Web + 独立数据库节点 + Prometheus 监控 |
| 5–20 台 / 高流量 | 云 LB 或自建 LB 双机 + Web 集群 + 数据库主从 + 对象存储/CDN + 集中日志(第 10 章扩展) |
| 微服务 / 快速增长 | 容器化 + K8s(演进路线:Compose → K8s) |
本章自测题
- 集群要解决的三个问题与三个目标是什么?
- 「无状态服务」和「有状态服务」集群难度差别为什么大?各举一例。
- Nginx upstream 实现负载均衡的核心配置段与关键参数(weight/backup/least_conn)。
- Keepalived 解决什么问题?VIP 是什么?主备如何切换?
- 两台 Web 共享上传文件,用什么方案?服务端与客户端各需要什么?
- Prometheus + Grafana 各自职责?node_exporter 干什么?
- K8s 的 Pod、Deployment、Service 各是什么?
- 2–5 台服务器的推荐架构画出来(文字描述即可)。
参考答案
1. 单点故障/性能上限/扩展性 → 高可用、负载均衡、可扩展。
2. 无状态(Web)挂哪台都能服务,随便加副本;有状态(数据库)数据必须一致,切换要同步复制。
3. upstream 块 + server 行;weight=权重、backup=备用、least_conn=最少连接。
4. 让两个 LB 共享 VIP,主挂备自动接管(VRRP 协议),业务无感。
5. NFS:服务端 exports 导出 + 客户端 mount 挂载(写 fstab)。
6. Prometheus 采集存储指标+告警;Grafana 画图展示;node-exporter 暴露机器指标。
7. Pod=最小调度单位;Deployment=声明副本数与镜像并自愈;Service=稳定访问入口。
8. LB(Nginx,可双机 Keepalived)+ 2 台 Web + 独立 DB 节点 + Prometheus/Grafana 监控。