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

开发者社区> 阿里中间件> 正文

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

简介: 前言 微服务引擎 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 服务永远在线

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里中间件
使用钉钉扫一扫加入圈子
+ 订阅

为企业提供高效、稳定、易扩展的中间件产品

官方博客
链接