最近在项目中用Docker Compose做容器编排，搭建了一套高可用高并发的架构，整个过程踩了不少坑，也积累了很多经验。Docker Compose是Docker官方提供的容器编排工具，能很方便地定义和运行多容器的应用，用一个YAML文件就能配置所有的服务，然后一条命令就能启动所有服务，非常方便。

但是，要做好高可用高并发的架构，还是有很多需要注意的地方，不是简单地把服务容器化就可以了。今天就来分享一下我用Docker Compose做高可用高并发架构设计的经验，包括架构设计、服务拆分、负载均衡、高可用、数据持久化、日志监控、性能优化等，希望能给正在做容器化和编排的朋友一些参考。

一、为什么选择Docker Compose

先说说为什么选择Docker Compose吧。我们的项目是一个Web应用，有前端、后端、数据库、缓存、消息队列等多个服务，之前是直接部署在服务器上的，部署很麻烦，环境不一致，经常出现"在我机器上能跑"的问题，而且扩容、迁移都很不方便。

后来，我们决定做容器化，用Docker来打包和运行服务，解决环境不一致的问题。但是，服务多了之后，手动管理容器很麻烦，每次启动都要手动启动好几个容器，还要配置网络、卷、环境变量等，很容易出错。于是，我们需要一个容器编排工具，来管理多容器的应用。

容器编排工具有很多，比如Docker Compose、Kubernetes、Docker Swarm、Mesos等，我们为什么选择Docker Compose呢？主要有几个原因：

  1. 简单易用：Docker Compose是Docker官方提供的，和Docker无缝集成，学习成本低，用一个YAML文件就能配置所有服务，一条命令就能启动、停止、重启所有服务，非常方便。
  2. 适合中小规模：我们的项目规模不大，服务数量不多，服务器数量也不多，用Docker Compose足够了，不需要Kubernetes那么复杂的编排工具，Kubernetes虽然功能强大，但是学习成本高，运维复杂，对于中小规模的项目来说，有点杀鸡用牛刀。
  3. 本地开发和生产环境一致：Docker Compose既能用于本地开发，也能用于生产环境，本地开发用的docker-compose.yml和生产环境用的基本一致，能保证开发环境和生产环境一致，避免"在我机器上能跑"的问题。
  4. 生态成熟：Docker Compose已经很成熟了，社区活跃，文档完善，遇到问题很容易找到解决方案，而且有很多现成的镜像和配置可以参考。

当然，Docker Compose也有它的局限性，比如不支持跨主机编排（不过可以用Docker Swarm或者其他工具配合），自动扩缩容能力不如Kubernetes，适合单主机或者小规模的多主机环境。但是对于我们的项目来说，Docker Compose完全够用了，而且简单易用，运维成本低，所以我们选择了Docker Compose。

二、整体架构设计

我们的整体架构，用Docker Compose编排了以下几个服务：

  1. Nginx：反向代理和负载均衡，接收客户端的请求，转发到后端的应用服务，同时处理静态资源、SSL、Gzip等。
  2. 应用服务（Web）：我们的后端应用，用Node.js写的，处理业务逻辑，提供API接口，部署了多个实例，做负载均衡和高可用。
  3. MySQL：数据库，主从复制，主库负责写，从库负责读，做读写分离和数据备份。
  4. Redis：缓存，做数据缓存、会话存储、消息队列等，主从复制，哨兵模式，做高可用。
  5. 消息队列（RabbitMQ）：异步消息处理，解耦系统，削峰填谷，处理异步任务。
  6. Elasticsearch：搜索引擎，做全文检索、日志存储和分析。
  7. 监控（Prometheus + Grafana）：监控系统，收集各个服务的指标，可视化展示，告警。
  8. 日志（ELK / Fluentd）：日志系统，收集各个服务的日志，集中存储和分析。

这些服务都用Docker容器运行，用Docker Compose编排，一个docker-compose.yml文件定义所有服务，一条命令就能启动整个栈。

