实战_Spring_Cloud（3）-阿里云开发者社区

实战_Spring_Cloud（2）https://developer.aliyun.com/article/1543983

微服务网关(Zuul)

Zuul是Netflix开源的微服务网关，可以和Eureka、Ribbon、Hystrix等组件配合使用，Spring Cloud对Zuul进行了整合与增强，Zuul默认使用的HTTP客户端是Apache HTTPClient，也可以使用RestClient或okhttp3.OkHttpClient。 Zuul的主要功能是路由转发和过滤器。zuul默认和Ribbon结合实现了负载均衡的功能

工作原理

zuul的核心是一系列的filters, 其作用类比Servlet框架的Filter，或者AOP。zuul把请求路由到用户处理逻辑的过程中，这些filter参与一些过滤处理，比如Authentication，Load Shedding等

Zuul使用一系列不同类型的过滤器，使我们能够快速灵活地将功能应用于我们的边缘服务。这些过滤器可帮助我们执行以下功能：

身份验证和安全性 - 确定每个资源的身份验证要求并拒绝不满足这些要求的请求
洞察和监控 - 在边缘跟踪有意义的数据和统计数据，以便为我们提供准确的生产视图
动态路由 - 根据需要动态地将请求路由到不同的后端群集
压力测试 - 逐渐增加群集的流量以衡量性能。
Load Shedding - 为每种类型的请求分配容量并删除超过限制的请求
静态响应处理 - 直接在边缘构建一些响应，而不是将它们转发到内部集群

添加网关

新建api-gateway子模块，作为服务网关、服务发现客户端、获取配置客户端，因此需要引入以下依赖。

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-client</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
    </dependency>
</dependencies>

在启动类上增加EnableDiscoveryClient和@EnableZuulProxy注解。

@EnableDiscoveryClient
@EnableZuulProxy
@SpringBootApplication
public class ApiGatewayApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(ApiGatewayApplication.class, args);
    }
 
}

启动服务，看看是否能正常获取配置，并注册到Eureka Server。
Zuul网关目前暴露的端口是8080，之前我们访问商品服务的api，是通过调用 http://localhost:11100/api/v1/product/productInfos来访问的，现在我们就可以通过Zuul，根据商品的服务名称shopping-produc来访问 http://localhost:8080/shopping-product//api/v1/product/productInfos，非常轻松的实现了路由的功能。

自定义路由

默认的路由规则是按照服务的名称来路由服务，当然我们也可以自定义。在zuul中，路由匹配的路径表达式采用ant风格定义

通配符	说明
？	匹配任意单个字符
*	匹配任意数量的字符
**	匹配任意数量的字符，支持多级目录

zuul:
  routes:
    # 简洁写法
    shopping-product: /product/**

将命名为product的所有路径都映射到shopping-product服务中去，然后通过product名称来访问，依旧能访问成功。
如果我们需要查看目前所有的路径映射呢，首先得引入actuator

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

其次，需要放开actuator维护端口的权限

management:
  endpoints:
    web:
      exposure:
        include: "*"

访问 http://localhost:8080/actuator/routes ，可以看到目前网关的所有路由映射
如果需要定义哪些方法不能通过网关调用，还可以设置排除哪些路由的规则

zuul:
  routes:
    # 简洁写法
    shopping-product: /product/**
  # 排除某些路由
  ignored-patterns:
    - /**/productInfos

这样我们再访问这个接口时，就提示 Not Found 错误了

Cookie与头信息

默认情况下，spring cloud zuul在请求路由时，会过滤掉http请求头信息中一些敏感信息，防止它们被传递到下游的外部服务器。默认的敏感头信息通过zuul.sensitiveHeaders参数定义，默认包括cookie,set-Cookie,authorization三个属性。所以，我们在开发web项目时常用的cookie在spring cloud zuul网关中默认时不传递的，这就会引发一个常见的问题，如果我们要将使用了spring security，shiro等安全框架构建的web应用通过spring cloud zuul构建的网关来进行路由时，由于cookie信息无法传递，我们的web应用将无法实现登录和鉴权。有时候，针对某些路由，我们需要传递这个cookie。

zuul:
  routes:
    # 完全写法
    product-route:
      path: /product/**
      serviceId: shopping-product
      # 将指定路由的敏感头设置为空
      sensitiveHeaders:

动态路由

之前路由的配置都是写在配置文件中，如果路由规则变化以后，需要重启网关服务。但是实际生产环境，一般都需要动态的加载路由的配置，不能轻易重启网关服务。

将配置信息集中到统一配置中心服务进行管理，具体实施参考前面章节-统一配置中心。

eureka:
  client:
    serviceUrl:
      defaultZone: http://eureka1:8761/eureka/,http://eureka2:8762/eureka/ #指定服务注册地址
 
spring:
  application:
    name: api-gateway  #应用名称
  cloud:
    config:
      discovery:
        enabled: true
        service-id: config-server

将zuul配置属性定义成支持动态刷新，增加@RefreshScope注解

@Component
public class ZuulConfiguration {
 
    @ConfigurationProperties("zuul")
    @RefreshScope
    public ZuulProperties zuulProperties(){
        return new ZuulProperties();
    }
}

自定义Filter

设想以下场景：我们需要判断用户请求的参数是否包含认证信息，如果包含token信息，则可以访问，否则禁止访问。可以用Zuul Filter很方便的实现在网关端，统一进行认证。

新建自定义的Filter，并继承ZuulFilter，默认需要实现4个接口

filterType()：返回 filter 的类型，设置为PRE_TYPE
filterOrder()：返回 filter 的顺序，设置为PRE_DECORATION_FILTER_ORDER-1
shouldFilter()：是否启用 filter，设置为true
run()：执行具体的过滤器逻辑

/**
 * 验证token 过滤器
 */
