*作者：草谷*

## 前言

业务大促备战是企业必做功课之一，今天趁着 99 大促来袭前，谈一谈如何利用 MSE 的服务自治能力提前发现潜在风险，通过可观测能力了解引擎内部运行状态，并提供自建 Nacos/ZooKeeper 一键迁移上云服务，帮助业务顺利应对大促。

*点击查看直播回放：*

[*https://yqh.aliyun.com/live/detail/29401*](https://yqh.aliyun.com/live/detail/29401)

## 微服务的挑战

### 单体到微服务的变化

随着互联网的业务快速增长，进而导致系统的架构也在不断的发生着变化，由最初的单体形态演变到现在最流行的微服务架构；软件架构设计里面没有银弹，享受着微服务带来的扩展性和性能提升，必然要承受它带来的一些副作用，总的来说，主要有以下几点的变化：

-   **调用链路增加了多跳**

单体应用的业务逻辑在一个节点进程里面闭环执行完成，微服务架构改造后，不同功能属性的逻辑拆分成一个个服务部署在独立的节点之上，要完成一段完整的业务逻辑，需要每个独立节点互相配合，A->B 变成了 A->B1->B2->B3。

-   **增加了复杂中间件的依赖**

微服务架构里面，RPC 是最基本的技术引入，它包含了：RPC 客户端（Dubbo/Spring Cloud），注册中心（Nacos/ZooKeeper/Eureka），如果有事务要求的，还需要依赖一些分布式事务组件如 Seata。

-   **从单兵作战到多团队协作**

微服务架构的升级，除了应用系统层面的变化，生产关系也可能产生了变化，以前一个系统由一个人负责，变成了多个服务团队协作开发，互相支持。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2db014ca127645bc96fd65c4a00633e1~tplv-k3u1fbpfcp-zoom-1.image "1.png")

### 带来的挑战

面对微服务架构带来的变化，给开发者和运维同学带来了不少挑战：

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/76806be7c804432fb4984ca59a87694b~tplv-k3u1fbpfcp-zoom-1.image "2.png")

在日常开发和运维过程中，经常会遇到一些如下的典型问题：

-   场景一：服务调用失败，Consumer 日志显示没有可用服务，可明明 Provider 进程正常运行着，是服务没注册上去呢？还是注册中心没把地址推送到客户端呢？

-   场景二：Nacos 客户端在某种极端场景下，出现了异常，排查了半天，是 Nacos 客户端已知 Bug 导致，需要升级到 xx 稳定版本，但是作为开发/运维的你，每天业务需求那么多，如何搞定对客户端版本迭代保持着时刻的关注呢？

-   场景三：业务大促即将来临，客户端热火朝天的扩容以应对激增的流量，突然间注册配置中心不工作了，原来是达到注册配置中心额定容量了，需要扩容了，每次都是出现问题才后知后觉，然后提前做好容量规划呢？

-   场景四：线上注册配置中心出现 FullGC，重启又缓解一下，每隔一段时间又出现，排查同学反馈是可能是有客户端错用，大量的读写数据导致内存吃不消，但是又苦于难以找出到底是谁在“捣乱”？

## 服务自治能力

云原生微服务仍然是目前最热门的技术架构（[《40%的云原生开发者专注于微服务领域》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247536858&idx=2&sn=45088fc583f7d00ce95f3861fc3f8b46&chksm=fae65b15cd91d20338a602ebda267b2582791434b29b33855f6f42aa2ec6fd012cb73a1a247b&scene=21#wechat_redirect)），因此解决这部分群体的痛点，能够给企业带来最大的价值，这也是 MSE 的初衷。

阿里巴巴从 08 年开始单体架构演进走到现在，有着十几年的踩坑经验，也总结出了一套打法；MSE 的服务自治能力 ，目标是帮助用户快速发现问题，定位问题，解决问题，它主要围绕以下 3 个方面提供一系列的功能和工具：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8b4c37e36dd1480b91b7f4b213bd1eeb~tplv-k3u1fbpfcp-zoom-1.image "3.png")

### 可观测性

可观测性（Observability）是帮助微服务稳健运行的重要一环：

-   “系统是否还是正常的？”
-   “终端用户的体验是否符合预期？”
-   “如何在系统快要出问题之前主动发现系统的风险？”

