从刷抖音说起：你每天都在 “用” 服务器，却可能不认识它

从刷抖音说起：你每天都在 “用” 服务器，却可能不认识它 - 详解

news/2025/10/3 12:24:40/文章来源:https://www.cnblogs.com/yxysuanfa/p/19124491

凌晨 2 点，我突然被手机震醒 —— 监控告警推送：“电商核心数据库服务器 CPU 使用率达 98%，响应延迟超 800ms”。爬起来打开电脑，远程连接到服务器集群，一步步排查：top 命令看进程，发现 mysql 占满 CPU；show processlist 查连接，一堆重复 SQL 在等待；explain 分析语句，果然是没加索引的全表扫描…… 加完索引，CPU 使用率瞬间掉到 30%，延迟恢复到 100ms 以内时，天已经蒙蒙亮了。

这是我做服务器工程师 5 年来的日常缩影。很多人听说 “服务器工程师”，第一反应是 “修电脑的？”“跟网管差不多？”—— 其实差远了。在开始讲我们的工作前，不如先搞清楚：到底什么是服务器？它跟你家里的电脑有啥区别？为什么少了它，我们的数字生活就玩不转？

一、服务器不是 “高端电脑”，而是数字世界的 “基建核心”

先抛个结论：服务器本质是 “献出计算 / 存储 / 网络服务的专用设备”，但它不是 “更贵的家用电脑”—— 从硬件到软件，从用途到可靠性，两者完全是两个物种。

1.1 硬件：服务器的 “身体”，每一寸都为 “稳定” 设计

你拆开家用电脑，能看到 CPU、内存、硬盘、主板；服务器也有这些部件，但每一个都经过 “特殊改造”，目标只有一个：7×24 小时不间断工作，不能掉链子。

先说说 CPU。家用电脑大多是 1 颗 CPU（最多 2 颗），比如 Intel 的 i5/i7；但服务器常用 “多路 CPU”，比如 2 颗、4 颗甚至 8 颗 Intel Xeon（至强）或 AMD EPYC（霄龙）。为什么要多颗？因为业务需要 “并行计算”—— 比如双 11 时，阿里的服务器要同时处理上亿用户的浏览、下单、支付，1 颗 CPU 根本扛不住。而且服务器 CPU 的 “核心数” 更多，比如 Xeon Gold 6448Y 有 36 核 72 线程，能同时跑上百个任务，这是家用 CPU 比不了的。

再看内存。你家电脑内存可能是 16G、32G，而服务器起步就是 64G，大的能到几 TB（比如 1TB=1024GB）。更关键的是，服务器用的是ECC 内存—— 这种内存能自动检测并修复 “单比特错误”（比如内存信息偶尔出错），还能预警 “多比特错误”。别小看这个功能：如果家用电脑内存出错，最多是脚本崩溃；但服务器内存出错，可能导致数据库丢数据、支付交易失败，损失可不是小数目。

硬盘就更不一样了。家用电脑常用 SSD（固态硬盘）或 HDD（机械硬盘），追求 “个人使用的速度”；服务器则分两种场景：要速度的用NVMe SSD（读写速度能到 3000MB/s 以上，是普通 SSD 的 3 倍），比如电商商品详情页、直播推流；要容量的用SAS 硬盘（机械硬盘的一种，稳定性比普通 HDD 强，适合存日志、备份信息），甚至用 “存储阵列”（多块硬盘组合，即使一块坏了，数据也不会丢）。

最后是网卡。你家宽带可能是 100M、1000M（1G），服务器网卡起步就是 10G，高端的能到 25G、40G 甚至 100G。为什么？比如抖音的一个服务器，要同时给上万个用户传视频，1G 网卡分分钟就满了，必须靠高带宽网卡才能扛住流量。

除了这些核心部件，服务器的电源、散热也很特殊。比如电源是 “冗余电源”——2 个电源同时工作，一个坏了，另一个能立刻接手，不会断电；散热用的是 “冗余风扇”，即使 1 个风扇停转，其他风扇会自动加速，保证服务器不高温。这些设计，都是为了避免 “单点故障”—— 家用电脑坏了，你重启就行；服务器坏了，可能影响几十万用户。

1.2 软件：服务器的 “大脑”，决定它能做什么

光有硬件还不行，服务器需要专门的软件 “驱动”，才能发挥作用。

最基础的是操作系统通过 Linux 系统。就是。家用电脑用 Windows 10/11、macOS，服务器则以 Linux 为主（比如 CentOS、Ubuntu Server、Red Hat），少数用 Windows Server。为什么选 Linux？因为它稳定（能连续运行几年不重启）、开源（能够根据需求改代码）、支持多用户多任务（同时给几百个用户提供服务）。比如你访问的百度、淘宝、抖音，背后的服务器几乎全

操作系统之上，是中间件和应用。比如 Web 服务器用 Nginx、Apache（负责接收用户的网页请求，返回内容）；应用服务器用 Tomcat、Jetty（运行 Java 写的后端程序）；数据库服务器用 MySQL、PostgreSQL（存储用户信息，比如你的账号、订单）；缓存服务器用 Redis、Memcached（把常用数据存在内存里，加快访问速度，比如你刷抖音的 “推荐列表”）。

这些软件不是随便装的 —— 比如 MySQL 要配置 “主从复制”（主服务器写数据，从服务器读数据，分担压力）；Redis 要做 “集群”（多台 Redis 服务器一起工作，避免一台坏了数据丢失）；Nginx 要配置 “负载均衡”（把用户请求分到多台 Web 服务器上，不让单台服务器过载）。

1.3 服务器 vs 家用电脑：5 个关键区别，看完就懂

很多人会问：“我把家用电脑装个 Linux，能不能当服务器用？” 理论上行，但实际用起来会出大问题。两者的核心区别，体现在 5 个方面：

对比维度	服务器	家用电脑
运行时间	7×24 小时不间断（每年停机不超几分钟）	每天用几小时，晚上可能关机
稳定性要求	极高（故障会影响业务 / 用户）	一般（故障最多影响个人使用）
扩展性	强（支持加 CPU、内存、硬盘、网卡）	弱（大多只能加内存、硬盘）
管理方式	远程管理（SSH、IPMI）	本地操作（鼠标键盘）
硬件设计	冗余（电源、风扇、硬盘）	无冗余（坏一个部件就停）

