开发者学堂课程【99大促来袭，利用MSE可观测能力和容量规划为业务保驾护航：99大促来袭，利用MSE可观测能力和容量规划为业务保驾护航】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1190/detail/18106
99大促来袭，利用MSE可观测能力和容量规划为业务保驾护航
四、MSE的服务自治体系
接下来给大家介绍MSE的服务自治体系
MSE服务自治体系的目标是帮助用户快速发现问题，定位问题，解决问题，它主要由以下三大块组成：
第一块是可观测性，可观测性提供了这个可观测性的大盘监控，就是把很多核心的指标放到一个大盘里面展示，第二个就是针对大盘的监控都提供了一些大盘指标的预警能力，就是通过电话或者短信通知到使用者，第二个就是链路追踪，链路追踪主要是根据配置中心的配置的变更，它的变更有没有变更成功，还有一些历史变更的查询，同时对这些配置的监听是否成功，是否正确，也有一个推送的机制，然后配置的数据推送到客户端有没有推送成功，也提供一个数据推送轨迹的这样一个功能，帮使用者去发现整个链路中推送的一些问题，第三个就是集群诊断，集群诊断主要是可以帮助使用者集中的去发现集群中的存在的一些风险问题，比如说客户端的版本的分布，集群是否是高可用的，集群是否有什么安全风险，主要是由这三大块组成我们在这个服务自治体系。
1、可观测性
接下来详细介绍每一块，首先就是可观测性这一块，可观测性，曾经管理大师曾经说过：如果无法衡量一个东西，那就无法管理它。同样的道理，我们的系统，如果没有办法去量化它、衡量它、观测它，就很难去管理这个系统，可观测性其实就是为了来解决这个量化、衡量的这样一些问题的，可观测性其实帮助微服务是非常重要的一块，这有几个问题：我们的系统是否还正常地运行着？终端用户的体验是否符合预期？我们如何在系统快要处问题之前主动发现系统的风险呢？可观测性就是从这几个方面去解决这些问题的，可观测性从系统的角度来看无非就是两大块，第一大块其实就是监控，监控它核心聚焦在发现问题，让问题提早的暴露给使用者，以此来保证系统的稳定性，另外一块就是可观测性，可观测性其实就是系统运行时的白盒化，状态白盒化，通过各种观测手段窥探你系统运行时的一个状态，然后出现问题的时候，通过状态找到整个系统的根因，动态这些问题，可观测性对于使用者来说，实验分成两部分，一部分是运维，对运维来讲可观测性给它提供的帮助其实就是它让运维者知道这个系统出现什么情况了，比如系统宕机了，通知到运维的同学，系统不可用了，看一下出了什么原因，知道目前这个系统处在什么状态，对于开发者来讲，可观测性的问题是解决开发要去定位这个系统的问题，出现在哪，为什么会出现这个问题？是什么原因？这个就是对于开发者来讲核心的重要的一个权利，就是可观测性。
对于这套理论，介绍的就是说MSE这边的话提供了哪些可观测性的能力。
第一个就是对于这个配置中心所有的一些基础指标进行的一个大盘的投出，基础指标包括第一个 JVM 监控，里面包括 YoungGC、FullGC，一些时间的技术，第二个就是内存和 CPU 的使用率，第三个就是网络流量，根据这三个基础指标，也提供了预警的配置，主要是运行跟利用，配置告警阀值建议大家配置到 60%，预留一些花费，用来应对平时遇到波峰的一些情况，JVM 监控如果是比较敏感的一些业务，就要重点关注这个 JVM 的监控，实际上这里面的 FullGC 如果出现可 FullGC 就要重点关注一下，因为 FullGC 在后台是反应就会延时，网络流量这一块可以观察到它可以发现网络上面的一些问题，同时业务波动，比如大量的服务在上下线，流量就会波动，就可以根据这个指标去看看业务的波动，这个是业务指标。
还提供了一些 Nacos 的大盘概览，就是这个大盘概览核心的目的就是能够快速地看到数据中心核心的一些指标，主要有以下几点，第一个就是客户端的分布情况，第二个就是当前配置和服务容量的水位，第三个就是服务中心的链接数的情况，链接的水位，第四个就是具体的配置数大概有多少，服务数大概有多少，这些服务性指标能解决当前的什么问题呢？第一个，假设一个场景，比如因为 Nacos 的客户端是不断的在迭代的，低版本可能会出现一些问题，比如 Nacos 出了一个公告，是1.4.1版本有个严重的 DNS 异常的解析异常问题，这时候会发通知到业务方，建议升级到最新的版本，作为运维同学，可能就去帮助开发的同学告诉他可能客户端配置太低了，这时候就需要借助客户端分布的指标就可以知道客户中有哪些客户使用了低版本的客户端，把它找出来，进而通知对应的业务进行开发升级，之后会对Nacos 出现问题的版本会进行升级，具体在官方云盘下，大家可以去看看，再结合客户端版本的指标去推动业务的升级，这个主要还能够去通过配置与服务的水位指标可以观测系统的目前水位的情况，提早发现容量预警，
还提供 Nacos 配置和服务指标的大盘，知道 Nacos 的场景其实分成配置中心和注册中心两个不同的接口，会说会配两个模块的板块，配置中心主要透出的中心指标是配置数，配置的数量，接下来是配置的监听数，配置的 TPS 和 QPS ，还有配置读写的RT，注册中心提供的也是类似的，就是服务提供者和订阅者的数量，注册中心的 QPS 和 TPS ，和注册中心读写RT，额外这里注册中心还提供了一些推动成功率、耗时，这个东西观察这个指标其实是可以对指控推送的数据去延时一些定价高的业务来表达，这还是很有用的，这些指标能解决什么问题呢？举个例子，就是一个场景，就是说在做大促的时候，大促队长要求对当前的配置中心做一些容量的评估，就是当前的注册配置中心的容量是多少？就是业务规模是多少，可以通过这些升级的指标可以提取出来，给到他，对这个系统有一个更直观的了解。
对于 Zookeeper 这一块对于 TopN 的指标大盘，TopN 的大盘的核心的目的就是发现事件中的勒索问题，说白了就是说经常问题的执行，就是说线上出现了一个错误，经过排查之后就发现有些客户端进行的一个疯狂的读写，数据变更的时候就导致整个内存是坏的，是能得出这个结论，但是很难发现到底是谁，哪个客户端做了这个事情，一些客户是没有这个监控的，没有这种发现能力的，然后根据开发的一个大盘就是 TopN 就可以找到它，里面也包括一些 Znode 的大小 Top N的排序，就是有哪些数据是写得很大的，还有一个就是某个连接对Z ookeeper 平台的频繁读写，会通过 sessionid 的模式 Top N的一个 sessionid 读写一个指标看到是哪个连接，对 Zookeeper 的一个频繁的读写，还有某个热点数据的读写跟监听，比如说有个路径里的热点数据，热点数据是通过路径来看的，可以看到哪个路径有很多的客户端去往这个路径上面写，就比如说这个路径上的数据，或者监听这个路径上的数据，就可以通过 Top N的形式展示，有了这套数据之后，任何人就可以去上面做一些捣乱的做法，就可以把它拎出来，这个是非常有用的。
根据刚才讲的一些像业务指标，设置了相应的预警能力，这里核心就那么几个，建议一定要去配置的一个指标，对于 Nacos 来讲就是说把服务读写的平均耗时，这个是怎么配上的，配完之后可以根据平时的日常值加上50%作为它的运行法则，这样可以发现 Nacos 的性能问题，第二个就是把长轮训链接数给它配上，长轮训链接数可以发现容量问题，当不断的往智慧中心里面去扩容的时候，这时候就要去关心智慧中心的容量，第三个就是服务数跟配置数，这个也可以去发现容量问题，包括一些客户端的错用，有些客户端发了很多去探索的，比如什么死循环 fo r循环，不断的往智慧中心里面发配置、发服务，这就会把智慧中心给宕掉，把这个配置给配上，这个至少可以发现 Zookeeper 事件可以把 Znode 数给它配上，因为不管是什么都是有预期的，如果配上一个阀值发现超过阀值发布的时候，要么是规模打开了，要么就是客户端错用了，才能不让写数据，是可以发现这个问题的，第二个就是连接数的变化率，比如打开1000个连接，突然之间降到了0，肯定是出问题了，一般数客户端出错了，把这个指标给它配上。单服务端链接数，这个指标把它配上，可以发现容量问题，就是说安装自己业务大小的规模，可能有三台机器，每台机器大概有几百个连接，最多不超过两百，给它单个服务端的话给它配置上三百个连接，超过的话可能就会有容量问题了，或者说客户端错用了，不断地向客户端去扩容，可以发现这样的一个问题，这几个就是核心的配置，其他就是根据自己的业务配置一些报警。
2、链路追踪
接下来讲MSE服务自治体系的链路追踪，链路追踪的第一个功能就是配置的发布跟监听的一个查询，它们能解决什么问题？这里举两个场景，第一个场景就是突然之间线上发布了一个配置在正常运行，突然之间有系统发现这个配置变化，导致出现了故障，需要定位谁对这个配置做了变更、修改，在这种情况下可以通过MSE里面的配置中心的历史查询的功能，就可以罗列出在出故障的时间段里面有谁去做了这个配置的变更。第二个场景就是发布了一个配置，这个配置现在就要下线了，但是下线这时候就要知道谁依赖了这个配置，谁监听了这个配置，把依赖方推动到它们下线，不能贸然下，下了可能就会引起故障了，这个时候就主要指导这个配置做哪些机器定义了，这时候用MSE的监听查询功能，可以把配置去查一下有谁监听了这个配置，就可以拎出来可以让它下线，下线了之后可以让它下线，这是一个发布监听这样的一个功能。
链路追踪第二个就是推送轨迹，推送轨迹能解决什么问题？首先推送轨迹是分注册中心的推送轨迹和配置中心的推送轨迹，一个个来，注册中心能解决什么问题？比如用注册中心去做服务的搭建有些这个 consumer 反馈说注册中心没有服务推到，导致调用出现了异常，导致 Not Found 这样的异常，这时候就需要排查到底这个服务为什么没有推到那个客户端，什么时候推到，要拎出来，所以这时候可以通过注册中心的推送轨迹这个功能，去查包括服务轨迹的那个查询的时候点击服务，把服务的推行者分给注册中心，再写按个实验派，就可以把服务所有的具体去到了哪些客户端，推送的服务的数量一个个功能很清楚列出来的，就可以解决这个问题，回答调用异常出现在某某时刻，把这个配置推送到了。作为配置中心的场景，也有一个推送轨迹的，当发现这个配置发布出现异常了，有没有发布成功？配置在配置中心上面，去做一些修改，修改了之后，就是所有的客户端都已经生效了，这些问题提出的时候就可以用推送轨迹这个功能去验证它去证实它，到底有没有推送成功，就是所有的机器都生效了，可以去查询的维度选配置，选好数据选好时间段，就可以把这个配置在这个时间段所有具体推送的情况一条条展示，把这个变更也可以展示出来，推送轨迹可以巡查注册中心、配置中心出现的各种推送的问题，可以很快速地去定义出来，事件新来，这是推送轨迹的功能。
3、集群诊断
接下来讲 MS E服务自治体系的集群诊断的功能，集群诊断它的目标就是全自动的去发现评估里面的一些问题，现在目前主要是三大块的问题，第一个容量评估，就是会自动评估当前引擎的容量，根据当前具体引擎的规格，比如1C2G、2C4G知道的，综合集群的使用量，匹配当前的容量，会告诉说自己的引擎的容量超出了多少，是不是要进行扩容了，会给一个最佳容量规格的建议。版本评估就是说会自动搜集扫描当前集群客户端的版本，这些客户端的版本有什么风险，有什么安全性能的问题，都会一个个找出来，然后再具体给到处理的办法，就是要升级到哪个版本，升级到哪个安全的版本。高可用评估就是可以自动检测当前的集群当前是如何部署的，部署是不是达到了多可用区容灾的一个高可用的能力，它检测如果是线上含性的话，是单个节点还是多个节点，如果是单个节点的话可能建议升级到多个节点，这是高可用的评估。它主要围绕这三大块的一键诊断，只需要去点一个按钮，就会去在这三个方面去评估健康度，关于这个容量其实是会有一个水位的对照表，如下图：
根据这个表会去给容量的一个最佳的建议，都是全自动的，不需要去拿鼠标去算，还没有上线，可能过两天上线。这个非常好用，大家可以去体验一下。
