30w 长链接,运维成本下降一倍 | 微服务引擎 MSE 在阿里巴巴的技术实践

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: 前言 微服务引擎 MSE ,是阿里集团配置中心和服务注册中心的云上版本,在集团内广泛应用于分布式一致性协调,注册中心,分布式配置中心等场景。以 2019 年天猫双十一为例,由于 MSE 在稳定性和性能方面持续投入,单集群最大超过 30W 长链接,对于业务团队而言,运维成本大幅下降一倍,管控体验大幅提升。

前言

微服务引擎 MSE(官网地址>>) ,是阿里集团配置中心和服务注册中心的云上版本,在集团内广泛应用于分布式一致性协调,注册中心,分布式配置中心等场景。以 2019 年天猫双十一为例,由于 MSE 在稳定性和性能方面持续投入,单集群最大超过 30W 长链接,对于业务团队而言,运维成本大幅下降一倍,管控体验大幅提升。MSE 产品出色的稳定性和性能,获得了标杆客户的高度认可,交出了一份漂亮的成绩单!

双十一战绩

1、MSE1.0 托管了阿里集团大部分 ZooKeeper 线上集群,覆盖的产品包括集团的多种核心基础组件;
2、双十一当天,所有集群整体运行稳定,容量水位,各项指标正常, 0 故障, 0 例问题反馈;
3、在高峰期间,MSE 托管的最大容量集群 Blink 集群,各项指标符合预期,平稳渡过,各项指标详趋势如下:

lADPDgQ9rud9MWPM8M0CNg_566_240_jpg_620x10000q90g

链接数

lADPDgQ9rud9MWbM9M0CNg_566_244_jpg_620x10000q90g

平均请求延时

2.0 架构升级,融合云原生赋能产品竞争力

MSE 2.0 的架构升级,是和云原生技术体系的无缝融合;从另一个角度理解,能够依托云原生带来的技术红利,给自己的产品带来技术创新,效率提升,性能提升,就是一种云原生能力。

1、MSE 1.0 采用的是集团部署模式,Sigma +集团内部网络+集团组件:
lALPDgQ9rud9MWfNAaTNAqs_683_420_png_620x10000q90g

在 1.0 的架构下,在产品平台能力,运维效率方面都比较低效,受限于平台,产品自身能力无法突破质的提升:

  • MSE1.0 的集群交付模式,是在用户需要部署的机房申请机器资源,然后人工在机器上面部署集群,部署完成之后,需要去配置中心上面维护一套节点IP的映射关系,整个流程下来,最少要 3 个小时,经常会因为资源交付的问题,协调多方。
  • 集团内部用户申请 ZooKeeper 资源,很多场景下是独立需求,也就是,需要一个独立的集群即可,这种情况下,如果每个用户给一个,维护的成本非常高,因此需要用户单独邮件说明场景,判断是否可交付公共集群,这个流程让用户难以达到快速安全接入的目的。
  • 集团内部支持的独立集群有非常多,每月集群宕机,物理机迁移后,需要人工恢复节点,由于 ZooKeeper 是有状态应用,服务端的配置文件状态依赖于服务器的地址,集群之间需要数据同步,无法做到和业务应用一样自动拉起。
  • 集群的扩缩容,需要手动修改每台节点的配置,每台都需要重启才能生效,由于涉及到 ZAB 协议规则,不能出现多主的情况,否则会出现数据丢失等严重后果,需要严格控制重启顺序和配置内容,具有较高的运维技术复杂度。
  • 用户在集群的地址发现服务时,有依赖到多种配置组件,有些为了降低依赖,就直连集群节点 IP ,在出现节点更换或者扩缩容时,需要额外去维护这份映射关系,如果出现纰漏,会导致服务不可用。
  • 服务端的配置,由手动进行修改同步,也没有机制保证每次人工操作的正确性,导致 ZooKeeper 集群在重启加载了不一致的配置,出现数据丢失,选主失败等问题。