举个例子：如果你用家用电脑当 “个人博客服务器”，偶尔有人访问还行；但如果突然有 1000 个人同时访问，家用电脑的 CPU、内存、网卡会瞬间满负荷，博客直接打不开 —— 这就是 “性能瓶颈”。而真正的服务器，能通过 “集群”（多台服务器一起工作）轻松扛住上万并发。

二、服务器分哪些种类？不同 “角色” 各司其职

就像公司里有产品、开发、运营，服务器也有不同 “分工”—— 根据用途，能分成 6 大类，每一类都有自己的 “技能点”。

2.1 按用途分：从 Web 到缓存，每种服务器都是 “专精人才”

（1）Web 服务器：用户的 “第一接触点”

你在浏览器输入 “www.baidu.com”，第一个接收请求的就是 Web 服务器。它的作用是 “接收 HTTP 请求，返回网页内容”—— 可能是静态的 HTML/CSS/JS，也可能是动态生成的页面（比如你搜索的结果）。

常用的 Web 服务器软件有 Nginx、Apache、IIS（Windows Server 用）。其中 Nginx 因为 “轻量、高性能、支持高并发”，成了现在的主流 —— 比如阿里、腾讯、字节的 Web 服务器，几乎全是 Nginx。

我之前做过一个电商工程，初期用 1 台 Nginx 服务器，每天 10 万访问量还行；后来搞促销，访问量涨到 100 万，Nginx 直接扛不住了。怎么办？加了 2 台 Nginx，做 “负载均衡集群”—— 用户请求先到 “负载均衡器”，再分到 3 台 Nginx 上，压力一下就分散了，访问速度也快了。

（2）数据库服务器：存储数据的 “金库”

你的微信账号、淘宝订单、抖音收藏，都存在数据库服务器里。它的核心需求是 “数据安全、读写速度快、不丢数据”。

常用的数据库分两种：关系型（MySQL、PostgreSQL、Oracle）和非关系型（MongoDB、Redis——Redis 也常当缓存用）。比如电商的 “订单表”，因为要关联用户、商品、支付信息，用 MySQL（关系型）；而抖音的 “用户评论”，数据格式不固定，用 MongoDB（非关系型）更灵活。

数据库服务器是 “重中之重”—— 一旦出挑战，数据丢了，业务就崩了。我之前遇到过一次 “数据库误删表”：创建不小心执行了 “drop table”，把用户订单表删了。幸好我们做了 “全量 + 增量备份”：前一天的全量备份恢复基础数据，当天的增量备份恢复最新订单，花了 2 小时才恢复，没造成大损失。从那以后，我们给数据库加了 “权限控制”—— 开发只能读，不能删表。

（3）应用服务器：业务逻辑的 “计算器”

Web 服务器负责 “接收请求”，数据库服务器负责 “存数据”，中间的 “业务逻辑” 就靠应用服务器处理。比如你在淘宝下单，“计算折扣、判断库存、生成订单” 这些运行，都是应用服务器做的。

用 Java 写的，跑在 Tomcat 上。就是应用服务器的软件，跟开发语言有关：Java 开发用 Tomcat、Jetty、Spring Boot；Python 开发用 Django、Flask；Go 开发用 Gin、Beego。比如阿里的 “支付宝” 后端，就

应用服务器的 “弹性伸缩” 很关键 —— 比如电商大促时，订单量是平时的 10 倍，需要临时加 10 台应用服务器；促结束后，再把多余的服务器关掉，节省成本。现在云服务器（比如阿里云 ECS）就能做到 “自动伸缩”，不用手动运行。

（4）缓存服务器：加速访问的 “快取”

如果用户每次访问都要查数据库，数据库会很累 —— 比如抖音的 “热门视频”，每天有几百万用户看，倘若每个用户都查一次数据库，数据库肯定扛不住。这时候就需要缓存服务器：把 “热门视频” 存在内存里，用户再访问，直接从缓存里拿，不用查数据库，速度快多了。

最常用的缓存服务器是 Redis—— 它的读写速度能到每秒 10 万次以上，是 MySQL 的 10 倍。比如大家做的电商项目，把 “商品详情页”“用户购物车” 存在 Redis 里，数据库的压力减少了 70%，页面加载速度从 500ms 降到了 50ms。

但缓存也有 “坑”—— 比如 “缓存雪崩”：假如 Redis 服务器突然宕机，所有请求都冲到数据库，数据库瞬间就崩了。我们的解决办法是 “Redis 集群”：3 台 Redis 服务器，1 台主服务器，2 台从服务器，主服务器坏了，从服务器能立刻接手，不会断缓存。

（5）负载均衡服务器：请求的 “交通警察”

当你有 10 台 Web 服务器、20 台应用服务器时，怎么把用户请求 “均匀” 地分到这些服务器上？靠的就是负载均衡服务器。它的作用是 “分发请求，避免单台服务器过载，提高可用性”。

常用的负载均衡软件有 Nginx（也能做简单负载均衡）、HAProxy、LVS。其中 LVS 是 “四层负载均衡”（基于 TCP/IP 协议），性能极强，能扛百万级并发；HAProxy 是 “七层负载均衡”（基于 HTTP 协议），能做更精细的转发（比如根据 URL 转发到不同服务器）。

我之前做过一个直播项目，用 LVS+HAProxy 做了 “二级负载均衡”：用户请求先到 LVS（第一层），分到 2 台 HAProxy（第二层），再由 HAProxy 分到 10 台 Web 服务器。这样即使 1 台 HAProxy 坏了，LVS 会自动把请求分到另一台，不会影响用户看直播。

（6）文件服务器：存储大文件的 “仓库”

你的微信头像、抖音视频、淘宝商品图片，都是 “大文件”，不适合存在数据库里（数据库适合存小数据，比如文字），这时候就需要材料服务器。它的核心需求是 “存储容量大、读写速度快、支持高并发”。

常用的记录服务器方案有 NFS（容易，适合小规模）、GlusterFS（分布式，适合大规模）、MinIO（对象存储，适合云环境）。比如字节跳动的 “火山引擎”，就是用 MinIO 存储用户上传的视频，拥护 PB 级容量（1PB=1024TB）。

我们之前做过一个教育项目，用户要上传课程视频（每个视频 1-2GB），初期用 NFS，结果 100 个用户同时上传，服务器就卡住了。后来换成 GlusterFS，用 10 台服务器做 “分布式存储”，每个视频分成 10 块，存在不同服务器上，上传速度快了 5 倍，也不卡了。

2.2 按硬件形态分：机架、刀片、塔式，适合不同场景

