Dockerfile 不直接实现服务发现，而是通过支持动态配置、健康检查、环境变量注入，并与 Docker Compose 或 Kubernetes 等编排工具协同完成——镜像需避免硬编码地址，使用 DNS 服务名通信，预留 HEALTHCHECK 和 ENTRYPOINT 配置能力。
要让 Docker 容器中的微服务能自动发现彼此，Dockerfile 本身不直接实现服务发现，但它必须为运行时服务发现做好准备——关键在于：镜像需支持动态配置、健康检查、环境变量注入，并与运行时编排工具（如 Docker Compose、Kubernetes）协同工作。
明确 Dockerfile 的定位：打包可配置的服务，而非硬编码地址
Dockerfile 的核心任务是构建一个轻量、可复用、环境无关的镜像。微服务不应在构建阶段写死其他服务的 IP 或端口（例如 不要写 RUN curl http://user-service:8080/health），而应把连接信息推迟到容器启动时通过环境变量、DNS 或配置中心注入。
- 使用 ENTRYPOINT 脚本替代硬编码 CMD，以便在启动前读取环境变量并生成配置（如 application.yml、nginx.conf）
- 基础镜像优先选 slim 或 alpine（如 openjdk:17-jre-slim），减少攻击面，加快启动速度
- 暴露端口用 EXPOSE 8080（仅文档作用），实际端口映射由 docker run 或 compose 控制
支持 DNS 基础服务发现：适配 Docker 内置 DNS
Docker 默认为同一自定义网络（如 docker network create mynet）内的容器提供基于容器名的 DNS 解析。你的服务只需用服务名（如 payment-service）作为 host 即可通信。
- 确保应用代码中访问其他服务时使用逻辑名（http://order-service:8080），而非 localhost 或 IP
- Dockerfile 中无需特殊指令，但需在运行时用 --network mynet 启动，或在 docker-compose.yml 中统一定义 network
- Java 服务建议添加 JVM 参数 -Djava.net.preferIPv4Stack=true，避免 IPv6 DNS 解析延迟
预留健康检查与配置注入能力
服务发现依赖健康状态判断。Dockerfile 应暴露健康端点，并允许外部探针集成。
- 在镜像中包含简单健康检查脚本（如 healthcheck.sh），用于容器内自检
- Dockerfile 中声明 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 CMD ["/bin/sh", "-c", "curl -f http://localhost:8080/actuator/health || exit 1"]
- 配置文件（如 Spring Boot 的 application.yml）中用占位符：spring.redis.host: ${REDIS_HOST:redis}，启动时由环境变量覆盖
配合编排层完成闭环：Dockerfile 是起点，不是终点
真正实现服务发现，需要 Dockerfile + 运行时网络 + 编排配置三者配合。例如：
- docker-compose.yml 中定义多个 service，共享 network，并通过 service 名互相调用
- Kubernetes 场景下，Dockerfile 构建镜像后，用 Service 和 DNS（orders.default.svc.cluster.local）实现跨 Pod 发现
- 若需更高级发现（如 Consul、Eureka），Dockerfile 需预装客户端 SDK 或 sidecar（如 consul-template），并在 ENTRYPOINT 中注册服务
