MSE 风险分布管理功能发布（二）| 学习笔记-阿里云开发者社区

开发者学堂课程【MSE风险管理功能发布：MSE 风险分布管理功能发布（二）】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1214/detail/18214

MSE 风险分布管理功能发布

四、如何提前控制风险

首先我们来看架构风险：

（1）注册的配置中心网关、业务系统、干节点都无法高可用；

（2）Nacos,ZK 等注册中心一致性协议对双数节点存在无法选主的问题，写请求不可用

（3）注册中心节点在可用区分部不均，可用区故障可能导致集群不可用

（4）在业务系统没有注册中心的容灾措施，比如没有提供保护服务列表的这个缓存和一些降级的方案，那么在注册中心发生故障的时候业务系统可能也会受到影响。

MSE 可用区的部署的容灾架构是通过三个副本来解决单点的问题，通过多可用区的部署的方式来减少单一可用区不可用的风险带来的影响。集群所依赖的网络还有存储的实力也都是通过多可用区部署的方式来部署的，这就是一个云上服务做高可用容灾的一个典型的一个架构，用户开发者在业务架构做业务架构的时候也可以同样可 follow 这样的模式。

说到业务架构通常一个网和账的一个业务调用的关系里面，会有系统里面一定会有服务消费者和提供者，就是我们说的 consumer& provider。

provider，Consumer 这一侧控制风险的方式：通过推空保护和服务降级的方式来保障这个调用链路的可用，因为consumer 会从制作中心上面去订阅我们 provide 的一个识别列表，那么当出现一些突发情况的时候都有可能会导致这个订阅的识别列表是不完全的或者是空的。在这种情况下 consumer 一侧出现异常。因为在这个这个实例列表在注射中心上面它的更新有一个延时，有一定的稍微空隙，所以就需要一系列的措施来保证它的高可用。

那具体来说, consumer 端的推动保护是：当 provider 端到这个，比如说到 MSE 注射中心的网络出现异常的时候，provider 的的心跳就上不去了，之后在注册中心这一块过一段时间就会把这一批 provider 的心跳过期做下线处理，在 consumer 这一侧它定义到的可能就是一个空的列表。那这种情况下如果配置了推空保护，那么当 consumer 收到这个空列表之后就会丢弃这一次异常的更新，仍然保持上一次非空的列表。在这个情况下这个业务的调量流量就能够正常的往上往下走了。这个推空保护的开启的方式非常简单，无论是说在弗里克，阿里巴巴的框架还是 double 框架里面都是一个配置就可以开启。第二个 consumer 有效的措施是服务降级。

服务降级——consumer 端可以通过不同的策略来选择是否将一个调用接口降级，也就是说利用服务自理平台的能力，将一些特定的接口做降级，这个降级是全自动的不需要干预，我们用户在这个页面上去配置具体的降级策略，比如返回的是空值，返回了多少次，有一个阈值，或者是返回一个特定的异常，或者是自定义一些结算数据，或者是通过一些回调来来做降级都是可以的，只要这个配置的策略被触发了，服务治理平台，就会自动的去执行这个预案，并且在 IC 控制台上也能够清楚的观测到服务占据。

在 provider 的这一侧，跑开的在大流量下面可能会出现异常，有的时候服务不是完全不可用的，它与注册中心之间是基于心跳去续约的，这个心跳的线程它是非常清亮的，所以当这个 provider 它的处理能力不足不是完全不可用的情况下,这个心跳它维持的需要的资源还是比较少，它的心跳仍然可以存在，但是服务可能不可用了。比如我们的系统的这个依赖底层的像慢射的比较多，导致 DB 的连接慢了，或者是 tomcat 的线程池被打满了，在这种情况下它是部分不可用的情况如何进行感知呢？可以通过我们的治理平台的离群实例摘除这个功能来保证某一个异常的这个实例能够快速的摘除掉，来保证业务流量的可用。具体实例的这个摘除能够去配一些摘除策略，包括网络异常或者是业务的错误，也可以去配置异常的一个阈值。或者是当这个系统的 QPS 下跌达到一个下限的时候可以按照预定的一个拆除比例去设置，整个降级的过程也是完全自动的，这样能够有效的去缩短这个不可用风险的持续时间。