如果说监控可以告诉我们系统出问题了，那么可观测就可以告诉我们系统哪里出问题了，什么原因导致的问题。可观测不但可以判断系统是否正常，还可以在系统出现问题之前，主动发现系统风险。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/46d0efcb24824c2294dea3cb747f5928~tplv-k3u1fbpfcp-zoom-1.image "4.png")

-   **监控大盘**

MSE 提供了丰富的监控大盘，无缝集成 ARMS，免费为大家提供了丰富的可观测能力，可以借助这些指标，窥探容量情况，尽早发现问题，定位问题：

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/204028649987493f9fb81edd8499c39a~tplv-k3u1fbpfcp-zoom-1.image "5.png")

#### 1. 基础大盘

提供了基础设施的一些核心指标，主要如下：

-   JVM 监控
-   内存/CPU
-   网络流量

针对这些基础核心指标，建议至少要把内存/CPU 的预警给加上，阀值设置到 60%。

如果你的应用是时延敏感的，需要重点关注下 JVM 监控中的 FullGC 指标，这个会导致进程响应变慢。

网络流量指标，可以用来观测 SLB 的网络问题，例如流量突然涨到某个点，然后一直横盘，这时你的客户端也相应出现链接失败异常，这个就可能是达到了流量阀值。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a5e34c8587ce4f76b99492f53ab4eba3~tplv-k3u1fbpfcp-zoom-1.image "6.png")

#### 2. 概览大盘

概览大盘的指标，主要的目的是给大家快速展示一些核心的指标，能够有一个全局的视角：

-   客户端分布
-   当前配置/服务水位
-   链接数
-   配置/服务数

其中，客户端分布指标，可以帮助你看到系统中各种客户端版本的分布情况，结合 Nacos 的版本使用限制，找到高危版本，推动解决掉客户端带来的稳定性风险。

例如：近期 Nacos 发布了最新的版本使用约束，Nacos 1.4.1 版本有严重的 DNS 解析异常问题，可以通过客户端分布指标，找到该客户端分布的情况，通知对应的业务进行升级。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/57b888bf5faa4747b0ae1052498ae8ac~tplv-k3u1fbpfcp-zoom-1.image "7.png")

#### 3. 业务大盘-Nacos 服务/配置大盘

MSE 提供的业务大盘里面的指标，都是精挑细选出来具有代表性的，能够帮助你全面了解注册配置中心的内部业务规模；大促来临，公司要求你评估注册配置中心当前容量规模，你可以通过这些指标数据进行一个全面的分析。Nacos 的使用场景分为注册中心和配置中心，MSE 根据这 2 个场景单独设置了大盘：

配置中心指标：

-   配置数量
-   配置监听数量
-   配置的 TPS/QPS
-   读写 RT

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/57482a0f8edf46c6b9952515ea65a138~tplv-k3u1fbpfcp-zoom-1.image "8.png")

注册中心服务指标：

-   服务提供者/订阅者数量
-   注册中心 QPS/TPS
-   注册中心读写 RT
-   推送成功率/耗时/TPS

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/14fe482379ba41bab222312af3e7b84e~tplv-k3u1fbpfcp-zoom-1.image "9.png")

#### 4. ZooKeeper TopN 大盘

TopN 大盘，对外部因素导致了服务端出现异常类的问题定位是非常高效的：

-   Znode 的大小 Top N 排序
-   客户端对 ZooKeeper 的读写 TPS/QPS Top N
-   热点数据的 TPS/QPS Top N
-   热点数据的监听数 Top N

在日常开发中，你大概率遇到过 ZooKeeper FullGC 的场景，但是又不知道是具体什么原因引起的 GC，可能是 ZooKeeper 在推送大量数据导致，又不确定是哪个热点数据被订阅导致的，也可能是有客户端往 ZooKeeper 里面写大数据，又找不到是哪个客户端写的？

我们看下 2 个客户端典型错用的场景：

1. 户端错用写入了大数据，订阅者非常多，导致 ZooKeeper 推送大量数据引起了 FullGC：

往/99testWriteBig 路径下面写入了大数据，可以通过 Znode 大小 TopN 发现大数据节点

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/04b4f4472a974693bcc07765d24e50d6~tplv-k3u1fbpfcp-zoom-1.image "10.png")

2. 客户端错用频繁读某 ZK，导致集群性能压力增加，响应延时，需要找到这个客户端：

一个 SessionId 为：0x1030871c8ed0004 的客户端，频繁读取/99testRead 节点，通过客户端 QPS TopN 大盘，可以找到它，同时也能看到这个当前 Server 中最频繁读取的是哪个数据

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a14b0c9d21d94357a7c15fef38e4768f~tplv-k3u1fbpfcp-zoom-1.image "11.png")

