微服务生命周期管理依赖标准化定义与编排工具：dockerfile通过entrypoint/cmd和healthcheck定义单容器行为；docker compose协调多服务启停与健康依赖；kubernetes通过liveness/readiness/startup probe实现生产级自动治理与智能调度。
微服务架构中，每个服务独立运行在自己的容器里，生命周期管理不是管“一个容器”，而是管“一批容器的启停、健康、扩缩、替换”——核心靠标准化定义 + 编排工具驱动。
用 Dockerfile 定义服务的启动与终止行为
每个微服务的 Dockerfile 不仅打包代码，还明确它的“活法”：
-
ENTRYPOINT/CMD 决定容器启动时执行什么命令，比如
java -jar app.jar，这是服务进程的根进程；一旦它退出，容器就终止 -
HEALTHCHECK 声明如何判断服务是否真正就绪并持续可用，例如：
HEALTHCHECK --interval=20s --timeout=5s --retries=3 CMD curl -f http://localhost:8080/actuator/health || exit 1 - 避免使用
bash或后台守护进程（如service nginx start && tail -f /dev/null），否则容器会因主进程“假死”而无法被编排系统正确感知
用 Docker Compose 统一协调多服务生命周期
开发和测试阶段，Docker Compose 是最直接的协同载体。它把多个服务的生命周期绑定在一个声明式文件中：
- 通过
depends_on控制启动顺序（如先等数据库容器healthy后再启动应用） - 用
restart:策略定义异常退出后的行为：unless-stopped（手动停才不重启）、on-failure:3（失败最多重试3次） -
healthcheck:配置可覆盖 Dockerfile 中的定义，支持更细粒度的就绪等待，例如：web:<br> depends_on:<br> db:<br> condition: service_healthy
用 Kubernetes 实现生产级自动生命周期治理
在生产环境，Kubernetes 承担真正的协同管理职责，把单个容器的生命周期升级为“服务实例集群”的智能调度：
- Liveness Probe：探测服务是否“活着”，失败则杀掉 Pod 并新建——防进程卡死但端口仍通
- Readiness Probe：探测服务是否“准备好接收流量”，未通过时自动从 Service 的 Endpoint 列表中剔除——防请求打到未初始化完的实例
- Startup Probe：针对启动慢的服务（如 Spring Boot 初始化耗时长），先等它“启动完成”，再启用 liveness/readiness 检查
- Deployment 控制器持续比对“期望状态”（如 replicas=5）与“实际状态”，自动创建、替换或驱逐 Pod
关键协同点：健康状态驱动上下游动作
容器健康不是孤立指标，而是整个微服务协同链路的触发开关：
- 当用户服务容器被标记为
unhealthy，Kubernetes 会停止向它转发请求，并在几秒内拉起新实例 - Docker Compose 的
docker-compose ps可直观看到各服务的Health状态列，便于快速定位故障源头 - 服务注册中心（如 Consul、Eureka）通常与健康检查联动：只有
healthy的实例才被注册，下线时自动注销
