Sentinel

是面向分布式、多语言异构化服务架构的流量治理组件主要以流量为切入点从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。

本篇博客介绍CAP理论微服务中的雪崩问题和Hystix的解决方案然后介绍sentinel阐述流量控制和熔断降级的概念给出了sentinel下载运行的流程以及参数解释。

前言引出一、回顾CAP理论二、微服务中的雪崩问题1.什么是微服务雪崩2.如何解决雪崩问题Hystix线程隔离不重要服务熔断Circuit

Breaker【重要】

三、初识sentinel1.sentinel是啥2.Hystrix

一、回顾CAP理论

①一致性对于客户端的每次读操作要么读到的是最新的数据要么读取失败。

换句话说一致性是站在分布式系统的角度对访问本系统的客户端的一种承诺要么我给您返回一个错误要么我给你返回绝对一致的最新数据不难看出其强调的是数据正确。

②可用性任何客户端的请求都能得到响应数据不会出现响应错误。

换句话说可用性是站在分布式系统的角度对访问本系统的客户的另一种承诺我一定会给您返回数据不会给你返回错误但不保证数据最新强调的是不出错。

③分区容忍性由于分布式系统通过网络进行通信网络是不可靠的。

当任意数量的消息丢失或延迟到达时系统仍会继续提供服务不会挂掉。

换句话说分区容忍性是站在分布式系统的角度对访问本系统的客户端的再一种承诺我会一直运行不管我的内部出现何种数据同步问题强调的是不挂掉。

https://github.com/Netflix/Hystrix/wiki

在分布式环境中许多服务依赖关系中的一些不可避免地会失败。

Hystrix是一个库通过添加延迟容忍和容错逻辑可以帮助您控制这些分布式服务之间的交互。

Hystrix通过隔离服务之间的访问点、停止跨服务的级联故障以及提供后备选项来实现这一点所有这些都提高了系统的整体弹性。

improve

微服务中服务间调用关系错综复杂一个请求可能需要调用多个微服务接口才能实现会形成非常复杂的调用链路

复杂分布式体系结构中的应用程序有几十个依赖项每个依赖项都不可避免地会在某个时刻失败。

如果主机应用程序没有与这些外部故障隔离开来那么它就有被这些故障摧毁的风险。

例如对于一个依赖30个服务的应用程序其中每个服务都有99.99%的正常运行时间您可以期待以下内容

99.99^30

即使所有依赖关系都表现良好如果不对整个系统进行弹性设计数十项服务中每项服务的0.01%停机时间的总影响也可能相当于每月停机数小时。

如图一次业务请求需要调用A、P、H、I四个服务这四个服务又可能调用其它服务。

如果此时某个服务出现异常

在高流量的情况下一个潜在的后端依赖可能会导致所有服务器上的所有资源在几秒钟内饱和。

应用程序中通过网络或进入客户端库可能导致网络请求的每一点都是潜在故障的根源。

比故障更糟糕的是这些应用程序还可能导致服务之间的延迟增加从而备份队列、线程和其他系统资源从而导致系统中更多的级联故障。

例如微服务

发生异常请求阻塞用户不会得到响应则tomcat的这个线程不会释放于是越来越多的用户请求到来越来越多的线程会阻塞

当通过第三方客户端执行网络访问时这些问题会加剧——这是一个“黑匣子”其中的实现细节是隐藏的可以随时更改并且每个客户端库的网络或资源配置不同通常很难监控和更改。

更糟糕的是可传递的依赖关系在没有被应用程序显式调用的情况下执行潜在的昂贵或易出错的网络调用。

网络连接出现故障或降级。

服务和服务器出现故障或速度变慢。

新的库或服务部署会更改行为或性能特征。

客户端库有错误。

所有这些都代表了需要隔离和管理的故障和延迟这样单个故障依赖关系就不会导致整个应用程序或系统瘫痪。

当您使用Hystrix包装每个底层依赖项时上图中所示的体系结构将更改为类似下图。

每个依赖关系都是相互隔离的在延迟发生时可能饱和的资源受到限制并包含在回退逻辑中该逻辑决定在依赖关系中发生任何类型的故障时做出什么响应

2.如何解决雪崩问题Hystix

Pattern和信号量隔离其中最推荐也是最常用的是线程池隔离。

Hystrix

的线程池隔离针对不同的资源分别创建不同的线程池不同服务调用都发生在不同的线程池中在线程池排队、超时等阻塞情况时可以快速失败并可以提供

fallback

机制。

线程池隔离的好处是隔离度比较高可以针对某个资源的线程池去进行处理而不影响其它资源但是代价就是线程上下文切换的

overhead

但是实际情况下线程池隔离并没有带来非常多的好处。

首先就是过多的线程池会非常影响性能。

考虑这样一个场景在

Tomcat

为各个资源创建的线程池总共线程数目会非常多几百个线程这样上下文切换会有非常大的损耗。

另外线程池模式比较彻底的隔离性使得

Hystrix

可以针对不同资源线程池的排队、超时情况分别进行处理但这其实是超时熔断和流量控制要解决的问题如果组件具备了超时熔断和流量控制的能力线程池隔离就显得没有那么必要了。

