乐优商城项目---day03-SpringCloud

最新推荐文章于 2022-05-22 17:35:11 发布

程序员DD

最新推荐文章于 2022-05-22 17:35:11 发布

阅读量440

点赞数 1

分类专栏： Java 文章标签： spring java mysql eureka

本文链接：https://blog.csdn.net/zgz102928/article/details/104310544

版权

Java 专栏收录该内容

120 篇文章 42 订阅

订阅专栏

6.负载均衡Ribbon

在刚才的案例中，我们启动了一个itcast-service-provider，然后通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。

但是实际环境中，我们往往会开启很多个itcast-service-provider的集群。此时我们获取的服务列表中就会有多个，到底该访问哪一个呢？

一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。

不过Eureka中已经帮我们集成了负载均衡组件：Ribbon，简单修改代码即可使用。

什么是Ribbon：

在复制一个Provider服务提供者，这里复制的时候可能会出现，读取之前的Yml，导致端口占用的问题，建议复制的时候点一些配置信息，或者等一小会，不然会出现端口冲突的问题。

在启动类的RestTempalte上加入@LoadBlanace的注解

之后就可以将RestTemplate发送的请求更换了，Ribbn可以自动解析服务提供者的列表并读取实例，获取端口号和地址

return   restTemplate.getForObject("http://server-provider/provider/user/"+id,User.class);

编写一个测试方法，看端口的更换

  @Test
   public void test01() {
        for (int i = 0; i < 50; i++) {
            ServiceInstance choose = client.choose("server-provider");
            System.out.println(choose.getHost()+":"+choose.getPort());
        }

发送50次请求可以看到端口时交替更换的

1.Hystrix

1.1.简介

Hystrix,英文意思是豪猪，全身是刺，看起来就不好惹，是一种保护机制。

Hystrix也是Netflix公司的一款组件。

主页：https://github.com/Netflix/Hystrix/

那么Hystix的作用是什么呢？具体要保护什么呢？

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。

1.2.雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。

如果此时，某个服务出现异常：

例如微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。

Hystix解决雪崩问题的手段有两个：

线程隔离
服务熔断

1.3.2.动手实践

1.3.2.1.引入依赖

在服务消费方，调用者添加依赖

     <dependency>
            <groupId>com.netflix.hystrix</groupId>
            <artifactId>hystrix-javanica</artifactId>
            <version>1.5.18</version>
        </dependency>

1.3.2.2.开启熔断在引导类上添加注解

@EnableCircuitBreaker           //开启熔断

这个里面需要注意的时被熔断的方法的方法名和参数列表要和熔断方法保持完全一致，熔断才会生效，所以控制器对应的注解要加上

  @GetMapping("{id}")
    @ResponseBody
    @HystrixCommand(fallbackMethod = "fallbackquery")
    public String findByid(@PathVariable Long id){
       /* List<ServiceInstance> instances = discoveryClient.getInstances("server-provider");
        ServiceInstance serviceInstance = instances.get(0);*/
       // http://localhost:8081/provider/user/30
        return restTemplate.getForObject("http://server-provider/provider/user/"+id,String.class);
    }

编写熔断方法

  public String fallbackquery(Long id){
        return "服务器正忙，请稍后再试试";
    }

完成测试:

1.3.2.5.设置超时

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystix的默认超时时长为1，我们可以通过配置修改这个值：

我们可以通过`hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds`来设置Hystrix超时时间。该配置没有提示。

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms

1.4.服务熔断

1.4.1.熔断原理

熔断器，也叫断路器，其英文单词为：Circuit Breaker

熔断状态机3个状态：

Closed：关闭状态，所有请求都正常访问。
Open：打开状态，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时

2.Feign

在前面的学习中，我们使用了Ribbon的负载均衡功能，大大简化了远程调用时的代码：

String user = this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);

如果就学到这里，你可能以后需要编写类似的大量重复代码，格式基本相同，无非参数不一样。有没有更优雅的方式，来对这些代码再次优化呢？

这就是我们接下来要学的Feign的功能了。

添加依赖，并且在引导类上添加@EnableFeignCliens的注解

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
            <version>2.0.1.RELEASE</version>
        </dependency>

2.2.3.Feign的客户端

在itcast-service-consumer工程中，添加UserClient接口：

@FeignClient("server-provider")
public interface UserClint {

    @RequestMapping("/provider/user/{id}")
    public User findByid(@PathVariable Long id);
}

首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟mybatis的mapper很像
@FeignClient，声明这是一个Feign客户端，类似@Mapper注解。同时通过value属性指定服务名称
接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果

改造原来的调用逻辑，调用UserClient接口：

@RestController
@RequestMapping(value = "/consumer/user")
public class UserController {

    @Autowired
    private UserClint userClient;


    @GetMapping("{id}")
    @ResponseBody
    public User findByid(@PathVariable Long id){
 return userClient.findByid(id);
    }

}

完成测试：

2.4.Hystrix支持

Feign默认也有对Hystrix的集成：

只不过，默认情况下是关闭的。我们需要通过下面的参数来开启：(在itcast-service-consumer工程添加配置内容)

feign:
  hystrix:
    enabled: true # 开启Feign的熔断功能

但是，Feign中的Fallback配置不像hystrix中那样简单了。

1）首先，我们要定义一个类UserClientFallback，实现刚才编写的UserClient，作为fallback的处理类


@Component
public class UserClintFallBack implements UserClint {
    @Override
    public User findByid(Long id) {
        User user = new User();
        user.setPassword("服务器启动错误，请稍后重试");
        return user;
    }
}

2）然后在UserFeignClient中，指定刚才编写的实现类

@FeignClient(value = "server-provider",fallback = UserClintFallBack.class)
public interface UserClint {

    @RequestMapping("/provider/user/{id}")
    public User findByid(@PathVariable Long id);
}

重新测试：

feign
   1.引入openFeign启动器
   2.feign.hystrix.enable=true,开启feign的熔断功能
   3.在引导类上 @EnableFeignClients
   4.创建一个接口，在接口添加@FeignClient(value="服务id", fallback=实现类.class)
   5.在接口中定义一些方法，这些方法的书写方式跟之前controller类似
   6.创建了一个熔断类，实现feign接口，实现对应的方法，这些实现方法就是熔断方法

3.Zuul网关

通过前面的学习，使用Spring Cloud实现微服务的架构基本成型，大致是这样的：

我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载。为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。

在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？

先来说说这样架构需要做的一些事儿以及存在的不足：

破坏了服务无状态特点。

为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。

从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。
无法直接复用既有接口。

当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。

面对类似上面的问题，我们要如何解决呢？答案是：服务网关！

为了解决上面这些问题，我们需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器的服务网关。

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。

3.1.简介

事实上，在微服务架构中，Zuul就是守门的大Boss！一夫当关，万夫莫开！

3.2.Zuul加入后的架构

不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。

3.3.快速入门

3.3.1.新建工程

新建模块创建模块，和之前的操作一样

3.3.3.编写引导类

通过@EnableZuulProxy注解开启Zuul的功能：

@SpringBootApplication
@EnableZuulProxy  //启用Zuul组件
public class CnItcastZuulApplication {

    public static void main(String[] args) {
        SpringApplication.run(CnItcastZuulApplication.class, args);
    }

}

编写配置文件

server:
  port: 8086
spring:
  application:
    name: itcast-zuul
zuul:
  routes:
    server-provider:
      path: /server/**
      url: http://lo

完成测试:

3.4.面向服务的路由

在刚才的路由规则中，我们把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然就不合理了。我们应该根据服务的名称，去Eureka注册中心查找服务对应的所有实例列表，然后进行动态路由才对！

对itcast-zuul工程修改优化：

3.4.1.添加Eureka客户端依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

之后就是添加Eureka得连接信息和引导类上开启注解信息，就可以了

eureka:
  client:
    registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

3.4.4.修改映射配置，通过服务名称获取

因为已经有了Eureka客户端，我们可以从Eureka获取服务的地址信息，因此映射时无需指定IP地址，而是通过服务名称来访问，而且Zuul已经集成了Ribbon的负载均衡功能。

3.5.简化的路由配置

在刚才的配置中，我们的规则是这样的：

zuul.routes.<route>.path=/xxx/**：来指定映射路径。<route>是自定义的路由名
zuul.routes.<route>.serviceId=service-provider：来指定服务名。

而大多数情况下，我们的<route>路由名称往往和服务名会写成一样的。因此Zuul就提供了一种简化的配置语法：zuul.routes.<serviceId>=<path>

比方说上面我们关于service-provider的配置可以简化为一条：

zuul:
  routes:
    server-provider: /server-provider/**
   #   path: /server/**
    #  url: http://localhost:8082
    #serviceId: server-provider
  prefix: /api

3.6.默认的路由规则

在使用Zuul的过程中，上面讲述的规则已经大大的简化了配置项。但是当服务较多时，配置也是比较繁琐的。因此Zuul就指定了默认的路由规则：

默认情况下，一切服务的映射路径就是服务名本身。例如服务名为：service-provider，则默认的映射路径就是：/service-provider/**

也就是说，刚才的映射规则我们完全不配置也是OK的，不信就试试看。

3.7.路由前缀

zuul:
  routes:
    service-provider: /service-provider/**
    service-consumer: /service-consumer/**
  prefix: /api # 添加路由前缀

完成测试：

3.8.过滤器

Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。

3.8.1.ZuulFilter

ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法：

public abstract ZuulFilter implements IZuulFilter{

    abstract public String filterType();

    abstract public int filterOrder();
    
    boolean shouldFilter();// 来自IZuulFilter

    Object run() throws ZuulException;// IZuulFilter
}

shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
run：过滤器的具体业务逻辑。
filterType：返回字符串，代表过滤器的类型。包含以下4种：
- pre：请求在被路由之前执行
- route：在路由请求时调用
- post：在route和errror过滤器之后调用
- error：处理请求时发生错误调用
filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。