Spring Cloud 脱去Netflix公司的系列微服务组件的外衣,基本就是Spring Boot,那么,给Spring Boot 换装Kubernetes,又是一番怎样的景象?
在转型微服务架构之初,我就把微服务应用的运行环境的研究放在首位,动辄十几个应用的微服务系统,不解决这个问题,部署、运维本身就是一个让人抓狂的工作,如此微服务就是个概念,优势将荡然无存。随着对Kubernates研究的深入,惊喜的发现它已经具备了诸多微服务的特性,服务网格通过Sidecar模式,更是让应用无须做任何改造即可支持微服务的熔断、限流和降级,构建一个异构微服务系统成为可能(一个大型系统应该是灵活包容的,不应该受开发语言的限制)。
K8S研究完成之后,感觉已经完全具备了微服务的所有特性: 服务注册与发现、负载均衡、限流、降级、熔断、配置中心、服务网关等每一个都可以支持, 是否还有必要引入Spring Cloud微服务体系,于是将K8S 和 Spring Cloud 从微服务特性方面进行了详细的对比:
序号 | 微服务架构特性 | Kubernates | Spring Cloud |
---|---|---|---|
1 | 服务注册 | 一、基本功能:内置了两套服务注册和发现机制 1. 服务内部: 基于kube-proxy的服务注册与发现。通过运行在宿主机的kube-proxy,动态的将Pod信息维护在kubernates的etcd数据库,Service从而实现了对Pod的动态发现。 2. 服务外部:基于域名(CoreDNS)的服务注册与发现。 每个Service都会被指派一个 DNS 名称,内部服务之间通过域名进行访问即可。 二、 核心技术 : etcd 、CoreDNS | 一、基本功能:SpringCloud 集成 Eureka组件实现服务注册和发现。 其包含了服务器端(
二、核心技术:eureka |
2 | 服务发现 | ||
3 | 负载均衡 | 方法一:Service( 通过运行在每台主机上的 kube-proxy实现负载功能) 实现服务的负载均衡。 方法二: ingress + traefik,可以避免通过kube-proxy 代理,相对来说性能更好。 | Netflix发布 的 Ribbon做负载均衡器 |
4 | 限流 | 服务的限流、熔断和降级有多中实现方法: 方法一:通过Ingress+Traefik实现。 Traefik 中内置了许多中间件:路径操作、多种身份验证机制、缓冲、断路器、重试、压缩、错误处理、headers、IP 白名单、限速、重定向等。此方法与服务网关实现。 方法二:如果集成了服务网格,可以通过Istio实现服务的限流、熔断和降级,此方法偏重量级一些。 | 服务的限流、熔断和降级有多中实现方法: 方法一: 对于内部服务之间调用,可以通过集成Netflix 的 Hystrix。 方法二: 如果服务通过服务网关统一路由和管控,也可以在服务网关配置限流、熔断和降级。 |
5 | 熔断 | ||
6 | 降级 | ||
7 | 配置中心 | Kubernates 支持 ConfigMap ,Secret等。 通过环境变量配置在运行的容器里,使用很方便。 | 目前SpringCloud支持的配置中心比较多,有如下几种: 1. Spring Cloud 官方支持的 Spring Cloud Config 2. 阿里巴巴的 nacos 3. 携程的apollo |
8 | 服务网关 | 边缘路由,将Path请求转换为K8S中 Service之间的调用。 目前有多个实现有Ingress + nginx 或 Ingress + traefik。 注意: 实践中,我们基于Spring Cloud Gateway实现了自己的网关,实现API鉴权等高级功能, Ingress + Traefik + Spring Cloud Gateway 整体效果不错。 | 原来采用的Netflix Zuul , 后来采用了基于Webflux 的 Spring Cloud Gateway |
总之,Spring Cloud 通过整合Neflix相关开源组件实现了一套完整的微服务方案,但是必须借助于K8S这样的容器编排工具才能实现理想的效果。而K8S却可以自成体系构建微服务系统,与基于Spring Cloud构建的微服务系统相比,具有如下优点:
1. 对构建的应用无侵入性,有更低的改造成本。
2. 对开发语言无要求,Go、nodeJS、Java、PHP都是可以的。
3. 程序的版本管理更加灵活,不受制与Spring Cloud的版本。
4. Spring Cloud 体系的程序如果部署在K8S的环境, 很多微服务特性都是重复的。