istio springcloud_从Spring Cloud到Kubernetes的微服务迁移实践

写在前面

要出发周边游（以下简称要出发）是国内知名的主打「周边游」的在线旅行网站，为了降低公司内部各个业务模块的耦合度，提高开发、交付及运维效率，我们在 2017 年就基于 Spring Cloud 完成了公司内部业务微服务化的改造，并在 2019 年实现了 Spring Cloud 至 UK8S 平台的迁移。本文从要出发的业务架构、Prometheus JVM 监控、基于 HPA 的峰值弹性伸缩、基于 Elastic 的APM链路跟踪及 Istio 服务治理等方面介绍了我们基于UK8S的 Spring Cloud 改造实践。

Why K8S & Why UK8S

Spring Cloud 作为当下主流的微服务框架，在功能层面为服务治理定义了智能路由、熔断机制、服务注册与发现等一系列的标准，并提供了对应的库和组件来实现这些标准特性，对微服务周边环境提供了最大力度的支持。

改造前，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 转型时，我们也考虑过使用 Kubes