从Spring Cloud到UCloud UK8S的微服务迁移实践
|
目前市面有很多开源的APM组件，Zipkin、Pinpoint、Skywalking等等。我们最终选择了基于Elastic开源的apm-server。正是由于市面上有太多的监控开源项目，但是各项目之间无法很好的互通。 而Elastic通过filebeat收集业务日志，通过metricbeat监控应用服务性能，通过apm-server实现服务间的tracing，并把数据统一存放在es，很好的将logging、metrics、tracing整合到一起，打破了各项目之间的壁垒，能够更快速的协助运维及开发定位故障，保障系统的稳定性。
Istio 服务治理 基于应用程序安全性、可观察性、持续部署、弹性伸缩和性能、对开源工具的集成、开源控制平面的支持、方案成熟度等考虑，我们最终选择了 Istio 作为服务治理的方案，主要涉及以下几个部分： 1. Istio-gateway 网关：Ingress Gateway 在逻辑上相当于网格边缘的一个负载均衡器，用于接收和处理网格边缘出站和入站的网络连接，其中包含开放端口和TLS的配置等内容，实现集群内部南北流量的治理。 2. Mesh 网关：Istio内部的虚拟Gateway，代表网格内部的所有Sidecar，实现所有网格内部服务之间的互相通信，即东西流量的治理。 3. 流量管理：在去除掉 Spring Cloud 原有的熔断、智能路由等组件后，我们通过对 Kubernetes 集群内部一系列的配置和管理，实现了 http 流量管理的功能。包括使用 Pod签对具体的服务进程进行分组（例如 V1/V2 版本应用）并实现流量调度，通过 Istio 内的 Destination Rule 单独定义服务负载均衡策略，根据来源服务、URL 进行重定向实现目标路由分流等，通过 MenQuota、RedisQuota 进行限流等。 4. 遥测：通过 Prometheus 获取遥测数据，实现灰度项目成功率、东西南北流量区分、服务峰值流量、服务动态拓扑的监控。
总结 目前我们已将旗下「云客赞」社交电商 App 全部迁移至 UK8S，开发语言包括Java、PHP-FPM、NodeJS 等等。结合CI/CD，能快速实现服务迭代以及新项目上线，大大提升了开发以及运维的工作效率；通过完善的日志、监控、链路跟踪及告警系统，能够快速的定位故障，并且根据遥测数据提前预判峰值，通过HPA实现服务自动伸缩，科学的分配资源，大大降低了计算资源成本；通过Istio服务治理，很好的实现了流量的管理，并且基于此轻松的实现了灰度发布。 接下来，我们将更加丰富CI/CD流水线，加入单元测试、代码扫描、性能测试等提升测试效率；引入chatops丰富运维手段；借助Istio实现多云管理进一步保障业务的稳定性。 作者：王琼，「要出发周边游」运维架构师兼运维经理，负责公司云原生落地和企业容器化改造。2016年开始接触K8S，在K8S以及Service Mesh领域持续深耕，致力于搭建生产级可用的容器服务平台。 （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