除了用途，服务器的 “长相” 也不一样 —— 根据硬件形态，能分成 3 类，适合不同的使用场景。

（1）机架式服务器：IDC 机房的 “主流选手”

机架式服务器。它的尺寸按 “U” 计算（1U=4.445cm），常见的有 1U、2U、4U。就是你去阿里云、腾讯云的 IDC 机房（数据中心），会看到一排排 “柜子”（机柜），里面插满了 “扁平的盒子”—— 这就

机架式服务器的优点是 “节省空间、便于管理”——1 个 42U 的机柜，能装 42 台 1U 服务器，或者 21 台 2U 服务器。而且它的接口（电源、网卡、USB）都在前面或后面，方便插线和维护。

几乎所有互联网公司的服务器，都是机架式的 —— 比如阿里的 “飞天” 系统，就是跑在几十万台 1U 机架式服务器上。我之前去 IDC 机房维护服务器，要先穿防静电服，拿着 KVM（远程控制设备），一个个机柜检查，累但很有成就感。

（2）刀片式服务器：高密度的 “空间杀手”

如果机架式服务器还不够 “省空间”，就用刀片式服务器 —— 它把多个 “刀片”（相当于独立的服务器）插在一个 “刀箱” 里，1 个刀箱能装 10-20 个刀片，空间利用率比机架式高很多。

刀片式服务器的优点是 “高密度、低功耗、易管理”—— 比如一个刀箱有统一的电源、散热、网络模块，不用给每个刀片单独插电源和网线，管理起来很方便。缺点是 “成本高”—— 刀箱和刀片都比机架式贵，而且一旦刀箱坏了，里面所有刀片都用不了。

刀片式适合 “超大规模数据中心”，比如谷歌、亚马逊的服务器集群，用刀片式能节省大量机房空间和电费。我们公司没用过刀片式，重要是成本太高，小公司用不起。

（3）塔式服务器：小型企业的 “入门选择”

塔式服务器长得像 “家用电脑主机”，只是更大、更重。它的优点是 “价格低、易维护”—— 不用机柜，直接放在桌子上就行，适合小规模使用（比如公司内部的文件服务器、打印服务器）。

“占用空间大、扩展性差”——1 台塔式服务器占的空间，能放 2 台 2U 机架式服务器，而且最多只能加 2 颗 CPU、64G 内存，没办法大规模扩展。就是缺点

我刚工作时，在一家小型电商公司，用的就是塔式服务器 ——1 台当 Web 服务器，1 台当数据库服务器，每天几千订单还行；后来订单涨到几万，塔式服务器扛不住了，才换成机架式集群。

三、服务器工程师：不是 “修电脑的”，而是数字基建的 “守护者”

讲完服务器，终于到正题了：服务器工程师到底是做什么的？便捷说，我们的工作是 “设计、部署、维护、优化服务器集群，确保业务稳定运行”—— 就像数字世界的 “基建工程师”，修的是 “看不见的公路和桥梁”。

3.1 岗位定位：撑起业务稳定的 “幕后英雄”

很多人以为大家 “只跟服务器打交道”，其实不是 —— 我们要跟开发、产品、测试、运维（比如网络运维、安全运维）协作，甚至要懂业务。比如：

开发要上线新能力，我们要评估 “需要加多少台应用服务器”；
产品要搞促销活动，我们要提前 “扩容服务器集群”，避免崩掉；
安全运维发现漏洞，我们要 “给服务器打补丁”，防止被黑客攻击。

等故障发生了再修。就是我们的核心 KPI（关键绩效指标）是 “可用性”—— 比如服务器集群的 “全年可用性 99.99%”，意味着每年停机时间不能超过 52 分钟。要达到这个目标，必须做很多 “防患于未然” 的工作，而不

3.2 核心工作一：从 0 到 1，搭建靠谱的服务器集群

任何业务的服务器集群，都不是 “买几台服务器插上电就行”—— 需要从需求分析到部署落地，一步步规划，稍有不慎就会留坑。

3.2.1 需求分析：先搞懂业务要什么

“问清楚业务需求”—— 比如：就是第一步不是选硬件，而

这个业务是 Web 网站还是 APP 后端？
每天有多少用户访问？高峰期并发多少？
要存储多少数据？数据增长速度如何？
对响应时间有要求吗？比如要低于 200ms？

我之前接了一个 “社区 APP” 的项目，产品说 “初期 10 万用户，后期可能涨到 100 万”。我算了一下：10 万用户每天发 1 万条帖子，每条帖子 1KB，一年才 3.6GB 数据，存储压力不大；但高峰期 1 万用户同时刷首页，需要 5 台应用服务器才能扛住。若是当时没算清楚，只买 2 台应用服务器，上线后肯定崩。

3.2.2 硬件选型：不是越贵越好，而是 “刚刚好”

需求清楚了，就开始选硬件 —— 这里的关键是 “平衡性能和成本”，不是越贵越好。

比如选 CPU：假设是数据库服务器，要选 “多核、高缓存” 的（比如 Xeon Gold 6448Y），因为数据库查询需要多线程；如果是缓存服务器，要选 “高频、低功耗” 的（比如 Xeon E-2388G），基于缓存读写快，不应该太多核。

选内存：Web 服务器和应用服务器，内存够跑程序就行（比如 64G）；数据库服务器要大内存（比如 256G），因为可以把数据缓存到内存里，减少硬盘读写；缓存服务器则需要超大内存（比如 512G），因为所有数据都存在内存里。

选硬盘：Web 服务器用 NVMe SSD（存静态资源，比如图片、JS）；数据库服务器用 “NVMe SSD+SAS 硬盘”（SSD 存热点数据，SAS 存冷数据）；文件服务器用 “大容量 SAS 硬盘”（存大文档，比如视频）。

我之前遇到过一个 “坑”：给一个日志存储项目选了普通 HDD 硬盘，结果每天要写入 100GB 日志，HDD 的写入速度太慢，日志堆积了十几个小时，差点影响故障排查。后来换成 SAS 硬盘，问题就解决了 —— 这就是 “选型错误导致的问题”。

3.2.3 部署落地：环境、软件、网络，一个都不能错

硬件到位后，就是 “部署”—— 包括体系安装、软件配置、网络调试，每一步都要仔细。

首先是操作系统安装。我们大多用 Linux，比如 CentOS 7/8、Ubuntu Server 20.04。安装时要注意：

