从上图可知，如果Eureka的服务不可用，就会影响业务服务的功能；
Docker环境中的依赖关系上述服务如果用docker-compose编排在一起，也面依赖着问题：Eureka容器启动完毕并且能提供http服务以后，业务服务的容器才能在Eureka注册成功并取得服务列表，通常我们都使用depends_on参数来设定依赖关系；以下是个docker-compose.yml文件，里面有两个容器：eureka和service，eureka是注册中心，service是业务服务，service启动后要去eureka注册，为了确保启动顺序，service配置了depends_on参数：version: '3'services: eureka: image: bolingcavalry/eureka:0.0.1-SNAPSHOT container_name: eureka restart: unless-stopped service: image: bolingcavalry/service:0.0.1-SNAPSHOT container_name: service restart: unless-stopped command: sh -c 'java -Xms1g -Xmx1g -cp /app/resources:/app/classes:/app/libs/ com.bolingcavalry.waitforitdemo.ServiceApplication' depends_on: - eureka上述yml文件能解决依赖问题吗？service服务启动时能否成功在eureka注册？来试试吧，在Linux电脑上创建docker-compose.yml文件，内容如上所示；在docker-compose.yml所在目录执行docker-compose up，docker服务会先去hub.docker.com下载镜像，然后依次创建容器，控制台会同时打印eureka和service的日志，如下图所示，service注册eureka失败了，请注意图中的文字分析：
为何会注册失败呢？继续看后面的日志，如下图，service注册失败后eureka才初始化完成，所以前面的service注册会失败：
另外您可能会说：没关系，service会自动重新注册，但是在真实环境中，不是每个服务都有能力去自己解决依赖不可用的问题，例如spring-cloud-config服务如果起不来，依赖它的服务可能会立即停止；
version: \"2.4\"services: web: build: . depends_on: db: condition: service_healthy redis: condition: service_started redis: image: redis db: image: redis healthcheck: test: \"exit 0\"
从上述编排内容可见：db容器有健康检查，可以确定db容器的服务是否可用，web容器的depends_on参数内可以配置condition，这样就做到了只有redis已经启动并且db的健康检查通过，才会启动web容器；
上述配置看起来似乎是个不错的方案，在我们这里，只要给eureka配置要健康检查，再让service容器的depends_on参数内配置condition: service_healthy就可以了；不幸的是：在docker-compose的第三版语法中，取消了condition参数！文档地址是：https://docs.docker.com/compose/compose-file/ ，如下图红框所示：因此，condition参数看似好用，但是从V3版开始的docker-compose.yml已经不再支持该参数，不能作为标准的解决方案；官方推荐的方案
如下图红框所示，docker官方推荐使用wait-for-it.sh脚本来解决问题，地址：https://docs.docker.com/compose/startup-order/ ：
至此，本篇已经分析了docker-compose下容器启动顺序的问题，下一篇文章，我们用SpringCloud应用来做实战，将其做到在docker-compose下有序启动；
参考文章如果您对docker容器健康检查有兴趣，可以参考以下文章：
https://blog.csdn.net/boling_cavalry/article/details/102641942 https://blog.csdn.net/boling_cavalry/article/details/102649435欢迎关注公众号：程序员欣宸
