SpringCloud 08 Feign 负载均衡和服务熔断

最新推荐文章于 2024-04-17 12:44:31 发布

牟泉禹[Dark Cat]

最新推荐文章于 2024-04-17 12:44:31 发布

阅读量402

点赞数

分类专栏：学习笔记文章标签： spring cloud 负载均衡 java

BY-牟泉禹/MuQuanyu

本文链接：https://blog.csdn.net/qq_52606908/article/details/126239774

版权

学习笔记专栏收录该内容

387 篇文章 11 订阅

订阅专栏

8.1 Feign 负载均衡

feign 是声明式的 web service 客户端，它让微服务之间的调用变得更加简单了。类似于 controller 调用 service。Spring Cloud 集成了 Ribbon 和 Eureka，可在使用 Feign 时提供负载均衡的 http 客户端。

只需要创建一个接口，然后添加注解即可。

feign，主要是社区太多人都习惯面向接口编程了，所以微服务访问调用的主流就有了两种方式：

微服务名字【ribbon】
接口和注解【feign】

Feign 能干什么？

Feign 旨在使编写 Java Http 客户端变得更容易。
前面在使用 Ribbon + RestTemplate 时，利用 RestTemplate 对 Http 请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处呀！往往一个接口会被多处调用。所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign 在此基础上做了进一步封装，有它来帮助我们定义和实现依赖服务接口的定义。在 Feign 的实现下，我们只需要创建一个接口，并使用注解的方式来配置它（类似于以前 Dao 接口上标注的 Mapper 注解一样，现在是一个微服务接口上面标注一个 Feign 注解就完事了。）这样就能完成对服务提供方的接口绑定，简化了使用 Spring Cloud Ribbon 时，自动封装服务调用客户端的开发量。

说白了就是，Feign 觉得我们不应该通过那种松散的方式去拿到服务，而且整体开发写代码的流程也不符合 RPC 的写法。而 Feign 认为远程调用，就应该跟 RPC 差不多！
比如说我们应该建立一个 服务接口，这个接口可以一一对应上我们应该获取到的服务（这里值得肯定是提供者提供的请求 Controller 那些方法），然后我们直接可以拿这个接口过来去使用！调用里面的方法，而里面的方法实现部分就是通过远程调用填充的。。
但是我们仍要知道它的本质不是 RPC，还是 HTTP + Rest。所以它在设计接收的 service 时，会显得很奇怪。因为我们无法直接拿到方法，只能通过人家提供者的 controller URL 请求拿到返回值而已。

新建springcloud-consumer-dept-feign 并且导入 Feign 的依赖

<!--        feign-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-feign</artifactId>
            <version>1.4.7.RELEASE</version>
        </dependency>

如果我们想要所有的子项目都能拿到这个 通过 Feign 拿到的 Service 那么就把这个 Service 接口写到 API 项目里面

所以 springcloud-api 也需要导入依赖

<!--        feign-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-feign</artifactId>
            <version>1.4.7.RELEASE</version>
        </dependency>

在这里插入图片描述
这些就是我们要拿到的接口。好，我们把他们封装成一个接口类。放到 API 项目里。

package top.muquanyu.springcloud.service;

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import top.muquanyu.springcloud.pojo.Dept;

import java.util.List;

@Component // 先把 这个 接口 注册到 IOC 容器中
@FeignClient(value = "SPRINGCLOUD-PROVIDER-DEPT") // 我们 需要 找到那个 服务叫啥名
public interface DeptClientService {
    
    @PostMapping("/dept/add")
    public boolean addDept(@RequestBody Dept dept);

    @GetMapping("/dept/get/{id}")
    public Dept queryByID(@PathVariable("id") Long id);

    @GetMapping("/dept/list")
    public List<Dept> queryAll();
}

开启 @EnableFeignClients 注解，并且我们要指定扫描的包。

在这里插入图片描述

8.2 服务熔断

分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败！

服务雪崩

多个微服务之间调用的时候，假设微服务A 调用 B 和 C，B 和 C 又调用其他的微服务，这就是诉我诶的扇出，如果扇出的链路上某个微服务的调用想用时间过长或者不可用，对微服务 A 的调用就会占用越来越多的系统资源，占用到了一定的程度后，进而引起系统的崩溃，这就是所谓的 **“雪崩效应” **

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒种内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败。不能取消整个应用程序或系统。

我们需要： 弃车保帅

就是把有问题的那个服务，用备份的服务顶替掉，当然这个备份的服务并没有真实的服务内容！只会反馈一些信息。当这样子做了之后，我们整体还可以正常的运作。这就叫弃车保帅