@Component
public class TokenFilter  extends ZuulFilter {
    @Override
    public String filterType() {
        return PRE_TYPE;
    }
 
    @Override
    public int filterOrder() {
        return 0;
    }
 
    @Override
    public boolean shouldFilter() {
        return true;
    }
 
    @Override
    public Object run() throws ZuulException {
 
        RequestContext currentContext = RequestContext.getCurrentContext();
        HttpServletRequest request = currentContext.getRequest();
 
        //测试在url参数中获取token
        String token = request.getParameter("token");
        if(StringUtils.isEmpty(token)){
            currentContext.setSendZuulResponse(false);
            currentContext.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
        }
 
        return null;
    }
}

验证结果，如果url中添加了 token 参数，TokenFilter 验证通过，正确返回结果；如果没有 token 参数，则返回 401（UNAUTHORIZED）错误
还可以在调用接口返回中，设置响应头

@Component
public class AddResHeaderFilter extends ZuulFilter{
    @Override
    public String filterType() {
        return POST_TYPE;
    }
 
    @Override
    public int filterOrder() {
        return SEND_RESPONSE_FILTER_ORDER - 1;
    }
 
    @Override
    public boolean shouldFilter() {
        return true;
    }
 
    @Override
    public Object run() {
        RequestContext requestContext = RequestContext.getCurrentContext();
        HttpServletResponse response = requestContext.getResponse();
        response.setHeader("X-Foo", UUID.randomUUID().toString());
        return null;
    }
}

限流

这里介绍一种限流的设计方案：

对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。如图所示，令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。

Google公司已经实现了上述的令牌桶的算法，直接使用 RateLimiter 就可以通过Zuul实现限流的功能：

@Component
public class RateLimitFilter extends ZuulFilter {
 
    private static final RateLimiter RATE_LIMITER = RateLimiter.create(100);
 
 
    @Override
    public String filterType() {
        return PRE_TYPE;
    }
 
 
    @Override
    public int filterOrder() {
        return SERVLET_DETECTION_FILTER_ORDER - 1;
    }
 
    @Override
    public boolean shouldFilter() {
        return true;
    }
 
 
    @Override
    public Object run() {
        if (!RATE_LIMITER.tryAcquire()) {
            throw new RuntimeException("未能获取到令牌.");
        }
 
        return null;
    }
}

小结

整体项目结构如下：

spring-cloud-app

--api-gateway（服务网关）

--config-server（统一配置中心）

--eureka-server（服务注册中心）

--shopping-common（购物公共模块）

--shopping-product（商品服务模块）

--shopping-order（订单服务模块）

目前所有的客户端请求，首先被发送到统一网关服务处理，然后由网关进行限流、熔断、权限验证、记录日志等等，然后根据自定义的路由规则，再分发到不同的应用服务中去，应用服务器返回处理结果后，由网关统一返回给客户端。

服务容错（Hystrix）

在分布式环境中，许多服务依赖项中的一些必然会失败。Hystrix是一个库，通过添加延迟容忍和容错逻辑，帮助你控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点、停止级联失败和提供回退选项来实现这一点，所有这些都可以提高系统的整体弹性。

设计原则

防止任何单个依赖项耗尽所有容器（如Tomcat）用户线程。
甩掉包袱，快速失败而不是排队。
在任何可行的地方提供回退，以保护用户不受失败的影响。
使用隔离技术（如隔离板、泳道和断路器模式）来限制任何一个依赖项的影响。
通过近实时的度量、监视和警报来优化发现时间。
通过配置的低延迟传播来优化恢复时间。
支持对Hystrix的大多数方面的动态属性更改，允许使用低延迟反馈循环进行实时操作修改。
避免在整个依赖客户端执行中出现故障，而不仅仅是在网络流量中。

如何实现

用一个HystrixCommand 或者 HystrixObservableCommand （这是命令模式的一个例子）包装所有的对外部系统（或者依赖）的调用，典型地它们在一个单独的线程中执行
调用超时时间比你自己定义的阈值要长。有一个默认值，对于大多数的依赖项你是可以自定义超时时间的。
为每个依赖项维护一个小的线程池(或信号量)；如果线程池满了，那么该依赖性将会立即拒绝请求，而不是排队。
调用的结果有这么几种：成功、失败（客户端抛出异常）、超时、拒绝。
在一段时间内，如果服务的错误百分比超过了一个阈值，就会触发一个断路器来停止对特定服务的所有请求，无论是手动的还是自动的。
当请求失败、被拒绝、超时或短路时，执行回退逻辑。
近实时监控指标和配置变化。

