江苏龙网

  1. 主页 > 生活百科 > >

从零开始入门K8S| 从Spring Cloud到Kubernetes的微服务迁移实践

k8s

写在前面要出发周边游（以下简称要出发）是国内知名的主打「周边游」的在线旅行网站 ， 为了降低公司内部各个业务模块的耦合度 ， 提高开发、交付及运维效率 ， 我们在 2017 年就基于 Spring Cloud 完成了公司内部业务微服务化的改造 ， 并在 2019 年实现了 Spring Cloud 至 UK8S 平台的迁移 。
本文从要出发的业务架构、Prometheus JVM 监控、基于 HPA 的峰值弹性伸缩、基于 Elastic 的APM链路跟踪及 Istio 服务治理等方面介绍了我们基于UK8S的 Spring Cloud 改造实践 。
Why K8S & Why UK8SSpring Cloud 作为当下主流的微服务框架 ， 在功能层面为服务治理定义了智能路由、熔断机制、服务注册与发现等一系列的标准 ， 并提供了对应的库和组件来实现这些标准特性 ， 对微服务周边环境提供了最大力度的支持 。

从零开始入门K8S| 从Spring Cloud到Kubernetes的微服务迁移实践

文章插图
 
改造前 ， Spring Cloud 的业务架构如下：服务发现部分采用了 Spring Cloud 的 Eureka 组件 ， 熔断器组件采用了 Hystrix ， 服务网关使用了Zuul 和 Spring Cloud Gateway（历史原因） ， 分布式配置主要采用了 Spring Cloud Config（部分小组使用了Apollo） ， 并通过 Feign 实现了客户服务端的负载均衡 。
但 Spring Cloud 也有一些不可避免的缺点 ， 如基于不同框架的不同组件带来的高应用门槛及学习成本、代码级别对诸多组件进行控制的需求与微服务多语言协作的目标背道而驰 。
在我们内部 ， 由于历史原因 ， 不同小组所使用的 API 网关架构不统一 ， 且存在多套 Spring Cloud ， 给统一管理造成了不便；Spring Cloud 无法实现灰度发布 ， 也给公司业务发布带来了一定不便 。更重要的是 ， 作为一家周边游网站 ， 我们经常会举行一些促销活动 ， 面临在业务峰值期资源弹性扩缩容的需求 ， 仅仅依靠 Spring Cloud 也无法实现资源调度来满足业务自动扩缩容的需求 。
在决定向 UK8S 转型时 ， 我们也考虑过使用 Kubespray 自建 K8S 集群 ， 并通过 Cloud Provider 实现 K8S 集群与云资源的对接 ， 例如使用 Load Balance、Storage Class、Cluster Autoscaler（CA） 等 ， 但在这种情况下 ， 新增 Node 节点需要单独去部署安装 Cloud Provider ， 给运维工作带来了一定的复杂性 。
UK8S 实现了与内部 UHost 云主机、ULB 负载均衡、UDisk 云盘等产品的无缝连接 ， 我们能够在 UK8S 集群内部轻松创建、调用以上产品 。在峰值弹性的场景下 ， 也能够通过 UK8S 内部的 CA 插件 ， 实现 Node 级别的资源自动扩缩容 ， 极大提升了运维效率 。通过其 CNI 插件 ， UK8S 与 UCloud 自身 VPC 网络相连接 ， 无需采用其他开源网络解决方案 ， 降低了网络复杂度；而且 UK8S 原生无封装的特质 ， 也给了更大的改造空间 ， 并且能够在出现故障时自己快速排查定位解决 。
整体业务架构从 Spring Cloud 到 UK8S 的过程 ， 也是内部服务模块再次梳理、统一的过程 ， 在此过程中 ， 我们对整体业务架构做了如下改动：
1. 去掉原有的 Eureka ， 改用 Spring Cloud Kubernetes 项目下的 Discovery 。Spring Cloud 官方推出的项目 Spring Cloud Kubernetes 提供了通用的接口来调用Kubernetes服务 ， 让 Spring Cloud 和 Spring Boot 程序能够在 Kubernetes 环境中更好运行 。在 Kubernetes 环境中 ， ETCD 已经拥有了服务发现所必要的信息 ， 没有必要再使用 Eureka ， 通过 Discovery 就能够获取 Kubernetes ETCD 中注册的服务列表进行服务发现 。
2. 去掉 Feign 负载均衡 ， 改用 Spring Cloud Kubernetes Ribbon 。Ribbon 负载均衡模式有 Service / Pod 两种 ， 在 Service 模式下 ， 可以使用 Kubernetes 原生负载均衡 ， 并通过 Istio 实现服务治理 。
3. 网关边缘化 。网关作为原来的入口 ， 全部去除需要对原有代码进行大规模的改造 ， 我们把原有的网关作为微服务部署在 Kubernetes 内 ， 并利用 Istio 来管理流量入口 。同时 ， 我们还去掉了熔断器和智能路由 ， 整体基于 Istio 实现服务治理 。
4. 分布式配置 Config 统一为 Apollo 。Apollo 能够集中管理应用在不同环境、不同集群的配置 ， 修改后实时推送到应用端 ， 并且具备规范的权限、流程治理等特性 。


推荐阅读


上一篇：绿茶减肥的方法,减肥的佳品

下一篇：临沧邦东古茶园,邦东最有名的是昔归茶