服务熔断降级 Sentinel(保姆级)

于 2024-09-06 14:13:28 发布
阅读量1.3k 收藏 10
点赞数 19
文章标签： sentinel
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_49425906/article/details/141955488
版权

1：⾼并发带来的问题

        在微服务架构中，我们将业务拆分成⼀个个的服务，服务与服务之间可以相互调⽤，但是由于⽹络原因或者⾃身的原因，服务并不能保证服务的100%可⽤，如果单个服务出现问题，调⽤这个服务就会出现⽹络延迟，此时若有⼤量的⽹络涌⼊，会形成任务堆积，最终导致服务瘫痪。

2：服务器雪崩效应

        在分布式系统中,由于⽹络原因或⾃身的原因,服务⼀般⽆法保证 100% 可⽤。如果⼀个服务出现了问题，调⽤这个服务就会出现线程阻塞的情况，此时若有⼤量的请求涌⼊，就会出现多条线程阻塞等待，进⽽导致服务瘫痪。由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩效应” 。

情景1: 微服务之间相互调⽤,关系复杂,正常情况如下图所示:

情景2：某个时刻，服务A挂了，服务B和服务C依然在调⽤服务A

情景3:由于服务A挂了,导致服务C和服务B⽆法得到服务A的响应,这时候服务C和服务B由于⼤量线程积压,最终导致服务C和服务B挂掉

情景4: 相同道理,由于服务之间有关联，所以会导致整个调⽤链上的所有服务都挂掉.

服务器的雪崩效应其实就是由于某个微⼩的服务挂了,导致整⼀⼤⽚的服务都不可⽤.类似⽣活中的雪崩效应,由于落下的最后⼀⽚雪花引发了雪崩的情况.雪崩发⽣的原因多种多样，有不合理的容量设计，或者是⾼并发下某⼀个⽅法响应变慢，亦或是某台机器的资源耗尽。我们⽆法完全杜绝雪崩源头的发⽣，只有做好⾜够的容错，保证在⼀个服务发⽣问题，不会影响到其它服务的正常运⾏。

3：常⻅容错⽅案

        要防⽌雪崩的扩散，我们就要做好服务的容错，容错说⽩了就是保护⾃⼰不被猪队友拖垮的⼀些措施, 下⾯介绍常⻅的服务容错思路和组件。

常⻅的容错思路

        常⻅的容错思路有隔离、超时、限流、熔断、降级这⼏种，下⾯分别介绍⼀下。

隔离机制: ⽐如服务A内总共有100个线程, 现在服务A可能会调⽤服务B,服务C,服务D.我们在服务A进⾏远程调⽤的时候,给不同的服务分配固定的线程,不会把所有线程都分配给某个微服务. ⽐如调⽤服务B分配30个线程,调⽤服务C分配30个线程，调⽤服务D分配40个线程. 这样进⾏资源的隔离，保证即使下游某个服务挂了，也不⾄于把服务A的线程消耗完。⽐如服务B挂了，这时候最多只会占⽤服务A的30个线程,服务A还有70个线程可以调⽤服务C和服务D.

超时机制: 在上游服务调⽤下游服务的时候，设置⼀个最⼤响应时间，如果超过这个时间，下游未作出反应，就断开请求，释放掉线程

限流机制: 限流就是限制系统的输⼊和输出流量已达到保护系统的⽬的。为了保证系统的稳固运⾏,⼀旦达到的需要限制的阈值,就需要限制流量并采取少量措施以完成限制流量的⽬的。

熔断机制: 在互联⽹系统中，当下游服务因访问压⼒过⼤⽽响应变慢或失败，上游服务为了保护系统整体的可⽤性，可以暂时切断对下游服务的调⽤。这种牺牲局部，保全整体的措施就叫做熔断。