分区：/boot 分 500MB，/swap 分内存的 2 倍（比如 64G 内存分 128G swap），/ 根分区用剩余空间；
关闭无用服务：比如防火墙（如果有专门的防火墙设备）、SELinux（安全增强组件，新手容易踩坑）；
安装必要工具：比如 SSH（远程连接）、vim（编辑文档）、top（查看进程）。

然后是软件部署。比如部署 MySQL 数据库，要做这些安装：

改配置文件 my.cnf：调整内存占用（比如 innodb_buffer_pool_size 设为内存的 50%）、连接数（max_connections 设为 1000）；
做主从复制：主库写，从库读，分担压力；
初始化数据：创建数据库、用户，设置权限（比如给编写只读权限）。

网络调试。要确保服务器之间能互通，用户能访问到服务器：就是最后

调整 IP 地址：给每台服务器配静态 IP（比如 192.168.1.100）；
设置路由：让不同网段的服务器能通信（比如 Web 服务器和数据库服务器在不同网段）；
配置防火墙：只开放需要的端口（比如 Web 服务器开放 80/443 端口，数据库服务器只开放 3306 端口给应用服务器）。

部署完成后，还要做 “压力测试”—— 比如用 JMeter 模拟 1 万用户并发访问，看服务器会不会崩，响应时间是不是达标。如果不达标，就要调整配备，直到满足需求。

3.3 核心工作二：日常运维，像 “医生” 一样守护服务器

部署完成不是结束，而是开始 —— 日常运维是我们最主要的工作，就像医生给病人做体检、治病，我们要 “监控服务器、排查故障、备份数据”，确保服务器一直健康。

3.3.1 巡检：防患于未然的 “体检”

巡检分 “日常巡检” 和 “专项巡检”—— 日常巡检每天做，专项巡检（比如大促前）每周做。

日常巡检的内容包括：

硬件：检查 CPU、内存、硬盘、网卡的使用率，看有没有报错（比如硬盘坏道、网卡断连）；
系统：检查系统日志（/var/log/messages），看有没有错误信息（比如内核 panic、服务崩溃）；
应用：检查 Web 服务器、数据库、应用服务器的日志，看有没有异常（比如 SQL 错误、接口超时）；
网络：检查网络带宽、延迟、丢包率，看有没有网络瓶颈。

我每天上班第一件事，就是打开监控平台，看所有服务器的状态：CPU 使用率有没有超过 80%？内存有没有快满了？硬盘剩余空间够不够？要是发现异常，比如某台服务器的硬盘使用率达 90%，就要立刻清理日志或扩容，避免硬盘满了导致服务崩溃。

专项巡检更细致，比如大促前，我们会：

正常，有没有备用硬盘；就是检查服务器的冗余设备：电源、风扇是不
检查备份：手动恢复一次数据，看备份是不是能用；
检查扩容：提前把服务器集群扩容到 2 倍，做压力测试，确保能扛住大促流量。

3.3.2 监控：实时掌握服务器的 “脉搏”

“实时盯”—— 大家会搭建监控平台，实时采集服务器的指标，一旦超过阈值就告警（比如 CPU 使用率超 90%、响应延迟超 500ms）。就是巡检是 “定时看”，监控

“Prometheus+Grafana”——Prometheus 负责采集指标（比如 CPU 使用率、内存使用率），Grafana 负责把指标做成图表，直观展示。还有 Zabbix（适合传统运维）、Nagios（适合小规模集群）。就是常用的监控工具组合

我们监控的核心指标有这些：

硬件指标：CPU 使用率、内存使用率、硬盘使用率、硬盘 IO、网卡带宽、网卡丢包率；
环境指标：进程数、文件描述符数、TCP 连接数、框架负载（load average）；
应用指标：Web 服务器请求数（QPS）、错误率、响应时间；数据库查询数、慢查询数；应用服务器接口调用量、超时率。

告警方式有很多种：短信、电话、微信、企业微信。比如严重故障（比如数据库宕机）会触发 “电话告警”，确保大家能立刻接到；一般故障（比如 CPU 使用率超 80%）会触发 “微信告警”，我们看到后及时处理就行。

我之前设置过一个 “微信告警机器人”，所有服务器的告警都会推到企业微信群里，还会 @对应的负责人。有一次凌晨 3 点，数据库从库宕机，机器人 @了我，我 10 分钟内就远程重启了从库，没影响业务 —— 这就是监控的重要性。

3.3.3 故障排查：和问题 “死磕”，直到解决

即使做了巡检和监控，故障还是会发生 —— 比如服务器宕机、网络断连、应用崩溃。我们的任务是 “快速定位问题，解决问题，恢复业务”。

故障排查有个 “方法论”：从现象到本质，逐步缩小范围，不要盲目操作。比如遇到 “用户访问 APP 提示‘加载失败’”，排查步骤是：

先看用户端：是不是所有用户都有问题？还是只有某个地区的用户？如果只有某个地区，可能是网络难题（比如 CDN 故障）；
再看 Web 服务器：用 ping 命令看 Web 服务器是不是能通？用 curl 命令访问 Web 服务器的接口，看有没有返回材料？如果 Web 服务器没响应，可能是 Web 服务崩溃了；
再看应用服务器：如果 Web 服务器有响应，但返回 “500 错误”（服务器内部错误），可能是应用服务器有问题。查看应用服务器日志，看有没有报错（比如数据库连接失败）；
连接数满了，调整数据库的 max_connections 参数。就是最后看数据库服务器：如果应用服务器日志显示 “数据库连接超时”，检查数据库服务器是不是宕机了？用 mysql 命令登录数据库，看能不能正常查询？如果数据库宕机，重启数据库；要是

我之前遇到过一个 “诡异的故障”：某台应用服务器每隔 2 小时就会卡顿 5 分钟，CPU 使用率飙升到 100%。查了好几天，日志里没报错，硬件也没问题。最后用 “perf 工具”（Linux 性能分析工具）查进程，发现是一个 Java 线程在 “死循环”—— 开发写的代码有 bug，每隔 2 小时就会触发死循环。修复代码后，故障就解除了。

故障克服后，还要写 “故障复盘报告”—— 记录故障原因、解决过程、预防措施，避免下次再犯。比如上次的 “死循环” 故障，我们在复盘报告里写了 “以后上线前，要用 perf 工具做性能测试，检查有没有死循环”。

3.3.4 备份：数据的 “救命稻草”，不能马虎

