@winglight2016 历史包袱太重了 公司也没重构的打算 服务发现的话 你们用了什么方案呀

@anubu 配置打算继续用 nacos 了

@liminany1 nacos 的节点重启后 会存在集群节点之前数据不同步的问题 这样就导致 nacos 集群中每个节点的 service 实例数量不一致 进而导致服务间调用会出现没有实例的问题 并且除了逐个重启之外没啥别的办法

cluster 模式 https://github.com/ucloud/redis-cluster-operator
哨兵模式 https://github.com/ucloud/redis-operator

可以试试 operator 的模式部署 redis 当 redis pod 发生异常时 由 operator 负责维护整个集群的工作状态
github 上 starts 数量多的 redis operator 都尝试了 综合下来 https://github.com/ucloud/redis-cluster-operator 这个的使用体验最好
手动删除 pod 后 redis 集群的状态没有出现过问题 扩充/缩减节点后还会自动进行 reshard ，备份功能可以配合一个 cronjob 进行处理
redis >= 7.0 的话 需要修改下源码 不然部署会报错

在 shutdown 处打个断点看下呢

传家宝可以啊

@butanediol2d 哦哦那就行 多谢

可以试试 bytebase

好好洗脸 好好睡觉 别吃太油的东西
可以去皮肤科看下
班赛 阿达帕林 甲硝锉凝胶

@anubu 谢谢你的意见 目前我们的项目部署在私有云上 采购第三方产品估计不太好推动 我们决定在测试上多跑跑 如果情况不太好的话 可能有状态组件就会考虑单独部署了

@gangbinfo123 好的 谢谢

@perfectlife 考虑到交付的便利性上 我们选择把很多中间件部署在 k8s 中 但是使用下来感觉有状态的服务部署在集群中需要很多额外的调整

@perfectlife 谢谢你的建议 我发现在 docker 部署的 nacos 的可靠性也会更高一点 目前这个项目也算是一个老项目了 我觉得去 springcloud 化的改造成本有些大

@biubiuGolang 好的 谢谢

@waising 您好 目前针对 cm 这块的替代方案有什么建议吗

@zhenjiachen 服务发现这块打算试试 spring cloud kubernetes 或者干脆不用 给所有后端服务配置 svc 然后通过 k8s 内部的服务发现来处理相互调用的问题 再后面考虑接入 istio 不过这个时候是不是 springcloud 的我感觉意义不是很大了