阿里巴巴宣布 Sentinel 开源，进一步完善 Dubbo 生态（附PPT）
Aliware Open Source•深圳站现场
1、当服务量大到一定程度，流量扛不住的时候，该如何处理？
2、应用之间相互依赖，当应用A出现响应时间过长，影响到应用B的响应，进而产生连锁反应影响整个依赖链上的所有应用，该如何处理？
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。Sentinel 作为阿里巴巴“大中台、小前台”架构中的基础模块，覆盖了阿里的所有核心场景，也因此积累了大量的流量归整场景以及生产实践。在近期的Aliware Open Source•深圳站-Apache Dubbo & ApacheRocketMQ开发者沙龙上，阿里巴巴中间件高级技术专家 子矜 宣布将Sentinel 进行开源，并发布了首个社区版本v0.1.0，以下是根据子矜的现场分享所整理，为大家回顾分享中的精彩内容。
分享嘉宾介绍：
林佳梁（子矜），阿里巴巴中间件高级技术专家，参与阿里巴巴多年双十一大促，对流量的管控、高可用架构有着丰富的经验，目前负责流量管控软件Sentinel的开发和商业化。
☞ 公众号后台发送“深圳沙龙PPT”，下载全场PPT。
☞ 公众号后台发送“深圳沙龙视频”，观看全场回顾视频。
Sentinel开源地址：
https://github.com/alibaba/Sentinel
在过去的 10 多年里，阿里巴巴投入了集团大量的精英人力用于提升淘宝、天猫平台服务的稳定性，正是有了多年来上万名阿里技术人才的持续创新和技术沉淀，在一系列秒杀大促中，特别是双11 这样现象级的电商大促中，才打造出了今天大家所看到的可轻松应对双11的平台稳定性体系，包括限流和降级、流量调度、业务开关、容量压测和评估、全链路压测、业务一致性平台等，而Sentinel正是在这种背景下产生的限流降级框架，目前已接入集团几乎所有的核心应用。
➤ 限流：
当我们设计了一个函数，准备上线，这时候这个函数会消耗一些资源，处理上限是1秒服务3000个QPS，但如果实际情况遇到高于3000的QPS该如何解决呢？Sentinel提供了两种流量统计方式，一种是统计并发线程数，另外一种则是统计 QPS，当并发线程数超出某个设定的阀值，新的请求会被立即拒绝，当QPS超出某个设定的阀值，系统可以通过直接拒绝、冷启动、匀速器三种方式来应对，从而起流量控制的作用。
➤ 熔断降级：
接触过Spring Cloud、Service Mesh的同学，都知道熔断降级的概念。服务之间会有相互依赖关系，例如服务A做到了1秒上万个QPS，但这时候服务B并无法满足1秒上万个QPS，那么如何保证服务A在高频调用服务B时，服务B仍能正常工作呢？一种比较常见的情况是，服务A调用服务B时，服务B因无法满足高频调用出现响应时间过长的情况，导致服务A也出现响应过长的情况，进而产生连锁反应影响整个依赖链上的所有应用，这时候就需要熔断和降级的方法。Sentinel通过并发线程数进行限制和响应时间对资源进行降级两种手段来对服务进行熔断或降级。
Aliware Open Source•深圳站花絮
➤ 塑形
通常我们遇到的流量具有随机性、不规则、不受控的特点，但系统的处理能力往往是有限的，我们需要根据系统的处理能力对流量进行塑形，即规则化，从而根据我们的需要来处理流量。Sentinel通过资源的调用关系、运行指标、控制的效果三个维度来对流量进行控制，开发者可以自行灵活组合，从而达到理想的效果。
➤ 系统负载保护
平时系统运行都没问题，但遇到大促的时候，发现机器的load非常高，这时候对系统的负载保护就显得非常重要，以防止雪崩。Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。需要注意的是，Sentinel在系统负载保护方面的判断机制是根据系统能够处理的请求，和允许进来的请求，来做平衡，而不是根据一个间接的指标（系统load）来做限流。因为我们最终追求的目标是在系统不被拖垮的情况下，提高系统的吞吐率，而不是load一定要到低于某个阀值。
程序员gg们和他们的中间件小姐姐
➤ 轻巧
轻巧指的是对性能影响小和对应用零入侵。
限流框架是寄宿在应用上的，这时候要求限流框架不能对系统资源有过多的消耗。就像汽车上的安全气囊如果会耗油、导致汽车跑得慢，这就不是一个好气囊，Sentinel的接入对系统资源的消耗极少。
除了对性能的影响要优化到最低以外，还有一个特征，就是需要保证他对应用的零入侵。零入侵是让开发者几乎意识不到这个框架的存在。如果让开发者一边开发，一边还要想着限流降级，这就非常累了。优秀的限流就像是汽车上的安全气囊，平时系统工作正常的时候我们感受不到他的存在，只有当系统出现无法应对当前流量的时候，才会出现，这就是对应用零入侵的体现，开发者无需关心如何接入流量框架，便可调用服务。
对此，Sentinel通过对主流框架，例如Dubbo、Spring Cloud, grpc等，进行默认适配，只要接入我们的适配器，默认的资源就都有了；如果不是用主流框架，也没有关系，只需要很简单，差不多3步，就可以接入，之后还会提供annotation，让用户更简单的用起来。
➤ 专业
不同的场景下有不同的限流需求。在什么时候减流量，流量减多了影响用户体验、流量减少了影响系统稳定性，陡峭高峰如何限流、销峰填谷如何限流，这里就涉及到限流的算法。不同于 hystrix 只提供一两个维度的限流方式，Sentinel提供了一个灵活的框架，从不同的维度出发，开发者可以根据自身的场景去制定自己的限流策略。
➤ 实时监控
流量具有很强的实时性，之所以需要限流，是因为我们无法对流量的到来作出精确的预判，不然的话我们完全可以通过弹性的计算资源来处理，所以这时候限流框架的实时监控功能就非常重要了。通过Sentinel的实时监控功能，运维人员可以根据实际流量情况，采取不同的措施，限流、降级、塑形、系统保护，所以在我们第一版开源版本中，我们加入了Sentinel的控制台，具备实时监控功能。
认识这位开发者的同学记得到公众号后台给小姐姐留言喔
➤ Dubbo service
我们已经把 Sentinel 的适配器捐给了Dubbo，社区地址：http://dubbo.incubator.apache.org/#!/blog/sentinel-introduction-for-dubbo.md?lang=zh-cn
如果开发者接入了Dubbo Sentinel，就能立即实现实时秒级监控的功能。这个监控提供单机链路维度和单机平铺维度，还提供汇总维度的监控。非常方便。
然后我们再来看Sentinel还带来了什么好处。当我们浏览一件商品时，背后可能应对着上百个服务，例如商品属性、商品库存、个人信息、评价信息、店铺信息、商品优惠、订单信息、交易信息、推荐信息等等，这类场景，我们可以由两个维度来看Sentinel在Dubbo service 中的实践，一个是从服务提供方service provider如何限流，例如在百个服务中要保证交易服务可以正常处理，那就可以通过容量或者并发量来限流。一个是从服务调用方service caller如何限流，则可以通过熔断降级来限流。
➤ RocketMQ客户端 & RocketMQ服务端
图中红色曲线是表示实际的消息流量，红色区域是超出我们处理能力的消息流量，这时候借助Sentinel对流量实施削峰填谷，把红色流量放到系统不太繁忙的时候再来处理，这样既不会丢失流量的请求，也不会对用户的购物体验产生影响。这类处理在电商的订单处理等环节很常见。在RocketMQ的服务端，消息的分发者则可以通过Sentinel匀速的对外发送请求。
这个最佳实践，我们也捐给了Apache RocketMQ，目前正在合并，大家很快就可以看到。
➤ Nacos
Sentinel和Nacos类似，是以Dubbo大生态中的核心组件的身份来对外开源的，目的是帮助开发者获得更完整的分布式服务解决方案。例如当我们限流的流量发生变化的时候，我们需要迅速推规则的时候，Sentinel可以和Nacos相互整合，起到快速操作、快速配送的效果。
Sentinel的理念是无缝对接Dubbo大生态，和Dubbo、Nacos等阿里中间件开源产品紧密结合，支持一键使用，并且全面拥抱开源生态，例如会对grpc ,Rest Service主流框架进行积极适配并开放出来，同时提供一系列API给到开发者，用于定制自己的需求。
今日推文
点击下方图片即可阅读