数据是业务的 “生命线”—— 如果数据库材料丢了，用户账号、订单信息都没了，业务就彻底崩了。于是备份是我们的 “底线工作”，绝对不能马虎。

备份的核心是 “3-2-1 原则”：

3 份备份：同一份数据，至少有 3 个副本；
2 种介质：备份存在 2 种不同的介质上（比如本地硬盘 + 云存储）；
1 个异地备份：至少有 1 份备份存在异地（比如北京的服务器，备份存在上海的机房）。

我们常用的备份策略是 “全量备份 + 增量备份 + 差异备份”：

全量备份：每周日凌晨做一次，备份所有数据（比如 MySQL 的 mysqldump 全量备份）；
增量备份：每天凌晨做一次，备份前一天新增的材料（比如 MySQL 的 binlog 增量备份）；
差异备份：每天中午做一次，备份从上次全量备份到现在的所有数据（介于全量和增量之间）。

备份后一定要 “恢复测试”—— 很多人以为备份了就万事大吉，结果必须恢复时才发现备份文件损坏，或者恢复步骤错了。我们每个月都会做一次恢复测试：在测试环境恢复备份数据，看能不能正常启用，确保备份是管用的。

要确保 “能用上”。就是我之前有个同事，没做恢复测试，结果数据库宕机时，发现备份文件损坏，数据全丢了 —— 最后公司赔了用户很多钱，他也被开除了。这件事给我敲响了警钟：备份不是 “走个流程”，而

3.4 核心工作三：性能优化，让服务器 “跑” 得更快

服务器能稳定运行还不够，还要 “跑得快”—— 比如用户访问 APP，响应时间从 500ms 降到 100ms，用户体验会好很多。性能优化是我们的 “进阶工作”，需要懂硬件、平台、应用、数据库，甚至业务。

扩容？看数据说话就是3.4.1 硬件优化：升级还

如果服务器性能不够，首先考虑 “硬件优化”—— 但不是盲目升级，而是看 “瓶颈在哪”。

比如：

如果 CPU 使用率持续超 90%，但内存、硬盘、网络都没事，说明瓶颈在 CPU，应该升级 CPU（比如从 8 核升到 16 核）或加 CPU（比如从 1 颗加到 2 颗）；
如果内存使用率持续超 90%，频繁应用 swap（虚拟内存），说明瓶颈在内存，应该扩容内存（比如从 64G 升到 128G）；
如果硬盘 IO 使用率超 90%（比如 iostat 命令看 % util 超 90%），说明瓶颈在硬盘，必须换成更快的硬盘（比如从 SAS 换成 NVMe SSD）；
如果网卡带宽超 90%，说明瓶颈在网络，需要升级网卡（比如从 10G 换成 25G）或加网卡做 “bonding”（网卡绑定，增加带宽）。

我之前做过一个 “短视频 APP” 的优化，用户反馈 “视频加载慢”。查了一下，发现文件服务器的网卡带宽超 95%，瓶颈在网络。怎么办？给每台档案服务器加了 1 块 10G 网卡，做 “bonding”（带宽叠加到 20G），视频加载速度一下就快了，用户投诉少了很多。

3.4.2 系统优化：调优内核，释放潜力

调整 Linux 内核参数，让系统更适合服务器场景。就是硬件优化后，再做 “系统优化”—— 首要

/etc/sysctl.conf）：就是常用的内核参数优化有这些（配置文件

net.core.somaxconn：调整 TCP 监听队列大小，默认是 128，改成 1024（适合高并发场景，比如 Web 服务器）；
1024，改成 2048（避免 SYN 洪水攻击，提高并发）；就是net.ipv4.tcp_max_syn_backlog：调整 TCP SYN 队列大小，默认
fs.file-max：调整系统最大文件描述符数，默认是 65535，改成 1048576（因为 Linux 里 “一切皆档案”，高并发场景得更多材料描述符）；
vm.swappiness：调整内存交换比例，默认是 60，改成 10（让系统尽量用内存，少用 swap，提高速度）。

调整完内核参数后，要执行 “sysctl -p” 生效。还要注意：不同服务器场景，优化参数不一样 —— 比如数据库服务器和 Web 服务器的内核参数，不能完全一样。

我之前给数据库服务器做优化时，把 vm.swappiness 改成了 0（完全不用 swap），结果内存满了后，系统直接 OOM（内存溢出），杀了 mysql 进程。后来改成 10，问题就解除了 —— 这说明 “优化不能极端，要适合场景”。

3.4.3 应用优化：从数据库到中间件，逐个突破

系统优化后，再做 “应用优化”—— 这部分得和开发协作，因为涉及到应用代码和配备。

（1）数据库优化

数据库是性能瓶颈的 “重灾区”，优化点最多：

索引优化：给常用查询的字段加索引（比如订单表的 “用户 ID” 字段），避免全表扫描；但不要加太多索引（索引会减慢写入速度）；
SQL 语句优化：优化慢查询，比如用 “join” 代替子查询，用 “limit” 限制返回行数，避免 “select *”（只查需要的字段）；
数据库数据量太大（比如超过 1000 万行），把数据分成多个库或多个表（比如订单表按 “用户 ID 哈希” 分表，分成 10 个表），减少单表数据量；就是分库分表：要
读写分离：主库写资料，从库读数据，分担主库压力（比如电商的 “下单” 写主库，“查订单” 读从库）。

我之前优化过一个 “用户查询订单” 的 SQL，原语句是 “select * from order where user_id=123”，没有加索引，执行时间是 500ms。加了 “user_id” 索引后，执行时间降到了 10ms；再把 “select *” 改成 “select order_id, order_time, amount”（只查要求的字段），执行时间降到了 5ms—— 这就是 SQL 优化的效果。

（2）Web 服务器优化

调整配置文件（nginx.conf）：就是Web 服务器（比如 Nginx）的优化，主要

worker_processes：设置工作进程数，等于 CPU 核心数（比如 8 核 CPU，设为 8）；
worker_connections：设置每个工作进程的最大连接数，默认是 1024，改成 10000；
gzip 压缩：开启 gzip，压缩 HTML、CSS、JS 文件，减少传输流量（比如 gzip on; gzip_types text/css application/javascript;）；
静态资源缓存：设置静态资源（图片、JS、CSS）的缓存时间（比如 expires 7d; 缓存 7 天），减少重复请求。

（3）应用服务器优化

应用服务器（比如 Tomcat）的优化，重要是调整线程池和内存：

