从Spring Cloud到UCloud UK8S的微服务迁移实践要出发周边游(以下简称要出发)是国内知

　写在前面

　　要出发周边游(以下简称要出发)是国内知名的主打「周边游」的在线旅行网站，以国内各大城市为中心，覆盖其周边旅游市场，提供包含酒店、门票、餐饮等在内的 1 – 3 天短途旅行套餐。为了降低公司内部各个业务模块的耦合度，提高开发、交付及运维效率，我们在 2017 年就基于 Spring Cloud 完成了公司内部业务微服务化的改造，并在 2019 年实现了 Spring Cloud 至 UCloud UK8S 平台的迁移。

　　本文从要出发的业务架构、Prometheus JVM 监控、基于 HPA 的峰值弹性伸缩、基于 Elastic 的APM链路跟踪及 Istio 服务治理等方面介绍了我们基于UCloud UK8S的 Spring Cloud 改造实践。

　Why K8S and Why UK8S

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

----从Spring Cloud到UCloud UK8S的微服务迁移实践//----

　　改造前， Spring Cloud 的业务架构如下：服务发现部分采用了 Spring Cloud 的 Eureka 组件，熔断器组件采用了 Hystrix ，服务网关使用了Zuul 和 Spring Cloud Gateway(历史原因) ，分布式配置主要采用了 Spring Cloud Config(部分小组使用了Apollo) ，并通过 Feign 实现了客户服务端的负载均衡。

　　但 Spring Cloud 也有一些不可避免的缺点，如基于不同框架的不同组件带来的高应用门槛及学习成本、代码级别对诸多组件进行控制的需求与微服务多语言协作的目标背道而驰。

　　在我们内部，由于历史原因，不同小组所使用的 API 网关架构不统一，且存在多套 Spring Cloud ，给统一管理造成了不便;Spring Cloud 无法实现灰度发布，也给公司业务发布带来了一定不便。更重要的是，作为一家周边游网站，我们经常会举行一些促销活动，面临在业务峰值期资源弹性扩缩容的需求，仅仅依靠 Spring Cloud 也无法实现资源调度来满足业务自动扩缩容的需求。

　　在决定向 UCloud UK8S 转型时，我们也考虑过使用 Kubespray 自建 K8S 集群，并通过 Cloud Provider 实现 K8S 集群与云资源的对接，例如使用 Load Balance、Storage Class、Cluster Autoscaler(CA) 等，但在这种情况下，新增 Node 节点需要单独去部署安装 Cloud Provider ，给运维工作带来了一定的复杂性。

　　UCloud UK8S 实现了与内部 UHost 云主机、ULB 负载均衡、UDisk 云盘等产品的无缝连接，我们能够在 UK8S 集群内部轻松创建、调用以上产品。在峰值弹性的场景下，也能够通过 UK8S 内部的 CA 插件，实现 Node 级别的资源自动扩缩容，极大提升了运维效率。通过其 CNI 插件， UCloud UK8S 与 UCloud 自身 VPC 网络相连接，无需采用其他开源网络解决方案，降低了网络复杂度;而 UK8S 原生无封装的特质，也给了更大的改造空间，并且能够在出现故障时自己快速排查定位解决。