docker compose编排微服务的核心是职责清晰、通信可靠、启动可控，通过业务边界拆分服务、显式网络隔离、healthcheck保障就绪、外置敏感配置及命名卷持久化，支撑本地开发与中小型部署。
用 Docker Compose 编排微服务集群，核心不是堆服务，而是让每个服务职责清晰、通信可靠、启动可控。它不解决生产级高可用，但能极高效支撑本地开发、测试和中小型部署场景。
按业务边界拆分服务，避免“伪微服务”
微服务不是把单体代码硬切成多个容器。先梳理清楚模块职责：比如用户注册登录归 user-service，订单创建与查询归 order-service，统一入口由 gateway 承担，数据库、Redis 等只做基础设施，不掺业务逻辑。
- 每个服务单独建目录（如
./user-service/），自带Dockerfile和配置文件 - 对外暴露端口严格限制——仅网关暴露
80或443，其他服务默认不映射宿主机端口，只在内部网络互通 - 服务间调用用服务名（如
http://user-service:8080），不用 IP，避免重启后失联
写好 docker-compose.yml，重点在隔离与依赖控制
一份干净的编排文件要分清三层：基础设施（db、redis）、业务服务（gateway、user-service 等）、可选工具（pgadmin、kafka-ui）。不要把所有东西塞进一个大文件。
- 用
networks显式定义私有桥接网络（如micro-net），所有服务加入同一网络才能互相解析服务名 -
depends_on只控制启动顺序，不能保证服务就绪；真正等 DB 启动完成，得配合healthcheck+condition: service_healthy - 敏感配置（密码、密钥）不要硬编码在 YAML 中，改用
.env文件或secrets挂载
让服务真正“健康就绪”，而不是“进程启动”
很多失败源于应用连不上 DB 或 Redis——因为容器进程起来了，但服务还没初始化完。Docker Compose 提供了更可靠的等待机制。
- 为 PostgreSQL 加 healthcheck：
healthcheck: test: ["CMD-SHELL", "pg_isready -U user -d mydb"] - 为 Redis 加 healthcheck：
healthcheck: test: ["CMD", "redis-cli", "ping"] - 业务服务里用
depends_on引用带 healthcheck 的服务，并设condition: service_healthy - Spring Boot 项目可加
spring-boot-starter-actuator，用/actuator/health做自定义健康探针
日志、数据和重启策略要面向稳定运行
本地跑通只是第一步，服务持续可用才关键。几个容易忽略但影响很大的点：
- 数据库和 Redis 必须挂载命名卷（如
pg-data:），否则容器一删，数据全丢 - 业务服务设
restart: on-failure或unless-stopped，避免意外退出后整个链路中断 - 避免用
logs -f逐个查日志，推荐统一输出到 stdout/stderr，再用docker-compose logs -t --tail=100聚合查看 - 调试时用
docker-compose exec <service> sh</service>进入容器，比反复重启更高效
