开发者学堂课程【99大促来袭，利用MSE可观测能力和容量规划为业务保驾护航：99大促来袭，利用MSE可观测能力和容量规划为业务保驾护航】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1190/detail/18106
99大促来袭，利用MSE可观测能力和容量规划为业务保驾护航
内容介绍：
一、课前导入，知识概要
二、MSE定位和竞争力
三、微服务结构带来的挑战
四、MSE的服务自治体系
五、平滑迁移到MSE方案
六、实践演示MSE的可观测大盘
一、课前导入，知识概要
今天是8月25号，即将迎来99大促，借这个机会介绍MSE的服务自治能力，希望带去一些帮助，今天分享的主要主题如下：
首先介绍微服务架构目前带来的一些挑战，会出一些问题，这个问题如何通过 MSE的服务自治能力去进行一个定位跟排查，MSE 的自治能力主要分为可观测性、链路追踪、集群诊断这三大块，接下来会介绍一下如果是自建的微服务中心如何能够平滑迁移到 MSE 上面去，享受一些刚才讲的 MSE 提供的一些独特的能力，最后会给大家实践地演示一下利用 MSE 体验 ZooKeeper 大盘去找到跟解决日常遇到的一些常见的问题。
二、MSE定位和竞争力
首先介绍一下MSE定位和竞争力，在听直播的大家应该对MSE不会陌生，MSE的中文名是叫微服务引擎，听这个名字就知道，这个产品是解决微服务架构体系中的一些问题，它是一个面向业界主流开源微服务生态的一站式微服务平台，它由好几个模块组成，可以看下图：
首先从流量的入口，提供了一个叫做流动网关的这样一个产品，流量进来之后就是要比后面的微服务的一些客户端，然后各部分有提供的很多一些开源框架的一个支撑，
Dubbo/spring-Cloud-Alibaba/Envoy 这一块呢就是属于数据面，控制面的话就由我们提供的一个叫做微服务治理这样的一个模块，来帮大家整装处理微服务过程的一些问题，它还可以提供一些 Sentinel、Istio、恢复等等能力，上图介绍的左下角就是今天介绍的主角，就是说注册配置中心，注册配置中心也提供一些 Nacos、Zookeeper、Eureka，接下来会介绍一些注册配置中心的一些服务自治的能力，可以帮助在发现线上的一些日常的问题。
MSE 其实是有竞争力的，它相较于自建主要有一下四个竞争力：
首先它的性能是非常高的，它比自建的性能高40%，商业化就是对产品配置的一些调优，包括题型的一些高技能的一些 ware，在高可用这一块MSE能够比自建的高1个9，目前我们对外层面的是99.95%，其实这个就是迎新的一个部署，就是一个多可用区的部署，在易用这一块你能够享受到的就是比自建的效率提升10倍，这个式子是一点都不夸张，大家可以自己去自建一下一个 Nacos 的一个服务系统，耗的时间是非常长的，基本上就是一键购买就套餐具有，在后面的应用过程中都有经常应用的一些功能，都有提供一些经常应用的一些功能，在安全这一块主要是网关这一块，对流量有一个很安全的管控，也经过安全的一些验证，支持构建安全等保三级系统。
三、微服务结构带来的挑战
接下来讲一下微服务架构带来的一些挑战，目前是市面上大部分的公司，80%的公司是从单体演变到微服务的一个架构，在整个演变的过程中，单体到微服务的演变主要有一下的变化：
首先微服务的调用链路发生了变化，以前单体的话就是A调B就结束了，现在基本上调用的深度非常的深，A调B调C多层，变化就是说进行微服务的架构的一个改进，必然会新增一些依赖，一些中间件的依赖，比如说新增注册配置中心，还有一些MSE 一些框架 Dubbo、spring-Cloud，再来一些技术指向的一些依赖，第三个的话就是除了系统上面的指向性的增加，以前还保管了厂商的 Cloud 文章，可能所有的服务都由一个人提供，就不需要去跟多个厂商进行协作，但现在把服务拆分开来之后，可能服务就被分成了多个团体，是一个变化，可以看一下以前有一个很清晰的专业链路：
现在做了微服务的架构之后，它的调用关系和特征就比较复杂，如下图一样，每个点都是一个调用点：
这些变化也带来一些挑战，主要有一下三点，第一点就是微服务之间的问题，因为定位是非常难的，因为有很多的结点，要定位一个问题，不知道是上游还是下游还是自己本身的问题，用了一些依赖，包括 Dubbo、spring-Cloud，还有一些新的注册中心，这个服务框架的技术部是非常复杂的，对开发的要求非常的高，也有能够去了解这些指向才能很好的去定位一个问题，这些问题可以很快的发现，以前的话出现一个问题就报警就会很快就知道了，而如果没有反馈，现在线上出了问题可能好几天才知道。
另外一个挑战就是整个节奏都变快了，以前是一个团队，做功能开发依赖到自己的团队，然后现在人家在主持结构的这样的一个变化，这些挑战主要会带来一些具体的问题，举个例子，意思是说用微服务有很多的客户端的版本，现在很多客户端的版本的话，很难知道哪些版本是有风险的，哪些是有性能问题的，很难知道的，第二个在微服务的 RPC 客户端如果调用失败了，不知道这个问题是注册中心的推送问题还是业务侧问题，第三个就是说如果是用了 google 的客户端，去做一个服务的发布，如果这时候如果用户不断地往这个客户端里面去写，写一些垃圾事件，导致一整个客户端的 FullGC 了，如果是一个管理者的话是不是很难知道自己是哪个业务做的一些操作，很难发现是哪个客户端捣乱的，第四个就是大家在做业务大促的时候，经常会有服务的扩容，就是几台扩容机器，扩着扩着可能就发现前面的服务都已经进不了了，就是说扩容的容量到顶了，导致整个业务中心都宕机了，导致服务不可用了，这个过程中怎么能够很好地去管理整个注册配置中心的容量？微服务架构带来很多问题，这些问题有什么好的解决方案？接下来会介绍一下 MSE 的服务技术来把这个问题给它解决。
