Docker搭建Sentinel并将Spring Cloud Alibaba和Sentinel进行整合
Docker搭建Sentinel
Sentinel简介
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel 具有以下特征:
- 丰富的应用场景:Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
- 完备的实时监控:Sentinel 提供实时的监控功能,您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况。
- 广泛的开源生态:Sentinel 提供开箱即用的与其它开源框架/库的整合模块,例如与 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel,同时 Sentinel 提供 Java/Go/C++ 等多语言的原生实现。
- 完善的 SPI 扩展机制:Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑,例如定制规则管理、适配动态数据源等。
Sentinel 的主要特性:
Sentinel 分为两个部分:
- 核心库(Java 客户端)不依赖任何框架/库,能够运行于所有 Java 运行时环境,同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
- 控制台(Dashboard)基于 Spring Boot 开发,打包后可以直接运行,不需要额外的 Tomcat 等应用容器。
Sentinel 基本概念
我们要使用一种技术的时候,首先必须要理解这里面涉及到的一些重要概念,这个是极其重要的,否则就算是做好了,你也不知道怎么使用。
- 资源:
它可以是 Java 应用程序中的任何内容
。例如由应用程序提供的服务,或由应用程序调用的其它应用提供的服务,甚至可以是一段代码。只要通过Sentinel API定义的代码就是资源,能够被Sentinel保护起来。大部分情况下,可以使用方法签名、URL、甚至服务名称作为资源名来表示资源。 - 规则:围绕资源的实时状态设定的规则,
可以包括流量控制规则、熔断降级规则以及系统保护规则,所有规则可以动态实时调整。
- 流量控制:流量控制在网络传输中是一个常用的概念,它用于调整网络包的发送数据。然而,从系统稳定性角度考虑,在处理请求的速度上,也有非常多的讲究。任意时间到来的请求往往是随机不可控的,而系统的处理能力是有限的,我们需要根据系统的处理能力对流量进行控制。Sentinel 作为一个调配器,可以根据需要把随机的请求调整成合适的形状,如下图所示:
- 熔断降级:除了流量控制以外,及时对调用链路中的不稳定因素进行熔断也是 Sentinel 的使命之一。由于调用关系的复杂性,如果调用链路中的某个资源出现了不稳定,可能会导致请求发生堆积,进而导致级联错误。Sentinel和Hystrix的原则是一致的: 当检测到调用链路中某个资源出现不稳定的表现,例如请求响应时间长或异常比例升高的时候,则对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联故障。
搭建Sentinel
查找镜像
执行下面搜索Sentinel镜像命令:
docker search sentinel
拉取镜像
执行下面拉取镜像命令:
docker pull bladex/sentinel-dashboard
查看镜像是否已加载
执行以下命令来查看镜像是否已加载:
docker images | grep sentinel
启动容器
执行以下命令来启动容器:
docker run --restart always --name sentinel -d -p 8858:8858 bladex/sentinel-dashboard:latest
查看容器日志
执行以下命令来查看容器日志:
docker logs -f ea8c13f2897e
启动成功。
在浏览器访问控制台
我们输入URL:http://localhost:8858/#/login
账号:sentinel
密码:sentinel
登录成功之后:
至此,使用docker搭建sentinel已经完成,下面我们进行接入。
Spring Cloud Alibaba整合Sentinel
下面将展示应用如何快速接入Sentinel,同时也可以通过Sentinel控制台实时监控资源以及管理规则。
STEP 1. 在应用中引入Sentinel Jar包
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
注意: ①Sentinel 仅支持 JDK 1.8 或者以上版本;②sentinel-datasource-nacos这个依赖要按需添加,需要将限流规则配置在nacos的就加,否则不加;
STEP 2. 配置文件
设置sentinel控制台地址,配置文件增加如下配置(我们这个写到共享配置里面):
spring:
cloud:
sentinel:
transport:
dashboard: 127.0.0.1:8080
至此,我们接入sentinel就完成了。
设置限流规则
这里默认大家的服务都已经启动完成。流量控制(flow control),其原理是监控应用流量的 QPS 或并发线程数等指标,当达到指定的阈值时对流量进行控制,以避免被瞬时的流量高峰冲垮,从而保障应用的高可用性。然后找到我们要设置流控的资源:
点击+流控:
我们这里设置的流控类型是QPS,阈值设置的是2,意思是当QPS超过2的时候,触发流控规则,点击新增:
我们多次访问这个资源:
Blocked by Sentinel (flow limiting)说明我们设置的流控生效了。到这里,可能有的同学就会问了:不需要我们手动定义资源吗?答案是不需要。加入spring-cloud-starter-alibaba-sentinel依赖之后,所有的 URL 就自动成为 Sentinel 中的埋点资源,可以针对某个 URL 进行流控。
所以我们上面demo里面的controller里面的/hello接口自动就会在簇点链路里面显示。
降级规则
除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块,可能是另外的一个远程服务、数据库或者第三方 API 等。例如,支付的时候,可能需要远程调用银联提供的 API;查询某个商品的价格,可能需要进行数据库查询。然而,这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况,请求的响应时间变长,那么调用服务的方法的响应时间也会变长,线程会产生堆积,最终可能耗尽业务自身的线程池,服务本身也变得不可用。现代微服务架构都是分布式的,由非常多的服务组成。不同服务之间相互调用,组成复杂的调用链路。以上的问题在链路调用中会产生放大的效果。复杂链路上的某一环不稳定,就可能会层层级联,最终导致整个链路都不可用。因此我们需要对不稳定的弱依赖服务调用进行熔断降级,暂时切断不稳定调用,避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段,通常在客户端(调用端)进行配置。
熔断策略
Sentinel 提供以下几种熔断策略:
- 慢调用比例 (SLOW_REQUEST_RATIO):选择以慢调用比例作为阈值,需要设置允许的慢调用 RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用。当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且慢调用的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断,若大于设置的慢调用 RT 则会再次被熔断。
- 异常比例 (ERROR_RATIO):当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且异常的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0],代表 0% - 100%。
- 异常数 (ERROR_COUNT):当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。
注意:异常降级仅针对业务异常,对 Sentinel 限流降级本身的异常(BlockException)不生效。
为了统计异常比例或异常数,需要通过 Tracer.trace(ex) 记录业务异常。
设置降级规则
我们配置的降级规则如下:
意思是:请求的响应时间大于1ms则统计为慢调用。当单位统计时长(statIntervalMs)内请求数目大于5,并且慢调用的比例大于1,则接下来的1s内请求会自动被熔断。经过1s后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断,若大于设置的慢调用 RT 则会再次被熔断。
还是不断的刷新我们刚才的资源:
看看实时监控数据:
簇点链路
再来看看我们的簇点链路:
可以看到我们设置了流控之后,分钟通过数以及分钟拒绝数。
实时监控
然后可以看到我们资源的实时监控信息: