Zuul服务网关-入门教程（Load balancer does not have available server for client解决方法）

最新推荐文章于 2024-04-25 01:10:35 发布

hrsweb

最新推荐文章于 2024-04-25 01:10:35 发布

阅读量1.9k

点赞数 1

分类专栏： SpringBoot 文章标签： java spring boot 分布式

本文链接：https://blog.youkuaiyun.com/weixin_45007945/article/details/120462045

版权

SpringBoot 专栏收录该内容

3 篇文章

订阅专栏

本文介绍了如何在SpringCloud Netflix中使用Zuul作为微服务网关，包括导入依赖、配置路由、开启Zuul功能、自定义过滤器以实现请求鉴权，并探讨了负载均衡和熔断的配置。通过Zuul，可以实现统一的REST API入口，权限控制以及服务路由和负载均衡。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

1. 导入依赖

<!--注入Eureka客户端依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<!--注入zuul依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
    <version>2.2.3.RELEASE</version>
</dependency>

注意：如果访问时出现HTTP Status 500 – Internal Server Error异常，当时我用的是SpringBoot2.5.5，换成SpringBoot2.4.8就解决了。

2. 覆盖默认配置

application.yml
方式一：将path的一切请求都代理到url的地址上

server:
  port: 10010

spring:
  application:
    name: USER-ZUUL

zuul:
  prefix: /api    # 路由前缀
  routes:
    PROVIDER-SERVER:             # 路由名称，自定义
      path: /provider-server/**  # 映射路径。当省略时映射路径为路由名称
      url: http://localhost:8081 # 映射路径对应的url

方式二：注册到Eureka上，通过服务名称获取服务ip地址。Zuul已集成负载均衡Ribbon

zuul:
  prefix: /api    # 路由前缀
  routes:
    PROVIDER-SERVER:             # 路由名称，自定义
      path: /provider-server/**  # 映射路径。当省略时映射路径为路由名称
      serviceId: PROVIDER-SERVER # 服务名称和路由名称相同就可以省略
  retryable: true
eureka:
  client:
    service-url:
      defaultZone: http://localhost:10086/eureka
    registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5秒
  instance:
    ip-address: 127.0.0.1
    prefer-ip-address: true

方式三：服务id和路由名称一致时可以省略服务id

zuul:
  prefix: /api    # 路由前缀
  routes:
    PROVIDER-SERVER:             # 路由名称，自定义
      path: /provider-server/**  # 映射路径。当省略时映射路径为路由名称
  retryable: true

方式四：路由名称和映射路径一致时，可以省略映射路径

zuul:
  prefix: /api    # 路由前缀
  routes:
    PROVIDER-SERVER:   # 路由名称，自定义
  retryable: true

3. 开启Zuul网关功能

SpringBoot启动类上开启网关功能

@SpringBootApplication
@EnableZuulProxy   // 开启Zuul网关的代理功能
@EnableEurekaClient  // 开启Eureka客户端
public class UserZuulApplication {

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

}

4. 自定义过滤器

Zuul一个重要的功能，就是请求鉴权。Zuul往往通过过滤器来实现

@Component
public class LoginFilter extends ZuulFilter {
    /**
     * 过滤器的类型：pre，routing，post，error
     * @return
     */
    @Override
    public String filterType() {
        return "pre";
    }
    /**
     * 过滤器执行顺序，数字越小优先级越高
     * @return
     */
    @Override
    public int filterOrder() {
        return 10;
    }
    /**
     * 判断过滤器是否需要执行run方法
     * @return
     */
    @Override
    public boolean shouldFilter() {
        return true;
    }
    /**
     * 执行拦截的业务逻辑
     * @return
     * @throws ZuulException
     */
    @Override
    public Object run() throws ZuulException {
        // 1.获取zuul网关上下文对象
        RequestContext context = RequestContext.getCurrentContext();
        // 2.获取请求对象
        HttpServletRequest request = context.getRequest();
        // 3.获取请求参数
        String token = request.getParameter("token");
        // 4.判断如果没有登录，就拦截
        if (StringUtils.isBlank(token)){
            // 不再转发
            context.setSendZuulResponse(false);
            // 设置响应状态码
            context.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
            // 设置响应信息
            context.setResponseBody("request error");
        }
        return null;
    }
}

正常流程：
- 请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
异常流程：
- 整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
- 如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。
- 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时，请求不会再到达POST过滤器了。

5. 负载均衡和熔断

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：

zuul:
  retryable: true	#开启重试机制
ribbon:
  ConnectTimeout: 250 # 连接超时时间(ms)
  ReadTimeout: 2000 # 通信超时时间(ms)
  OkToRetryOnAllOperations: true # 是否对所有操作重试
  MaxAutoRetriesNextServer: 2 # 同一服务不同实例的重试次数
  MaxAutoRetries: 1 # 同一实例的重试次数
hystrix:
  command:
  	PROVIDER-SERVER:    # 服务名称
        execution:
          isolation:
            thread:
              timeoutInMillisecond: 6000 # 熔断超时时长：6000ms