kubernetes和springcloud的发展历程 SpringCloud技术体系简介我们通过

SpringCloud技术体系简介
我们通过时间线展开整个项目背景：
在我刚开始工作的时候（2010年以前），可能还没有云原生社区，当时Java体系是企业级开发的首选。
2010年， Netflix推出了MovetoCloud计划，将绝大部分的服务迁到了AWS上。
2012年， Netflix推出了OpenSourceSoftwareCenter（开源软件中心仓库），类似于ApacheMaven ，提供了一些在上云过程中沉淀下来的开源项目。
2014年， MartinFowler发表了一篇非常知名的博客，名叫Microservices(https://martinfowler.com/articles/microservices.html) ，把当时一些公司的架构风格称为“微服务” 。文章中指出微服务架构有以下一些特点：
高可维护性和可测试性；
服务之间松耦合；
服务可独立部署；
服务围绕业务组织；
被一些小团队使用。
2015年， Spring社区围绕之前Netflix沉淀的一些组件以及Martin提出的微服务理念，推出了SpringCloudv1.0.0 ，直到现在SpringCloud还被广泛使用。SpringCloudv1.0.0包含的组件较少，只有服务发现、配置管理等几个核心组件。
所以微服务架构的发展历程并不是从论文走向产业化，而是从工程师的实践中抽象出特点，最后形成完整的生态。到今天， SpringCloud组件已经比较的完善了，包含配置、服务解耦、服务发现、熔断、路由、消息传递、API网关、tracing、CI管道和测试等。这些构成了整个SpringCloud的生态。
SpringCloud是基于Java构建的微服务体系，在Spring和Java社区不停迭代的过程中，出现了一股全新的力量。2014年6月7日， Kubernetes首次发布，当时还有DockerSwarm、Mesos这些调度平台互相竞争。
从时间线可以看出来， Kubernetes和SpringCloud的发展是同时期的。

文章图片

文章图片
微服务的一些关键组件包括配置管理、服务发现、LoadBalance、API网关、中心化日志、Metrics等， SpringCloud这套体系和Kubernetes体系还是有一些交叠的。举例来说， SpringCloud有ConfigServer（类似的有阿里开源的Nacos、携程开源的Apollo）， Kubernetes则有ConfigMap、Secret等，它本身也有配置能力，但是比较弱。Kubernetes的优势在于它的组件和整个系统之间的交融度比较高，但在SpringCloud里可能是所有组件都要去兼容SpringCloud ，以Java社区为主，和其他语言的交互比较少。

文章图片

文章图片
上图展示了软件的各种能力。可以看到Kubernetes包含的能力范围比SpringCloud更大。比较突出的有AutoScaling、DevOps、进程隔离，这些是SpringCloud不能管辖到的。
在当时，一些新兴客户会面临一个问题：对于基于Java的业务应用，开发的时候选择哪种模式更好？
对于这个问题，现在我们更推荐使用Kubernetes ，因为Kubernetes是一个语言无关的平台。SpringCloud虽然是JVM体系，但是离开了JVM很多事情都做不了，因此不得不逼迫客户随着一起做变动，这个体验其实不太好。所以我们后面也说服了同公司的一些团队一起参与到CNCF云原生技术架构的建设。
SpringCloud基础能力替换
配置中心
SpringCloud的ConfigServer具有较多的能力：
【kubernetes和springcloud的发展历程】Git作为配置仓库。
JDBC和Redis提供了统一的配置抽象层。
但不太好用。一些个性化的需求比如配置中心的权限管理和热加载， SpringCloudConfigServer本身不支持，需要做二次开发。
对于Kubernetes ，可以通过ConfigMap或者Secret按照更加原生的方式以环境变量、文件或启动参数的方式注入到应用中去，就像敲Linux命令一样方便。