目录哨兵是什么？Sentinel的历史概述：HistorySentinel分为两部分：两部分基本概念和功能基本概念：主要功能：Sleuth概述zipkin分布式监控客户端基本概念总结什么是Sentinel？分布式系统流量卫士概述随着微服务的普及，服务和服务的稳定性变得越来越重要。Sentinel以流量为切入点，从流量控制、断路器、系统负载保护等多个维度保障服务的稳定性。Sentinel的历史：历史2012年，Sentinel诞生，主要功能是ingress流量控制。2013年到2017年，Sentinel在阿里巴巴集团内部快速发展，成为覆盖所有核心场景的基础技术模块。也因此，Sentinel积累了大量的流量整合场景和生产实践。2018年，Sentinel开源并继续发展。2019年，Sentinel继续探索多语言扩展方向，推出了C++原生版本。同时还针对ServiceMesh场景推出Envoy集群流控支持，解决ServiceMesh架构下多语言限流问题。2020年推出SentinelGo版本，继续向云原生方向演进。Sentinel分为两部分：两部分核心库（Java客户端）不依赖任何框架/库，可以运行在所有Java运行环境中，对Dubbo/SpringCloud等框架也有很好的支持。控制台（Dashboard）基于SpringBoot开发，无需Tomcat等额外的应用容器，打包后即可直接运行。基本概念和作用基本概念：Resource是Sentinel的核心概念。它可以是Java应用程序中的任何东西，例如应用程序提供的服务，或者应用程序调用的另一个应用程序提供的服务，甚至是一段代码。在接下来的文档中，我们将使用资源来描述代码块。只要SentinelAPI定义的代码是资源，就可以被Sentinel保护。在大多数情况下，您可以使用方法签名、URL甚至服务名称作为资源名称来标识资源。我们所说的资源可以是任何东西，一个服务，一个服务中的一个方法，甚至是一段代码。使用Sentinel进行资源保护主要分为几个步骤：定义资源，首先定义可能需要保护的资源，然后配置规则。也可以这样理解，只要我们有资源，我们可以随时灵活定义各种流量控制规则。编码的时候只需要考虑代码是否需要保护，如果需要保护就定义为资源。定义规则检查规则是否有效。围绕资源实时状态设置的规则可以包括流量控制规则、断路器降级规则和系统保护规则。所有规则都可以实时动态调整。主要作用：流量控制什么是流量控制概述流量控制是网络传输中常用的一个概念，用来调整网络数据包的发送数据。但是，从系统稳定性的角度来看，处理请求的速度也有很大的讲究。随时到来的请求往往是随机的、不可控的，系统的处理能力是有限的。我们需要根据系统的处理能力来控制流量。Sentinel作为调整器，可以根据需要将随机请求调整为合适的形状。流控有以下几个角度：资源调用关系，比如资源调用链接，资源与资源之间的关系；运行指标，如QPS、线程数等；控制效果，如直接限流（fastfailure）、冷启动（WarmUp）、均匀排队（queuewaiting）等。Sentinel的设计理念是让你自由选择控制的角度，灵活组合以达到达到预期的效果。QPS流量控制当QPS超过一定阈值时，采取措施进行流量控制。流控的作用包括：直接拒绝、预热、统一排队。直接拒绝（RuleConstant.CONTROL_BEHAVIOR_DEFAULT）直接拒绝方式是默认的流量控制方式。当QPS超过任何一条规则的阈值时，新的请求会被立即拒绝，拒绝方式是抛出FlowException。这种方法适用于系统处理能力确切已知的情况，如WarmUp（预热）WarmUp方法，当通过压力测量确定系统的准确水位时，即预热/冷启动方法。当系统长期处于低水位时，当流量突然增加时，直接将系统拉到高水位可能会使系统瞬间不堪重负。通过“冷启动”，让过往流量缓慢增加，在一定时间内逐渐增加到上限阈值，给冷系统预热时间，避免冷系统不堪重负。时间，也就是让请求匀速通过，对应的是漏桶算法。AssociationRateLimiting概述当关联资源请求达到阈值时，它会限制自己的速率。链路限流概述并发线程数限流用于保护业务线程数不被耗尽。例如，当应用程序所依赖的下游应用程序由于某种原因导致服务不稳定、响应延迟增加时，对于调用方来说，意味着吞吐量下降，线程被占用，极端情况下甚至会耗尽线程池。.为了应对线程占用过多的情况，业界有隔离的解决方案，比如通过不同的业务逻辑使用不同的线程池来隔离业务本身之间的资源争用（线程池隔离）。这种隔离方案虽然隔离性更好，但是代价是线程太多，线程上下文切换的开销比较大，尤其是对于低延迟的调用。Sentinel当前对并发线程数的限制并不负责创建和管理线程池，只是简单统计当前请求上下文中的线程数。如果超过阈值，新的请求会立即被拒绝，效果类似于信号量隔离。熔断降级概述除了流量控制，Sentinel也是通过在调用链路中熔断不稳定资源来保证高可用的重要措施之一。Sentinelfusedowngrade会在调用链路中某个资源处于不稳定状态（比如调用超时或比值异常升高）时，限制对该资源的调用，从而使请求快速失败，避免影响其他资源。连接错误。当资源降级时，在下一个降级时间窗口内，对资源的调用会自动中断（默认行为是抛出DegradeException）。Sentinel和Hystrix的原理是一样的：当调用链路中某个资源不稳定时，比如异常比例以超时形式增加时，限制对该资源的调用，快速请求失败，避免影响其他资源，最终产生雪崩效应。当前限制退化指标有三个平均响应时间（RT）概述平均响应时间（DEGRADE_GRADE_RT）：当资源的平均响应时间超过阈值（在DegradeRule中计数，单位ms，默认上限为4900ms），资源进入准降解状态。如果1秒内有5个请求继续进入，并且他们的RT继续超过这个阈值，那么在下一个时间窗口（DegradeRule中的timeWindow，以s为单位）内，调用该方法会自动返回（抛出DegradeException）。下一个时间窗口到来时，再放入5个请求，重复上面的判断。异常比率概述异常比率（DEGRADE_GRADE_EXCEPTION_RATIO）：当资源每秒请求数>=5，且每秒异常总数占吞吐量的比率超过阈值（DegradeRule中的count），资源进入降级状态，即在接下来的时间窗口（DegradeRule中的timeWindow，以s为单位）内，对该方法的调用会自动返回。异常值比率的阈值范围是[0.0,1.0]，表示0%-100%。ExceptionCount概述ExceptionCount(DEGRADE_GRADE_EXCEPTION_COUNT)：当过去1分钟的资源异常次数超过阈值时，将进行熔断。系统负载保护规则持久化概述无论是通过硬编码更新规则，还是通过访问SentinelDashboard，在页面上操作更新规则，都有一个问题无法避免，那就是服务后重新启动，规则将丢失。因为规则默认保存在内存中。我们在Dashboard上为客户端配置了规则，并推送给了客户端。此时由于某些因素导致客户端异常，服务不可用。当客户端恢复正常，再次连接到Dashboard时，此时所有的规则都丢失了。我们需要重新配置规则，这绝对不是我们想要的。.Sleuth概述SpringCloudSleuth为springCloud实现了分布式链接跟踪解决方案，大量借鉴了Dapper、Zipkin和HTrace等链接跟踪技术。侦探对大多数用户来说应该是不可见的，你与外部系统的所有交互都应该被自动检测到。您可以简单地捕获日志中的数据，或将其发送到远程收集器服务。随着分布式系统越来越复杂，你的一个请求发送过去，各种微服务之间的跳转可能会导致某天某个请求压力太大，过去一个请求没有响应，而且一个请求继续依赖三四个服务，但是你不知道哪个服务出了问题。这个时候需要跟踪微服务吗？要监控一个请求的发起和服务之间传递的过程，我最好记录下来，记录每一个需要多长时间。一旦出现问题，我们可以有针对性地进行优化。是增加节点，降低压力，还是服务继续拆分，让逻辑更简单？这时候springcloud-sleuth集成的zipkin就可以帮助我们解决这些服务跟踪问题。Zipkin分布式监控客户端概述Zipkin是一个分布式跟踪系统。它有助于收集解决微服务架构中的延迟问题所需的计时数据。它管理此数据的收集和查找。Zipkin的设计基于GoogleDapper论文。向Zipkin报告时间序列数据的应用程序。ZipkinUI还提供了一个依赖关系图，显示每个应用程序传递的跟踪请求数。如果您想解决延迟问题或错误，可以按应用程序、跟踪长度、注释或时间戳过滤或排序所有跟踪。选择跟踪时，您可以看到每个跨度所需的总跟踪时间百分比，从而可以识别有问题的应用程序。通过docker安装dockerrun-d-p9411:9411openzipkin/zipkin通过jar包安装java-jarzipkin-server-*exec.jar包下载地址https://search.maven.org/remo...在浏览器中客户端访问http://localhost:9411基本概念Span基本工作单元。发送远程请求将生成一个跨度。跨度由64位ID唯一标识。跟踪由另一个64位ID表示。span还有其他数据信息，比如摘要、时间戳事件、键值注释（标签）、spanID、progressID（通常是IP地址）。跨度不断启动和停止，同时记录时间信息。当您创建跨度时，您必须在将来的某个时间点停止它。Trace由一系列span组成的树结构。例如：发送一个请求，需要调用多个微服务。每个微服务调用都会生成一个跨度。这些span形成一个traceAnnotationprofile来及时记录一个事件的存在。一些核心注释用于定义请求的开始和结束。cs-ClientSent-客户端发起请求。此注释描述了跨度sr的开始-服务器已接收-服务器收到请求并准备开始处理它。如果用它的sr减去cs时间戳，可以得到网络延时服务器可以获取cr-ClientReceived-表示span结束，客户端成功接收到服务客户端的回复，如果cr减去cs时间戳，可以得到客户端获取a所需的所有时间从服务器回复。例如一个请求如下：使用zipkin跟踪整个请求过程如下：上图展示了一个请求链接，一个链接通过TraceId的唯一标识，Span标识发起的请求信息，并且span是通过parentid关联起来的，如图总结这篇文章就到这里了，希望能给大家带来帮助