架构的特点：

  • 无状态服务多实例：应用服务是无状态的，部署多个实例，通过Nginx做负载均衡，任何一个实例挂了，其他实例还能继续提供服务，实现高可用。
  • 有状态服务主从复制：数据库、缓存等有状态的服务，用主从复制，实现数据备份和高可用，主库挂了，从库可以提升为主库，继续提供服务。
  • 反向代理统一入口：Nginx作为统一入口，处理所有客户端请求，做负载均衡、SSL、Gzip、静态资源处理等，后端服务不需要直接暴露给公网，更安全。
  • 异步解耦：用消息队列做异步处理，解耦系统，削峰填谷，提高系统的并发处理能力和可用性。
  • 监控日志完善：有完善的监控和日志系统，能实时了解系统的运行状态，出现问题能快速定位和解决。

三、docker-compose.yml配置详解

现在来看看我们的docker-compose.yml配置，这里分享一些关键的配置和经验。

1. 版本和服务定义

version: '3.8'

services:
  nginx:
    image: nginx:1.21
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/ssl:/etc/nginx/ssl
      - ./static:/usr/share/nginx/html
      - nginx-logs:/var/log/nginx
    depends_on:
      - web
    restart: always
    networks:
      - app-network

  web:
    build: ./web
    expose:
      - "3000"
    volumes:
      - ./web:/app
      - /app/node_modules
    environment:
      - NODE_ENV=production
      - DB_HOST=mysql
      - DB_PORT=3306
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - RABBITMQ_HOST=rabbitmq
      - RABBITMQ_PORT=5672
    depends_on:
      - mysql
      - redis
      - rabbitmq
    restart: always
    networks:
      - app-network
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure

这里有几个关键点：

  • version：指定Compose文件的版本，建议用最新的稳定版本，3.8是比较新的，支持很多新特性。
  • image vs build：Nginx用官方镜像，直接用image；我们自己的应用用build，从Dockerfile构建。
  • ports vs expose：Nginx需要暴露端口给公网，用ports；应用服务不需要暴露给公网，只需要在内部网络访问，用expose，更安全。
  • volumes：挂载配置文件、静态资源、日志等，数据持久化，容器销毁之后数据不会丢。注意，挂载代码目录的时候，要排除node_modules等容器内的目录，用匿名卷，避免覆盖容器内的文件。
  • environment：环境变量，配置数据库、缓存等连接信息，用服务名作为主机名，因为Compose会自动创建内部DNS，服务名可以解析到对应的容器IP。
  • dependson：服务依赖，指定服务启动顺序，但是注意，dependson只会等待容器启动，不会等待服务就绪，所以如果需要等待服务就绪，要用wait-for-it脚本或者健康检查。
  • restart：重启策略，always表示容器退出时总是重启，保证服务的可用性。
  • networks：网络，所有服务都加入同一个自定义网络，服务之间可以用服务名互相访问，隔离外部网络，更安全。
  • deploy.replicas：副本数，部署3个应用实例，做负载均衡和高可用。注意，这个配置只有在Swarm模式下才生效，普通的docker-compose up不支持replicas，如果要用多实例，要么用Swarm模式，要么手动定义多个服务，或者用其他工具。

踩坑1：depends_on不会等待服务就绪

这是一个常见的坑，depends_on只会等待容器启动，不会等待服务就绪，比如MySQL容器启动了，但是MySQL服务还没初始化完成，这时候应用服务就启动了，连接数据库会失败。

解决方法：

  • 用wait-for-it脚本，在应用启动之前，等待数据库端口就绪，然后再启动应用。
  • 用健康检查（healthcheck），配置服务的健康检查，然后dependson配合condition: servicehealthy，等待服务健康之后再启动。
  • 在应用代码里做重试，连接数据库失败的时候，重试几次，等待数据库就绪。

我们用的是wait-for-it脚本，在Dockerfile的ENTRYPOINT里，先等待数据库和缓存就绪，然后再启动应用，很可靠。

踩坑2：普通模式不支持replicas

上面说了，deploy.replicas只有在Swarm模式下才生效，普通的docker-compose up不支持，如果你用普通模式，写了replicas也不会生效，只会启动一个实例。

解决方法：

  • 用Docker Swarm模式，docker stack deploy，支持replicas、滚动更新等高级特性。
  • 普通模式下，手动定义多个服务，比如web1、web2、web3，每个服务用相同的配置，然后Nginx upstream配置这三个服务。
  • 用其他工具，比如docker-compose scale（旧版本支持，新版本已经废弃）。