服务熔断⼀般有三种状态：

        熔断关闭状态（Closed）

                服务没有故障时，熔断器所处的状态，对调⽤⽅的调⽤不做任何限制

        熔断开启状态（Open）

                后续对该服务接⼝的调⽤不再经过⽹络，直接执⾏本地的fallback⽅法

        半熔断状态（Half-Open）

                尝试恢复服务调⽤，允许有限的流量调⽤该服务，并监控调⽤成功率。如果成功率达到预期，则说明服务已恢复，进⼊熔断关闭状态；如果成功率仍旧很低，则重新进⼊熔断关闭状态。

降级机制: 降级其实就是为服务提供⼀个兜底⽅案，⼀旦服务⽆法正常调⽤，就使⽤兜底⽅案

4:常⻅的容错组件

Hystrix

        Hystrix是由Netflflix开源的⼀个延迟和容错库，⽤于隔离访问远程系统、服务或者第三⽅库，防⽌级联失败，从⽽提升系统的可⽤性与容错性。

Resilience4J

        Resilicence4J⼀款⾮常轻量、简单，并且⽂档⾮常清晰、丰富的熔断⼯具，这也是Hystrix官⽅推荐的替代产品。不仅如此，Resilicence4j还原⽣⽀持Spring Boot 1.x/2.x，⽽且监控也⽀持和prometheus等多款主流产品进⾏整合。

Sentinel

        Sentinel 是阿⾥巴巴开源的⼀款断路器实现，本身在阿⾥内部已经被⼤规模采⽤，⾮常稳定。

5:Sentinel⼊⻔

什么是Sentinel

        Sentinel (分布式系统的流量防卫兵) 是阿⾥开源的⼀套⽤于服务容错的综合性解决⽅案。它以流量为切⼊点, 从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性

Sentinel 具有以下特征:

        丰富的应⽤场景：Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景, 例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤应⽤等。

        完备的实时监控：Sentinel 提供了实时的监控功能。通过控制台可以看到接⼊应⽤的单台机器秒级数据, 甚⾄ 500 台以下规模的集群的汇总运⾏情况。

        ⼴泛的开源⽣态：Sentinel 提供开箱即⽤的与其它开源框架/库的整合模块, 例如与 Spring Cloud、Dubbo、gRPC 的整合。只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊Sentinel。

Sentinel分为两个部分:

        核⼼库（Java 客户端）不依赖任何框架/库,能够运⾏于所有 Java 运⾏时环境，同时对 Dubbo /Spring Cloud 等框架也有较好的⽀持。

        控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运⾏，不需要额外的 Tomcat 等应⽤容器。

6：微服务集成Sentinel

为微服务集成Sentinel⾮常简单, 只需要加⼊Sentinel的依赖即可

第一步:导入依赖

<!--sentinel组件-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

第二步：安装Sentinel控制台

把他放到一个文件夹里面，然后在该文件夹里启动CMD窗口，运行下面的命令(在百度网盘里)

找一个这样的jar包，因为我的jar也找不到了，所以需要的人只能自己去网上找了，不好意思

# 直接使⽤jar命令启动项⽬(控制台本身是⼀个SpringBoot项⽬)
java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.0.jar

看见这样就是启动好了，然后在网页上localhost:8080 账号密码都是 sentinel

第三步：修改shop-order-server项⽬中的配置⽂件application.yml,新增如下配置:

spring:
    cloud:
        sentinel:
            transport:
                port: 9999 #跟控制台交流的端⼝,随意指定⼀个未使⽤的端⼝即可
                dashboard: localhost:8080 # 指定控制台服务的地址

这个资源名称是只有被请求过了 才会有的 单机阀值 是每秒中可以处理多少个请求，多的请求 他会自动的拒绝 这个单机阀值要写多少呢 这个要在上线之前进行压测 阀值要少于压测的值

流控规则

流量控制，其原理是监控应⽤流量的QPS(每秒查询率) 或并发线程数等指标，当达到指定的阈值时对流量进⾏控制，以避免被瞬时的流量⾼峰冲垮，从⽽保障应⽤的⾼可⽤性。

资源名：唯⼀名称，默认是请求路径，可⾃定义

针对来源：指定对哪个微服务进⾏限流，默认指default，意思是不区分来源，全部限制

