Java有必要学springcloud,有了kubernetes你为什么还要用 springcloud

本来想的标题是 《springcloud 和 kubernetes 比较 》

不过想着想着就放弃了，因为本来的出发点就是，有了kubernetes我为啥还要用springcloud ... 想了半天，完全没理由啊

就好像机箱为啥买太阳神，就为了ROG全家桶？没理由啊

第一次用springcloud 还是在 2017年，那时候微服务概念刚刚兴起 ( 也可能是孤陋寡闻的我刚刚听说 )，于是做了一个基于 Docker 的 springcloud 架构

原理就是 Docker 封装的 Springboot应用 然后构成了一个 springcloud 平台，反正当时kubernetes还不熟

不过时至今日，我真心想不出如果重新为一个新项目做技术选型，我为啥还要用springcloud

微服务架构，主要组成有，简单列一些

这里我盗个图

看来看去大家都一样么，这里你看看 配置中心，既然，kubernetes的 configmap 能做这么多，为什么还要用 Config server 呢？

你可以理解成，springcloud只能用在 springboot的java环境中，而kubernetes明显是通吃，只要能被塞进 docker 的应用，包括 springboot ，都可以在kubernetes上运行，而且更轻量，更简单

这里最关键的点还在于，Java本身就不适合做微服务，即便是一个最简单的 helloworld springboot 镜像，也需要300M，没有其他办法，JVM的大小毕竟摆在那里，一个简单的 tomcat从启动到完成，也需要大概10秒才能初始化一个 ioc 容器, 这些都太耗时了，大规模的微服务平台，一个非常重要的特点就是 容器可以 优雅的启动 然后 优雅的销毁，Java根本做不到，论易用性不如Python，论性能和易于部署不如Golang，论前后端统一不如 Nodejs

如果但得你还有精力学习除了java之外的新知识，我都不建议使用java或者springcloud来构建微服务架构，虽然做过10年Java，但是在微服务云架构上，我要给Java头完全反对票

总上所述，spring cloud 也好，kubernetes 也好，实际上都是 云原生十二要素的一种实践

一份代码，多份部署

依赖

配置中心

服务

构建，发布，运行

无状态独立进程

数据隔离

并发

易处理，能被优雅的启动和销毁

开发环境和生产环境等价

日志管理

管理进程 ( job )