lcg72
lcg72
要保证应用也是docker启动的，docker之间是通过容器名寻址的，用docker-compose启动的话，指定容器名和主机名，并在配置的时候用容器名代替ip。如果是k8s的话，需要新建一个服务来暴露端口，配置的时候用服务暴露出来的ip To ensure that the application is also started by docker, the address between dockers is addressed by the container name. When starting with docker compose, specify the container name...
试试dubbo2.7.4.1，当初是基于这个版本解决的，也可以尝试nacos服务端采用1.3.0，怀疑是不是k8s关闭pod的时候某些duboo版本没有正常取消注册，而且nacos心跳检测存在问题。
@daiqingliang 如果是你描述的场景出现问题，我就没有机会碰到了，我设置了K8S里面ReadinessProbe探针。保证新的容器里面Dubbo正常提供服务后再关闭旧的容器。可以利用actuator来判断dubbo的运行状态。 我觉得要保证dubbo服务的可用性，运维是需要根据不同环境做优化的。
@daiqingliang ReadinessProbe探针：用于判断容器是否启动完成，即容器的Ready是否为True。 由于项目已经交付，我现在看不到完整的配置，只是提供一下思路。 首先需要配置dubbo和actuator，目的是能够通过url判断dubbo的健康状态。 然后是配置探针，配置上这个url。 当重新部署服务的时候，K8S会根据这个url去检测是否ready。只有ready状态，才会去清理旧的容器。 如果不去对dubbo状态做检测的话，dubbo还没有对外提供服务，而旧的容器被关闭，就会造成一段时间服务不可用。
@daiqingliang 重新部署，可以在K8S生成一个重新部署的钩子，然后在部署脚本中或镜像更新时调用，剩下的事情交给K8S自己去弄。
@wghemail 改了确实能正常启动win10.
交叉调用，需要设置dubbo.consume.check=false 参考代码：https://github.com/lcg72/testalibaba 先本地启动nacos1.1.4, 然后启动服务A和服务B（先后顺序不重要），启动后 访问服务A（调用服务B）：http://127.0.0.1:18086/lcg 访问服务B（调用服务A）：http://127.0.0.1:18088/testLocalDateTime