阈值类型/单机阈值：

        QPS（每秒请求数量）: 当调⽤该接⼝的QPS达到阈值的时候，进⾏限流

        线程数：当调⽤该接⼝的线程数达到阈值的时候，进⾏限流

是否集群：暂不需要集群

1：流控模式

点击上⾯设置流控规则的编辑按钮，然后在编辑⻚⾯点击⾼级选项，会看到有流控模式⼀栏。

sentinel共有三种流控模式，分别是：

        直接（默认）：接⼝达到限流条件时，开启限流

        关联：当关联的资源达到限流条件时，开启限流 [适合做应⽤让步]

        链路：当从某个接⼝过来的资源达到限流条件时，开启限流

关联流控模式

关联流控模式指的是，当指定接⼝关联的接⼝达到限流条件时，开启对指定接⼝开启限流。

场景:当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。⽐如对数据库同⼀个字段的读操作和写操作存在争抢，读的速度过⾼会影响写得速度，写的速度过⾼会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使⽤关联限流来避免具有关联关系的资源之间过度的争抢

链路流控模式

链路流控模式指的是，当从某个接⼝过来的资源达到限流条件时，开启限流。

        1. 在shop-order-server项⽬的application.yml⽂件中新增如下配置:

spring:
    cloud:
        sentinel:
            web-context-unify: false

        2. 在shop-order-server项⽬中新增TraceServiceImpl.java

@Service
@Slf4j
public class TraceServiceImpl {

    @SentinelResource(value = "tranceService")
    public void tranceService(){
        log.info("调⽤tranceService⽅法");
    }
}

        3. 在shop-order-server项⽬中新增TraceController.java

@RestController
public class TraceController {

    @Autowired
    private TraceServiceImpl traceService;

    @RequestMapping("/trace1")
    public String trace1(){
        traceService.tranceService();
        return "trace1";
    }

    @RequestMapping("/trace2")
    public String trace2(){
        traceService.tranceService();
        return "trace2";
    }
}

        4. 重新启动订单服务并添加链路流控规则

流控效果

        快速失败（默认）: 直接失败，抛出异常，不做任何额外的处理，是最简单的效果

        Warm Up：它从开始阈值到最⼤QPS阈值会有⼀个缓冲阶段，⼀开始的阈值是最⼤QPS阈值的1/3，然后慢慢增⻓，直到最⼤阈值，适⽤于将突然增⼤的流量转换为缓步增⻓的场景。

        排队等待：让请求以均匀的速度通过，单机阈值为每秒通过数量，其余的排队等待； 它还会让设置⼀个超时时间，当请求超过超时间时间还未处理，则会被丢弃。

Sentinel规则-降级

降级规则就是设置当满⾜什么条件的时候，对服务进⾏降级。Sentinel提供了三个衡量条件：

        慢调⽤⽐例: 选择以慢调⽤⽐例作为阈值，需要设置允许的慢调⽤ RT（即最⼤的响应时间），请求的响应时间⼤于该值则统计为慢调⽤。当单位统计时⻓内请求数⽬⼤于设置的最⼩请求数⽬，并且慢调⽤的⽐例⼤于阈值，则接下来的熔断时⻓内请求会⾃动被熔断。经过熔断时⻓后熔断器会进⼊探测恢复状态（HALF-OPEN 状态），若接下来的⼀个请求响应时间⼩于设置的慢调⽤ RT 则结束熔断，若⼤于设置的慢调⽤ RT 则会再次被熔断。

        异常⽐例: 当单位统计时⻓内请求数⽬⼤于设置的最⼩请求数⽬，并且异常的⽐例⼤于阈值，则接下来的熔断时⻓内请求会⾃动被熔断。经过熔断时⻓后熔断器会进⼊探测恢复状态（HALF-OPEN状态），若接下来的⼀个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常⽐率的阈值范围是 [0.0, 1.0] ，代表 0% - 100%。

        异常数：当单位统计时⻓内的异常数⽬超过阈值之后会⾃动进⾏熔断。经过熔断时⻓后熔断器会进⼊探测恢复状态（HALF-OPEN 状态），若接下来的⼀个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。

