用 Docker Compose 做微服务性能基准测试的核心是确保环境真实、可观测、可复现，需精准控制依赖顺序（配合 healthcheck 与 condition）、暴露关键指标（集成 Prometheus/Grafana/cAdvisor）、执行可控压测（使用 fortio/wrk 并关联指标分析），并通过多环境配置分离实现结果比对。
直接用 Docker Compose 做微服务性能基准测试，核心不是“跑起来”，而是让测试环境真实、可观测、可复现。重点在于三件事：精准控制服务依赖顺序、暴露关键性能指标、隔离干扰因素。
配置带健康检查与资源限制的服务拓扑
默认的 depends_on 只按启动顺序等待，不保证服务真正就绪，容易导致压测一开始就连不上数据库。必须配合 healthcheck 和条件启动：
- 为每个有状态服务（如 PostgreSQL、Redis、Kafka）定义明确的健康检测命令，例如 PostgreSQL 用
pg_isready -U postgres，Redis 用redis-cli ping - 在依赖服务中设置重试次数和超时，避免短时抖动导致整个编排失败
- 给每个服务加上
deploy.resources限制，防止某个服务突发占满 CPU 或内存，影响其他服务表现 - 示例片段：
db: image: postgres:15-alpine healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 12 deploy: resources: limits: cpus: '1.5' memory: 1g api: build: ./api depends_on: db: condition: service_healthy deploy: resources: limits: cpus: '2' memory: 2g
集成可观测性组件并暴露指标端点
没有监控数据的性能测试等于盲测。Docker Compose 要一次性拉起指标采集链路：
- 在 compose 文件中加入
prometheus和grafana服务，并配置 Prometheus 抓取目标为各微服务的/metrics端点（需服务本身支持，如 Go 的promhttp或 Spring Boot Actuator） - 为容器启用 cAdvisor，它能自动采集所有容器的 CPU、内存、网络、磁盘 I/O 实时数据，并通过 Prometheus 抓取
- 确保所有服务网络互通且允许跨容器访问指标路径，建议统一使用自定义 bridge 网络，禁用默认网络隔离
- 不要只看吞吐量或响应时间，重点关注
container_cpu_usage_seconds_total、container_memory_usage_bytes、http_request_duration_seconds_bucket这类原生指标
用标准工具执行可控压测并关联指标
压测工具要能运行在独立容器里，与被测服务同处一个网络，避免宿主机网络栈干扰：
- 推荐使用
ghcr.io/davidjpeacock/wrk或fortio镜像，它们轻量、支持高并发、输出结构化结果 - 压测命令应固定并发数、持续时间和请求路径，例如：
fortio load -qps 100 -t 120s http://api:8080/health - 压测期间同步抓取 Prometheus 指标快照，可用
curl http://prometheus:9090/api/v1/query?query=...或 Grafana 自动导出面板数据 - 特别注意错误率突增时对应的 CPU 使用拐点、GC 频次上升或连接池耗尽等关联信号，这才是定位瓶颈的关键
多环境配置分离与结果比对
单次测试价值有限，真正有用的是不同配置下的横向对比：
- 用多文件机制拆分配置：一个
docker-compose.base.yml定义服务结构，一个docker-compose.perf.yml专门覆盖资源限制、健康检查和可观测性组件 - 测试不同参数组合时，只需切换 override 文件，例如对比开启/关闭 Redis 缓存、调整 JVM 堆大小、更换数据库连接池策略
- 每次测试后保存指标截图和 wrk/fortio 的 JSON 输出，用脚本自动提取 P90 延迟、QPS、错误率生成简明对比表
- 避免在测试中混入开发配置（如热重载、debug 日志），所有服务统一用 production profile 启动