线程池：设置最小线程数（minSpareThreads）、最大线程数（maxThreads），比如 minSpareThreads=50，maxThreads=200（根据并发量调整）；
内存：设置 JVM 内存（比如 - Xms2g -Xmx2g，初始内存和最大内存都是 2G），避免内存太小导致频繁 GC（垃圾回收），影响性能。

3.5 核心工作四：安全防护，筑牢数字 “防火墙”

服务器一旦被黑客攻击，后果不堪设想 —— 比如材料泄露、服务被劫持、业务瘫痪。因而安全防护是我们的 “底线工作”，必须做到位。

3.5.1 服务器加固：把 “后门” 都关上

服务器加固的核心是 “最小权限原则”—— 只开放需要的服务和端口，禁用不必要的作用，减少攻击面。

常用的加固措施有：

禁用 root 远程登录：root 是 Linux 最高权限用户，远程登录风险高。创建普通用户（比如 admin），用 sudo 授权，禁止 root 通过 SSH 登录（修改 /etc/ssh/sshd_config，设置 PermitRootLogin no）；
用 SSH 密钥登录：代替密码登录，更安全。生成 SSH 密钥对（ssh-keygen），把公钥传到服务器（ssh-copy-id admin@服务器 IP），禁用密码登录（修改 sshd_config，设置 PasswordAuthentication no）；
关闭无用端口：用 iptables 或 firewalld 防火墙，只开放需要的端口（比如 80/443 端口给 Web 服务，3306 端口只开放给应用服务器）；
安装杀毒软件：比如 ClamAV，定期扫描服务器，防止病毒和恶意软件。

我之前遇到过一次 “暴力破解 SSH”：黑客用字典猜 root 密码，1 小时内尝试了 1 万次登录。幸好我们禁用了 root 远程登录，还用了 SSH 密钥，黑客没成功。后来我们又加了 “fail2ban”（防暴力破解工具），只要某 IP 连续 5 次登录失败，就拉黑该 IP 24 小时，彻底解决了问题。

3.5.2 漏洞管理：及时打补丁，不给黑客可乘之机

服务器的操作系统、软件（比如 MySQL、Nginx）会有漏洞，黑客会利用这些漏洞攻击服务器（比如 Log4j 漏洞、Heartbleed 漏洞）。所以我们要 “定期扫描漏洞，及时打补丁”。

漏洞管理的流程是：

漏洞扫描：用软件（比如 Nessus、OpenVAS）定期扫描服务器，发现漏洞（比如操作系统漏洞、软件漏洞）；
漏洞评估：评估漏洞的风险等级（高危、中危、低危），高危漏洞优先处理；
打补丁：对于操作系统漏洞，用 yum 或 apt-get 更新（比如 yum update）；对于软件漏洞，升级软件版本（比如把 Nginx 从 1.18 升到 1.20，修复已知漏洞）；
验证：补丁打完后，再扫描一次，确保漏洞已修复。

2021 年 Log4j 漏洞爆发时，我们连夜排查所有服务器 —— 凡是用了 Log4j 的应用服务器，都升级到最新版本，还在防火墙加了规则，禁止外部访问相关端口。虽然忙了一整晚，但避免了服务器被攻击，值了。

3.5.3 日志审计：追踪异常，揪出 “不速之客”

即使做了加固和漏洞管理，也可能有黑客突破防线 —— 这时候日志审计就能帮我们 “追溯攻击过程，找出黑客”。

我们要收集的日志包括：

系统日志：/var/log/messages（系统整体日志）、/var/log/secure（SSH 登录日志）；
应用日志：Nginx 日志（/var/log/nginx/access.log）、MySQL 日志（/var/log/mysql/error.log）、应用服务器日志（比如 Tomcat 的 catalina.out）；
网络日志：防火墙日志、路由器日志。

日志收集后，用工具（比如 ELK Stack：Elasticsearch+Logstash+Kibana）存储和分析 —— 比如在 Kibana 里搜索 “SSH 登录失败”，看有没有异常 IP；搜索 “数据库删除操作”，看有没有未授权的删除。

我之前通过日志发现过一次 “异常访问”：有个 IP 从凌晨 2 点开始，频繁访问我们的后台管理接口，虽然没登录成功，但很可疑。我们立刻把这个 IP 拉黑，还检查了所有管理账号的密码，确保安全 —— 这就是日志审计的作用。

3.6 核心工作五：自动化运维，让自己 “从重复劳动中解放”

如果每天都手动巡检、部署、打补丁，工作量会非常大 —— 比如有 100 台服务器，手动部署一次应用要 2 小时，而自动化工具只要 5 分钟。所以自动化运维是大家的 “必备技能”，能大大提高效率。

3.6.1 脚本编写：一行代码搞定百台服务器

最基础的自动化是 “写脚本”—— 用 Shell 或 Python 脚本，自动化重复工作。

比如：

批量执行命令：用 Shell 脚本 “for i in 服务器 IP 列表；do ssh $i ' 命令 '; done”，在百台服务器上同时执行命令（比如查看 CPU 使用率）；
批量部署软件：用 Python 脚本，自动登录服务器，安装软件（比如 Nginx），配置文件；
日志清理：用 Shell 脚本，定期清理过期日志（比如删除 30 天前的 Nginx 日志），避免硬盘满了。

我写过一个 “服务器巡检脚本”：用 Python 调用 psutil 库（获取硬件指标）、subprocess 库（执行系统命令），收集 CPU、内存、硬盘、网络指标，生成巡检报告，每天早上自动发到企业微信群里。之前手动巡检要 1 小时，现在脚本 5 分钟就搞定，省了很多时间。

3.6.2 容器化：Docker 让应用部署 “一次打包，到处运行”

脚本只能自动化轻松任务，复杂的应用部署得 “容器化”—— 用 Docker 把应用和依赖（比如 Java、Python 环境）打包成 “镜像”，然后在任何服务器上运行 “容器”，不用再担心 “环境不一致” 的障碍。

比如部署一个 Java 应用：

写 Dockerfile：定义基础镜像（比如 openjdk:8）、复制应用 jar 包、设置启动命令；
构建镜像：docker build -t my-java-app:1.0 .；
运行容器：docker run -d -p 8080:8080 my-java-app:1.0。

“轻量、隔离、可移植”—— 比如你在本地开发环境用 Docker 运行应用，测试通过后，直接把镜像传到生产服务器，运行容器就行，不用再在生产服务器上装 Java 环境。就是Docker 的优点