-   **指标预警**

MSE 给注册配置中心提供了核心指标的预警能力，建议把如下的指标都配置上：

-   Nacos 建议配置：

-   -   服务读写平均耗时：可以发现性能问题
    -   配置长轮训链接数：可以发现容量问题
    -   服务数/配置数：可以发现容量问题/客户端错用

-   ZooKeeper 建议配置：

-   -   Znode 数：可以发现客户端错用
    -   连接数变化率：突降的话服务端节点可能出现了故障
    -   单服务端链接数：可以发现容量问题/客户端错用

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6e21178ae5dc4baa987fd3cf6c1b1682~tplv-k3u1fbpfcp-zoom-1.image "12.png")

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52c371585a70423f98b21ee5d60c50ac~tplv-k3u1fbpfcp-zoom-1.image "13.png")

### 链路追踪

-   **推送轨迹**

推送轨迹，是指注册配置中心从 server 端到 client 端的一次推送链路上的相关信息展示。推送轨迹可以让用户非常方便的查询到，当开发过程中，出现如下问题，都可以通过推送轨迹快速定位到，极大的提高问题的排查效率：

-   客户端未收到服务推送
-   服务间调用出现异常
-   配置发布异常了
-   配置修改完发现某台机器不生效
-   需要查看配置中心变更及推送事件

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ad8ffb1523df4e0cae31fb48eb1005fe~tplv-k3u1fbpfcp-zoom-1.image "14.png")

MSE - Nacos 注册中心推送轨迹查询页面

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e9043de75c484766a5352632c696d60c~tplv-k3u1fbpfcp-zoom-1.image "15.png")

MSE - Nacos 配置中心推送轨迹配置维度查询页面

### 集群诊断

-   **一键诊断**

如果说 MSE 提供的各种监控大盘，是辅助你去发现，定位问题，那么 MSE 即将提供的一键诊断功能，就是自动帮你去扫描发现风险，2 者互相配合辅助，它目前主要从下面 3 个方面去做评估：

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/87dbc6c78e024c44806b4459ab7c7b01~tplv-k3u1fbpfcp-zoom-1.image "16.png")

下图是一键诊断的功能页面，从上面可以看到目前你当前购买的引擎存在的风险，这些都是根据内置规则给自动扫描出来的，你不用再去人肉进行排查了，并且提供了合理的建议给到你进行改进：

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2b4613d1de6942b79f12ff6ddf1ce1b6~tplv-k3u1fbpfcp-zoom-1.image "17.png")

## 平滑迁移 MSE

上面给大家介绍的 MSE 服务自治功能，后续将继续完善打磨，提供更多的自治能力，包括事件统计、健康审计等功能，降低注册和配置中心的问题排查难度、提升可用性。

如果你现在还是自建的注册配置中心，建议尽快迁移上云，享受这些企业级服务，MSE 提供了高效的迁移工具 MSE Sync，提供双向同、自动服务获取、一键同步全部服务等能力，帮助用户更好的完成 Nacos、Zookeeper 注册配置中心的迁移。

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c612764a73cf4573b28e52f70c0811a9~tplv-k3u1fbpfcp-zoom-1.image "18.png")

MSE 的官网文档，提供了详细的 Step by Step 的迁移操作文档：

*《自建 Dubbo ZooKeeper 迁移到 MSE ZooKeeper》*

*<https://help.aliyun.com/document_detail/444943.html>*

*《自建 Dubbo ZooKeeper 注册中心迁移到 MSE Nacos》*

*<https://help.aliyun.com/document_detail/446904.html>*

*《自建 Dubbo Nacos 注册中心迁移到 MSE Nacos》*

*<https://help.aliyun.com/document_detail/445140.html>*

如果迁移过程遇到问题或者需要定制，可以联系我们提供专家一对一的迁移支持。

## 购买 MSE 享受企业级服务

MSE 提供了 高可用、高性能、安全易用等核心竞争力！

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0d9257c229514c3fa22a309dcb7cf951~tplv-k3u1fbpfcp-zoom-1.image "19.png")

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/54421627fae9432fb0a2fe6509eda172~tplv-k3u1fbpfcp-zoom-1.image "20.png")

ITPub博客

99 大促来袭，利用 MSE 服务自治体系为业务保驾护航

最新文章