菜鸟 Cpaas 平台微服务治理实践

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: 在使用mse的云产品之后,对paas平台层来说,避免很多重复功能的建设。在我们业务侧实际落地的远不止如上列举的场景,比如:服务优雅停机、注册中心等能力,均解决了业务侧的微服务治理上的难点问题。在实现了对项目环境及灰度发布的能力开发之后,我们接下来对服务离群摘除、应用服务列表透出、服务鉴权、本地联调部署等能力做重点关注,在降低业务侧服务运维成本、微服务可观测、服务可用性方面与MSE团队加强合作,帮助业务侧解决微服务治理中的痛点。

背景


CPaaS(cainiao platform as a service)是以公有云为基座,结合先进的云原生理建设的企业级DevOps的PaaS平台,CPaaS主要目前主要支持的场景:菜鸟生态的云上研发运维、菜鸟公有云SaaS化的能力透出、菜鸟商业化输出支撑,部署到客户的公有云、专有云环境。

在服务了菜鸟多家生态公司及部分商业化输出的产品过程中,深入客户业务场景,解决业务研发及部署痛点的过程中,积累了一些宝贵的经验。这里我们主要对规范云上研发流程,提升研发效率为目标建设的环境治理(云上项目环境)及减少线上版本发布风而险建设的灰度平台的实现过程进行展开介绍。


目标


1、通过项目环境,为多分支并行开发场景提供流量隔离及快速联调的能力。

2、生产环境实现服务灰度发布(金丝雀发布),降低变更风险。

3、微服务应用具备优雅上下线能力,避免启停过程中带来的服务调用出错问题。


调研阶段


微服务流量管控


我们首先调研了开源自建的方案。在调研时我们发现,开发和维护开源 SDK方案的成本非常大。需要对 Spring Cloud 和 Dubbo 这些微服务框架以及 RockeMQ 这类消息中间件非常了解,才能准确地找到各个框架的增强点进行定制化开发。

除此之外,业务方使用的微服务框架版本也是跨度很大,维护这些不同版本的微服务框架适配,也需要投入大量的精力。

最重要的一点是,使用开源 SDK 自建的方案,开发业务的同事,需要在应用的开发和部署运维的流程都感知到 SDK 的存在,对开发、构建、运维的侵入性很大,很难进行推广。

后来我们也找到了阿里集团负责中间件的同事寻求支持,了解到中间件团队已经推出了一款面向公有云的微服务治理产品 MSE,于是我们进行了调研。

MSE作为公有云的微服务治理产品,具备云上的服务管控、微服务测试、标签路由、离群摘除、优雅上下线等能力,与我们的诉求完全吻合,并且通过agent方式实现,对应用代码无侵入,更适合PaaS平台对业务应用增加扩展。

(图 1.1)

经过与MSE团队同时的几次电话和会议沟通之后,逐渐对MSE产品有了一些功能上的认知。其中在微服务治理中,我们结合实际的业务需求,落地实现了下面MSE的部分能力。

(图 1.2)


落地场景


项目环境

在多分支开发的场景下,我们通常需要同时部署多个分支。但是多个分支同时部署之后,如何将开发自测流量与日常环境的测试流量分开,以及如何让各个分支拥有自己独立的流量,都是需要解决的问题。

流量隔离

调研和验证MSE的标签路由的能力之后,实现思路:通过标签路由能力,将流量进行隔离。

相同应用的不同分支,使用不同的deployment实现对版本和容器标签的管理。图2.1中core应用项目环境c1和项目环境c2均使用独立于日常环境的容器单独部署,各自的路由标签为joint1和joint2。通过对流量携带流量标记的方式,完成项目环境流量的控制。

接入层应用则通过K8S-Ingress实现流量路由,只需要在请求流量的请求头中携带 x-mse-tag的标签,则可以将流量路由到对应标签的入口层应用。入口应用设置标签传递的开发,可将流经此容器的流量打标传递到上有服务。如此反复,则实现流量在整个调用链路的封闭。

(图 2.1)

服务测试

在研发过程中,除了分支之间的相互干扰需要隔离之外,还需要从业务侧研发的角度解决服务测试的效率问题。MSE平台提供了微服务测试平台,可以快速的帮助开发者实现服务自测,并且我们通过集成方式集成到自身的paas平台中,免去自身重建的痛苦。

测试平台支持按照服务提供者IP的维度进行服务测试,刚好与流量隔离相互契合,可以对自身关注的项目环 境的应用容器发起服务测试完成服务自测。

图(2.2)

灰度环境

灰度环境的目的是为了降低线上应用版本发布的风险,减小问题爆炸半径。同样可以通过MSE提供的标签路由功能基础上完成对流量灰度的实现。


