如何看待spring cloud与基于k8s生态在多个领域的碰撞,以及最终会朝什么方向发展

如何看待spring cloud与基于k8s的生态在多个领域的碰撞,以及最终会朝什么方向发展

如图,springcloud与k8s在多个领域都有重叠。从2015年springcloud第一个版本发布之后标志着微服务的全面落地,到后来的k8s大行其道。当我们将之前开发的springcloud服务转入k8s时,一切都显得不那么舒服。

多方面的冲突

服务发现 – nacos,eureka… VS service

配置管理 – nacos… VS secret configmap

断路器 – hystrix VS Istio

负载均衡 – ribbon VS service

等等

总结

多方面的冲突使我们不得不做出取舍、k8s在容器编排技术已经是实际的标准,引用另一篇文章的话说就是——“容器编排将意味着服务、计算资源将能够更高效的被调度。如果你抛弃编排,或者自己构建一套编排系统,你将异常艰辛”。但二者好像并不能很好的共用。

所以,springcloud会被k8s取代么?你觉得呢?

说下个人观点:

  1. 全面云原生的公司肯定k8s全家桶了,
  2. 更常见的是混合模式,服务部署在k8s上,在集成一些spring cloud 方面的组件;
  3. 更小规模的公司可能都没上k8s,所以只能选择spring cloud 了