微服务之SpringCloud-Zuul 网关

最新推荐文章于 2022-05-04 13:59:52 发布

huang_yx

最新推荐文章于 2022-05-04 13:59:52 发布

阅读量199

点赞数

分类专栏：微服务文章标签： java 分布式

本文链接：https://blog.csdn.net/huang_yx/article/details/108112766

版权

微服务专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1.4.2.开启Eureka客户端发现功能

1.4.3.添加Eureka配置，获取服务信息

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

接上一篇“微服务之SpringCloud-负载均衡Ribbon、Hystrix熔断器、Feign服务调用”

1.Zuul网关

通过前两篇文章了解，使用 SpringCloud 实现微服务的架构基本形态：

我们使用Spring Cloud Netfix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过 Ribbon 或 Feign 实现服务的消费以及负载均衡；通过Spring Cloud Config 实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用 Hystrix 的熔断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。

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

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

1）首先，破坏了服务无状态特点；

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

2）其次，无法直接复用既有接口；

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

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

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

1.1.简介

官网：https://github.com/Netflix/zuul；事实上，在微服务架构中，Zuul 就是守门的大Boss！一夫当关，万夫莫开！

Zuul 是 Netfix 开元的微服务网关，他可以和Eureka、Ribbon、Hystrix 等组件配合使用。Zuul 的核心是一系列的过滤器，这些过滤器可以完成以下功能：

1）身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。

2）审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。

3）动态路由：动态的将请求路由到不同的后端集群。

4）压力测试：主键增加指向集群的流量，以了解性能。

5）负载分配：为每一种负载类型分配对应容量，并启用超出限定值的请求。

6）静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。

7）多区域弹性：跨域 AWS Region 进行请求路由，旨在实现ELB（Elastic Load Balancing，弹性负载平衡）使用的多样化，以及让系统的边缘更贴近系统的使用者。

Spring Cloud 对 Zuul 进行了整个与增强。目前，Zuul 使用的默认 HTTP 客户端是 Apache HTTP Client，也可以使用RestClient 或者 okhttp3.OkHttpClient。如果想要使用 RestClient，可以设置 ribbon.restclient,enabled=true；想要使用okhttp3.OkHttpClient，可以设置 ribbon.okhttp.enabled=true。

1.2.Zuul加入后的架构

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

1.3.快速入门

1.3.1.新建工程

使用springboot脚手架快速搭建一个工程，注意在选择依赖的时候，添加Zuul的依赖：

1.3.2.编写启动类

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

@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
public class ZuulDemoApplication {

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

1.3.3.编写配置

server:
  port: 10010 #服务端口
spring: 
  application:  
    name: api-gateway #指定服务名

1.3.4.编写路由规则

我们需要用Zuul来代理user-service服务，先看一下Eureka页面中的服务状态

ip为：127.0.0.1；端口为：8081

映射规则：

zuul:
  routes:
    user-service: # 这里是路由id，随意写
      path: /user-service/** # 这里是映射路径
      url: http://127.0.0.1:8081 # 映射路径对应的实际url地址

我们将服务 path 规则的一切请求，都代理到 url 参数指定的地址。如上面，将 /user-service/**开头的请求，代理到http://127.0.0.1:8081中。

1.4.面向服务的路由

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

1.4.1.添加Eureka客户端依赖

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

1.4.2.开启Eureka客户端发现功能

@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
@EnableDiscoveryClient
public class ZuulDemoApplication {

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

1.4.3.添加Eureka配置，获取服务信息

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

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

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

zuul:
  routes:
    user-service: # 这里是路由id，随意写
      path: /user-service/** # 这里是映射路径
      serviceId: user-service # 指定服务名称

1.5.简化的路由配置

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

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

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

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

zuul:
  routes:
    user-service: /user-service/** # 这里是映射路径

省去了对应服务名称的配置

1.6.默认的路由规则

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

默认情况下，一切服务的映射路径就是服务名本身。

如：服务名为：user-service，则默认的映射路径就是：/user-service/**；也就是说，刚才的映射规则我们完全不配置也是可以的。

1.7.路由前缀

配置示例：

zuul:
  prefix: /api # 添加路由前缀
  routes:
      user-service: # 这里是路由id，随意写
        path: /user-service/** # 这里是映射路径
        service-id: user-service # 指定服务名称

通过`zuul.prefix=/api`来指定了路由的前缀，这样在发起请求时，路径就要以/api开头。

如：路径/api/user-service/user/1将会被代理到/user-service/user/1

1.8.过滤器

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

1.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，过滤逻辑
}

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

1.8.2.过滤器执行生命周期：

这张是Zuul官网提供的请求生命周期图，清晰的表现了一个请求在各个过滤器的执行顺序。

1）正常流程：

请求到达首先会经过 pre 类型过滤器，而后到达 routing 类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达 post 过滤器。而后返回响应。

2）异常流程：

整个过程中，pre 或者 routing 过滤器出现异常，都会直接进入error 过滤器，在error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
如果error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。
如果POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的是，请求不会在打到POST过滤器了。

所有内置过滤器列表：

1.8.3.使用场景

请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了。
异常处理：一般会在error类型和post类型过滤器中结合来处理。
服务调用时长统计：pre和post结合使用。

1.9.负载均衡和熔断

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

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

ribbon的超时时长，真实值是（read+connect）*2，必须小于hystrix时长。

huang_yx

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
微服务之SpringCloud-Zuul 网关

接上一篇“微服务之SpringCloud-负载均衡Ribbon、Hystrix熔断器、Feign服务调用”1.Zuul网关通过前两篇文章了解，使用 SpringCloud 实现微服务的架构基本形态：我们使用Spring Cloud Netfix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过 Ribbon 或 Feign 实现服务的消费以及负载均衡；通过Spring Cloud Config 实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用 Hyst
复制链接

扫一扫