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 请求 拿到 返回值而已。

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

        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-feignartifactId>
            <version>1.4.7.RELEASEversion>
        dependency>
1
2
3
4
5
6

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

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

        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-feignartifactId>
            <version>1.4.7.RELEASEversion>
        dependency>
1
2
3
4
5
6

这些 就是我们 要 拿到的 接口。好，我们把他们 封装成 一个 接口类。放到 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();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

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

---

8.2 服务熔断

分布式系统面临的问题

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

服务雪崩

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

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

我们需要 ： 弃车保帅

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