Hystrix

的信号量隔离限制对某个资源调用的并发数。

这样的隔离非常轻量级仅限制对某个资源调用的并发数而不是显式地去创建线程池所以

overhead

请求并发量大并且耗时长请求耗时长一般是计算量大读数据库采用线程池隔离这样的话可以保证大量的容器线程可用不会由于服务原因一直处于阻塞状态或等待状态快速失败返回。

信号量隔离

请求并发量大并且耗时短请求耗时短可能是计算量小读缓存采用信号量隔离因为这类服务的返回通常会非常快不会占用容器线程太长时间而且也减少了线程切换的一些开销提高了缓存服务的效率。

服务熔断Circuit

Hystrix会对请求情况计数当一定时间内失败请求百分比达到阈值则触发熔断断路器会完全打开。

默认失败比例的阈值是50%请求次数最少不低于20次。

默认是

五秒之内请求20次

Open半开状态open状态不是永久的打开后会进入休眠时间默认是5S。

随后断路器会自动进入半开状态。

此时会释放部分请求通过若这些请求都是健康的则会完全关闭断路器否则继续保持打开再次进行休眠计时

三、初识sentinel

https://github.com/alibaba/Sentinel/wiki/%E4%B8%BB%E9%A1%B5

随着微服务的流行服务和服务之间的稳定性变得越来越重要。

Sentinel

是面向分布式、多语言异构化服务架构的流量治理组件主要以流量为切入点从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。

Sentinel

应用程序中的任何内容例如由应用程序提供的服务或由应用程序调用的其它应用提供的服务甚至可以是一段代码。

在接下来的文档中我们都会用资源来描述代码块。

Sentinel

保护起来。

大部分情况下可以使用方法签名URL甚至服务名称作为资源名来标示资源。

围绕资源的实时状态设定的规则可以包括流量控制规则、熔断降级规则以及系统保护规则。

所有规则可以动态实时调整。

2.Hystrix

SentinelHystrix隔离策略信号量隔离线程池隔离/信号量隔离熔断降级策略基于响应时间或失败比率基于失败比率实时指标实现滑动窗口滑动窗口基于

RxJava规则配置支持多种数据源支持多种数据源扩展性多个扩展点插件的形式基于注解的支持支持支持限流基于

QPS支持基于调用关系的限流有限的支持流量整形支持慢启动、匀速器模式不支持系统负载保护支持不支持控制台开箱即用可配置规则、查看秒级监控、机器发现等不完善常见框架的适配Servlet、Spring

Cloud、Dubbo、gRPC

流量控制在网络传输中是一个常用的概念它用于调整网络包的发送数据。

然而从系统稳定性角度考虑在处理请求的速度上也有非常多的讲究。

任意时间到来的请求往往是随机不可控的而系统的处理能力是有限的。

我们需要根据系统的处理能力对流量进行控制。

Sentinel

作为一个调配器可以根据需要把随机的请求调整成合适的形状如下图所示

资源的调用关系例如资源的调用链路资源和资源之间的关系运行指标例如

QPS、线程池、系统负载等控制的效果例如直接限流、冷启动、排队等。

熔断降级

的使命之一。

由于调用关系的复杂性如果调用链路中的某个资源出现了不稳定可能会导致请求发生堆积进而导致级联错误。

Sentinel

当检测到调用链路中某个资源出现不稳定的表现例如请求响应时间长或异常比例升高的时候则对这个资源的调用进行限制让请求快速失败避免影响到其它的资源而导致级联故障。

Hystrix

资源进行了隔离。

这样做的好处是资源和资源之间做到了最彻底的隔离。

缺点是除了增加了线程切换的成本过多的线程池导致线程数目过多还需要预先给各个资源做线程池大小的分配。

Sentinel

通过限制资源并发线程的数量来减少不稳定资源对其它资源的影响。

这样不但没有线程切换的损耗也不需要您预先分配线程池的大小。

当某个资源出现不稳定的情况下例如响应时间变长对资源的直接影响就是会造成线程数的逐步堆积。

当线程数在特定资源上堆积到一定的数量之后对该资源的新请求就会被拒绝。

堆积的线程完成任务后才开始继续接收请求。

还可以通过响应时间来快速降级不稳定的资源。

当依赖的资源出现响应时间过长后所有对该资源的访问都会被直接拒绝直到过了指定的时间窗口之后才重新恢复。

1.官网下载运行

https://github.com/alibaba/Sentinel/releases

java

-Dcsp.sentinel.dashboard.server192.168.111.130:7777

-Dproject.namesentinel-dashboard

-jar

sentinel-dashboard-1.8.6.jarfirewall-cmd

--zonepublic

-Dproject.namesentinel-dashboard

Sentinel

如果你有多张网卡的话你还需要指定使用哪张网卡IP来接受各个微服务上报的信息

-Dcsp.sentinel.heartbeat.client.ip192.168.xxx.xxx

1.6.0

-Dsentinel.dashboard.auth.usernamesentinel

sentinel

-Dsentinel.dashboard.auth.password123456

sentinel

-Dserver.servlet.session.timeout7200

用于指定