Kubernetes 还是 SpringCloud？

2020-12-28 本文已影响0人码道功臣

前些年，随着微服务的概念提出以及落地，不断有很多的公司都加入到了这场技术革新中，现在可谓是人人都在做和说微服务。
提到微服务，Java栈内，就不得不提SpringBoot、SpringCloud、Dubbo。
近几年，随着Cloud Native技术的普及，又涌现出了一大批新技术，Docker、Kubernetes、Istio、Service Mesh，这些新技术的加入，又对微服务有了更深层次的定位。
那么，我们该如何去定位这些技术在我们实际工作中的应用呢？如果你参与到了技术选型中，就不得不把这些弄清晰，否则将毒害整个团队。

首先让我们了解下SpringBoot和SpringCloud的发展（下列内容摘自网络）

2012年10月，Mike Youngstrom在Spring jira中创建了一个功能需求，要求在Spring框架中支持无容器Web应用程序体系结构。他建议通过main方法引导的Spring容器内配置Web容器服务。这一需求促成了2013年初开始的Spring Boot项目的开发。2014年4月，Spring Boot 1.0.0发布。从那以后，一些Spring Boot小版本开始出现。

Spring Boot 1.1（2014年6月）：改进的模板支持，gemfire支持，elasticsearch和apache solr的自动配置
Spring Boot 1.2（2015年3月）：升级到servlet 3.1/tomcat 8/jetty 9和spring 4.1，支持banner/jms /SpringBoot Application注释
Spring Boot 1.3（2016年12月）：升级到spring4.2，新的spring-boot-devtools，缓存技术的自动配置（ehcache，hazelcast，redis，guava和infinispan）以及完全可执行的jar支持
Spring Boot 1.4（2017年1月）：升级到spring 4.3，couchbase/neo4j支持，启动失败分析和RestTemplateBuilder
Spring Boot 1.5（2017年2月）：支持kafka /ldap，第三方库升级，放弃对CRaSH支持和执行器日志终端用以动态修改应用程序日志级别
Spring Boot 的简便性使java开发人员能够快速大规模地应用于项目。 Spring boot可以说是Java中开发基于RESTful微服务Web应用的最快方法之一。它也非常适合docker容器部署和快速原型设计
Spring Boot 2.0.0，于2018年3月1日发布，新版本特点有：
基于 Java 8，支持 Java 9；支持 Quartz 调度程序；支持嵌入式 Netty，Tomcat, Undertow 和 Jetty 均已支持 HTTP/2；执行器架构重构，支持 Spring MVC, WebFlux 和 Jersey；对响应式编程提供最大支持；引入对 Kotlin 1.2.x 的支持，并提供了一个 runApplication 函数，用Kotlin 通用的方式启动 Spring Boot 应用程序。

随着2015年3月SpringCloud的第一个版本Angel发布，微服务的全部落地，正式拉开序幕。
SpringCloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。我们可以看出，Spring Cloud 是一套微服务框架。

我们再来了解下Kubernetes与SpringCloud的对比

Kubernates概述
 下一代微服务技术-服务网格-Istio

SpringCloud与Kubernetes的功能重叠

SpringCloud与Kubernetes的层次重叠

Kubernetes和Spring Cloud的激烈冲突

Java 生态的 Spring Cloud 可谓是迄今最完整的微服务框架，基本满足所有微服务架构需求，网上的教程也不胜枚举。
但也因为 Spring Cloud 生态过于完整，如今 k8s 大行其道，当我们把原来基于 Spring Cloud 开发的服务放到 k8s 后，一些机制自成一格，不受 k8s 生态的工具和机制管控。

因为从扩展部署、运维角度出发的 k8s，在最原始容器、应用程序部署及网络层管理的基础上，已逐步实现並贴近应用层的需要，一些微服务架构下的基础需求（如：Service Discovery、API Gateway 等）开始直接或间接被纳入 k8s 生态。
导致双方有很多组件功能重复，且只能择一而终，一旦你选了 Spring Cloud 的解決方案，就得放弃 k8s 那边的机制。

服务发现 (Service Discovery)

Spring Cloud 的经典解决方案：Netflix Eureka、Alibaba Nacos、Hashicorp。主要原理都是在服务部署时，去注册自己的服务，让其他服务可检索到自己。

spring.cloud.service-registry.auto-registration.enabled
@EnableDiscoveryClient(autoRegister=false)

但在 k8s ，服务的注册和查询由 Service 元件负责，其连线名称，是利用內部 DNS 实现。这代表我们要将服务发现功能，接上 k8s 的 Service 机制。
为达成目的，方案中提供了 DiscoveryClient 组件，让基于 Spring Cloud 所开发的程序可方便查询其他服务。
使用了 Kubernetes 原生的服务发现，才能被 Istio 追踪，未來才能纳入 Service Mesh 的管控。

配置管理 (Configuration Management)

Spring Cloud 的解决方案：spring-cloud-config。但在 Kubernetes 上，有 ConfigMap 和 Secret 可使用，而且通常还会搭配 Vault 管理敏感配置。

而该方案提供了 ConfigMapPropertySource 和 SecretsPropertySource，来存取 Kubernetes 上的 ConfigMap 和 Secret。

负载均衡和熔断器 (Load Balancing & Circuit Breaker)

Spring Cloud原有方案：Netflix Ribbon 和 Hystrix，但在 k8s 有 Service 实现负载均衡，以及 Istio 可实现熔断器，开发者只需专注 crud。
由于负载均衡和熔断器會依赖服务发现机制，因此 Ribbon 和 Hytrix 原先的功能在 k8s 原生环境下失效。
该解决方案內虽然有提到一些关于 Ribbon 整合 Kubernetes 原生环境的实现，但相关链接已消失，应该是放弃了。
所以推荐避免使用客户端的负载均衡和熔断器。

最后

目前Kubernetes已成容器编排技术的事实标准，容器编排将意味着服务、计算资源将能够更高效的被调度。如果你抛弃编排，或者自己构建一套编排系统，你将异常艰辛；
遇到很多项目是使用了Kubernetes编排，但是微服务全家桶使用了SpringCloud，当你对两个技术有了充分的理解之后，你也会异常的难受，既启用了Kubernetes相关功能，但又要跛脚的去调试SpringCloud内部功能。比如：Kubernetes内部启用了DNS实现服务发现，即方便又高效，但是SpringCloud又有自己的服务发现，双层服务发现，让人实在难受。
没有一成不变的技术方案，优雅的方案是可以随着时代，逐渐迭代，从而更新自我，如果我们一开始的方向错了，便将逐渐走入到另一个洪流之中，最终也将消失。