前言

---

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

双十一战绩

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

链接数

平均请求延时

 

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

---

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

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

在 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 ）

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 集群时，填写域名，在集群的实例变化后 ，客户端不需要修改地址，会自动解析到新地址，降低用户使用时的切换成本。

2、集群节点健康状态可视化

通过状态页面，客户可以看到每个节点的健康情况以及节点角色。

3、MSE 运行时参数优化，支持更高的链接性能及降低运维成本

用户自维护的 64 核物理机，在迁移到 MSE 后，评估了容量及性能要求，使用了 12 核， CPU 利用率最后能够稳定保持在 15% 左右，GC 频率降低 80% ，同等业务规模下，只需要 1/5 的机器资源就满足了业务需求，节省了客户的机器资源。

4、数据节点编辑功能

MSE 提供了集群数据管理视图，贴合业务场景，可以方便的对数据进行白屏化操作。

5、版本升级，MSE 一键滚动升级

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

6、集群监控指标趋势图

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

7、用户侧自定义报警

可以针对不同的监控指标，设置对应的报警阀值，支持短信，钉钉群，邮件。

新征程，新挑战

---

• 产品技术高度融合，基于 Nacos 内核，统一内部多款配置中心，服务注册心， Nacos 产品基于 MSE 平台商业化，集团内部集群全部上云，整体节省机器成本 50% ，人效提升 3 倍。

• 商业化，意味着对产品的可用性和性能有着更苛刻的要求， 需要满足更高的SLA，99.99%读服务可用，99.9% 写服务可用，平均请求延时 小于50ms 99.99%。

• 云原生技术体系的深度融合，支持弹性伸缩，服务 ServerLess 化，资源成本最少降至 50% ，配合产品配置修改不重启的能力，做到 MSE 服务永远在线

求贤若渴

目前团队在高速发展，求贤若渴，职位详情见：

有想一起搞事的同学可以尽快联系我们！！！

作者信息：

草谷，阿里云高级工程师，目前负责阿里集团内软负载分布式组件 TaoKeeper ，商业化产品 MSE ，分布式服务注册中心及高可用架构领域的相关工作。

本文缩略图：icon by Victoria

Tips：

# 点下“在看”❤️

# 然后，公众号对话框内发送“CNCF”，试试手气？????

# 本期奖品是正版CNCF指尖陀螺 。

#由于疫情原因，较多快递停发，本期抽奖礼品，将在大部分快递恢复后再寄出，请谅解。

查看评论