「这是我参与2022首次更文挑战的第18天,活动详情查看:2022首次更文挑战」
SpringCloud 应用笔记
服务熔断Hystrix入门
雪崩效应
在微服务架构中,一个请求需要调用多个服务是非常常见的。但!!
如客户端访问A服务,而A服务需要调用B 服务,B服务需要调用C服务 但!!
- 如果,由于网络原因或者自身的原因:
B服务或者C服务不能及时响应A服 务将处于阻塞状态,直到B服务C服务响应。 - 此时若有大量的请求涌入,容器的线程资源会被消耗完毕
导致服务瘫痪。 - 服务与服务之间的依赖性,故障会传播,造成连锁反应,
会对整个微服务系统造成灾难性的严重后果这就是服务故障的“雪崩”效应。
雪崩是系统中的蝴蝶效应导致其发生的原因多种多样:
- 有不合理的容量设计
- 亦或是某台机器的资源耗尽。
- 或者是高并发下某一个方法响应变慢
- 硬件问题,这感觉只能说是点背了⊙︿⊙
- 缓存击穿,导致调用全部访问某服务,导致down掉
- 我们无法完全杜绝雪崩源头的发生,但是
雪崩的根本原因来源于服务之间的强依赖所以我们可以提前评估,做好:熔断,隔离,限流。避免雪崩的产生~
避免雪崩的产生
服务隔离
- 顾名思义,它是指将系统按照一定的原则划分为若干个服务模块:
各个模块之间相对独立,无强依赖。 - 当有故障发生时
能将问题和影响隔离在某个模块内部而不扩散风险,不波及其它模块,不影响整体的系统服务。
熔断降级
- 熔断这一概念来源于电子工程中的断路器(Circuit Breaker)
电压高~保险丝断~跳闸~保护电器在互联网系统中,当下游服务因访问压力过大而响应变慢或失败上游服务为了保护系统整体的可用性,可以暂时切断对下游服务的调用。 - 在客户端控制对依赖的访问,如果调用的依赖不可用时,则不再调用,
直接返回错误,或者降级处理。所谓降级,就是当某个服务熔断之后,服务器将不再被调用此时客户端可以自己准备一个本地的fallback回调,返回一个缺省值.也可以理解为 兜底fallback回调方法是对你目前请求失效后的一个解决方案: - 开源的库比如
hystrix很好的实现了熔断和降级的功能。 他的主要思想是,设置一些阀值,比如,最大并发数,错误率百分比,熔断尝试恢复时间等。 通过这些阀值来转换熔断器的状态: 1.关闭状态,允许调用依赖2.打开状态,不允许调用依赖,直接返回错误,或者调用fallback3.半开状态,根据熔断尝试恢复时间来开启,允许调用依赖,如果调用成功则关闭失败则继续打开
服务限流
- 限流可以认为服务降级的一种 限流就是限制系统的输入和输出流量已达到保护系统的目的。
- 一般来说系统的吞吐量是可以被测算的
一旦检测达到的限制的阈值,就限制流量访问并采取少量措施以完成限制流量的目的。 - 限制客户端的调用来达到限流的做法是很常见的
比如,我们限制每秒最大处理200个请求,超过个数量直接拒绝请求。 - 推迟解决,拒绝解决,或者者部分拒绝解决等等。
- 常见的算法如令牌桶算法
Hystrix介绍
logo:非洲的一个动物, 豪猪~我也不知道为啥..就很nice~
Hystrix是由Netflflix开源的一个延迟和容错库
用于隔离访问远程系统、服务或者第三方库,防止级联失败: 从而提升系统的可用性与容错性。
- 在分布式系统中,每个服务都可能会调用很多其他服务
被调用的那些服务就是依赖服务,有的时候某些依赖服务出现故障也是很正常的。 - Hystrix可以让我们在分布式系统中对服务间的调用进行控制,加入一些调用延迟或者依赖故障的
容错机制. - Hystrix通过将依赖服务进行资源隔离,进而组织某个依赖服务出现故障的时候
这种故障在整个系统所有的依赖服务调用中进行蔓延时Hystrix还提供故障时的fallback降级机制 总而言之,Hystrix通过这些方法帮助我们提升分布式系统的可用性和稳定性
Hystrix主要通过以下几点实现: 延迟 容错
包裹请求:
- 使用
HystrixCommand包裹对依赖的调用逻辑包裹,使每个命令在独立线程中执行。一般来说是对于经常使用的方法进行包裹~ 不是很长调用的并不需要进行包裹~ 也对 Hystrix 也主要是做熔断的...防止雪崩对于不经常使用的方法也不会崩坏
跳闸机制:
- 当某
包裹服务的错误率超过一定的阈值时, - Hystrix可以
自动或手动跳闸,停止请求:服务一段时间错误率:当请求满足一定的数量默认20 且请求失败比例的大于 50% Hystrix就会使服务暂时的停止...使服务冷静一段时间, 这段时间都是响应一个可正常运行的fallback方法, 并不会让你的程序卡在这儿... 等过一段时间, 又会自动的又将 服务打开~让你进行访问...整个过程都是自动的!
资源隔离:
- Hystrix为每个依赖都维护了一个小型的线程池(或者信号量)
- 如果该线程池已满
发往该依赖的请求就被立即拒绝,而不是排队等待,从而加速失败判定。(也是保护服务正常运行的一种形式...)下面的 Hystrix监控就是靠着这些线程需要进行的操作..
监控:
- Hystrix可以近乎实时地监控运行指标和配置的变化
例如成功、失败、超时、以及被拒绝的请求等。 - 甚至还提供一个图表, 供运维人员可以实时的看图, 就了解了当前程序的状态
回退机制:
- 当请求失败、超时、被拒绝,或当断路器打开时,执行回退逻辑。 回退逻辑由开发人员自行提供,例如返回一个缺省值。
- 自我修复:
断路器打开一段时间后,会自动进入“半开”状态。半开状态: 有可能之后变为打开, 有可能是关闭状态;半开状态对当前情况一种分析,来觉得之后的状态情况!
Rest 实现服务熔断 实战!
ok, 终于经过了上面 乱七八糟,令人头疼的理论终于到了代码了...
- 目前我们简单的了解了:
什么是雪崩熔断降级.. - 接下来就让我们通过 Rest方式实现
处理雪崩的 熔断降级rest 是调用方请求的一种方式...Hystrix 一般对调用方的方法进行包裹监视如果出现问题进行降级fallback处理
在之前项目基础上更改: 不了解同学可以点击这儿!!耐心学习~
公工配置:
严格遵循了SpringCloud的 三板斧原则:依赖 配置 注解
首先还是万变不离其宗的依赖 pom.xml
pom.xml
<!-- hystrix实现服务熔断 -->
<!-- 熔断器 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- SpringCloud 对hystrix 的starter全部依赖集成... -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
如果需要对状态进行实时的监视配置 还需配置.yml
.yml
#不在任何节点写属性,它就是首级...
management:
endpoints:
web:
exposure:
include: hystrix.stream # hystri流文件实时监控的文件
#stream流: 配置这个表示状态信息已流的方式 实时进行记录;
- 这个 .yml不是强求! 如果不需要实时的监控可以不要
- 通过下面的: 接口就可以访问当然
包裹方法的执行状态!http://localhost:对应调用者端口/actuator/hystrix.stream本人这里都是已学习为主的,所以都是localhost本地的ip
主程序类需要提供一个注解:
主程序类, 几乎不要任何的配置!就只要一个注解:
- @EnableCircuitBreaker
表示, 开启Hystrix的熔断降级!
接下来介绍 熔断降级的两种实现~ controller层进行的修改! 在最顶上进行的降级!
默认一个服务降级 @HystrixCommand
- @HystrixCommand声明在一个要
包裹的controller请求方法上! fallbackMethod = "指定的降级方法"并通过 fallbackMethod 属性指定一个降级方法 当原方法出现异常, 则会直接执行降级方法.- 降级方法, 是一个除了方法名以外一切和 包裹方法
一模一样的方法!!参数参数类型返回值..修饰符!类型真的坑我就写错成 int 和 Integer找了半天的错
UserController.Java
//编程控制层,接受请求响应结果
@RestController
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/showUserOrder") //页面请求的方法名,get方式请求!
@HystrixCommand(fallbackMethod = "showUserOrderFallBack") //给方法指定一个局部熔断方法;
public List<Order> showUserOrder(Integer uid){
int num = (int) (Math.random() * 10); //这里为了方便看到效果,本人决定手动随机抛出异常! 70%几率
System.out.println(num);
if (num > 7) {
throw new RuntimeException(); //主动对外抛出异常...
}
return userService.currentUserOrder(uid);
//Service又是通过网络调用 订单模块来响应的结果,因此在此基础上要缺点订单模块是运行中的...
}
//局部熔断器方法...方法名外: 一模一样
public List<Order> showUserOrderFallBack(Integer uid){
//这里主要做的就是对请求的一种处理,方法: 假的数据....
System.out.println("局部熔断方法");
List<Order> list = new ArrayList<>();
list.add(new Order(0, "进入熔断降级方法", 0.0, uid));
return list;
}
}
类全局 服务降级 @DefaultProperties
- @DefaultProperties 一般上面在类上:
- 并通过
defaultFallback = "全局的降级方法"指定全局的降级处理类中任一个报错都会进入该方法 - 与全局不同的是
实现的降级方法不在需要一模一样...因为你也不知道要啥参数 返回值了... 需要注意: 虽然@DefaultProperties在类上声明了还是要给 要降级的方法上声明 @HystrixCommand但是不用在指定降级方法了!!
UserController.Java
//编程控制层,接受请求响应结果
@RestController
@DefaultProperties(defaultFallback = "commonFallBack") //全局熔断器 (如有控制器抛出异常直接进到这个方法)
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/showUserOrder") //页面请求的方法名,get方式请求!
@HystrixCommand//(fallbackMethod = "showUserOrderFallBack") //给方法指定一个局部熔断方法;
public List<Order> showUserOrder(Integer uid){
int num = (int) (Math.random() * 10); //这里为了方便看到效果,本人决定手动随机抛出异常! 70%几率
System.out.println(num);
if (num > 7) {
throw new RuntimeException(); //主动对外抛出异常...
}
return userService.currentUserOrder(uid);
}
// //局部熔断器方法...方法名外: 一模一样
// public List<Order> showUserOrderFallBack(Integer uid){
// //这里主要做的就是对请求的一种处理,方法: 假的数据....
// System.out.println("局部熔断方法");
// List<Order> list = new ArrayList<>();
// list.add(new Order(0, "进入熔断降级方法", 0.0, uid));
// return list;
// }
//全局熔断器方法... 因为是全局的所以参数就不好提供了;
public List<Order> commonFallBack(){
System.out.println("全局熔断方法");
List<Order> list = new ArrayList<>();
list.add(new Order(0, "全局熔断方法", 0.0, 1));
return list;
}
}
总结:
- 三板斧~
- 熔断主要做的是类似
异常处理的, 不一定在调用方写的! pom.xml导入对应依赖- 如果要实时记录数据需要做的
.yml配置 - 主程序的启动注解
@EnableCircuitBreaker - 根据需求场景来决定: 局部/全局降级策略!!!
Hystrix的监控平台
Hystrix 对降级操作提供一个监控器平台
- Hystrix官方还提供了基于图形化的DashBoard(仪表板)监控平台。
- Hystrix仪表板可以显示每个断路器(被@HystrixCommand注解的方法)的状态。
主要作用是:
- 主要作用就是针对上面,
.yml配置的监控文件, 它可以对文件进行监视. - 并产生图形化的页面给开发人员更方便的观看
实时的数据!! 毕竟 没人喜欢一直盯着这个满屏的子 瞅! 😥
搭建 Hystrix的监控平台
ok , 我们又搭建了一个新的模块 hystrix-dashBoard-server
这个监控平台实现的话,特别容易! 就 依赖 配置监控平台端口 启动主程序即可!!
引入依赖!
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>SpringCloudBJ</artifactId>
<groupId>org.example</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>hystrix-dashBoard-server</artifactId>
<dependencies>
<!-- hystrix实现服务熔断 -->
<!-- 熔断器 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- SpringCloud 对hystrix 的starter全部依赖集成... -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
<!-- 仪表盘:等会页面展示需要的依赖: -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>
</dependencies>
</project>
启动端口配置 .yml
application.yml
server:
port: 7003
本人的端口 7003~这个随便搞都行!
主程序启动 监控注解: @EnableHystrixDashboard
MyHystrixDashBoardServer.Java
@SpringBootApplication
@EnableHystrixDashboard
public class MyHystrixDashBoardServer {
public static void main(String[] args) {
SpringApplication.run(MyHystrixDashBoardServer.class, args);
}
}
正常不能在正常的SpringBoot 微服务项目, 就加了一个注解 @EnableHystrixDashboard 启动数据图形化仪表盘
运行 localhost:服务端口/hystrix
这样就表示成功了!!
使用!
再次强调指定要查看的 监视流文件(copy):
http://localhost:被监控的端口/actuator/hystrix.stream ok, 进入监控文件!
需要注意这里
端口状态:
- 熔断器有三个状态 CLOSED 、 OPEN 、 HALF_OPEN 熔断器默认关闭状态
CLOSED,当触发熔断后状态变更为OPEN在等待到指定的时间,Hystrix会放请求检测服务是否开启,这期间熔断器会变为HALF_OPEN半启状态,熔断探测服务可用则继续变更为CLOSED关闭熔断器。 - CLOSED 关闭状态(断路器关闭),所有请求都正常访问。 代理类维护了最近调用失败的次数,如果某次调用失败,则使失败次数加1。 如果最近
失败次数超过了在给定时间内允许失败的阈值,则代理类切换到断开(Open)状态。 此时代理开启了一个超时时钟,当该时钟超过了该时间,则切换到半断开(Half-Open)状态。 该超时时间的设定是给了系统一次机会来修正导致调用失败的错误。 - OPEN 打开状态(断路器打开),所有请求都会被降级。 Hystix会对请求情况计数,当一定时间 内失败请求百分比达到阈值,则触发熔断,断路器会完全关闭。
默认20次 失败率 50%以上
- HALF_OPEN 半开状态,open状态不是永久的,打开后会进入休眠时间
(默认是5S)。随后断路 器会自动进入半开状态。此时会释放1次请求通过,若这个请求是健康的,则会关闭断路器否则 继续保持打开,再次进行5秒休眠计时.
断路器聚合监控Turbine
上面已经通过 Hystrix 实现了, 监视器实时的监控数据, 但只是对于一个请求的使用, 那么如果有很多呢? 我怎么一下子看很多, 开很多的 Hystrix监视页面吗? 一个页面一个? 很显然是不行滴!!
Turbine 汇通 实时流文件...至监控器查看!
修改 hystrix-dashBoard-server 监控平台
因为要给监控器加一个 监视多个的操作,这是要修改 监控平台的 依旧三板斧坚持到底~~
加入新的 Turbine依赖
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>SpringCloudBJ</artifactId>
<groupId>org.example</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>hystrix-dashBoard-server</artifactId>
<dependencies>
<!-- hystrix实现服务熔断 -->
<!-- 熔断器 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- SpringCloud 对hystrix 的starter全部依赖集成... -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
<!-- 仪表盘:等会页面展示需要的依赖: -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>
<!-- 导入turbine所需要的依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-turbine</artifactId>
</dependency>
</dependencies>
</project>
配置.yml 文件
application.yml
server:
port: 7003
spring:
application:
name: my-cloud-hystrix-dashboard
#注册至eureka上
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka/
instance:
prefer-ip-address: true
turbine:
# 要监控的微服务列表,多个用,分隔
app-config: user-server
cluster-name-expression: "'default'"
#因为归根结底,想要通过turbine来实现多服务监控;
#底层是将多个服务模块的流文件写入到一个 turbine的流文件;
#htstrix监视器解析的是 汇总之后的turbine的流文件————实现多文件查看!!
加了一个 注册中心 因为它要去注册中心上去找, 要监控对应的服务... 注册中心可以提供方便的访问!! turbine配置
- 因为归根结底,想要通过turbine来实现多服务监控;
- 底层原理就是将多个服务模块的流文件写入到一个
turbine的流文件; - htstrix监视器解析的是 汇总之后的turbine的流文件————实现多文件查看!!
主程序加 @EnableTurbine
MyHystrixDashBoardServer.Java
@SpringBootApplication
@EnableHystrixDashboard //作为一个独立的监控项目,需要配置启动类,开启HystrixDashboard监控平台
@EnableTurbine //并激活Turbine
public class MyHystrixDashBoardServer {
public static void main(String[] args) {
SpringApplication.run(MyHystrixDashBoardServer.class, args);
}
}
测试:
首先Eureka注册中心上可以看到 已经都在注册中心上了: 可以实现访问了 分布直接查看
实时监控文件的情况可以看到页面是在不停的实时刷新,监测新的数据~ 单文件 http://localhost:6002/actuator/hystrix.stream 汇总文件 http://localhost:7003/turbine.stream 前面端口别在意, 根据自己情况来! 后面的请求路径才是要注意 需要copy的! 查看多文件监视的时候,
使用汇总文件~
Turbine 汇总, 监控器查看:
三板斧!!
- 导入依赖
- yml 配置:
提供注册中心配置,为了更好的去汇总模块的监视文件Turbine根据 , 逗号分隔添加多个要汇总的模块.. - 主程序注解 @EnableTurbine
激活Turbine
Feign实现服务熔断
SpringCloud Fegin默认已为Feign整合了hystrix
- 所以添加Feign依赖后就
不用在添加hystrix依赖
实现:
开始之前首先你要是一个Fegin的环境:
可以参考这里:拉到最后Fegin服务调用 和之前相比加了一个
Fegin服务调用的接口实现, 专门为其做熔断的类 OrderFeginRD
加入Fegin 开启服务熔断的配置:
- 虽然 Fegin 的内部集成了 hystrix的依赖~
不需要加入什么依赖 - 但, 还是要pom.xml 开启属性配置的~
pom.xml
#fegin 就是最顶层!
feign:
hystrix:
enabled: true #开启fegin的熔断
创建一个 FeginRD 熔断包;
定一个一个实现类 实现Fegin服务调用的 提供者provide模块,接口
OrderFeginRD.Java
//把普通pojo实例化到spring容器中,相当于配置文件中的 )
@Component
public class OrderFeginRD implements OrderFeginClient {
@Override
public List<Order> findOrderByUser(Integer uid){
//这里做的就是熔断服务降级的,处理方法...根据需求来呗! 本人就返回一个 List:Order Fegin熔断!
System.out.println("Fegin熔断降级!!");
List<Order> list = new ArrayList<>();
list.add(new Order(1, "Fegin的熔断方法", 0.0, 1));
return list;
}
}
client 包中的接口:
它主要是实现采用 Fegin调用模块, 所引入调用模块 声明的接口 OrderFeginClient.Java
//@FeignClient指定需要调用的微服务名称
@FeignClient(value = "order-server",fallback = OrderFeginRD.class)
public interface OrderFeginClient {
//调用的请求路径,要注意这里尽量要和 提供者的实现方法一模一样包括参数,参数类型!!
@GetMapping("/findOrderByUser/{uid}")
public List<Order> findOrderByUser(@PathVariable("uid") Integer uid);
}
fallback = OrderFeginRD.class 指定当改接口实现, 出现错误进行熔断降级的实现类 OrderFeginRD
最后别忘了主程序的启动注解:@EnableFeignClients
这个应该不会忘, 毕竟Fegin的服务调用,也需要这个注解来实现:@EnableFeignClients 启动Fegin的支持!
Fegin熔断总结:
- 首先在一个Fegin服务调用的环境下
因为Fegin的内部实现了 hystrix 所以不需要在引入什么依赖~ - Fegin的服务调用是创建一个和 调用方的Controller中要掉方法,
一模一样的接口方法!Fegin的底层对其做了实现!给Service直接调用! - 所以, 熔断降级就是实现这个接口, 重写方法();
重写的方法就是后面熔断降级方法 Fallback - 在接口类中:
@FeignClient(value = "order-server",fallback = OrderFeginRD.class)value = "order-server" 引入要调用的模块名~ fallback = "当方法异常,熔断降级的类!"目前这个降级类就是 当然接口的实现类! 因此:Fegin的熔断策略是针对 , 调用方的调用方出现异常, 则执行Fallback的降级方法~
ok, 这就实现了Fegin的熔断, 是不是特别简单!! 说实话把, 难? 不难但是SpringCloud / Boot 的东西:注解/中间件/依赖.... 实在太多了!不费点劲, 可不容易完全搞懂!
Hystrix的替换方案 Sentinel
- 18年底Netflflix官方宣布Hystrix 已经足够稳定,不再积极开发 Hystrix 该项目将处于维护模式。
- 就目前来看Hystrix是比较稳定的,并且Hystrix只是停止开发新的版本, 并不是完全停止维护,Bug什么的依然会维护的。因此
短期内,Hystrix依然是继续使用的。 - 但从长远来看,Hystrix总会达到它的生命周期,那么Spring Cloud生态中是否有替代产品呢?
Sentinel概述
Alibaba Sentinel
- Sentinel 是
阿里巴巴开源的一款断路器实现 目前在Spring Cloud的孵化器项目Spring Cloud Alibaba中的一员 Sentinel本身在阿里内部已经被大规模采用,非常稳定。因此可以作为一个较好的替代品。
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。 Sentinel 以流量为切入点:
从流量控 制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel 特征:
- 丰富的应用场景: Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景:
例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。 - 完备的实时监控: Sentinel 同时提供实时的监控功能。
您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况。 - 广泛的开源生态: Sentinel 提供开箱即用的与其它开源框架/库的整合模块
例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 - Sentinel.完善的 SPI 扩展点 Sentinel 提供简单易用、完善的 SPI 扩展接口。
您可以通过实现扩展接口来快 速地定制逻辑。例如定制规则管理、适配动态数据源等 - Sentinel 的主要特性:
使用 Sentinel 来进行熔断保护,主要分为几个步骤:
- 定义资源 资源:可以是任何东西,一个服务,服务里的方法,甚至是一段代码。
- 定义规则 Sentinel 支持以下几种规则: 流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则和 热点参数规则。 Sentinel 的所有规则都可以在内存态中动态地查询及修改,修改之后立即生效先把可能需要保护的资源定义好,之后再配置规则。 也可以理解为,只要有了资源,我们就可以在任何时候灵活地定义各种流量控制规则。
- 检验规则是否生效 复合规则的则,则生效处理...
开始实现:
这里使用的是 用户模块common_userService:已经采用hystrix 实现了熔断!就不在用Sentinel 处理熔断降级了
- 这样的话,代码几乎没有任何更改!Sentinel 在阿里巴巴的 管理监控服务平台!
- 本次并没有使用 Sentinel 来进行处理:
熔断降级~只是使项目被管理 监控!所以代码不多就导了个 依赖pom 配置.yml!
首先启动:Sentinel中的管理控制台
使用前要确保存在,启动一个:管理控制台
您可以从官方网站中下载最新版本的控制台 jar 包 sentinel-dashboard-1.6.3.jar
在Jar包路径下执行,使用如下命令启动控制台:
java -Dserver.port=10000 -Dcsp.sentinel.dashboard.server=localhost:10000 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.6.3.jar
- 其中: -Dserver.port=10000 用于指定 Sentinel 控制台端口为 10000 如果你的端口不巧被某应用占用了可以更改端口~
上述的两个 10000 更改为你要修改的端口号:xxx - 从 Sentinel 1.6.0 起,Sentinel 控制台引入基本的登录功能,默认用户名和密码都是
sentinel - 启动 Sentinel 控制台需要 JDK 版本为 1.8 及以上版本。
客户端接入控制台, 导入依赖:
给要进行管理的 项目模块导入Sentinel的依赖:pom.xml
<!-- 阿里巴巴 Sentinel所需依赖: -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
引入父工程依赖:pom.xml
<!-- <dependencyManagement></> :结构下,因为是阿里巴巴的依赖,需要引入阿里巴巴的 父依赖! -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>1.5.0.RELEASE</version>
<type>pom</type> <!-- 因为这里是 pom所以是父工程的 -->
<scope>import</scope>
</dependency>
配置启动参数 .yml
application.yml
spring:
application:
name: user-server #服务模块名!
cloud:
sentinel:
transport:
dashboard: http://localhost:1000 #这里设置需要引入,你Sentinel 的路径!
测试
总结:
- Sentinel 是对服务进行监管 控制的平台, 可以对服务实现很多的操作! 管理!
- 首先下载官方的 启动Jar
在目录下通过命令启动 - 父工程 | 要管理的子工程 加入对应的依赖:
- 要管理的子工程:配置.yml配置使:
服务被平台管理!