通常不做任何措施的情况下，这个服务商业线其实都是有损的。当这个 provider 实力在上线或者下线的过程中，它的心跳在注册中心里面需要生效变更的都有一个一定的时间。在这个时间段当中 consumer 端的这个订阅列表更新没有非常及时，在这个下线之后 consumer 流量还会掉到下线的这个 provider，那 provider 的进程已经停掉了。在治理平台当中我们也默认支持了上下线的这个功不是接入之后就默认开启了。在流程这整个应用发布的过程当中，会对这个应用停止部署，回滚，收容重置这些操作的时候，这些无损下线的动作都会自动的去执行，这样不需要侵入任何代码，也不需要多长的改造就可以无感知的去开启，以此够保证流量就是业务下线，就是实力下线的过程中流量不至于损失。

版本风险——任何软件的版本都有一个迭代的过程，不断的去增强功能和优化，那么在这个过程当中也会无意当中引入一些问题，比如在我们发布的客户端版本中存在一些版本，在特定条件下会出现一些比较严重的问题，像Java客户端的1.4.1，这个版本在特定的异常，就是 DNS 查询失败的异常，它的心跳现场是无法自愈的，那么就会影响我们业务的自愈过程，同样的，服务端版本也是，在 MSE 的商业化团队维护的版本当中，无论是注册中心还是网关，都是在不断的去迭代，收敛各种性能问题和功能缺陷。

在一些过去比较旧的一些版本当中也会存在一些比较严重的缺陷，所以我们也会通过发布的风险管理功能，对用户透出信息。下面我分享一个客户真实的案例：一个客户他使用的是 K8S。部署这些业务在底层网络，就的网络发生异常之后，由于这个 DNS 的实力，两个副本都在同一个 MSE 上，这就出现了一个单点的问题，导致集群内的 DNS 就查赵不到，DNS 异常，这个客户端1.7.1的这个版本，DNS 短暂失效了之后，虽然网络恢复了，但是实力的业务这块受到了更大的影响，因为它无法自愈，心跳没办法恢复，因此依赖一个有风险这个客户端版本客户这一侧就导致了 MSE 这个客户端缺陷在失败之后没有补货，心跳续约就出现了问题，大大增加了风险影响的时间。

五、网络评估

容量评估是一个非常复杂的事情，每一年每一个大促，阿里内部人都会做一次全年度的压测，目的就是确保每一个业务、每一个子系统，它的容量都做到了最佳的一个评估的结果，容量风险带来的这个雪崩的效应就像洪水一样，它能够瞬间的摧毁整个系统，所以这个风险是不容小觑的。说它复杂，是因为每一个子系统都有不同的评估指标和标准，比如注册中心关注的是 propose 数量、连接数和吞吐量，配置中心的关注还关注常人群请求的量，网关的可能更加复杂一些，并发连接数，每秒的这个新建的连接数，带宽，正能量，甚至不同条件，它的这个情况也是不同的，例如这个连接是长连接还是短连接，每一个这个 HP 的这个包的大小都不一样，它的这个容量性能表现也是不一样的，以及是否开启 HPS 或者是开启 GZ 的压缩，这些都会影响网关的这个容量。在不同条件下，整体这个容量上限是都是不一样的。业务系统除了评估自身的吞吐能力之外，还需要关注上下游，依赖它的处理能力，所以我们通过全天利用压压测的这种方式来来找到这个过程方法，并把它解决掉。

大促的特点第一个就是瞬时流量非常高，是秒级的一个突发流量，而且通常我们的监控并不能发现这个秒级的这个流量。所以很难通过监控的一些措施做到这种应急的响应，所以我们一般是通过预留水位，来应对一些就是可能的一些网络攻击；或者做限流的过载保护，来保护我们这个大部分流量是可用的，超出这个容量上限之外的流量丢弃掉，这样的话也能够做到，就是把风险的影响降到最低。