2019年 5 月份,我们将 MSE 1.0 进行了平台级别的架构升级改造,希望能够解决目前所遇到的问题,同时在支持集团内部的同时,能将产品能力对外输出(基于公有云上引擎的存量调研数据,市场是非常大的),在技术选型时,充分考虑了底座基于K8S的云原生架构,未来是云时代,各种云上能力,未来一定是都会主动对接到标准云原生架构中的,MSE 需要借助这些云原生标准能力,将 MSE 产品的平台能力整体提升,也为后续云原生战役做好技术铺垫。

2、MSE 2.0 ,基于 ACK+ 云能力多位一体组合( VPC,DNS,SLB,高效云盘,ARMS )

lALPDgQ9rud9MWrNAgHNAs0_717_513_png_620x10000q90g

MSE 2.0 架构,底层容器资源通过 ACK 进行统一管理,完全兼容开源K8s标准,因此也获得了K8s的多种高级特性支持:

  • 集群交付能力效率提升 100 倍
    K8s 的 POD 拉起,加上云盘, SLB 等资源分配, 3 分钟即可交付一套集群,对比 1.0 流程,资源申请,配置同步等,最少需要半天,效率提升了百倍。
  • 集群节点多可用区部署,具备多机房容灾能力
    MSE 每个 Region 都支持最少 2 个可用区,在集群节点分配时,已配置的 K8s亲和性调度,会将节点打散至多个可用区部署。
  • 压力负载均衡完美,后端稳定性大大提升
    SLB是一款成熟的产品,得到了市场的检验,MSE 依托它的4层负载均衡能力,客户端能够均匀的分布在每台节点上面,避免了用户使用IP直连的情况下,出现负载不均衡的情况。
  • 机器宕机,自动迁移重建
    降低了运维成本,同时提高了可用性,以往需要自己申请机器,由于需要状态同步,需要人工修改配置手动重启每一台节点,复杂度非常高,同时频繁的手工操作也给线上稳定性带来了风险隐患
  • 监控指标丰富
    在监控方案选型上,采用了云原生标准的监控体系方案-普罗米修斯,由于和开源兼容一致,在 MSE 业务监控指标数据的采集组件上,完全复用了 ZooKeepper 开源组件的上报能力,研发效率得到了翻倍的提升。

普罗米修斯监控,提供了强大的后台交互大盘,同时MSE 前端可通过数据查询接口,按需重新绘制监控指标趋势图。

技术能力产品化,满足客户多层次需求

相比 MSE 1.0 ,MSE 2.0 将许多技术上的能力,进行了产品化改造,提升产品竞争力外,同时也将技术能力赋予了用户,满足了客户多层次的需求。

1、集群交付方式支持域名交付
用户在客户端连接 MSE 集群时,填写域名,在集群的实例变化后 ,客户端不需要修改地址,会自动解析到新地址,降低用户使用时的切换成本。

lADPDgQ9rud9MWxJzQLq_746_73_jpg_620x10000q90g

2、集群节点健康状态可视化
通过状态页面,客户可以看到每个节点的健康情况以及节点角色。

lADPDgQ9rud9MW_M8s0CUA_592_242_jpg_620x10000q90g

3、MSE 运行时参数优化,支持更高的链接性能及降低运维成本
用户自维护的 64 核物理机,在迁移到 MSE 后,评估了容量及性能要求,使用了 12 核, CPU 利用率最后能够稳定保持在 15% 左右,GC 频率降低 80% ,同等业务规模下,只需要 1/5 的机器资源就满足了业务需求,节省了客户的机器资源。

4、数据节点编辑功能
MSE 提供了集群数据管理视图,贴合业务场景,可以方便的对数据进行白屏化操作。
lADPDgQ9rud9MXHNATPNAmA_608_307_jpg_620x10000q90g

5、版本升级,MSE 一键滚动升级
升级MSE版本时,只需要更新镜像 ,然后在控制台点击升级,即可让MSE集群所有节点逐台滚动升级

