Docker 不用Compose手动部署微服务的三大痛点及解决方案

本节我们将讨论不用Compose手动部署微服务的三大痛点及解决方案。

问题 1：启动顺序要求严格

（1）具体表现：

必须先启动 MySQL、Redis 等基础依赖服务，才能启动微服务（比如订单服务）；如果先启动微服务，会因 “依赖服务未就绪” 导致连接失败、服务启动报错。

（2）问题：

手动部署时需要人工记顺序，一旦顺序错了就得重新启动，效率极低。

（3）Compose 解决方案：

在docker-compose.yml中用depends_on配置服务依赖，Compose 会自动按依赖顺序启动（比如配置微服务depends_on: [mysql, redis]，Compose 会先启 MySQL、Redis，再启微服务）。

问题 2：多docker run命令繁琐，无一键部署能力

（1）具体表现：

部署一个微服务工程，需要执行多个docker run命令（比如docker run mysql、docker run redis、docker run order-service），且每个命令都要加端口、挂载、环境变量等参数，操作步骤多且容易输错。

（2）问题：

重复劳动多，部署效率低；团队协作时，每个人都要重复执行相同的命令，容易出现 “环境不一致” 问题。

（3）Compose 解决方案：

把所有docker run的参数（端口、挂载、环境变量）写在docker-compose.yml中，执行

docker-compose up -d

即可一键启动所有服务；停止时用

docker-compose down

一键关闭，实现 “一键部署 / 销毁”。

问题 3：容器 IP 不稳定，服务间通信易出错

（1）具体表现：

容器重启、宕机后，Docker 会重新分配 IP；如果微服务代码里写死了依赖容器的 IP（比如订单服务配置mysql_ip=172.17.0.2），IP 变化后会导致连接失败。（要么生产Ip写死(可以但是不推荐)，要么通过服务调用）

（2）问题：

生产环境中容器 IP 是动态的，写死 IP 会导致服务不稳定；若不用 IP，手动维护容器间的网络关系又很复杂。

（3）Compose 解决方案：

Compose 会自动创建自定义网络，同一工程内的服务可以直接用 “服务名” 通信（比如订单服务配置mysql_host=mysql，不用写 IP）；即使容器 IP 变化，Compose 会自动维护服务名与容器的映射，保证通信稳定。