我们公司现在所有应用都用 Docker 部署，之前部署一个应用要 30 分钟（装环境、配依赖），现在 5 分钟就搞定，而且不会出现 “本地能跑，生产跑不了” 的问题。

3.6.3 云原生：K8s 搭建弹性伸缩，应对业务波动

容器编排应用，能自动管理容器的生命周期：就是如果有 100 个 Docker 容器，手动管理会很麻烦 —— 比如容器崩了要重启，服务器宕机了要迁移容器。这时候就需要 “Kubernetes（K8s）”——K8s

自动重启：容器崩了，K8s 自动重启；
自动扩缩容：根据 CPU 使用率或请求量，自动增加或减少容器数量（比如高峰期从 5 个容器扩到 20 个）；
自动迁移：服务器宕机了，K8s 把容器迁移到其他健康的服务器上。

我之前做的电商方案，用 K8s 管理所有应用容器：大促前，K8s 自动把应用容器从 10 个扩到 50 个；促结束后，自动缩到 10 个，既保证了性能，又节省了成本。而且 K8s 有 “滚动更新” 功能 —— 更新应用时，先启动新容器，再停止旧容器，用户完全感觉不到服务中断。

现在 “云原生” 是趋势 —— 越来越多的公司把服务器搬到云上（阿里云、腾讯云、AWS），用 K8s 管理容器，实现 “弹性伸缩、高可用”。作为服务器工程师，掌握 Docker 和 K8s，已经成了必备技能。

四、想当服务器工程师？这些技能你得会

讲完了工作内容，很多人可能会问：“我想做服务器工程师，需要学什么？”—— 这个岗位对技能的要求比较全面，既要懂硬件，又要懂软件；既要会手动排查故障，又要会自动化工具。

4.1 硬技能：从操作系统到云原生，技巧栈要扎实

硬技能是 “敲门砖”，必须掌握以下几类：

（1）操作系统：Linux 是核心

服务器的 “灵魂”，必须精通 —— 至少掌握一种主流发行版（比如 CentOS、Ubuntu Server），能熟练操作：就是Linux

命令行：常用命令（ls、cd、cp、mv、rm、top、ps、netstat、iptables），能写 Shell 脚本；
系统管理：用户管理（useradd、passwd）、权限管理（chmod、chown）、服务管理（systemctl）、进程管理（kill、pkill）；
内核调优：懂常用内核参数，能根据场景调整；
日志分析：会看系统日志、应用日志，能从日志里找障碍。

推荐学习资源：《Linux 就该这么学》《鸟哥的 Linux 私房菜》，还有实验平台（比如 VMware、VirtualBox）—— 自己装个 Linux 系统，多练手。

（2）网络知识：TCP/IP 是基础

服务器之间的通信靠网络，必须懂 TCP/IP 协议：

基础协议：IP、TCP、UDP、HTTP、HTTPS、DNS，知道它们的工作原理；
网络配置：会配 IP、子网掩码、网关、DNS，会用 ping、traceroute、curl 排查网络问题；
防火墙：会用 iptables 或 firewalld 配置防火墙规则，限制端口访问；
负载均衡：懂 LVS、Nginx、HAProxy 的工作原理，会部署负载均衡。

通过推荐学习资源：《TCP/IP 详解卷 1：协议》《计算机网络：自顶向下方法》，能够用 Wireshark 抓包，分析 TCP/IP 协议。

（3）数据库：MySQL 是必备

数据库是服务器的 “数据仓库”，至少要掌握 MySQL：

基础执行：会建库、建表、增删改查（SQL 语句）；
索引优化：懂索引的原理（B + 树），会给字段加索引，会用 explain 分析 SQL；
主从复制：会配置 MySQL 主从复制，实现读写分离；
备份恢复：会用 mysqldump 做全量备份，用 binlog 做增量备份，会恢复数据。

推荐学习资源：《高性能 MySQL》《MySQL 科技内幕：InnoDB 存储引擎》，能够自己装个 MySQL，练手 SQL 和主从复制。

（4）自动化设备：Docker、K8s 要掌握

趋势，必须会用这些器具：就是现在自动化运维

脚本语言：至少会一种（Shell、Python），能写自动化脚本；
Docker：会写 Dockerfile、构建镜像、运行容器，懂 Docker 的网络和存储；
K8s：懂 K8s 的核心概念（Pod、Deployment、Service、Ingress），会部署应用、设置自动扩缩容；
自动化运维工具：会用 Ansible（批量管理服务器）、Jenkins（CI/CD，自动化部署应用）。

推荐学习资源：Docker 官方文档、K8s 官方文档，《Docker 实战》《Kubernetes in Action》，可以用 Minikube（本地 K8s 环境）练手。

（5）监控设备：Prometheus+Grafana 要会用

监控是运维的 “眼睛”，必须会搭建监控系统：

Prometheus：会配置 Prometheus 采集服务器和应用指标；
Grafana：会用 Grafana 制作监控图表，配置告警；
日志分析：会用 ELK Stack 收集和分析日志，排查问题。

推荐学习资源：Prometheus 和 Grafana 官方文档，《Prometheus 监控实战》。

4.2 软技能：沟通、抗压、学习，一个都不能少

光有硬技能还不够，软技能同样重要：

（1）问题排查能力：会 “定位问题” 比 “解决问题” 更重要

盲目尝试。比如服务器宕机，先看硬件日志，再看系统日志，最终看应用日志，一步步找到原因。就是故障排查是服务器工程师的核心能力 —— 遇到问题时，要冷静，有逻辑，能从现象到本质，逐步缩小范围，而不

（2）沟通能力：要和不同角色协作

服务器工程师不是 “单打独斗”，要和开发、产品、测试、安全运维协作：

和开发沟通：要懂制作语言（比如 Java、Python），能看懂应用日志，和制作一起优化性能；
和产品沟通：要懂业务需求，能评估服务器资源，给产品提扩容建议；
和运维团队沟通：要和网络运维、安全运维配合，解决网络和安全问题。

（3）抗压能力：能应对突发故障

服务器故障可能在任何时候发生 —— 凌晨、周末、节假日，都可能被告警叫醒。这时候要能顶住压力，快速解决问题，不能慌。比如大促期间服务器崩了，要在几分钟内定位问题，恢复服务，否则会造成巨大损失。

（4）学习能力：工艺更新快，要不断学习