我们后来用了Docker Swarm模式，因为需要多实例和滚动更新，Swarm模式和Compose兼容很好，配置文件基本不用改，用docker stack deploy就能部署，很方便。

2. 数据库和缓存的配置

  mysql:
    image: mysql:5.7
    command: --default-authentication-plugin=mysql_native_password --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    volumes:
      - mysql-data:/var/lib/mysql
      - ./mysql/conf.d:/etc/mysql/conf.d
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: appdb
      MYSQL_USER: appuser
      MYSQL_PASSWORD: apppassword
    restart: always
    networks:
      - app-network
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:6.2
    command: redis-server --appendonly yes --requirepass redispassword
    volumes:
      - redis-data:/data
    restart: always
    networks:
      - app-network
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "redispassword", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

这里有几个关键点：

  • 数据卷：数据库和缓存的数据，用命名卷（named volume）持久化，容器销毁之后数据不会丢，不要用bind mount，性能和权限都有问题。
  • 配置挂载：配置文件用bind mount挂载，方便修改配置，不需要重新构建镜像。
  • 环境变量：数据库的root密码、数据库名、用户名、密码，用环境变量配置，镜像启动的时候会自动初始化。
  • command：覆盖默认的启动命令，配置字符集、认证插件、Redis密码、AOF持久化等。
  • healthcheck：健康检查，配置服务的健康检查命令，Compose会定期检查服务是否健康，不健康的话会重启，也可以配合depends_on使用。

踩坑3：数据库权限和数据卷权限问题

用MySQL镜像的时候，经常会遇到权限问题，比如数据卷的权限不对，导致MySQL启动失败，或者连接不上。

解决方法：

  • 用官方镜像，按照官方文档的配置来，不要随便改用户和权限。
  • 数据卷用命名卷，不要用bind mount，命名卷的权限是镜像自动处理的，不会有问题。
  • 如果用bind mount，要确保目录的权限正确，MySQL镜像用的是mysql用户，UID是999，要把目录的所有者改成999:999。
  • 第一次启动的时候，MySQL会初始化数据库，需要一点时间，不要急着连接，等初始化完成。

踩坑4：Redis没有配置密码，被攻击了

一开始，我们的Redis没有配置密码，而且端口暴露给了公网，结果被黑客扫描到了，入侵了我们的服务器，植入了挖矿程序，导致CPU占用100%，服务器很卡。

解决方法：

  • Redis一定要配置密码，用--requirepass参数，或者在配置文件里配置requirepass。
  • 不要把Redis端口暴露给公网，用expose，只在内部网络访问，不要用ports。
  • 数据库、缓存这些有状态的服务，都不要暴露给公网，只在内部网络访问，通过应用服务访问，更安全。
  • 定期更新镜像，修复安全漏洞。

这次被攻击给了我们很大的教训，安全一定要重视，不要图省事，该配置的密码一定要配置，该关闭的端口一定要关闭。

3. 网络和卷的定义

networks:
  app-network:
    driver: bridge

volumes:
  mysql-data:
  redis-data:
  nginx-logs:
  es-data:

这里定义了一个自定义网络app-network，用bridge驱动，所有服务都加入这个网络，服务之间可以用服务名互相访问，隔离外部网络，更安全。

卷定义了几个命名卷，用来持久化数据库、缓存、日志等数据，容器销毁之后数据不会丢。

踩坑5：用默认网络，服务之间不能用服务名访问

一开始，我们没有定义自定义网络，用的是Compose的默认网络，结果服务之间不能用服务名访问，连接失败。

解决方法：

  • 定义自定义网络，所有服务都加入这个网络，服务之间就能用服务名互相访问了。
  • 其实Compose的默认网络也是支持服务名访问的，但是如果服务有多个网络，或者用了link，可能会有问题，最好还是显式定义自定义网络，所有服务都加入，更可靠。

四、高可用设计

高可用是我们架构设计的重点，这里分享一下我们做高可用的经验。

1. 无状态服务多实例+负载均衡