6、集群监控指标趋势图
可以查看当前集群监控指标的实时值,也可以查看历史趋势,例如集群的链接数变化情况, 7 天历史变化趋势

lALPDgQ9rud9MXPNAYrNAuo_746_394_png_620x10000q90g

7、用户侧自定义报警
可以针对不同的监控指标,设置对应的报警阀值,支持短信,钉钉群,邮件。

lALPDgQ9rud9MXXNAW_NAh0_541_367_png_620x10000q90g

新征程,新挑战

  • 产品技术高度融合,基于 Nacos 内核,统一内部多款配置中心,服务注册心, Nacos 产品基于 MSE 平台商业化,集团内部集群全部上云,整体节省机器成本 50% ,人效提升 3 倍。
  • 商业化,意味着对产品的可用性和性能有着更苛刻的要求, 需要满足更高的SLA,99.99%读服务可用,99.9% 写服务可用,平均请求延时 小于50ms 99.99%。
  • 云原生技术体系的深度融合,支持弹性伸缩,服务 ServerLess 化,资源成本最少降至 50% ,配合产品配置修改不重启的能力,做到 MSE 服务永远在线
相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
14天前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
44 1
|
17天前
|
消息中间件 API 持续交付
后端开发中的微服务架构实践####
【10月更文挑战第21天】 本文深入探讨了微服务架构在后端开发中的应用,从基本概念出发,详细阐述了微服务的核心优势、设计原则及关键技术。通过实际案例分析,揭示了微服务如何助力企业应对复杂业务需求,提升系统的可扩展性、灵活性与可靠性。同时,也指出了实施微服务过程中可能面临的挑战,并提供了相应的解决方案和最佳实践。 ####
26 3
|
13天前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
9天前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
9天前
|
算法 NoSQL Java
微服务架构下的接口限流策略与实践#### 一、
本文旨在探讨微服务架构下,面对高并发请求时如何有效实施接口限流策略,以保障系统稳定性和服务质量。不同于传统的摘要概述,本文将从实际应用场景出发,深入剖析几种主流的限流算法(如令牌桶、漏桶及固定窗口计数器等),通过对比分析它们的优缺点,并结合具体案例,展示如何在Spring Cloud Gateway中集成自定义限流方案,实现动态限流规则调整,为读者提供一套可落地的实践指南。 #### 二、
26 3
|
12天前
|
负载均衡 Java 开发者
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
46 5
|
8天前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
24 1
|
9天前
|
监控 安全 持续交付
构建高效微服务架构:策略与实践####
在数字化转型的浪潮中,微服务架构凭借其高度解耦、灵活扩展和易于维护的特点,成为现代企业应用开发的首选。本文深入探讨了构建高效微服务架构的关键策略与实战经验,从服务拆分的艺术到通信机制的选择,再到容器化部署与持续集成/持续部署(CI/CD)的实践,旨在为开发者提供一套全面的微服务设计与实现指南。通过具体案例分析,揭示如何避免常见陷阱,优化系统性能,确保系统的高可用性与可扩展性,助力企业在复杂多变的市场环境中保持竞争力。 ####
27 2
|
9天前
|
消息中间件 运维 API
后端开发中的微服务架构实践####
本文深入探讨了微服务架构在后端开发中的应用,从其定义、优势到实际案例分析,全面解析了如何有效实施微服务以提升系统的可维护性、扩展性和灵活性。不同于传统摘要的概述性质,本摘要旨在激发读者对微服务架构深度探索的兴趣,通过提出问题而非直接给出答案的方式,引导读者深入
27 1
|
10天前
|
负载均衡 监控 API
后端开发中的微服务架构实践与挑战
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势和面临的挑战,并通过案例分析提出了相应的解决策略。微服务架构以其高度的可扩展性和灵活性,成为现代软件开发的重要趋势。然而,它同时也带来了服务间通信、数据一致性等问题。通过实际案例的剖析,本文旨在为开发者提供有效的微服务实施指导,以优化系统性能和用户体验。

相关产品

  • 微服务引擎