Docker 环境搭建时怎么在开发机上完美搭建高可用集群测试环境-Docker-PHP中文网

在开发机上搭建高可用集群测试环境，关键是以最小资源验证故障转移、数据不丢和服务自动恢复；需使用 docker compose 创建自定义网络（如 kafka-test-net）、为服务分配静态 ip、选用轻量镜像、配置健康检查与手动故障注入，并按场景合理持久化数据以确保重启可延续、清理可彻底。

docker 环境搭建时怎么在开发机上完美搭建高可用集群测试环境

直接在开发机上搭高可用集群测试环境，关键不是“堆节点数量”，而是用最小资源模拟真实高可用逻辑。开发机通常内存有限（8–16GB）、单物理机，硬套生产架构（比如3台ZooKeeper+3台Kafka）容易OOM或端口冲突。真正“完美”的标准是：能验证故障转移、数据不丢、服务自动恢复，且启动快、清理干净、配置可复用。

用 Docker Compose + 自定义网络快速构建隔离集群

开发机上不建议用 Swarm（需多节点），Docker Compose 就够用，但必须规避默认 bridge 网络的局限性：

所有容器共用 172.17.0.0/16，IP 不固定，服务发现靠 hostname 不稳定
缺少自定义子网和静态 IP 分配，重启后容器 IP 变化会导致 Kafka/ZooKeeper 配置失效

✅ 正确做法：

先创建专用网络：

docker network create --driver bridge --subnet=172.21.0.0/24 --gateway=172.21.0.1 kafka-test-net

在 docker-compose.yml 中为每个关键服务（如 ZooKeeper、Kafka Broker）显式指定 ipv4_address，例如：
```
zoo1:
  networks:
    kafka-test-net:
      ipv4_address: 172.21.0.11
kafka1:
  networks:
    kafka-test-net:
      ipv4_address: 172.21.0.21
```
这样每次 docker-compose up 启动，IP 固定、hostname 可靠、连接不中断，ZooKeeper 的 server.x= 和 Kafka 的 advertised.listeners 才真正生效。

用轻量镜像 + 最小化配置降低资源占用

开发机不是服务器，要主动“减配”：

Docker Container Cleaner

CLI工具，用于清理已停止的Docker容器、未使用的镜像、卷和网络，释放磁盘空间。

下载

ZooKeeper 不用 3 节点全集群，2 节点 + 1 个仲裁节点（observer） 即可满足多数 HA 场景验证（如 leader 切换、session 恢复）
Kafka Broker 设 replication.factor=2、min.insync.replicas=2，配合 2 个 Broker 就能模拟 ISR 收缩与 leader 重选
关闭非必要日志输出、调低 JVM 堆内存（如 -Xmx512m），避免容器因 OOM 被 kill
使用 confluentinc/cp-zookeeper:7.4.0 或 bitnami/kafka:3.7 这类优化过的镜像，比原生 Apache 镜像更省资源

示例 Kafka Broker 内存限制：

kafka1:
  mem_limit: 1g
  mem_reservation: 512m
  environment:
    KAFKA_HEAP_OPTS: "-Xms512m -Xmx512m"

加入健康检查 + 自动故障注入验证 HA 行为

光“跑起来”不算高可用，得验证它“挂了还能活”：

给每个服务加 healthcheck，比如 Kafka：

healthcheck:
  test: ["CMD-SHELL", "kafka-broker-api-versions --bootstrap-server localhost:9092 --command-config /tmp/client.properties 2>/dev/null | grep -q 'supported' || exit 1"]
  interval: 30s
  timeout: 10s
  retries: 3

手动模拟故障（不用等它真崩）：

# 强制停掉一个 Kafka Broker
docker kill kafka1
# 观察 kafka2 是否接管 topic leader（用 kafka-topics.sh --describe 查看）
# 30 秒后 docker-compose 自动重启 kafka1，检查是否重新加入 ISR

日志里重点盯 INFO [Controller id=2] Starting controller、INFO [ReplicaFetcherManager] Removed fetcher for partitions 这类关键词，确认切换真实发生。

数据持久化要分场景，别一股脑挂宿主机目录

开发机上持久化不是为了长期保存，而是保证重启后状态可延续、故障恢复可复现：

ZooKeeper：把 /data 和 /datalog 挂到宿主机子目录（如 ./zoo1/data），避免容器删掉数据就全丢
Kafka：只挂 log.dirs（如 ./kafka1/logs），不挂 __consumer_offsets 的 compact topic 数据（太占空间），用 --delete-topic-enable=true 配合脚本定期清理
测试完一键清理：
```
docker-compose down -v && rm -rf ./zoo* ./kafka* ./data
```
这样既保留可调试性，又不污染开发环境。

不复杂但容易忽略