1 慢调⽤⽐例案例

1. 在shop-order-server项⽬中新增FallBackController.java类,代码如下:

@RestController
@Slf4j
public class FallBackController {
@RequestMapping("/fallBack1")
public String fallBack1(){
try {
log.info("fallBack1执⾏业务逻辑");
//模拟业务耗时
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "fallBack1";
}
}

2. 新增降级规则:

上⾯配置表示，如果在1S之内,有【超过1个的请求】且这些请求中【响应时间>最⼤RT】的【请求数量⽐例>10%】，就会触发熔断，在接下来的10s之内都不会调⽤真实⽅法，直接⾛降级⽅法。

        ⽐如: 最⼤RT=900,⽐例阈值=0.1,熔断时⻓=10,最⼩请求数=10

                 情况1: 1秒内的有20个请求，只有10个请求响应时间>900ms, 那慢调⽤⽐例=0.5，这种情况就会触发熔断

                情况2: 1秒内的有20个请求，只有1个请求响应时间>900ms, 那慢调⽤⽐例=0.05，这种情况不会触发熔断

                情况3: 1秒内的有8个请求，只有6个请求响应时间>900ms, 那慢调⽤⽐例=0.75，这种情况不会触发熔断，因为最⼩请求数这个条件没有满⾜.

注意: 我们做实验的时候把最⼩请求数设置为1，因为在1秒内，⼿动操作很难在1s内发两个请求过去，所以要做出效果,最好把最⼩请求数设置为1。

2 异常⽐例案例

1. 在shop-order-server项⽬的FallBackController.java类新增fallBack2⽅法:

int i=0;
@RequestMapping("/fallBack2")
public String fallBack2(){
log.info("fallBack2执⾏业务逻辑");
//模拟出现异常，异常⽐例为33%
if(++i%3==0){
throw new RuntimeException();
}
return "fallBack2";
}

2. 新增降级规则:

上⾯配置表示，在1s之内，,有【超过3个的请求】，异常⽐例30%的情况下，触发熔断，熔断时⻓为10s.

3 异常数案例

1. 在shop-order-server项⽬的FallBackController.java类新增fallBack3⽅法:

@RequestMapping("/fallBack3")
public String fallBack3(String name){
log.info("fallBack3执⾏业务逻辑");
if("wolfcode".equals(name)){
throw new RuntimeException();
}
return "fallBack3";
}

2. 新增降级规则

上⾯配置表示，在1s之内，,有【超过3个的请求】，请求中超过2个请求出现异常就会触发熔断，熔断时⻓为10s

Sentinel规则-热点

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最⾼的 Top K 数据，并对其访问进⾏限制。⽐如：

        商品 ID 为参数，统计⼀段时间内最常购买的商品 ID 并进⾏限制

        ⽤户 ID 为参数，针对⼀段时间内频繁访问的⽤户 ID 进⾏限制

热点参数限流会统计传⼊参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调

⽤进⾏限流。热点参数限流可以看做是⼀种特殊的流量控制，仅对包含热点参数的资源调⽤⽣效。

1. 在shop-order-server项⽬中新增HotSpotController.java,代码如下:

@RestController
@Slf4j
public class HotSpotController {
@RequestMapping("/hotSpot1")
@SentinelResource(value = "hotSpot1")
public String hotSpot1(Long productId){
log.info("访问编号为:{}的商品",productId);
return "hotSpot1";
}
}

注意:⼀定需要在请求⽅法上贴@SentinelResource直接，否则热点规则⽆效

2. 新增热点规则:

3. 在热点规则中编辑规则,在编辑之前⼀定要先访问⼀下/hotSpot1,不然参数规则⽆法新增.

4. 新增参数规则:

5. 点击保存，可以看到已经新增了参数规则

6:访问http://localhost:8091/hotSpot?productId=1 访问会降级

访问http://localhost:8091/hotSpot?productId=2 访问不会降级

Sentinel规则-授权