触发降级

在实际工作中，尤其是分布式、微服务越来越普遍的今天，一个服务经常需要调用其他的服务，即RPC调用，而调用最多的方式还是通过http请求进行调用，这里面就有一个问题了，如果调用过程中，因为网络等原因，造成某个服务调用超时，如果没有熔断机制，此处的调用链路将会一直阻塞在这里，在高并发的环境下，如果许多个请求都卡在这里的话，服务器不得不为此分配更多的线程来处理源源不断涌入的请求。

更恐怖的是，如果这是一个多级调用，即此处的服务的调用结果还被其他服务调用了，这就形成了所谓的雪崩效应，后果将不堪设想。因此，需要某种机制，在一定的异常接口调用出现的时候，能够自动发现这种异常，并快速进行服务降级。

首先，shopping-order项目模拟一个远程调用shopping-product服务http请求

/**
 * Hystrix 测试
 */
@RestController
@RequestMapping("api/hystrix")
public class HystrixController {
 
    @GetMapping("/getProductEnv")
    public String getProductEnv() {
 
        RestTemplate restTemplate = new RestTemplate();
        return restTemplate.postForObject("http://localhost:11100/api/env", null, String.class);
 
    }
}

如果此时将shopping-product服务关闭，则shopping-order调用远程服务不可用，进入等待，超时时返回 Error Page的错误页面。其实我们希望服务不可用的时候直接处理，返回通知服务的不可用状态。可以引入Hystrix。

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

在启动类上增加@EnableCircuitBreaker注解，或者将@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker 三个合并成一个@SpringCloudApplication注解。

@EnableFeignClients(basePackages = "tech.lancelot.shoppingorder.client")
//@SpringBootApplication
//@EnableDiscoveryClient
//@EnableCircuitBreaker
@SpringCloudApplication
public class ShoppingOrderApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(ShoppingOrderApplication.class, args);
    }
}

修改 HystrixController，增加@HystrixCommand注解，并指定调用方法失败时的错误处理回调。也可以为整个类增加@DefaultProperties注解，定义一个默认的返回方法

/**
 * Hystrix 测试
 */
@RestController
@RequestMapping("api/hystrix")
public class HystrixController {
 
    @HystrixCommand(fallbackMethod = "defaultFallback")
    @GetMapping("/getProductEnv")
    public String getProductEnv() {
 
        RestTemplate restTemplate = new RestTemplate();
        return restTemplate.postForObject("http://localhost:11100/api/env", null, String.class);
 
    }
 
    // 默认服务不可达的返回信息
    private String defaultFallback() {
        return "太拥挤了, 请稍后再试~~";
    }
}

重启启动后，再次访问接口，就会发现接口直接返回错误信息，不会阻塞在这里。

超时设置

如果我们没有配置默认的超时时间，Hystrix 将取 default_executionTimeoutInMilliseconds（1秒）作为默认超时时间，也可以自定义超时时间。

代码中修改默认超时配置（改为3秒）：

@HystrixCommand(commandProperties = {
    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")})

这样的话，shopping-order调用远程服务，超过3s之后，立刻返回错误处理，不会再阻塞。

可以在配置文件中定义HystrixCommand属性

hystrix:
  command:
    default:        # 方法默认属性
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 1000
    getProductEnv:  # 该名称方法属性
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 3000

熔断机制

如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

熔断器有三个状态 CLOSED、OPEN、HALF_OPEN 熔断器默认关闭状态，当触发熔断（至少有 circuitBreaker.requestVolumeThreshold 个请求，错误率达到 circuitBreaker.errorThresholdPercentage）后状态变更为 OPEN,在等待到指定的时间（circuitBreaker.sleepWindowInMilliseconds），Hystrix会放请求检测服务是否开启，这期间熔断器会变为HALF_OPEN 半开启状态，熔断探测服务可用则继续变更为 CLOSED关闭熔断器。

在方法上增加熔断属性的相关设置

@HystrixCommand(commandProperties = {
    @HystrixProperty(name = "circuitBreaker.enabled", value = "true"), //设置熔断
    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),//请求数达到后才计算
    @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"), //休眠时间窗
    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60"),    //错误率
})

实战_Spring_Cloud（4）https://developer.aliyun.com/article/1543990

实战_Spring_Cloud（3）

微服务网关(Zuul)

工作原理

添加网关

自定义路由

Cookie与头信息

动态路由

自定义Filter

限流

小结

服务容错（Hystrix）

设计原则

如何实现

触发降级

超时设置

熔断机制

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

实战_Spring_Cloud（3）

微服务网关(Zuul)

工作原理

添加网关

自定义路由

Cookie与头信息

动态路由

自定义Filter

限流

小结

服务容错（Hystrix）

设计原则

如何实现

触发降级

超时设置

熔断机制

热门文章

最新文章

相关课程

相关电子书

相关实验场景