1. 背景与核心概念兄弟们这几天一直被“PTS服务器开荒”这几个字刷屏群里好几个朋友都在喊“PTS 开荒求玩”。如果你是刚接触这套东西第一反应肯定是PTS 到底是什么开荒又是开什么荒今天这篇不聊虚的直接把 PTS 服务器从零搭建、配置、压测到上线联调的完整流程拆开揉碎手把手带大家走一遍。1.1 什么是 PTS 服务器PTS 是 Performance Test Server 的缩写也就是性能测试服务器。它和我们平时开发用的 Dev 环境、上线用的 Prod 环境不一样PTS 服务器专门用来跑性能测试、压测、大并发模拟以及新版本上线前的容量评估。简单理解开发环境管“功能能不能跑通”PTS 环境管“扛不扛得住、哪里会先挂”。在一些互联网公司和游戏团队里PTS 服务器也被称作“预发压测环境”它通常需要尽量模拟生产环境的部署架构、数据量级和网络拓扑否则压测出来的数据没有参考意义。比如生产环境是 8 台应用服务器 1 套数据库集群那 PTS 环境最好也是同样的比例至少不能差得太远。1.2 “开荒”在服务器语境下指什么“开荒”这个词最早来自游戏圈意思是进入一块全新的地图没有人走过所有机制都要自己摸索。放到服务器搭建里开荒就是指拿到一台全新的服务器从装机、配环境、部署应用、初始化数据库到第一次把它跑起来、第一次扛住流量压测的完整过程。PTS 服务器开荒的特点是“一锤子买卖”性质比较强服务器是全新的系统刚装好软件源里什么都没有。没有现成的部署脚本每一步都得手动确认。压测数据是第一次跑没有历史基线可以参考。遇到性能瓶颈可能要从应用层、系统层、网络层一层一层往下挖。所以PTS 开荒不仅是“把服务器搭起来”更是一个完整的工程过程。1.3 为什么你需要掌握 PTS 服务器搭建很多开发者平时只接触开发环境对压测环境比较陌生。但实际工作中无论是自研项目还是公司业务一旦涉及上线评估、大促保障、容量规划PTS 服务器都是绕不开的基础设施。掌握 PTS 服务器搭建至少有三个实际收益能独立完成压测环境的交付而不是每次都等运维排期。能根据压测结果反向推断应用瓶颈例如是 CPU 先被打满还是数据库连接池先耗尽。能更合理地规划服务器资源避免出现“8 核 16G 跑一个 hello world”的资源浪费也避免“2 核 4G 硬扛高并发”的翻车现场。下面我们进入正题从一台全新服务器开始完整走一遍 PTS 开荒流程。2. 环境准备与版本说明先说明一下本文的示例环境以常见的 Linux 服务器 Docker 部署方式为例。版本需要根据你的项目实际情况调整本文重点演示的是配置思路和完整流程。2.1 服务器硬件建议PTS 服务器的硬件配置没有绝对标准取决于你要压测的业务类型。但有一个通用的参考基线场景CPU内存磁盘带宽轻量接口压测2 核4G40G SSD5MbpsWeb 应用压测4 核8G100G SSD10Mbps数据库/缓存压测8 核16G200G SSD20Mbps全链路压测模拟16 核32G500G SSD50Mbps这里建议大家优先选择 SSD 磁盘因为压测过程中会高频读写日志、写入压测数据机械盘很容易成为 IO 瓶颈导致误判。2.2 操作系统与基础软件本文示例使用以下环境操作系统CentOS 7.9 / Ubuntu 22.04命令差异不大下面会标注Docker20.10Docker Composev2 版本JDK1.8 或 11按你的应用要求选择Nginx1.24可选用于反向代理压测工具Apache Benchab、wrk这些版本都是比较稳定的组合。如果你使用的是其他系统版本比如 Rocky Linux 或 Debian操作逻辑是一样的只是包管理器命令略有区别。2.3 示例项目结构为了方便演示我们会搭建一个包含以下组件的 PTS 测试环境pts-server/ ├── docker-compose.yml ├── nginx/ │ └── default.conf ├── app/ │ ├── Dockerfile │ └── pts-demo.jar ├── mysql/ │ └── init.sql └── logs/ ├── nginx/ └── app/这个结构模拟的是一个典型的 Web 应用Nginx 做反向代理Java 应用提供接口MySQL 存储数据。压测时就打 Nginx 入口观察整个链路的表现。3. PTS 服务器环境搭建开荒第一步先把基础环境准备好。如果你拿到的是云服务器建议先做两件事更新系统软件包、创建独立的部署用户。用 root 跑应用虽然省事但安全性和可维护性都比较差。3.1 系统初始化拿到新服务器后先执行系统更新。这一步可能会花几分钟取决于网络状况。# CentOS / Rocky Linux yum update -y # Ubuntu / Debian apt update apt upgrade -y然后创建部署用户并加入 sudo 组# CentOS / Rocky Linux useradd -m -d /home/pts pts usermod -aG wheel pts passwd pts # Ubuntu / Debian useradd -m -d /home/pts pts usermod -aG sudo pts passwd pts后续的操作我们都用 pts 用户执行避免直接在 root 下操作带来的权限风险。3.2 安装 Docker 与 Docker Compose现代服务器开荒Docker 基本是标配。它能把应用、依赖、配置一起打包大幅降低环境差异带来的问题。先安装 Docker# 使用国内镜像加速安装 curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun启动 Docker 并设置开机自启systemctl enable docker systemctl start docker安装 Docker Compose v2 插件mkdir -p /usr/local/lib/docker/cli-plugins curl -SL https://github.com/docker/compose/releases/download/v2.24.0/docker-compose-linux-x86_64 -o /usr/local/lib/docker/cli-plugins/docker-compose chmod x /usr/local/lib/docker/cli-plugins/docker-compose验证安装结果docker --version docker compose version如果网络下载慢可以找镜像源替代这里不做展开。只要能正常输出版本号环境就算就绪了。3.3 关闭防火墙或放行端口PTS 压测环境一般在内网可以直接关闭防火墙方便压测工具访问。如果是云服务器还需要在安全组里放行对应端口。# CentOS / Rocky Linux systemctl stop firewalld systemctl disable firewalld # Ubuntu / Debian ufw disable如果不想关防火墙至少要放行这几个端口80HTTP、3306MySQL按需、8080应用服务。压测机和服务器的网络要保证互通最好在同一个内网网段避免公网延迟干扰压测数据。4. 核心服务编排与配置基础环境就绪后我们开始配置本次开荒的核心内容通过 Docker Compose 一键拉起 Nginx、Java 应用、MySQL 三个服务。为什么用 Docker Compose因为 PTS 环境需要频繁重建用 Compose 可以保证每次部署的一致性避免“在我机器上是好的”这种情况。4.1 创建项目目录使用 pts 用户创建项目目录mkdir -p /home/pts/pts-server/{nginx,app,mysql,logs}目录说明nginx存放 Nginx 配置文件app存放应用 Dockerfile 和 jar 包mysql存放数据库初始化脚本logs统一存放日志文件便于压测后收集分析4.2 编写 Nginx 配置Nginx 在 PTS 环境里的角色是反向代理和负载均衡入口。压测时我们直接打 Nginx 的地址模拟真实用户请求先经过网关层的情况。文件路径/home/pts/pts-server/nginx/default.confupstream pts_app { server app:8080; keepalive 64; } server { listen 80; server_name _; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; location / { proxy_pass http://pts_app; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 5s; proxy_read_timeout 10s; } # 健康检查端点不转发到后端 location /health { access_log off; return 200 ok\n; } }这里有两个关键点upstream pts_app中的app对应的是 Docker Compose 里的服务名Compose 会自动做 DNS 解析。keepalive 64开启 upstream 长连接减少压测时频繁建连带来的开销这个在压测场景下尤其重要因为它能把 Nginx 到后端应用的连接复用起来从而更真实地反映应用本身的处理能力。4.3 编写 Java 应用 Dockerfile我们准备一个简单的 Spring Boot 应用作为被测对象。为了方便演示这个应用提供一个/api/test接口内部会做一次字符串处理并返回当前时间。实际项目中你可以替换成自己的业务接口。文件路径/home/pts/pts-server/app/DockerfileFROM openjdk:8-jdk-alpine LABEL maintainerpts COPY pts-demo.jar /app/pts-demo.jar WORKDIR /app EXPOSE 8080 ENV JAVA_OPTS-Xms512m -Xmx512m ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar pts-demo.jar]Java 应用的 JVM 参数可以根据服务器内存调整。PTS 环境建议把-Xms和-Xmx设为相同值避免运行过程中堆大小动态变化影响压测稳定性。4.4 编写 MySQL 初始化脚本MySQL 在 PTS 环境中的角色是模拟数据存储层。压测接口如果需要读写数据库那么数据库的配置和性能就直接影响整体结果。文件路径/home/pts/pts-server/mysql/init.sqlCREATE DATABASE IF NOT EXISTS pts_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE pts_db; CREATE TABLE IF NOT EXISTS test_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, request_id VARCHAR(64) NOT NULL, request_time DATETIME NOT NULL, response_time_ms INT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_request_time (request_time) ) ENGINEInnoDB;这张表用于记录压测请求的响应时间。在正式压测中把这些数据落库压测完成后可以拉出来做百分位分析比如 P99、P95 响应时间。这里要注意压测时写入数据库本身也会消耗数据库 IO所以表设计尽量精简避免复杂的索引影响写入性能。4.5 编写 Docker Compose 编排文件核心配置文件就是它了。文件路径/home/pts/pts-server/docker-compose.ymlversion: 3.8 services: nginx: image: nginx:1.24-alpine container_name: pts-nginx ports: - 80:80 volumes: - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro - ./logs/nginx:/var/log/nginx depends_on: - app restart: always networks: - pts-net app: build: ./app image: pts-demo:latest container_name: pts-app expose: - 8080 environment: - SPRING_PROFILES_ACTIVEpts - DB_HOSTmysql - DB_PORT3306 - DB_NAMEpts_db - DB_USERpts - DB_PASSWORDpts123456 depends_on: - mysql restart: always networks: - pts-net mysql: image: mysql:5.7 container_name: pts-mysql ports: - 3306:3306 environment: - MYSQL_ROOT_PASSWORDroot123456 - MYSQL_USERpts - MYSQL_PASSWORDpts123456 - MYSQL_DATABASEpts_db volumes: - ./mysql/init.sql:/docker-entrypoint-initdb.d/init.sql:ro - mysql-data:/var/lib/mysql command: - --max_connections500 - --innodb_buffer_pool_size256M restart: always networks: - pts-net volumes: mysql-data: networks: pts-net: driver: bridge这个 Compose 文件有几个细节值得注意app服务没有映射端口到宿主机只通过expose暴露给 Nginx 访问。这样外部无法直接访问应用必须经过 Nginx更符合生产环境的网络隔离思路。MySQL 通过MYSQL_USER和MYSQL_PASSWORD创建专用账号避免应用使用 root 连接数据库。这属于基础的安全实践压测环境也要养成习惯。depends_on只保证容器启动顺序不保证 MySQL 初始化完成。实际使用中应用启动后可能会短暂报数据库连接失败重启一次应用容器即可或者应用端做好重试机制。innodb_buffer_pool_size设置为 256M这是 MySQL InnoDB 的缓存池大小。PTS 环境如果内存充裕可以适当调大。4.6 启动服务编写完所有配置后使用 Docker Compose 一键启动cd /home/pts/pts-server docker compose up -d查看容器状态docker compose ps预期输出类似NAME IMAGE COMMAND SERVICE STATUS PORTS pts-nginx nginx:1.24-alpine /docker-entrypoint.… nginx running 0.0.0.0:80-80/tcp pts-app pts-demo:latest sh -c java $JAVA_O… app running 8080/tcp pts-mysql mysql:5.7 docker-entrypoint.s… mysql running 0.0.0.0:3306-3306/tcp如果某个服务启动失败用下面命令查看日志docker compose logs -f 服务名到这里PTS 服务器的基础环境已经“开荒”完成三件套Nginx App MySQL已经跑起来了。5. 开荒演练功能验证与性能摸底服务跑起来只是万里长征第一步。PTS 开荒的重头戏是验证功能和摸底性能。这一节我们分别从“能不能用”和“扛不扛得住”两个维度来演练。5.1 功能连通性测试先测试 Nginx 是否正常转发到后端应用curl http://127.0.0.1/health预期返回ok再测试业务接口curl http://127.0.0.1/api/test返回 HTTP 200 和 JSON 数据说明整个链路已经打通。如果在服务器本机测试没问题但外部访问不通优先检查云平台安全组是否放行 80 端口。5.2 使用 ab 进行轻量压测Apache Benchab是最简单的压测工具适合快速摸底。先安装# CentOS / Rocky Linux yum install httpd-tools -y # Ubuntu / Debian apt install apache2-utils -y执行一次简单的并发测试ab -n 10000 -c 100 http://127.0.0.1/api/test参数说明-n 10000总请求数 10000-c 100并发数 100压测结束后重点看这几个指标Requests per second: 4856.32 [#/sec] (mean) Time per request: 20.592 [ms] (mean) Percentage of the requests served within a certain time (ms) 50% 18 95% 35 99% 58Requests per second每秒请求数QPS 的雏形Time per request平均每个请求耗时百分位耗时50% 请求在 18ms 内完成99% 在 58ms 内完成如果 QPS 远低于预期先把并发降下来用-c 1跑一次看单请求的耗时ab -n 1000 -c 1 http://127.0.0.1/api/test如果单请求耗时本身就很高说明问题不在并发而在应用本身的处理逻辑或者数据库查询。这样能快速定位优化方向。5.3 使用 wrk 进行更高并发压测ab 在并发较高时容易因为单线程模型成为瓶颈所以我们再引入 wrk。wrk 使用 epoll 和多线程可以压出更高的并发。安装 wrk# 源码编译安装 yum install -y git make gcc git clone https://github.com/wg/wrk.git /tmp/wrk cd /tmp/wrk make cp wrk /usr/local/bin/执行压测wrk -t8 -c400 -d30s --latency http://127.0.0.1/api/test参数说明-t88 个线程-c400400 个并发连接-d30s持续压测 30 秒--latency输出延迟分布运行完成后会输出类似结果Running 30s test http://127.0.0.1/api/test 8 threads and 400 connections Thread Stats Avg Stdev Max /- Stdev Latency 21.35ms 12.67ms 250.31ms 82.45% Req/Sec 2.37k 190.45 3.10k 75.60% Latency Distribution 50% 19.28ms 75% 27.55ms 90% 38.12ms 99% 89.76ms 562894 requests in 30.00s, 78.63MB read Requests/sec: 18763.13 Transfer/sec: 2.62MB这里能看到完整的平均延迟、标准差、最大延迟以及延迟分布。如果标准差很大说明响应时间抖动明显可能存在线程竞争或 GC 暂停。排查时配合top和 JVM GC 日志一起看。5.4 压测中的资源观察压测过程中在另一个终端窗口通过top命令观察服务器实时负载top重点关注%Cpu(s)us用户态、sy系统态、waIO 等待占比load average1/5/15 分钟平均负载Mem和Swap内存使用情况如果在压测时发现%wa很高说明磁盘 IO 跟不上通常是日志写太多或者数据库落盘压力大。这时候要优化日志策略比如把日志级别从 INFO 改成 WARN或者把日志写到内存盘。si和soswap in/out如果长时间不为 0则说明内存不够用需要调整 JVM 堆大小或增加物理内存。另外可以用docker stats查看各容器资源消耗docker stats --no-stream这个命令会实时显示每个容器的 CPU%、内存使用量。它能帮你快速判断瓶颈是在 Nginx、应用还是 MySQL 容器里。5.5 压测数据落库验证前面我们在 MySQL 里建了test_record表但这个表目前是空的。为了让压测更接近真实场景可以在接口里加入写库逻辑压测时把每条请求的响应时间写入 MySQL。这个逻辑在你的实际项目中按需实现我这里给出一个简化的 MyBatis 示例public interface TestRecordMapper { Insert(INSERT INTO test_record(request_id, request_time, response_time_ms) VALUES(#{requestId}, #{requestTime}, #{responseTimeMs})) int insert(TestRecord record); }压测完成后可以用 SQL 分析压测数据SELECT COUNT(*) AS total_count, AVG(response_time_ms) AS avg_time, MAX(response_time_ms) AS max_time, MIN(response_time_ms) AS min_time FROM test_record;也可以算百分位SELECT response_time_ms FROM test_record ORDER BY response_time_ms LIMIT 1 OFFSET 9900;这条 SQL 在总记录数 10000 条时取第 9901 条就是 P99 响应时间。实际项目中建议用专门的性能分析平台来收集这些数据PTS 开荒阶段用 SQL 临时查一下够用。6. 数据备份与安全加固PTS 服务器虽然主要用于测试但压测数据、配置脚本都是重要资产。如果服务器被入侵或者数据丢失重新搭建的成本不可忽视所以基础的安全和备份工作还是要有。6.1 MySQL 数据备份在测试环境同样建议开启定时备份否则误删数据后只能重新初始化浪费时间。最简单的备份方式mysqldump -h127.0.0.1 -upts -ppts123456 pts_db /home/pts/backup/pts_db_$(date %Y%m%d_%H%M%S).sql这一步生成 SQL 文件后验证备份文件是否正常grep CREATE TABLE /home/pts/backup/pts_db_*.sql | head -5如果能正常看到建表语句说明备份文件有效后续可以把这个命令写入 crontab0 2 * * * mysqldump -h127.0.0.1 -upts -ppts123456 pts_db /home/pts/backup/pts_db_$(date \%Y\%m\%d_\%H\%M\%S).sql 2 /home/pts/backup/backup.log find /home/pts/backup -name *.sql -mtime 7 -exec rm {} \;这条 crontab 每天凌晨 2 点备份一次同时删除 7 天前的备份文件避免磁盘被备份文件占满。6.2 Docker 配置备份Docker Compose 文件是整个 PTS 环境的“源代码”必须纳入版本管理。最简单的做法是把整个pts-server目录打包备份cd /home/pts tar -czf pts-server_$(date %Y%m%d).tar.gz pts-server/如果公司有 GitLab 或 Gitea建议把配置文件推送到代码仓库这样每次改动都有记录出问题可以回滚。6.3 基础安全加固PTS 服务器虽然没有生产环境那么敏感但依然要做基础加固修改 SSH 默认端口禁止 root 直接登录。使用密钥登录关闭密码登录。MySQL 中为应用配置独立账号不要用 root。Docker 容器以非 root 用户运行部分镜像可能需要自定义 Dockerfile。定期更新系统补丁、Docker 版本和镜像。这些措施做一遍时间成本很低但对整体安全性的提升是立竿见影的。尤其云服务器如果暴露公网被扫描暴力破解是很常见的事。7. 常见问题与排查思路PTS 服务器开荒过程中下面这些问题是出现频率比较高的。我把它们整理成了表格方便你快速定位。问题现象常见原因解决思路docker compose up -d启动失败端口被占用或镜像拉取失败先docker ps查看占用再docker compose logs查看具体报错容器启动后立即退出应用启动时报错如数据库连不上docker compose logs app查看日志确认数据库账号密码和应用配置是否一致curl 本机能通外部访问不通防火墙未关闭或云安全组未放行端口检查firewalld/ufw状态并检查云平台安全组规则压测 QPS 很低单请求就慢应用逻辑耗时、数据库查询慢、网络链路问题先-c 1单并发测试用日志或链路追踪定位慢在哪一层压测时 CPU 被打满应用线程数与 CPU 核数不匹配或代码里有死循环用top -Hp 进程ID查看线程级别 CPU 占用结合线程 dump 分析压测时大量Connection refused并发超过应用最大连接数或连接池耗尽调大 Nginx worker 连接数、调整应用线程池和数据库连接池上限MySQL 连接数耗尽默认max_connections不够修改 Compose 文件中的--max_connections参数重启 MySQL 容器磁盘空间不足日志增长过快、压测产生的数据文件占满磁盘先df -h查看磁盘清理日志和备份文件配置 logrotate 日志轮转docker compose logs中文乱码容器内字符集与宿主机不一致在 Compose 文件的environment中加入LANGC.UTF-8Nginx 返回 502 Bad Gateway后端应用服务挂了或upstream地址解析有问题先docker ps确认 app 容器是否存活再docker compose logs app查看应用日志这里挑两个典型问题展开讲解排查思路。7.1 容器启动后立即退出这是最容易遇到的问题。通常是应用启动时发现自己依赖的 MySQL 还没有完全初始化导致连接失败。此时按照下面的顺序排查第一步查看容器状态docker ps -a | grep pts-app如果状态是Exited (1)说明进程异常退出。第二步查看应用日志docker compose logs app如果看到类似Communications link failure或Access denied for user的日志基本可以确认是数据库连接问题。第三步确认 MySQL 容器是否正常并提供服务docker compose ps mysql docker exec -it pts-mysql mysql -upts -ppts123456 -e show databases;如果能列出数据库但应用还是连不上检查应用环境变量中DB_HOST是否指向了正确的服务名mysql而不是127.0.0.1。7.2 压测时Requests per second异常波动压测结果不稳定通常有以下几个原因压测工具所在机器自身性能不足比如笔记本上跑压测结果不准确。服务器上还有其他任务抢占资源比如定时备份。应用 JVM 在压测中触发了频繁的 Full GC。日志 I/O 竞争激烈。排查时可以使用vmstat观察系统状态vmstat 1 10重点关注r运行队列、cs上下文切换、waIO 等待这几列。如果cs很高说明线程切换太频繁可能线程数设置过大如果wa很高说明磁盘 IO 是瓶颈。同时打开 GC 日志在 Java 启动参数中加入-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/home/pts/logs/gc.log压测完查看 GC 日志中 Full GC 的频率。如果频繁出现就要考虑调整堆大小或降低压测并发。8. PTS 服务器开荒的最佳实践作为压测基础设施PTS 服务器的搭建方式会直接影响后续每一次压测结果的可靠性。根据我自己的落地经验有几点建议值得参考。8.1 环境配置尽量与生产保持一致PTS 环境最大的价值是“模拟生产”。如果生产是 4 核 8G 的机器PTS 就别用 16 核 32G如果生产 MySQL 用的是 8.0PTS 也别图省事装 5.7。配置差异越大压测结果就越没有参考意义最后压出来的数据只能“自嗨”对容量规划和性能优化帮助十分有限。务必要在配置前和生产负责人确认核心参数比如 JVM 堆大小、连接池上限、MySQL buffer pool 等。8.2 初始化脚本要版本化PTS 环境的初始化脚本初始化脚本、部署脚本、压测脚本应该和代码一起纳入版本管理放在同一个仓库里。这样新同事接手时不用靠口头传话拉下来一看就懂。版本化带来的另一个好处是改动可追溯万一环境坏了可以对照历史版本快速定位差异。8.3 每次压测前重置数据压测数据是会污染的。第一次压测往数据库里写了 10 万条记录第二次压测的查询性能就比第一次差因为数据量不同。所以每次压测前按需恢复数据库快照或者用脚本清理test_record表确保每次压测的初始数据量一致。TRUNCATE TABLE test_record;同样日志文件也要提前清空或按压测批次分目录存放避免不同批次的日志混在一起。8.4 建立性能基线开荒完成后把第一次压测的结果保存在项目文档里作为性能基线接口: /api/test 环境: 4核8G / Docker Compose 日期: 2025-01-15 QPS: 18763 P99: 89.76ms CPU: 峰值 78% 内存: 峰值 4.2G之后每次改动代码或升级配置都跑一遍同样的压测对比基线数据。这样能迅速发现性能回退避免上线前才暴露问题。8.5 压测结束及时释放资源PTS 服务器如果不再使用及时释放或关停避免产生不必要的费用。特别是云服务器按量计费的模式下一台 8 核 16G 的 PTS 服务器闲置一个月成本也不低。建议团队内部约定压测任务结束后 3 天内释放资源有需要再随时拉起。9. 小结与下一步行动到这里一台 PTS 服务器的“开荒”流程已经完整走通了从系统初始化、Docker 环境搭建到 Nginx App MySQL 三件套的编排部署再到功能验证、性能摸底、数据备份和问题排查。整个流程里最核心的其实是环境标准化和数据可对比。服务器配置再高如果每次压测的环境都不一样数据就没有可比性也就失去了 PTS 环境存在的意义。如果你现在手头正好有闲置服务器或者准备接手团队的压测环境搭建工作可以直接按照本文的步骤实操一遍。遇到具体问题时优先去看容器日志。日志是排查问题最直接的入口顺着日志一层层往上找大部分坑都能绕过去。希望这篇开荒笔记能给你的工作带来实际帮助。如果你在搭建过程中遇到了其他问题也欢迎在评论区把你的报错日志贴出来一起交流解决思路。下一篇可以聊聊压测报告怎么分析、性能瓶颈怎么定位感兴趣的话可以先关注到时候不迷路。