开发者学堂课程【2022阿里云云原生中间件开发者大会集锦：Sentinel 2.0 ：流量治理全面升级】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1053/detail/15301
Sentinel2.0：流量治理全面升级
内容介绍
一、分享内容介绍与发展历程介绍
二、社区的发展规划与方向
三、Sentinel2.0流量治理方式与社区贡献
一、分享内容介绍与发展历程介绍
今天分享的主题是Sentinel2.0，流量治理全面升级。今天的分享分为四块：
介绍Sentinel项目的一个发展历程以及它未来的一个品牌升级的一个规划。
接下来会分别去介绍一下三层岛社区近期在云原生生态的一些探索，以及流量治理标准化演进相关的一些探索。最后来回顾和展望一下Sentinel的这个社区建设。
首先先来回顾一下Sentinel的一个演进历程。
Sentinel的这个项目其实脱胎于阿里集团内部，在2012年在阿里巴巴集团内部诞生，一开始主要场景是支撑双11的一些性能降级的种稳定性的一些场景，在阿里集团内部迅速发展，成为了一个基础的一个基础模块，覆盖了所有的这个流量稳定性的一个核心场景。
到2018年决定将曾老这一个有空降级的一个中心件正式开源，来为社区提供这种更多的线条降级的一个能力。
其实Sentinel社区从2018年开园，社区就在迅速发展，然后不断的去扩充的这一个，生态和能力，相继扩充了 double的等等的微服务的生态，相继扩充了4门课等等的网关的生态，逐步的成为最受欢迎的一个同类组建。 在19年，开始在多元的生态开始探索，推出了c++的这个原生版本。同时针对service match场景也做了一些尝试，比如说在note1.7.0的版本，结合Java的集群流通的图文server，推出了 n位全局留空 iOS的一个支持，它其实是针对service场景的一些初步的一些探索。
在20年推出了一个重磅的一个go的一个原生版本，这里面会主打一个云原生生态的这么一个演进，并不断与打报告，斗鱼、等等的、社区来进行合作，把购服务以及对应的这些云生基础组建的这么一些生态，来去把这些生态能够去利用上分到的这些能力，你同时真的继续朝着语言声方向进行演进。
在21年会探索这么一些底层相关的这么一些场景，推出了Ross的原生版本，并且基于rust的这个衍生版本，然后对n位的这一个 web example excension集成以及在ETF层进行流控做了这么一些探索，并且取得了一些比较小的一些进展。
二、社区的发展规划与方向
（1）重点发展架构
大家可能都会比较感兴趣的是在今年社区的一个重点规划是怎样的，分到社区的一个发展方向，未来的一个引进的这个形式是怎样的，其实finan的一开始开源的时候，会把它定位为一个留空降级的一个中间件，它其实围绕着这一个流量的这一个角度，从流控熔断、并发隔离，自适应的过载保护以及热点参数，也就是精细化的流控等等的一些能力来帮助大家保障微服务的一个稳定性。
同时在微服务的这一个架构中，也逐渐的意识到就是影响微服务稳定性，影响微服务演进的这么一些条件，它是方方面面的，它不仅是有流控降级等等这些核心能力，它还可能需要去结合服务发现，结合负载均衡，结合jvm结合数、据库等等的这么各种各样的一些能力，来去把真正的一个微服务整条链路来保证它的一个稳定性。
所以决定真正的2.0会做这么一个品牌升级，会把原先流控降级的这么一个品牌升级为流量治理的这么一个大品牌。
（2）发展治理能力
这里面除了之前提到的流控降级等等的这些能力之外，还会在更多的方面来去探索相关的一些治理的一些能力，包括的流量调度与路由的这些场景，可以去针对流量的权重进行调整。可以在负载均衡层针对不同标签的流量进行路由，来达到业务的目的或者是稳定性的目的。 同时在服务容错层面也会持续的去发掘更多的这些场景，同时可以去结合负载均衡服务发现等等的一些能力，来去做这种离群，实力调度等等的这么一些更多的这些场景，会把这些场景都抽到分到2.0流量治理这个大品牌里边去。但同时会发现，标准化也是未来云云生发展的一个重要路径。阿里最近也重磅开源了open circle标准化的这么一个项目。
其实在3-2.0中，会和open circle形成一个紧密结合的一个关系，会基于流量治理的一些能力，会抽出一些通用的标准放在open circle中，作为一个标准规范，分了里面则是作为一个核心的标准实现，同时也不局限于去适配这么一个标准，
期望与更多的公司更多的社区来去共建，把这一个标准做得更大，做成微服务领域的一个通用标准，让所有的框架，所有的生态都可以去完美的去适配这个标准。
这个其实是真正的核心的一个品牌升级的这么一个规划。下面就来看一下在send到的这个2.0的测试，在眼镜中会有哪些东西？首先分到2.0结合刚才的品牌升级，会把它定义为一个流量质疑与自愈的标准实现，这里面会提供流控芙蓉、的量级，流量调度与陆游服务隔离，自适应流量资源等核心的治理能力。同时会结合open circle，推出流量治理的标准规范，然后再与各个社区各个公司来进行合作。
分到作为一个标准实现，同时提供各个框架的一个适配层，期望的一个最终的一个语音原声形态则是说的这一个真听到的SD k就现在的Java Go等等的各种核心的原子能力的一个实现，后面可能还会有agent，再加上一个服务化的一个组件，比如说它会提供一些全局的一些策略，如全局的一些自适应的策略，全局的这种流量控制，也就是大家比较关注的分布式流控，以及这种在全局视角来做服务的这种权重调整，会把它放在一个服务化的一个组件里来去做这件事情，同时也会紧密的和原生的这些生态和k8s等等的这些生态去做结合，可能会有operator等等的一些东西，来去做相关的一些管控操作。
同时也会结合的标准化接口来去对外提供这一些服务。 同时这里边的一个在生态方面，会加强与多语言以及和门市的一些生态的一些建设，尤其是加强go社区的一个建设，加强与ninstitute Sentinel2.0等等这种match社区的一个联动，最终的目的是将的流量治理能力全方位的覆盖到的云原生生态中。
同时也不局限于把的这个流量治理只局限在微服务的这些生态，会扩充这种流浪自己的领域，在网关层、在微服务层、在的数据层、在MAC层都需要有对应的流量治理的标准和实现。 其实也会不断的去扩大在数据层流量治理的一个领域，包括这里边可能会和金斯贝尔等等社区来去做合作，把这些数据库缓存等等的这些相关的这些治理能力。
分库分表，然后读写分离等等这些能力，都会把它纳入到分到流量治理的这么一个能力版图中。
同时结合open circle的这个标准规范，将流量治理相关的这个技术标准化，能够提供这种通用的Crd能力与适配，只需要去通过这些标准的方式来去做配置，即可，而无需去对接的这一个之前的这一些具体的这些定义实现。
刚刚是三的2.0的这么一个流量治理全面升级的这么一个品牌升级的规划。
下面来看一下深圳到社区近期在云原生生态的一些探索。第一个，就是在mercy的多语言流量这里的一个探索，其实早在19年真正的就在1.7.0版本适配了no word的这一个全局流量控制的这么一个标准服务，可以借助signal的这一个标准的图文server，来提供这种全局流量控制的能力，这个其实是可以用到这个模式层。
但这里面它的一个局限就在于这里边的能力会为自身的这一个global iOS的模型的这个局限，它的这一个场景可能只适用于这种每次请求的集群流控，它的这个场景会比较局限，同时性能由于每次请求都会额外的经过一次通关server，它的性能也是有瓶颈的。 同时也在社区关注的enever社区提供这种更好的这么一些扩展方式。比如说enever的这种基于property web examine的这种扩展方式，它可以去借助分到的这个原生实现，比如说Ross版本或者购物版本的这个原生实现，然后去把它做成一个n5位的一个 Web exam里的一个插件，在它的htp一层或者是PC层等等的来去做，流量的治理、流量的拦截，流量的控制。
其实这里边就可以去借助原生的Python的这些能力，把这些能力全面覆盖到的这个 esq noword的这一个实现中。
在去年也做了这么一个基于三到Ross版本的一个web三类的一个插件，它可以为n word的这些htp，流量提供这种原声的流控，熔断、降级等等的这一些能力。
通过这一点，其实无需额外的一些功能的开发工作，只需要去对接它的这个外部family的这一个适配插件，即可把的这一些 s的这些原生能力都给n位加一sq去用。同时借助33~2.0的流量治理的这么一个大品牌升级，未来也会把更多的这一些流量治理流量调度相关的一些能力，去结合到institute加n位的这些mercy生态中，来丰富 mass社区的这么一个流量治理的一个能力。 同时也在去探索这一些更为底层的流量治理的一些实现。
比如说近几年社区中比较流行的 ETF相关的技术，它其实会从内核层会从一个比较底层一个比较初级的一个角度来去做一些控制的一个事情，它可以做到一些前置的流量拦截或者转发等等的这么一些操作，对性能的损耗比较少，同时又是处于一个比较前置的一个状态。这里面其实，的这个Ross社区购社区也在结合APP来做，Sentinel2.0在这个 low level流量治理层面做了一些探索。
目前社区会结合的这一个，曾老的这个ross的版本去抽出流量治理相关的一个插件来去做到深圳到的一些能力，可以去转化到up层来去做。限制同时在epf层，也可以不仅针对的这个kps，不仅针对的这一些调用次数等等的这些维度，也可以去针对的这个流量大小，针对的连接等等等来去做这么一些限制。
其实它的一个范围会更大。目前分到社区，还在做相关的一些探索，也欢迎各位感兴趣的开发者来一起参与到社区去，来一起把相关的能力给共建起来。
（3）流量治理标准化探索
接下来再来介绍一下三个社区在流量治理标准化相关的一个探索。其实之前大家如果有用过center或者了解过send，可能都会知道send会抽出了比较多的规则，比如说流控规则、熔断规则、降级规则、等等的，但其实每个框架都有自己的一些规则与配置的一些定义，比如说在深层里去配了一个限流，可能在官网里面想配一个限流，可能又是另一种写法，在它本cloud里面去配，又是一个写法，在n位里面去配又是一个写法。
这里面会发现的流量治理，生态中其实会缺乏流量治理相关的一个标准的抽象，所以也希望去借助分到已有的这些能力，把它提炼出流量治理领域的一些标准，把它作为open circle里边流量治理标准的重要的一部分。
三、Sentinel2.0流量治理方式与社区贡献
同时Sentinel2.0提供这些标准的实现与适配，这里面其实会有一个简单的抽象，就是会把流量治理相关的规则分为三部分。
第一部分则是说的这个治理的规则针对怎样的一个流量，比如说在参照中熟悉的一个概念叫做资源名，可以最简单的按名称来去做划分，同时针对某一些特定的一些流量比如说针对htb请求。可以说针对包含某个特定的一个请求，或者是URL为怎样的一个请求，或者说甚至是去按流量的这个流向来进行划分。 这个是第一点针对怎样的一个流量。
第二点则是对应怎样的一个流量治理的策略，这个就其实对应到之前讲的几种规则，像流控并发控制熔断等等的这些策略。
第三点则是说流量治理策略触发以后，它是一个怎样的一个 Forbid行为。比如说HP的这个请求它可以返回特定的一个状态码，返回特定的这个返回值， rpc请求可以返回特定的返回值或者异常，甚至是可以说的请求可以在陆游的其他节点中。
通过这三部分的组合，就定义出流量治理中的一个规则。 这样一看就可以把的这一个流量治理的这么一个配置，通过这三部分的一个组合来实现这么一个标准化的这么一个抽象这里面，其实社区目前在做这么一个简单的一个抽象，左边则是刚才讲的第二部分，就是策略的这一部分，左边其实对应两个策略，一个就是一个流控的策略，这个流控策略它的1个策略就是全局每秒钟不超过10个请求量。
下面则是的一个熔断器的一个策略，它会在这一个30秒内请求超过500毫秒的这一个请求会记为慢着用，慢着用的这个比例达到60%的时候，会自动触发熔断，垄断的恢复时长为5秒。
大家可能会关注到这里边可能有一些字段，有一些策略和sent now，目前的一些策略比较类似，其实这里面很多，就是针对当前现有的一些能力做出的一些提炼和抽象，然后右边则是最终的一个流量治理规则的一个组合。这里面其实是一个最简单的一个组合，这里面的target则是直接用了Sentinel2.0特的资质域名的一个概念，当然后面的版本中也会基于CC流量或者是其他IPC协议流量来去抽出这种特定的target，来帮助大家去更好的去定义这一个target。 同时佛拜凯恩省这里边省略则是一个最简单的一种配置，不止量则为默认的一个行为，比如说的这一个针对这个 URL的这个限流则是默认返回，通过这三个要素的一个组合，就可以通过压帽的方式来去配这么一个规则，分到这里面做了哪些适配。
其实Sentinel2.0这里面会有数据源的一个概念，其实的这一个规则的配置，也是一个需要通过数据源机制来去做下发的这么一个机制。
其实分到社区，首先会适配的是基于k8scrd这么一种标准配置方式的这么一个标准适配，可以去通过QQ control来去配这么一个CIT的，也可以在后期通过控制台来去配置这些治理的这些规则，这些规则都会变成cod的方式，通过这一个k8s的APS over，然后增到它会有一个apso的一个数据源来去监听相关CRD的一个变更，转化为真到中相关的这些流量治理的一些规则，再结合分到core里面核心的这一些能力与股价，真正做到的时候，增长的这些治理能力，可以和这个标准的这种配置方式相结合的这么一个作用。
后续默认的这一个版本中就会包含的这一个 CRD方式的这个数据源的一个引入。
其实如果是在的k8s原生的环境中，则只需要去针对简单的去进行配置，比如说配这个，API的这个地址，即可去通过QQ control或者是通过控制台来做到标准方式，CRD方式来去管理流量治理规则的这么一个效果。这个其实就是流量治理的一个标准适配的这么一个动作，未来还会结合更多流量治理的这些能力，包括流量调度路由等等这些能力，抽出更多的这个标准，同时在三道中去进行对应的一个实现。
最后来回顾和展望一下现在的这个社区映射。其实他从2018年至今，已经有超过200位贡献者，然后超过10多位的这个 Commit一起把的这个Sentinel2.0特的这个社区一步步的去做大做强的，社区的能力一步步的做宽。
其实这里边都离不开各位贡献者的一个努力。在这里也感谢各位曾老参与过贡献的的这些开发者以及核心的这一些commit，也欢迎大家未来结合增长2.0流量治理标准升级的一个契机，一起更多的去参与到的这个社区贡献中。
其实参与社区贡献的这个方式会非常简单，假设说咱们是初次参与贡献，其实可以到get up上去挑选这种good first的医术，来去把一些比较简单的这些因素让他去有一个实现，然后再结合的这一个贡献指南去提一个PR，这个其实就是参与社区的一个非常好的一个方式。同时也可以去参与到的这个核心贡献小组中，通过认证任务的这个方式来去挑选自己感兴趣的一些费事，来去实现。
同时也欢迎大家一起来去review社区提到的一个 PR，很多时候不一定大家是一定要去自己提交PR可能是去有一些比较复杂的一些 face，需要大家一起，把这些PR来去梳理好去real好，让这些东西真正可以变成社区可以服用的一些能力。
通过这里面，自己可以得到一些技术的成长，同时社区对应贡献者也有一些对应的一些激励，包括一些小礼品，一些共性的证书等等的，来去让大家能够在社区中真正的有参与感。同时核心贡献者会主动发展为conster能一起来去主导社区的一个演进。
未来三档2.0流量治理的这一个领域，它其实是一个非常大的一个全新的这么一个领域，是需要的这个贡献者一起在社区中一起开疆拓土的。
所以也非常希望各位贡献者，大家一起来去 start hiking，一起去把的这一个流量治理的这个社区去做大做强。
