共计 4617 个字符，预计需要花费 12 分钟才能阅读完成。
目录
Sentinel 是什么？
概述
Sentinel 的历史：
历史
Sentinel 分为两个局部:
两局部
基本概念及作用
基本概念：
次要作用：
Sleuth
概述
zipkin 分布式监控客户端
基本概念
总结
Sentinel 是什么？
概述
分布式系统的流量防守兵
随着微服务的风行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量管制、熔断降级零碎负载爱护等多个维度爱护服务的稳定性。
Sentinel 的历史：
历史
2012 年，Sentinel 诞生，次要性能为入口流量管制。
2013-2017 年，Sentinel 在阿里巴巴团体外部迅速倒退，成为根底技术模块，笼罩了所有的外围场景。Sentinel 也因而积攒了大量的流量归整场景以及生产实践。
2018 年，Sentinel 开源，并继续演进。
2019 年，Sentinel 朝着多语言扩大的方向一直摸索，推出 C++ 原生版本，同时针对 Service Mesh 场景也推出了 Envoy 集群流量管制反对，以解决 Service Mesh 架构下多语言限流的问题。
2020 年，推出 Sentinel Go 版本，持续朝着云原生方向演进。
Sentinel 分为两个局部:
两局部
外围库（Java 客户端）不依赖任何框架 / 库，可能运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的反对。
控制台（Dashboard）基于 Spring Boot 开发，打包后能够间接运行，不须要额定的 Tomcat 等利用容器。
基本概念及作用
基本概念：
资源
是 Sentinel 的要害概念。它能够是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它利用提供的服务，甚至能够是一段代码。在接下来的文档中，咱们都会用资源来形容代码块。
只有通过 Sentinel API 定义的代码，就是资源，可能被 Sentinel 爱护起来。大部分状况下，能够应用办法签名，URL，甚至服务名称作为资源名来标示资源。
咱们说的资源，能够是任何货色，服务，服务里的办法，甚至是一段代码。应用 Sentinel 来进行资源爱护，次要分为几个步骤:
定义资源
先把可能须要爱护的资源定义好，之后再配置规定。也能够了解为，只有有了资源，咱们就能够在任何时候灵便地定义各种流量管制规定。在编码的时候，只须要思考这个代码是否须要爱护，如果须要爱护，就将之定义为一个资源。
定义规定
测验规定是否失效
规定
围绕资源的实时状态设定的规定，能够包含流量管制规定、熔断降级规定以及零碎爱护规定。所有规定能够动静实时调整。
次要作用：
流量管制
什么是流量管制
概述
流量管制在网络传输中是一个罕用的概念，它用于调整网络包的发送数据。然而，从零碎稳定性角度思考，在解决申请的速度上，也有十分多的考究。任意工夫到来的申请往往是随机不可控的，而零碎的解决能力是无限的。咱们须要依据零碎的解决能力对流量进行管制。Sentinel 作为一个调配器，能够依据须要把随机的申请调整成适合的形态
流量管制有以下几个角度:
资源的调用关系，例如资源的调用链路，资源和资源之间的关系；
运行指标，例如 QPS、线程数等；
管制的成果，例如间接限流（疾速失败）、冷启动（Warm Up）、匀速排队（排队期待）等。
Sentinel 的设计理念是让您自由选择管制的角度，并进行灵便组合，从而达到想要的成果。
QPS 流量管制
当 QPS 超过某个阈值的时候，则采取措施进行流量管制。流量管制的成果包含以下几种：间接回绝、Warm Up、匀速排队。
间接回绝（RuleConstant.CONTROL_BEHAVIOR_DEFAULT）
间接拒形式是默认的流量管制形式，当 QPS 超过任意规定的阈值后，新的申请就会被立刻回绝，回绝形式为抛出 FlowException。这种形式实用于对系统解决能力确切已知的状况下，比方通过压测确定了零碎的精确水位时
Warm Up（预热）
Warm Up 形式，即预热 / 冷启动形式。当零碎长期处于低水位的状况下，当流量忽然减少时，间接把零碎拉升到高水位可能霎时把零碎压垮。通过 ” 冷启动 ”，让通过的流量迟缓减少，在肯定工夫内逐步减少到阈值下限，给冷零碎一个预热的工夫，防止冷零碎被压垮
匀速排队
匀速排队形式会严格控制申请通过的间隔时间，也即是让申请以平均的速度通过，对应的是漏桶算法。
关联限流
概述
当关联的资源申请达到阈值时，就限流本人。
链路限流
概述
并发线程数限流用于爱护业务线程数不被耗尽。例如，当利用所依赖的上游利用因为某种原因导致服务不稳固、响应提早减少，对于调用者来说，意味着吞吐量降落和更多的线程数占用，极其状况下甚至导致线程池耗尽。为应答太多线程占用的状况，业内有应用隔离的计划，比方通过不同业务逻辑应用不同线程池来隔离业务本身之间的资源争抢（线程池隔离）。这种隔离计划尽管隔离性比拟好，然而代价就是线程数目太多，线程上下文切换的 overhead 比拟大，特地是对低延时的调用有比拟大的影响。Sentinel 并发线程数限流不负责创立和治理线程池，而是简略统计以后申请上下文的线程数目，如果超出阈值，新的申请会被立刻回绝，成果相似于信号量隔离。
熔断降级
概述
Sentinel 除了流量管制以外，对调用链路中不稳固的资源进行熔断降级也是保障高可用的重要措施之一。
Sentinel 熔断降级会在调用链路中某个资源呈现不稳固状态时（例如调用超时或异样比例升高），对这个资源的调用进行限度，让申请疾速失败，防止影响到其它的资源而导致级联谬误。当资源被降级后，在接下来的降级工夫窗口之内，对该资源的调用都主动熔断（默认行为是抛出 DegradeException）。
Sentinel 和 Hystrix 的准则是统一的: 当调用链路中某个资源呈现不稳固，例如，体现为 timeout，异样比例升高的时候，则对这个资源的调用进行限度，并让申请疾速失败，防止影响到其它的资源，最终产生雪崩的成果。
限流降级指标有三个
均匀响应工夫（RT）
概述
均匀响应工夫 (DEGRADE_GRADE_RT)：当资源的均匀响应工夫超过阈值（DegradeRule 中的 count，以 ms 为单位，默认下限是 4900ms）之后，资源进入准降级状态。如果 1s 之内继续进入 5 个申请，它们的 RT 都继续超过这个阈值，那么在接下来的工夫窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个办法的调用都会主动地返回（抛出 DegradeException）。在下一个工夫窗口到来时, 会接着再放入 5 个申请, 再反复下面的判断。
异样比例
概述
异样比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：当资源的每秒申请量 >= 5，且每秒异样总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的工夫窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个办法的调用都会主动地返回。异样比率的阈值范畴是 [0.0, 1.0]，代表 0% – 100%。
异样数
概述
异样数 (DEGRADE_GRADE_EXCEPTION_COUNT)：当资源近 1 分钟的异样数目超过阈值之后会进行熔断。
零碎负载爱护
规定长久化
概述
无论是通过硬编码的形式来更新规定，还是通过接入 Sentinel Dashboard 后，在页面上操作更新规定，都无奈防止一个问题，那就是服务重启后，规定就失落了，因为默认状况下规定是保留在内存中的。
咱们在 Dashboard 上为客户端配置好了规定，并推送给了客户端。这时因为一些因素客户端出现异常，服务不可用了，当客户端恢复正常再次连贯上 Dashboard 后，这时所有的规定都失落了，咱们还须要重新配置一遍规定，这必定不是咱们想要的。
Sleuth
概述
Spring Cloud Sleuth 为 springCloud 实现了一个分布式链路追踪解决方案，大量借鉴了 Dapper，Zipkin 和 HTrace 等链路追踪技术。对于大多数用户而言，Sleuth 应该是不可见的，并且您与内部零碎的所有交互都应主动进行检测。您能够简略地在日志中捕捉数据，也能够将其发送到近程收集器服务。
随着分布式系统越来越简单，你的一个申请发过发过来，各个微服务之间的跳转，有可能某个申请某一天压力太大了，一个申请过来没响应，一个申请上来依赖了三四个服务，然而你去不晓得哪一个服务进去问题，这时候我是不是须要对微服务进行追踪呀？监控一个申请的发动，从服务之间传递之间的过程，我最好记录一下，记录每一个的耗时多久，一旦出了问题，咱们就能够针对性的进行优化，是要减少节点，加重压力，还是服务持续拆分，让逻辑更加简略点呢？这时候 springcloud-sleuth 集成 zipkin 能帮咱们解决这些服务追踪问题。
zipkin 分布式监控客户端
概述
Zipkin 是一种分布式跟踪零碎。它有助于收集解决微服务架构中的提早问题所需的时序数据。它治理这些数据的收集和查找。Zipkin 的设计基于 Google Dapper 论文。应用程序用于向 Zipkin 报告时序数据。Zipkin UI 还提供了一个依赖关系图，显示了每个应用程序通过的跟踪申请数。如果要解决提早问题或谬误，能够依据应用程序，跟踪长度，正文或工夫戳对所有跟踪进行筛选或排序。抉择跟踪后，您能够看到每个跨度所需的总跟踪工夫百分比，从而能够辨认有问题的应用程序。
通过 docker 装置
docker run -d -p 9411:9411 openzipkin/zipkin
通过 jar 包装置
java -jar zipkin-server-*exec.jar
jar 包下载地址
https://search.maven.org/remo…
在浏览器端拜访
http://localhost:9411
基本概念
Span
根本工作单元。发送一个近程申请就会产生一个 span，span 通过一个 64 位 ID 惟一标识，trace 以另一个 64 位 ID 示意，span 还有其余数据信息，比方摘要、工夫戳事件、要害值正文 (tags)、span 的 ID、以及进度 ID(通常是 IP 地址)。span 在一直的启动和进行，同时记录了工夫信息，当你创立了一个 span，你必须在将来的某个时刻进行它。
Trace
一系列 spans 组成的一个树状构造。例如：发送一个申请，须要调用多个微服务，每调用一个微服务都会产生一个 span，这些 span 组成一个 trace
Annotation
简介
用来及时记录一个事件的存在，一些外围 annotations 用来定义一个申请的开始和完结
cs – Client Sent - 客户端发动一个申请，这个 annotion 形容了这个 span 的开始
sr – Server Received - 服务端取得申请并筹备开始解决它，如果将其 sr 减去 cs 工夫戳便可失去网络提早
ss – Server Sent - 注解表明申请解决的实现(当申请返回客户端)，如果 ss 减去 sr 工夫戳便可失去服务端须要的解决申请工夫
cr – Client Received - 表明 span 的完结，客户端胜利接管到服务端的回复，如果 cr 减去 cs 工夫戳便可失去客户端从服务端获取回复的所有所需工夫
例如一个申请如下：
应用 zipkin 跟踪整个申请过程如下：
上图示意一申请链路，一条链路通过 Trace Id 惟一标识，Span 标识发动的申请信息，各 span 通过 parent id 关联起来，如图
总结
本篇文章就到这里了，心愿能给你带来帮忙
