Java 应用上了 k8s 之后是不是可以不需要 spring cloud 里的部分组件了

[woyao396]

[wandehul]

是的，很多功能重叠。。。。。。。 之前和本司一个开发讨论这个，他说 k8s 能实现的，spring cloud 都能实现，然后我就不想讨论这个问题了 。

[threeEggs123]

我们只用了 hystrix，其他的都没有用。

[thinkmore]

是的，我们是用 springboot + k8s

[hantsy]

从 5 年前第一次写项目 POC，讨论的结果就淘汰了 Spring Cloud 里面的大部分组件，图上这个观点还是比较客观的。

MS 从一开始就应该考虑容器部署，DevOps，自动化。用 Spring Cloud 那些运维相关的功能会成绊脚石，特别是早期的版本，加入后，项目依赖变得超级庞大，写单元测试变得太困难。

目前感觉比较有用的就 日志, Open tracing, metrics，另外像 Gateway （作为聚合需要） Resilient4j，FeignClient，Spring Cloud Contract 这些可以选取，其他不用。

[hantsy]

另外可以看看 Spring Cloud K8S 这个项目，针对 K8s 提供了一些简单的 Glue 。

[xuanbg]

微服务基础组件，譬如注册中心、配置中心这些，应该基于一套统一的开放的协议。在实现协议的基础上，A 的客户端可以对接 B 的服务，用谁家的实现就无所谓了。

[jingslunt]

换成 istio

[zoharSoul]

我们的就是 k8s + spring boot

[bootvue]

看项目规模了 小一点的规模或者没有可靠的运维 对 k8s 不熟悉的话 专注 spring cloud 还是易于维护的

[ptrees]

换句话说用了这些的话是不是没必要上 k8s?公司代码也不太复杂,不想研究了😹

[CoderGeek]

k8s + spring boot 可以 用 k8s + spring cloud 也很平滑 不用改动很多现有代码

[lewis89]

@xuanbg #6 难啊，光是 SpringBoot 里面 针对 Properties 就有很多骚操作 从配置中心到 bean 上的变量 中间封装的层次太多，想弄一套开放的协议太难了，除非只是 应用于应用之间的配置信息管理，这个倒是很好做，但是做了也没什么卵用，无非就是通知跟下发配置文件，轻量的话 几个接口就完成了。