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

我们会发现SpringCloudConfigServer更像是一个独立的软件， Kubernetes的ConfigMap更像是软件内的功能，这就是两者之间的区别。
配置管理
Kubernetes的配置管理比较简单，只需要在最终的启动声明里增加Environment ，或者是将ConfigMap以Volume的方式加载进去就可以了。
有时候会有同事问， SpingCloud虽然原生没有热加载能力，但是基于SpringEventBus ，甚至用一些第三方厂商的开源工具，也可以实现所谓的热加载， Kubernetes可以做到吗？
其实Kubernetes也是可以做到的。环境变量当然是immutable挂进去，但是我们可以将一些可变的属性以文件的方式挂载到宿主机容器化应用程序的YMAL文件里去。随着ConfigMap的变动， YMAL也会同时变动，这时只需要让应用能watch配置文件的变化，进行自动从加载就可以了。而热加载本来就应该由应用自身实现。
Kubernetes本身也有reload能力，尤其是在扩展到其他语言的时候。字节内部使用Go语言比较多，大家只要能够reload某一个文件或远程地址，应用就可以将自己的行为进行变化。
服务发现
SpringCloud和Kubernetes最大的不同在于服务发现。我们绝大部分的功能都需要基于服务发现去做二次扩展，这时就会面临服务发现的选择问题。
SpringCloud的服务发现是基于Eureka的（后期也可以基于Consul进行），提供了自上报的机制和客户端负载均衡，是一个AP系统。
Kubernetes则更像传统的云厂商，可帮助用户创建机器/容器。平台自然知道应用在哪里，就可以通过DNS以及服务端负载均衡帮助导流。这样的体验是截然不同的。
SpringCloud这套体系如果是EurekaClient ，永远是要嵌入业务内部的，因为在启动的那一刻才知道应用在哪里，通过Utils组件去获取当前的IP地址。而Kubernetes并不需要由应用进行感知，这是非常大的区别。
接入Kubernetes的服务发现也是比较简单的。只要创建一个service的资源（resource），定义其对应的Label即可。我认为服务发现是Kubernetes的一个很大的优点。
AutoScaling&SelfHealing
AutoScaling和SelfHealing是SpringCloud不具备的。在SpringCloud里， Eureka会做一些健康检查。其逻辑比较简单：Eureka不停地发请求，看心跳有没有定时上报上来。但SpringCloud只能知道服务是否健康，无法阻止访问不健康的服务。如果要扩容或自恢复不健康的服务，需要在SpringCloud里做很多扩展。

文章图片

文章图片
Kubernetes这方面做得好一点。它本身提供readless的检测，检测完之后，如果调用失败了，平台就会帮助进行自动扩展和调度。要实现这样的功能也很简单，只要在应用或容器内开通一个端口，能够检测服务当前是否运行正常，可以比如说有延迟的参数，或者是间隔周期，在恰当时候进行一次请求，就可以知道应用是否就绪/健康。
这样会更符合所谓的微服务原子要素，因为我们不光要能检测系统是否健康，更希望能够自动扩展。Kubernetes社区还在做HPA ，甚至可以监测某些指标，随着指标变化进行自动扩缩容。这些在SpringCloud里面都是非常难实现的。
SpringCloud流量治理能力替换
APIGateway
绝大部分用户都会面临一个很重要的问题：已经基于SpringCloud做了很多流量治理工作，这个工作如何迁移到云上？比如APIgateway ， SpringCloudGateway提供了很多能力，允许通过filter做很多开发，以完成自己的业务逻辑。
Kubernetes是怎么实现的呢？它选择了更大的一个场景，把整个生态开源出来了。这个开源生态下有很多工具，比如APIGateway就有Kong、Tyk、Gloo等工具。