        很多时候，我们需要根据调⽤来源来判断该次请求是否允许放⾏，这时候可以使⽤ Sentinel 的来源访问控制（⿊⽩名单控制）的功能。来源访问控制根据资源的请求来源（ origin ）限制资源是否通过，若配置⽩名单则只有请求来源位于⽩名单内时才可通过；若配置⿊名单则请求来源位于⿊名单时不通过，其余的请求通过。

1. 在shop-order-server中新建RequestOriginParserDefinition.java,定义请求来源如何获取

@Component
public class RequestOriginParserDefinition implements RequestOriginParser {
@Override
public String parseOrigin(HttpServletRequest request) {
/**
* 定义从请求的什么地⽅获取来源信息
* ⽐如我们可以要求所有的客户端需要在请求头中携带来源信息
*/
String serviceName = request.getParameter("serviceName");
return serviceName;
}
}

2. 在shop-order-server中新建AuthController.java,代码如下:

@RestController
@Slf4j
public class AuthController {
@RequestMapping("/auth1")
public String auth1(String serviceName){
log.info("应⽤:{},访问接⼝",serviceName);
return "auth1";
}
}

3. 新增授权规则

4. 访问测试

访问http://localhost:8091/auth1?serviceName=pc 不能访问

访问http://localhost:8091/auth1?serviceName=app 可以访问

Sentinel规则-系统规则

        系统保护规则是从应⽤级别的⼊⼝流量进⾏控制，从单台机器的 load、CPU 使⽤率、平均 RT、⼊⼝QPS 和并发线程数等⼏个维度监控应⽤指标，让系统尽可能跑在最⼤吞吐量的同时保证系统整体的稳定性。

        

        系统保护规则是应⽤整体维度的，⽽不是资源维度的，并且仅对⼊⼝流量⽣效。⼊⼝流量指的是进⼊应⽤的流量（ EntryType.IN ），⽐如 Web 服务或 Dubbo服务端接收的请求，都属于⼊⼝流量。

系统规则⽀持以下的模式：

        Load ⾃适应（仅对 Linux/Unix-like 机器⽣效）：系统的 load1 作为启发指标，进⾏⾃适应系统保护。当系统 load1 超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护（BBR 阶段）。系统容量由系统的 maxQps * minRt 估算得出。设定参考值⼀般是 CPUcores * 2.5 。

        CPU usage（1.5.0+ 版本）：当系统 CPU 使⽤率超过阈值即触发系统保护（取值范围 0.0-1.0），⽐较灵敏。

        平均 RT：当单台机器上所有⼊⼝流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。

        并发线程数：当单台机器上所有⼊⼝流量的并发线程数达到阈值即触发系统保护。⼊⼝ QPS：当单台机器上所有⼊⼝流量的 QPS 达到阈值即触发系统保护。

Sentinel ⾃定义异常返回

当前⾯设定的规则没有满⾜是，我们可以⾃定义异常返回.

        FlowException 限流异常

        DegradeException 降级异常

        ParamFlowException 参数限流异常

        AuthorityException 授权异常