应用服务是无状态的，我们部署了3个实例，通过Nginx做负载均衡，请求分发到不同的实例，任何一个实例挂了，Nginx会自动把它从upstream里摘除，请求转发到其他健康的实例，用户不会感知到故障，实现高可用。

Nginx的upstream配置：

upstream web_backend {
    server web1:3000 max_fails=3 fail_timeout=30s;
    server web2:3000 max_fails=3 fail_timeout=30s;
    server web3:3000 max_fails=3 fail_timeout=30s;
    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;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

这里配置了maxfails和failtimeout，某个实例失败3次之后，30秒内不会再把请求转发给它，自动摘除故障实例。

2. 有状态服务主从复制

数据库和缓存是有状态的，我们用主从复制实现高可用：

  • MySQL主从复制：一主一从，主库负责写，从库负责读，主库的数据实时同步到从库，主库挂了，可以把从库提升为主库，继续提供服务。
  • Redis主从+哨兵：一主一从，哨兵模式，哨兵监控主库的状态，主库挂了，哨兵自动把从库提升为主库，实现自动故障转移，不需要人工干预。

主从复制不仅能实现高可用，还能做读写分离，减轻主库的读压力，提高并发处理能力。

3. 健康检查和自动重启

所有服务都配置了健康检查和自动重启：

  • 健康检查：Compose会定期检查服务的健康状态，不健康的服务会被标记为不健康，Nginx不会把请求转发给不健康的实例。
  • 自动重启：restart: always，容器退出的时候自动重启，服务挂了自动恢复，不需要人工干预。

健康检查的配置，上面已经说了，用healthcheck字段，配置检查命令、间隔、超时、重试次数。

4. 滚动更新

用Swarm模式的话，支持滚动更新，更新服务的时候，不会一次性把所有实例都停掉，而是一个一个更新，先更新一个实例，等待一段时间，确认没问题之后，再更新下一个，保证更新过程中服务不中断，用户无感知。

配置：

    deploy:
      replicas: 3
      update_config:
        parallelism: 1  # 每次更新1个实例
        delay: 10s      # 每个实例更新后等待10秒
        order: start-first  # 先启动新实例，再停止旧实例
      restart_policy:
        condition: on-failure

start-first表示先启动新实例，健康检查通过之后，再停止旧实例，保证更新过程中始终有足够的实例提供服务，不会中断。

5. 数据备份

虽然有主从复制，但是还是要定期做数据备份，防止误操作、数据损坏、机房故障等情况。我们用脚本每天凌晨自动备份数据库，备份文件上传到对象存储，保留最近7天的备份，出了问题可以快速恢复。

备份脚本：

#!/bin/bash
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="/backup/mysql_$DATE.sql.gz"
docker exec mysql mysqldump -u root -ppassword --all-databases | gzip > $BACKUP_FILE
# 上传到对象存储
ossutil cp $BACKUP_FILE oss://mybucket/backup/
# 删除7天前的备份
find /backup -name "mysql_*.sql.gz" -mtime +7 -delete

用crontab每天凌晨2点执行，自动备份。

五、高并发优化

高并发是我们架构设计的另一个重点，这里分享一下我们做高并发优化的经验。

1. 负载均衡

用Nginx做负载均衡，把请求分发到多个应用实例，提高并发处理能力。Nginx的负载均衡策略有轮询、加权轮询、IP哈希、最少连接等，我们用的是加权轮询，根据服务器的性能分配权重，性能好的服务器分配更多的请求。

除了Nginx，还可以用HAProxy、Traefik等负载均衡工具，Nginx是最常用的，功能强大，性能好。

2. 缓存

缓存是提高并发性能最有效的手段，我们用了多级缓存：

  • 浏览器缓存：静态资源设置Cache-Control，浏览器缓存，减少请求。
  • CDN缓存：静态资源放到CDN，用户从最近的CDN节点获取，减轻源站压力。
  • Nginx缓存：Nginx缓存静态资源和部分动态页面，减少后端请求。
  • 应用缓存：应用层用Redis缓存热点数据，比如用户信息、商品信息、文章列表等，减少数据库查询。
  • 数据库缓存：MySQL的查询缓存、InnoDB buffer pool，缓存数据和索引，减少磁盘IO。

通过多级缓存，大部分请求都能在缓存层命中，不需要查询数据库，大大提高了并发处理能力，降低了数据库的压力。

3. 读写分离

数据库用主从复制，做读写分离，写请求走主库，读请求走从库，减轻主库的读压力，提高并发处理能力。我们的应用是读多写少，读写分离效果很明显，读请求都打到从库，主库只处理写请求，压力小了很多。

读写分离可以在应用层做，也可以用中间件做，比如MyCat、ShardingSphere、ProxySQL等，我们用的是ProxySQL，自动路由读写，对应用透明，不需要改代码。

4. 异步处理

用消息队列做异步处理，把不需要实时返回的任务，比如发送邮件、短信、生成报表、数据同步等，放到消息队列里，异步处理，不阻塞主流程，提高接口的响应速度和并发处理能力。

我们用的是RabbitMQ，也可以用Kafka、Redis等，根据业务场景选择。消息队列还能做削峰填谷，流量高峰期的时候，请求先放到消息队列里，慢慢处理，避免数据库被打垮。

5. 数据库优化

数据库优化是高并发优化的重点，我们做了这些优化：

  • 索引优化：给常用的查询字段加索引，避免全表扫描，定期分析慢查询，优化慢SQL。
  • 分库分表：数据量大的表，做分库分表，提高查询和写入性能。
  • 连接池优化：合理配置数据库连接池，避免连接数过多或过少。
  • 参数优化：优化MySQL的参数，比如innodbbufferpoolsize、innodblogfilesize、max_connections等，提高性能。

6. 静态资源优化

静态资源（图片、CSS、JS、视频等）不经过应用服务，直接由Nginx或者CDN处理，减轻应用服务的压力。静态资源做压缩（Gzip/Brotli）、合并、缓存，减少请求大小和数量，提高加载速度。

7. 容器资源限制

给每个容器设置合理的CPU和内存限制，避免某个服务占用太多资源，影响其他服务。配置：

    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2G
        reservations:
          cpus: '0.5'
          memory: 512M

limits是最大资源限制，reservations是预留资源，合理配置，保证服务的稳定性，避免资源争抢。

六、日志和监控

日志和监控是高可用高并发架构必不可少的部分，出了问题能快速定位，平时能了解系统的运行状态。

1. 日志收集

我们用Fluentd收集各个容器的日志，统一发送到Elasticsearch，用Kibana做可视化和查询，也就是EFK栈（Elasticsearch + Fluentd + Kibana）。

Docker的日志驱动配置成fluentd，所有容器的日志都自动发送到Fluentd，不需要在每个容器里配置日志收集，很方便。

docker-compose.yml里配置日志驱动：

    logging:
      driver: fluentd
      options:
        fluentd-address: localhost:24224
        tag: docker.{{.Name}}

所有容器的日志都自动收集，集中存储，能在Kibana里统一查询和分析，出了问题能快速定位。

2. 监控告警

我们用Prometheus + Grafana做监控，Prometheus收集各个服务的指标，Grafana做可视化展示，配置告警规则，有异常的时候通过邮件、短信、钉钉等方式告警。

需要监控的指标：

  • 服务器指标：CPU、内存、磁盘、网络、负载等。
  • 容器指标：容器的CPU、内存、网络、重启次数等。
  • 应用指标：QPS、响应时间、错误率、并发数等。
  • 数据库指标：连接数、QPS、慢查询、缓存命中率、主从延迟等。
  • 缓存指标：命中率、内存使用、连接数、QPS等。
  • 消息队列指标：队列长度、消费速度、生产速度、堆积数等。

Grafana里配置了各种仪表盘，实时展示系统的运行状态，一目了然。配置了告警规则，比如CPU使用率超过80%、内存使用率超过80%、磁盘使用率超过90%、应用错误率超过1%、主从延迟超过10秒等，有异常马上告警，通知运维人员处理。

3. 链路追踪

对于微服务架构，链路追踪也很重要，我们用Jaeger做分布式链路追踪，能看到一个请求经过了哪些服务，每个服务的耗时，出了问题能快速定位是哪个服务的问题。

应用代码里集成Jaeger的SDK，自动上报链路数据，Jaeger收集和展示链路信息，很方便。

七、部署和运维

最后，说说部署和运维的经验。

1. 环境区分

我们区分了开发环境、测试环境、生产环境，每个环境有独立的docker-compose配置，用环境变量区分，避免环境混淆。

  • 开发环境：本地开发用，代码挂载，热重载，方便调试。
  • 测试环境：测试用，和生产环境配置一致，部署测试版本，供测试人员测试。
  • 生产环境：正式环境，配置高可用、监控、告警，部署正式版本。

用docker-compose的override功能，基础配置是docker-compose.yml，环境特定的配置是docker-compose.override.yml，启动的时候自动合并，很方便。

2. CI/CD

我们用GitLab CI做持续集成和持续部署，代码提交之后，自动构建镜像，运行测试，测试通过之后，自动部署到测试环境，测试通过之后，手动确认部署到生产环境。

CI/CD流程：

  1. 代码提交到GitLab。
  2. GitLab CI自动触发，构建Docker镜像。
  3. 运行单元测试和集成测试。
  4. 测试通过，镜像推送到镜像仓库。
  5. 自动部署到测试环境。
  6. 测试人员测试，测试通过。
  7. 手动确认，部署到生产环境（滚动更新）。

整个流程自动化，减少人工操作，提高部署效率和可靠性。

3. 运维脚本

我们写了很多运维脚本，比如备份脚本、日志清理脚本、健康检查脚本、故障恢复脚本等，自动化运维，减少人工操作，提高效率。

常用的运维命令：

# 启动所有服务
docker-compose up -d

# 停止所有服务
docker-compose down

# 重启某个服务
docker-compose restart web

# 查看服务状态
docker-compose ps

# 查看服务日志
docker-compose logs -f web

# 进入容器
docker-compose exec web bash

# 滚动更新（Swarm模式）
docker stack deploy -c docker-compose.yml myapp

# 查看服务状态（Swarm模式）
docker service ls

# 查看服务实例（Swarm模式）
docker service ps myapp_web

熟练掌握这些命令，运维起来很方便。

4. 安全加固

安全很重要，我们做了这些安全加固：

  • 所有服务都不要用root用户运行，在Dockerfile里创建普通用户，用普通用户运行。
  • 数据库、缓存等有状态服务，不要暴露端口给公网，只在内部网络访问。
  • 所有需要密码的服务，都配置强密码，不要用弱密码。
  • 定期更新镜像，修复安全漏洞。
  • 服务器配置防火墙，只开放必要的端口（80、443、22）。
  • SSH用密钥登录，禁用密码登录，修改默认端口。
  • 配置fail2ban，防止暴力破解。
  • 定期做安全扫描，发现漏洞及时修复。

安全是一个持续的过程，要定期检查和加固，不能掉以轻心。

八、写在最后

Docker Compose编排架构设计：高可用高并发。

以上就是我用Docker Compose做高可用高并发架构设计的经验，从架构设计、配置详解、高可用、高并发、日志监控，到部署运维，都做了一个比较全面的总结。

Docker Compose是一个非常好用的容器编排工具，简单易用，功能强大，对于中小规模的项目来说，完全够用了，而且学习成本低，运维成本低，能大大提高开发和部署效率。但是，要做好高可用高并发的架构，还是有很多需要注意的地方，不是简单地把服务容器化就可以了，需要在服务拆分、负载均衡、高可用、数据持久化、性能优化、监控告警、安全加固等方面，做很多工作。

当然，Docker Compose也有它的局限性，如果项目规模很大，服务很多，服务器很多，需要复杂的编排、自动扩缩容、服务发现等，那可能需要用Kubernetes这样更强大的编排工具。但是对于大部分中小规模的项目来说，Docker Compose已经足够了，而且更简单，更轻量，运维成本更低。

技术没有最好，只有最合适，根据项目的规模和需求，选择合适的技术，才是最重要的。

希望我的这些经验，能给正在做容器化和编排的朋友一些参考，少踩坑，少走弯路，搭建出稳定、高效、高可用的架构。

最后，用一句话结尾："容器化不是目的，高可用高并发才是目的；工具只是手段，稳定可靠的服务才是根本。"愿我们都能用好工具，搭建出稳定可靠的系统，给用户最好的体验。