服务器领域的技术更新很快 —— 比如从传统服务器到云服务器，从手动运维到自动化运维，从 Docker 到 K8s，每年都有新手艺出现。要是不学习，很快就会被淘汰。所以要保持学习的热情，关注技术趋势，比如云原生、AI 运维（AIOps）。

五、服务器工程师的发展前景：行业需要，未来可期

很多人担心 “服务器工程师会不会被淘汰？”—— 其实不用担心，因为只要有互联网业务，就应该服务器，就需要服务器工程师。而且随着数字化转型，传统企业（比如银行、医院、制造业）也在大量部署服务器，对人才的需求只会增加。

5.1 职业发展路径：从运维到架构，越走越宽

服务器工程师的职业发展路径很清晰，关键有 3 个方向：

（1）手艺专家方向：深耕运维，成为 “运维专家”

初级服务器工程师（1-2 年）：负责日常巡检、故障排查、方便部署；
中级服务器工程师（3-5 年）：负责服务器集群设计、性能优化、自动化运维；
高级服务器工程师（5 年以上）：负责大规模服务器集群架构设计、云原生运维、AI 运维，能解决麻烦手艺问题。

（2）管理方向：从 “做事” 到 “管人”，成为 “运维经理”

运维组长（3-5 年）：带领小团队（3-5 人），负责具体项目的运维；
运维经理（5-8 年）：带领团队（10-20 人），制定运维策略，管理项目进度和成本；
运维总监（8 年以上）：负责公司整体运维体系，制定技术路线，对接业务和管理层。

（3）转型方向：拓展技能，转做其他相关岗位

DevOps 工程师：结合开发和运维，负责自动化部署、CI/CD，需要懂开发语言（比如 Go、Python）和自动化工具；
云架构师：负责云服务器（阿里云、腾讯云）的架构设计、迁移、管理，需要懂云服务（ECS、RDS、OSS）；
安全工程师：专注服务器安全，负责漏洞扫描、渗透测试、安全防护，需要懂安全手艺（防火墙、WAF、IDS）；
SRE 工程师（站点可靠性工程师）：结合运维和研发，负责服务的可用性、性能、效率，是互联网公司的热门岗位。

5.2 薪资水平：不同阶段，收入如何？

服务器工程师的薪资水平不错，尤其是在互联网公司，收入和经验、城市挂钩：

初级工程师（1-2 年）：一线城市（北京、上海、广州、深圳）8K-15K，二线城市（杭州、成都、武汉）6K-12K；
中级工程师（3-5 年）：一线城市 18K-30K，二线城市 15K-25K；
高级工程师（5 年以上）：一线城市 35K-50K+（月薪），或者年薪 50 万 - 100 万；
管理岗（运维经理 / 总监）：一线城市年薪 80 万 - 200 万 +，具体看公司规模和业务。

比如阿里、腾讯、字节跳动的高级服务器工程师，年薪大多在 80 万以上；即使是中小型互联网公司，高级工程师的年薪也能到 50 万左右。

5.3 行业需求：哪里需要服务器工程师？

服务器工程师的需求很广，几乎所有有 “IT 系统” 的公司都需要：

（1）互联网公司：需求最大，手艺最前沿

比如阿里、腾讯、字节跳动、百度、美团、京东，这些公司的服务器集群规模大（几十万甚至上百万台服务器），应该大量服务器工程师，负责运维、优化、自动化。而且互联网公司的科技更新快，能接触到云原生、K8s、AI 运维等前沿技术，适合想提升技术的人。

（2）传统企业：数字化转型，需求增长快

比如银行（工商银行、建设银行）、医院（三甲医院）、制造业（华为、格力）、零售（沃尔玛、苏宁），这些传统企业正在做数字化转型，需要部署服务器集群，搭建 IT 系统，对服务器工程师的需求越来越大。而且传统企业的工作节奏相对慢，适合想稳定的人。

（3）云服务商：技术核心，高薪高要求

比如阿里云、腾讯云、AWS、华为云，这些云服务商的核心业务是 “卖服务器（云服务器 ECS）”，需要服务器工程师负责云服务器的架构设计、运维、优化。云服务商的手艺要求高，薪资也高，适合技术能力强的人。

（4）外包公司：入门容易，适合新手

比如一些 IT 外包公司，给其他公司提供运维服务，需求大，入门门槛相对低，适合刚毕业的新手积累经验。但外包公司的手艺深度不够，薪资相对低，不适合长期发展。

六、给想入行的你：从 0 开始，如何成为服务器工程师？

若是你想做服务器工程师，不用怕 “零基础”—— 我也是从零基础开始的，只要有耐心，一步步学，就能入行。

6.1 第一步：打好基础，从 Linux 开始

零基础的话，先从 Linux 学起 —— 这是服务器工程师的 “基本功”。

入门阶段（1-2 个月）：
1. 装一个 Linux 框架：用 VMware 或 VirtualBox，装 CentOS 7 或 Ubuntu Server 20.04；
2. 学常用命令：每天花 1-2 小时，练 ls、cd、cp、mv、rm、top、ps、netstat 这些命令，直到熟练；
3. 学系统管理：练用户管理、权限管理、服务管理，比如创建用户、修改文件权限、启动 / 停止 Nginx 服务。
进阶阶段（2-3 个月）：
1. 学 Shell 脚本：写简单的脚本，比如批量执行命令、日志清理脚本；
2. 学 Linux 内核调优：懂常用内核参数，比如 net.core.somaxconn、fs.file-max；
3. 学网络配置：练 IP、网关、DNS 配置，用 ping、traceroute 排查网络障碍。

推荐资源：《Linux 就该这么学》，B 站上的 “韩顺平 Linux 教程”，还有实验平台（比如阿里云 ECS 学生机，很便宜）。

6.2 第二步：多练手，搭建自己的实验环境

光看书不行，必须多练手 —— 最好搭建一个 “迷你服务器集群”，模拟真实工作场景。

比如搭建一个 “Web 服务集群”：

用 VMware 装 3 台 Linux 虚拟机：1 台 Nginx（Web 服务器），1 台 Tomcat（应用服务器），1 台 MySQL（数据库服务器）；
部署应用：在 Tomcat 上部署一个简单的 Java Web 应用（比如留言板），连接 MySQL 数据库；
配置 Nginx：让 Nginx 转发请求到 Tomcat，实现 Web 服务；
做压力测试：用 JMeter 模拟 1000 用户并发访问，看服务会不会崩，响应时间是不是达标。

再比如搭建 “监控体系”：