        SystemBlockException 系统负载异常

在shop-order-server项⽬中定义异常返回处理类

@Component
public class ExceptionHandlerPage implements BlockExceptionHandler {
@Override
public void handle(HttpServletRequest request, HttpServletResponse
response, BlockException e) throws Exception {
response.setContentType("application/json;charset=utf-8");
ResultData data = null;
if (e instanceof FlowException) {
data = new ResultData(-1, "接⼝被限流了");
} else if (e instanceof DegradeException) {
data = new ResultData(-2, "接⼝被降级了");
}else if (e instanceof ParamFlowException) {
data = new ResultData(-3, "参数限流异常");
}else if (e instanceof AuthorityException) {
data = new ResultData(-4, "授权异常");
}else if (e instanceof SystemBlockException) {
data = new ResultData(-5, "接⼝被降级了...");
}
response.getWriter().write(JSON.toJSONString(data));
}
}
@Data
@AllArgsConstructor//全参构造
@NoArgsConstructor//⽆参构造
class ResultData {
private int code;
private String message;
}

@SentinelResource的使⽤

在定义了资源点之后，我们可以通过Dashboard来设置限流和降级策略来对资源点进⾏保护。同时还能通过@SentinelResource来指定出现异常时的处理策略。

@SentinelResource ⽤于定义资源，并提供可选的异常处理和 fallback 配置项。

其主要参数如下:

属性作⽤
value资源名称，必需项（不能为空）
entryTypeentry 类型，可选项（默认为 EntryType.OUT ）
blockHandler / blockHandlerClassblockHandler 对应处理 BlockException 的函数名称，可选项。blockHandler 函数访问范围需要是public ，返回类型需要与原⽅法相匹配，参数类型需要和原⽅法相匹配并且最后加⼀个额外的参数，类型为BlockException 。blockHandler函数默认需要和原⽅法在同⼀个类中。若希望使⽤其他类的函数，则可以指定blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则⽆法解析。
fallback / fallbackClassfallback 函数名称，可选项，⽤于在抛出异常的时候提供fallback 处理逻辑。fallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore ⾥⾯排除掉的异常类型）进⾏处理。fallback 函数签名和位置要求：1. 返回值类型必须与原函数返回值类型⼀致；2.⽅法参数列表需要和原函数⼀致，或者可以额外多⼀个Throwable 类型的参数⽤于接收对应的异常。3.fallback 函数默认需要和原⽅法在同⼀个类中。若希望使⽤其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则⽆法解析。
defaultFallback默认的 fallback 函数名称，可选项，通常⽤于通⽤的fallback 逻辑（即可以⽤于很多服务或⽅法）。默认fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore ⾥⾯排除掉的异常类型）进⾏处理。若同时配置了 fallback 和 defaultFallback，则只有fallback 会⽣效。defaultFallback 函数签名要求：1. 返回值类型必须与原函数返回值类型⼀致；2. ⽅法参数列表需要为空，或者可以额外多⼀个Throwable 类型的参数⽤于接收对应的异常。3. defaultFallback 函数默认需要和原⽅法在同⼀个类中。若希望使⽤其他类的函数，则可以指定 fallbackClass为对应的类的 Class 对象，注意对应的函数必需为 static函数，否则⽆法解析。
exceptionsToIgnore⽤于指定哪些异常被排除掉，不会计⼊异常统计中，也不会进⼊ fallback 逻辑中，⽽是会原样抛出。

 定义限流和降级后的处理⽅法

