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

　整体业务架构

　　从 Spring Cloud 到 UCloud 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 能够集中管理应用在不同环境、不同集群的配置，修改后实时推送到应用端，并且具备规范的权限、流程治理等特性。

　　5. 增加 Prometheus 监控，特别是对 JVM 一些参数和一些定义指标的监控，并基于监控指标实现了 HPA 弹性伸缩。

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

　　Kubernetes 化后业务架构将控制平面和数据平面分开。 Kubernetes Master天然作为控制平面，实现整套业务的控制，不部署任何实际业务。数据平面中包含了基于 Java、PHP、Swoole、.NET Core 等不同语言或架构的项目。由于不同语言对机器性能有着不同要求，我们通过 Kubernetes 中节点 Label ，将各个项目部署在不同配置的 Node 节点上，做到应用间互不干扰。

　基于 Prometheus 的 JVM 监控

　　在 Spring Cloud 迁移到 Kubernetes 后，我们仍需要获取 JVM 的一系列底层参数，对服务的运行状态进行实时监控。 Prometheus 是目前较为成熟的监控插件，而 Prometheus 也提供了 Spring Cloud 插件，可以获取到 JVM 的底层参数，进行实时监控。

　　我们设置了响应时间、请求数、JVM Memory、JVM Misc、Garbage Collection 等一系列详尽的参数，为问题解决、业务优化提供可靠的依据。