第二个特点是大会有热点商品，所以在底层业务的这个业务架构里面，他可能会造成一些热点的问题，比如底层如果做分库分表的话可能分给一个特定的库，这个库它的水位就会比较高，所以在网关这个可以来做的，就是网关可以提前把小流量，将这些对热点的商品做一些这种缓存的一些处理，这样的话不至于流量能透到透到底层去。

第三个特点是保障整个核心电路，因为大促期间一些不是主电路的功能比如一些锦上添花的功能是可以在网关这一侧直接降级的，这样也避免一些不必要的流量打到业务系统上，举一个体会的比较深的一个例子：因为疫情，每一个学校都是通过钉钉在家上网课，为了保障视频链路的流畅，所有的跟这个视频无关的一些功能就会被就被降级掉，比如一些表情标签、点赞这些功能，因为一般人不会因为不能点赞去抱怨这个功能异常而产生一些舆情，所以这个降级也是合理风险。

开源产品总是会时不时爆出一些安全漏洞，但是一般开发者就是客户这一侧很难去实时的关注到一些漏洞的信息，无论是产品自身也好，还是第三方的一些依赖的漏洞也好。我们都很难及时的去更新，另外我们 MSE 目前所已经具备了比较高的一个安全能力。很多客户，就是为了调试方便的，在这个助费中心公网的这个 Endpoint 上面就没有设置ACL 就没有设置这个防控，那么很容易就被攻击的。所以我们也建议就是大家自查一下有没有将这个 ACL 版名单这个功能开启。网关这块我们还获得了新东院的安全评级认证，拿到这个证书的厂商应该不多，而且网关还支持了 WAF 的防护能力，能够做流量清洗。

这一次MSE发布的风险管理功能目的是让开发者能够简单高效的去识别和控制风险，给大家一个MSE产品相关的风险控制的最佳时间指导。

过去风险的识别都是依赖人工感知的，甚至有些滞后，到了风险发生的时候再采取措施就为时已晚。现在MSE相关的产品都已经能够做到系统自动化去识别风险信息，并且能够主动推送到使用产品的负责人，这两周有一些用户应该已经收到我们发出的风险预定的信息了，已经完成了风险识别透出诊断链路的整体的一个建设，那么后续还会不断建设完善更多的诊断方式。把诊断工具和流程不断的起来，发现更多的一些风险，增加风险的这个识别能力。未来还会探索风险治愈能力建设，希望把一些明确的一些风险问题能够做到自愈，让用户不需要感知风险收敛的过程，例如会推出我们会感知容量的风险，让这个实力能够做自动弹性，并且在可运维的时间内去做风险的自愈操作。另外可能会提供一个用户可以主动订阅的事件中心，这样，能够帮助用户快速的去感知一场事件的发生。

六、MSE 风险管理功能介绍

风险通过风险识别和透出诊断到最终解决，我们我们会通过不同的角度来提供风险的识别能力，比如前面提到的这些风险的类型，架构，安全版本，容量，我们会在这些方面都给用户一些最佳的一些可用的一些建议，给大家做一个功能上的演示：

上图这个页面就是我们实例的一个详情页。是一个 numbers 实例，在 number 实例左侧这个菜单栏中有一个新增的一个风险管理。这个页面我们点开之后，可以看到一个实例，比如说可以看到他的整体的一共有多少个风险，我们给这个实例打上一个分数，右侧是我们实例的这个诊断的一个历史记录，左边是每一个风险具体的一些内容，例如刚才提到的这个高风险，这个客户端版本我们在后台能够自动的检测到使用这个客户端版本是有风险的，会给出一个具体的一个建议链接到我们这个版本相关的一个说明文档。还有一些比如容量的一些相关的风险，比如我们建议容量是1000现在达到2000了，那会建议做扩容，具体的评估方式我们也会给出一个具体的文档，除容量风险之外，还有架构风险以及版本的一些风险，都会在左侧给出相应的建议。