想要流量实现灰度,那么需要对流量的所有入口实现流量路由。通常我们所感知的流量入口包括:HTTP接入层、RPC下游调用、MQ服务消费、Task任务调度。当前在MSE的灰度能力支持范围内,微服务云网关、金丝雀发布、MQ灰度均可以组合实现。

当然,这里我们只实现了HTTP接入层+RPC的灰度能力,因为历史的原因,在接入层使用了另一个接入层(MSHA的MSFE,本质上是一个tengine)实现接入层的灰度。但这里丝毫不影响与MSE的灰度能力完成流量的串联,这得益于mse产品自身拥有良好的对其他产品的兼容性。我们只需要在入口层的应用上设置流量经过此容器时带标,即可完成灰度流量的传递。


(图 2.3)

在实际的业务灰度场景中,我们总结了常见的四种灰度场景,均通过MSE完成并实现。

(图 2.4)


未来规划


在使用mse的云产品之后,对paas平台层来说,避免很多重复功能的建设。在我们业务侧实际落地的远不止如上列举的场景,比如:服务优雅停机、注册中心等能力,均解决了业务侧的微服务治理上的难点问题。

在实现了对项目环境及灰度发布的能力开发之后,我们接下来对服务离群摘除、应用服务列表透出、服务鉴权、本地联调部署等能力做重点关注,在降低业务侧服务运维成本、微服务可观测、服务可用性方面与MSE团队加强合作,帮助业务侧解决微服务治理中的痛点。

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
1天前
|
Cloud Native Java 持续交付
云原生时代的微服务架构实践
在数字化转型的浪潮中,云原生技术已成为推动企业IT现代化的重要力量。本文旨在通过深入浅出的方式,探讨在云原生环境下微服务架构的实践要点,从基础概念到具体实现,带领读者逐步理解并掌握如何在云计算平台上构建、部署和管理高效的微服务应用。我们将一起探索容器化、持续集成/持续部署(CI/CD)等关键技术,并通过实际案例分析,揭示微服务架构带来的业务价值和挑战。无论您是云原生技术的新手,还是希望深化理解的开发者,这篇文章都将为您开启一段云上之旅。
|
1天前
|
微服务
微服务实践之使用 Visual Studio 2022 调试Dapr 应用程序
微服务实践之使用 Visual Studio 2022 调试Dapr 应用程序
12 2
|
1天前
|
Kubernetes Docker 微服务
微服务实践k8s&dapr开发部署实验(1)服务调用(一)
微服务实践k8s&dapr开发部署实验(1)服务调用(一)
18 2
|
1天前
|
Kubernetes Cloud Native 微服务
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
13 1
|
10天前
|
Cloud Native 持续交付 微服务
云原生时代的微服务架构实践
【9月更文挑战第30天】随着云计算技术的不断进步,云原生已经成为现代软件开发的重要趋势。本文将通过深入浅出的方式,介绍如何在云原生环境下设计并实施微服务架构,以及如何利用容器化技术和自动化工具来提升服务的可维护性和可扩展性。我们将一起探讨微服务架构的核心原则、优势,以及在云平台中部署和管理微服务的最佳实践。无论你是初学者还是有经验的开发者,这篇文章都将成为你探索云原生和微服务世界的一盏明灯。
|
13天前
|
监控 Cloud Native 持续交付
云原生时代的微服务架构设计原则与实践
【9月更文挑战第27天】本文深入探讨了在云原生环境下,如何高效地实施微服务架构。通过分析微服务的基本概念、设计原则和关键技术,结合实际案例,指导读者理解并应用微服务架构于云计算项目之中。文章旨在为软件开发者和架构师提供一条清晰的路径,以实现更加灵活、可扩展且易于维护的系统。
|
14天前
|
存储 运维 负载均衡
后端开发中的微服务架构实践与思考
本文旨在探讨后端开发中微服务架构的应用及其带来的优势与挑战。通过分析实际案例,揭示如何有效地实施微服务架构以提高系统的可维护性和扩展性。同时,文章也讨论了在采用微服务过程中需要注意的问题和解决方案。
|
14天前
|
运维 持续交付 API
深入理解并实践微服务架构:从理论到实战
深入理解并实践微服务架构:从理论到实战
45 3
|
1天前
|
Kubernetes Docker 微服务
微服务实践k8s&dapr开发部署实验(1)服务调用(二)
微服务实践k8s&dapr开发部署实验(1)服务调用(二)
18 0
|
1天前
|
设计模式 消息中间件 监控
后端开发中的微服务架构:从概念到实践
后端开发中的微服务架构:从概念到实践