        直接将限流和降级⽅法定义在⽅法中

@RestController
@Slf4j
public class AnnoController {
@RequestMapping("/anno1")
@SentinelResource(value = "anno1",
blockHandler="anno1BlockHandler",
fallback = "anno1Fallback"
)
public String anno1(String name){
if("wolfcode".equals(name)){
throw new RuntimeException();
}
return "anno1";
}
public String anno1BlockHandler(String name,BlockException ex){
log.error("{}", ex);
return "接⼝被限流或者降级了";
}
//Throwable时进⼊的⽅法
public String anno1Fallback(String name,Throwable throwable) {
log.error("{}", throwable);
return "接⼝发⽣异常了";
}
}

Feign整合Sentinel

1. 在shop-order-server项⽬的配置⽂件中开启feign对Sentinel的⽀持

171

2. 创建容错类

@Component
public class ProductFeignFallBack implements ProductFeignApi {
@Override
public Product findByPid(Long pid) {
Product product = new Product();
product.setPid(-1L);
product.setPname("兜底数据");
product.setPprice(0.0);
return product;
}
}

3. 在feign接⼝中定义容错类

@FeignClient(name = "product-service",fallback =
ProductFeignFallBack.class)
public interface ProductFeignApi {
@RequestMapping("/product/{pid}")
public Product findByPid(@PathVariable("pid") Long pid);
}

4. 停⽌所有 商品服务,重启 shop-order 服务,访问请求,观察容错效果

可能上⾯的案例并不是特别恰当，我们只是通过案例来演示Feign集成Sentinel实现降级的效果. 接下来我们具体更贴切的案例来讲解Feign降级的作⽤.

⽐如我们在购物的时候，查看商品详情⻚⾯的时候，⾥⾯包含库存信息,商品详情信息,评论信息，这个需求包含的微服务如下:

假设现在评论服务宕机了,那是不是意味⽤户发出查看商品请求也⽆法正常显示了，商品都看不到了，那⽤户也⽆法进⾏下单的操作了. 但是对于⽤户来说，评论看不到并不影响他购物，所以这时候我们应该对评论服务进⾏及·降级处理，返回⼀个兜底数据(空数据)，这样⽤户的查看商品请求能正常显示，只是评论数据看不到⽽已，这样的话，⽤户的下单请求也不会受到影响.

咸鱼的动力
关注
sentinel 熔断降级
weixin_43931625的博客
04-06 5088
sentinel 熔断降级
SpringCloud从0到实战()
weixin_57511142的博客
10-14 283
SpringCloudAlibaba从零到实战保姆级教学
Java小案例-Sentinel的实现原理
weixin_54449574的博客
12-23 1793
通过整篇文章的分析之后，再回头看看Sentinel的简介的内容，其实就能更好地理解Sentinel的定位和功能。Sentinel核心就是一堆统计数据和基于这些统计数据实现的流控和熔断的功能，源码并不复杂，而且Sentinel的代码写得非常好。
服务降级的艺术：Spring Cloud中的策略与实践
最新发布
2401_85761762的博客
08-11 630
在微服务架构中，服务降级是一种必要的容错机制，用于在下游服务不可用或响应时间过长时，保证系统的可用性和稳定性。它通过监控服务调用的失败率，在达到一定的阈值时自动“断开”对服务的调用，防止系统过载。服务降级是指在系统负载过高或服务不可用时，通过牺牲非核心服务或功能，保证核心服务可用性的一种策略。通过上述分析和实践指导，我们可以更深入地理解Spring Cloud中的服务降级策略，并将其应用于实际的微服务架构中，以提升系统的健壮性和用户体验。容错策略通过引入重试机制和备用服务，增加系统对错误的处理能力。
【微服务】服务熔断降级 Sentinel
m0_64210833的博客
03-12 998
jmeter测试高并发带来的问题demo
【微服务】Sentinel（熔断降级，热点限流）
Sun的个人博客
03-29 2493
慢调用的比例达到阈值，QPS大于最小请求数待超过熔断时长后，如果还是满足熔断条件（慢调用的比例达到阈值，QPS大于最小请求数），则会继续进行熔断使用@SentinelResource注解来制定被热点限流的接口以及处理热点限流的接口/*** 测试热点限流* @return*/@SentinelResource(value = "news", blockHandler = "hot") // value为资源名可以任意指定，blockHandler为限流处理。
Sentinel 熔断降级
FAIRYTAIL的博客
09-28 4448
详细资料看官方文档 点此查看 注意我用的是1.7.0版本的Sentinel，和1.8.0以上的还是有区别的，本篇只记录1.7.0版本的使用方式，关于1.8.0及以上的版本下一篇再单独记录。 降级规则 先看下Sentinel降级规则的添加页面： 熔断降级规则（DegradeRule）包含下面几个重要的属性： Field 说明 默认值 resource 资源名，即规则的作用对象 grade 熔断策略，支持慢调用比例/异常比例/异常数策略 慢调用比例 ..
Sentinel熔断降级
liuerchong的博客
07-30 801
Sentinel熔断降级 降级策略 我们通常用以下几种方式来衡量资源是否处于稳定的状态： 平均响应时间 (DEGRADE_GRADE_RT)：当资源的平均响应时间超过阈值（DegradeRule 中的 count，以 ms 为单位）之后，资源进入准降级状态。接下来如果持续进入 5 个请求，它们的 RT 都持续超过这个阈值，那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回（抛出 DegradeException）。注意 Senti
若依框架（RuoYi-Cloud 微服务版本）
08-30
它整合了Spring Cloud的核心功能与阿里巴巴中间件产品的能力，如Nacos用于服务发现和服务配置管理、Sentinel用于流量控制与熔断降级等，使得开发者能够更加专注于业务逻辑的实现而不用担心复杂的微服务架构问题。...
干货|如何步入Service Mesh微服务架构时代
03-19 810
今天要和大家分享的是关于新一代微服务架构——Service Mesh的具体玩法！在微服务架构盛行的今天，作为一名互联网技术从业人员，对于微服务的概念相信大家都已经耳熟能详了！而至于像Spring Cloud这样的微服务框架，因为大部分互联网公司都在此基础上构建过第一代微服务体系，所以对于做Java 的同学来说，Spring Cloud微服务体系应该是非常熟悉了！ 这里并不是说其他语言栈就没有构建微服务体系的框架，例如Go语言也有像Go-Micro这样的微服务框架，只不过目前除了像头条这样重度使用Go语言的.
2022Java经典面试题总结(附问题和答案)
AlanChen的博客
05-20 3940
 Java基础  面向对象 封装：封装的意义，在于明确标识出允许外部使用的所有成员函数和数据项，内部细节对外部调用透明，外部调用无需修改或者关心内部实现 继承：继承基类的方法，并做出自己的改变和/或扩展，子类共性的方法或者属性直接使用父类的，而不需要自己再定义，只需扩展自己个性化的 多态：基于对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同  JDK、JRE、JVM之间的区别 JDK：Java Develpment Kit java 开发工具 JRE：Java Runt
Sentinel架构篇 - 熔断降级
The Secret
03-08 1092
本文解析Sentinel的熔断降级。
【Springcloud】Sentinel熔断和降级
weixin_44823875的博客
09-05 1957
服务的稳定是公司可持续发展的重要基石，随着业务量的快速发展，一些平时正常运行的服务，会出现各种突发状况，而且在分布式系统中，每个服务本身又存在很多不可控的因素，比如线程池处理缓慢，导致请求超时，资源不足，导致请求被拒绝，又甚至直接服务不可用、宕机、数据库挂了、缓存挂了、消息系统挂了…对于一些非核心服务，如果出现大量的异常，可以通过技术手段，对服务进行降级并提供有损服务，保证服务的柔性可用，避免引起雪崩效应。（1）服务熔断。
Sentinel之熔断降级
weixin_30908941的博客
09-10 475
　　除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。Sentinel熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资...
Sentinel服务熔断和降级
Leon_Jinhai_Sun的博客
07-30 4766
Sentinel服务熔断和降级
Spring Cloud构建微服务架构：服务容错保护（Hystrix服务降级）【Dalston版】
weixin_34261739的博客
07-12 134
前言 在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依...
Sentinel的熔断降级
yangkeOK的博客
10-22 167
这里写一个设置资源的规则的两种方式，
微服务熔断降级sentinel
08-31
Sentinel 是由阿里巴巴开源的一款针对微服务架构下的流量控制、熔断降级、系统负载保护等功能提供的解决方案。它可以帮助开发者有效地保护和控制微服务的稳定性和可靠性。 在微服务架构中，不同的服务之间存在着相互调用的关系。当某个服务出现故障或者过载时，如果没有相应的措施进行限流和熔断，会导致故障在整个微服务系统中蔓延，最终导致整个系统不可用。 Sentinel 提供了以下功能来保护微服务系统的稳定性： 1. 流量控制：通过设置 QPS（每秒查询率）等参数，限制对某个接口或服务的访问量，防止过度访问导致系统崩溃。 2. 熔断降级：当某个服务出现异常或过载时，Sentinel 可以自动触发熔断机制，暂时停止对该服务的访问，从而保护整个系统的可用性。 3. 系统负载保护：Sentinel 可以根据系统的负载情况，自动调节流量控制和熔断降级的策略，保证系统在高负载情况下仍然能够正常运行。 总之，Sentinel 是一款强大的微服务流量控制和熔断降级工具，可以帮助开发者提高微服务系统的稳定性和可靠性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

咸鱼的动力

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值