开发者学堂课程【MSE风险管理功能发布：MSE 风险分布管理功能发布（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1214/detail/18214
MSE 风险分布管理功能发布
内容：
一、微服务高可用如何设计
二、如何提前控制风险
三、风险管理介绍
MSE 高可用方向的重要功能——风险管理的发布。本次分享能够了解到以下知识点和能力：
（1）能够熟悉微服务体系的高朋友应该如何设计；
（2）握如何去控制系统中的风险；
（3）了解到 MSE 的微服引擎，风险管理功能够解决什么风险；
（4）熟悉如何去使用风险管理功能；
（5）了解风险管理更多的高级功能的未来规划
本次分享的内容将分为三个部分：首先我谈一谈微服务体系的高可用如何设计，接着引出一个话题——如何在风险来临之前提前的控制住它；最后详细的介绍 MSE 这一次新发布的重要功能将会如何帮助开发者快速的去识别和治理风险并做一段演示。
一、微服务高可用如何设计
首先看阿里巴巴十几年的大促经验，积累了一套成熟的微服务高可用评估体系，我们现在就以大促的场景为例，来谈一谈怎么样能够做好高可用。
从图中架构上来看内部的电商、物流、文娱这些业务系统都是基于 MSE 微服引擎提供的原声网关和 Nacos 的配置中心来构建一整套微服体系的。基于 arms from transportation 的能力做好了链路的可观测，在底层通过容器化，基于K8S 这一套成熟的调度体系解决了资源利用快速交付和弹性的问题.那么在大促即将到来之前阿里是怎样去做大促的？如何去评估这个系统的高可用？
首先通过上层这个 PDS。提供的全链路压测能力，对整个大数涉及到的所有的业务链路进行端到它的压测，这样能够真实的去模拟大数的流量对整个系统的压力，我们才能够通过 ARMS 能够观测到每一个子系统他们之间的能够验证到我们在大数阶段限流降级的预案是不是是能够准确无误的执行。在峰值之前，我们通过快速弹性将预备的容量能够快速的上限，在峰值之后，我们通过快速的收容将这批业务容器下限。
基于这一套双11的大数实践经验，阿里中基建团队将这一套微服务最佳实践开源并且提供了一整套的完整的商业化解决方案即 MSE 产品，通过这个解决方案来满足外部客户对于高性能，高可用，高集成度的和安全的诉求。
那么一套微服务系统如果从零开始搭建，应该如何去设计保证它的高可用？
用一张简单的图表示一个微服系统的基本架构。微服系统全链路包含网关、注册中心还有业务子系统，任何地方都是牵一发而动全身，一个抖动都有可能会较大的范围的影响，整个系统中每一个业务子系统之间还有复杂的调用关系，有时候甚至是网状。
二、如何识别这个系统中的风险？它们有哪些风险？
从入口的网关来看最典型的问题就是容量不足导致吞吐量下降，表现是用户访问系统出现超时了、页面刷不开、也可能是错配导致流量丢失，用户访问页面找不到打不开，比如，最流行使用的 Linux 没有页面操作的都是黑屏操作，很容易出现漏配或者错配的情况，而且这些配置都是黑屏，缺少一个版本的管理，也无法回滚，非常容易失误，都是靠人为去操作的。注册中心的故障，会导致注册失败，影响大数场景下快速、长期弹性上线或者下线新的容器，都无法注册上来，在服务调用方可能还可能会收到空列表的情况给调用给业务的这个调用带来异常，所以在配置中心出问题的时候，可能也会导致风险预案没有办法下发，可能会导致业务不能够降级，某些功能不能够打开或者关闭。对于一些大数阶段可能要做的一些方案的调整。
再看业务子系统，它可能会更加复杂。可能会出现某个子系统流量出现瓶颈，拖垮整个业务的这个情况导致业务异常，如果缺少观测手段也可能该打的日志没有地方打，无法准确的定位到问题在哪里，这样线上的故障的时间就会不断的延长，这些都需要借助服务治理的能力来解决这些问题。以上情况都是以往大数当中我们遇到的真实的案例，每一个都可用的方案的背后都是有一段血泪史。
不得不承认一个事实——没有任何的系统是100%没有问题的。高可用的架构实际上是面对失败设计，或者说是面对失败风险设计。出现基础设施意外风险最典型的是几年前杭州的某条光缆被地铁施工挖断导致全国的支付宝都用不了，这种风险一旦发生业务是很难承受的，还有比如业务操作系统上面的依赖，比如存储故障、网络抖动或者时间服务不稳定，DNS 故障等等，甚至系统耗死连监控报警都有可能上不来，还有业务系统服务端错误，故障内存泄漏客户端等等问题可能发生。虽然我们不能够避免这些风险的发生，但是可以控制风险——高可用的本质实际上就是控制风险。
三 、控制风险的策略
主要可以分为四个方面：
第一个策略就是缩小风险的影响范围，比如可以通过集群系统这个高可用多副本、多可用区的方式来降低一个可用区或者一个副本故障带来的影响，这样它的风险范围、影响范围就缩小了。
第二，可以通过上下游的依赖，把强依赖改成弱依赖，比如说数据库故障，我们这个请求是不是可以通过缓存来解决，我们将这个数据库做成读，做成弱依赖就能够减小业务的风险。
第三个减少触碰风险的次数，比如做灰度发布，新版本上线其中一部分的节点先发布新的版本做一部分的灰度，或者将客户分为几个部分，比如说10%的客户接收能够返回新的版本，这样去做灰度然后是降级或者限流，把一些有问题的这个系统，能够降低掉风险而不去影响它整体的这个降量。限流也是一样的，在系统出现容量风险的时候我们把一部分的客户的流量限掉，这样不至于影响所有客户的这个所有人调用的这个流量。第二个侧面就是缩短风险发生的这个持续时间——如果我们的系统如果没有观测能力没有监控报警，那么出现问题我们只能通过我们的业务系统面对的客户投诉了什么方式才能够发现我们系统有问题，那么这个风险它的持续发生的时间就会非常长了。我们通过可观测能力能够降低门的这个风险发生的这个时间，缩短风的发生的时间能够快速的去发现现场的问题。第二个紧急预案也是一样的道理，当我们发生风险的时候能快速的去识别这个风险，它涉及到的这个功能模块是哪一个，如果这个风险它影响整个系统，如果把它降级掉就关闭掉那么这个这个异常可能就不会影响整个系统，我们就可以通过一些预案来保证这个风险能够快速的去先执行第三个策略，即减少触控风险的次数，也就是说在一些重要的时间避免去变更，比如通过封网的方式避免变更，那么在这些重要时间，它发生这个风险的概率就大大的下降了，当我们不去动它的时候它不会一般是不会出问题的。
第四是降低风险发生的概率。有一些风险其实是可以避免的，在能够确定知道有一些风险是能够提前识别出来的，去控制它。
