Spring Could 核心组件知识点, 看这篇就够了!

1.ribbon

说到负载均衡，Ribbon与Lvs、Nginx不一样，nginx是服务端负载均衡，Ribbon是客户端负载均衡，具体表现为客户端从注册中心拿到服务的所有实例，然后以负载均衡方式去调用服务，默认以轮询的方式去调用服务实例.

实战思路：1.启用注册中心，2.创建服务提供者，服务提供者至少启动两个节点，3.创建服务消费者，以restTemplate的方式调用服务提供者，查看ribbon组件是否以负载均衡的方式调用服务提供者

2.feign

Feign具有以下一些重要特性：

• 整合了Hystrix，支持fallback容错降级
• 整合了Ribbon，直接请求的负载均衡
• 支持HTTP请求和响应的压缩
• 使用OkHttp替换原生URLConnection，提高效率

具体高级应用为如下几条：

• 1.使用feign进行服务间的调用
• 2.feign开启Gzip压缩
• 3.feign开启日志
• 4.feign替换JDK默认的URLConnection为okhttp
• 5.feign超时设置
• 6.feign使用hystrix进行熔断、降级处理

3.hystrix

为什么服务要进行隔离、熔断、降级？当服务出现异常时可以和其他服务隔离开来，不影响其他服务

隔离：将请求封装在HystrixCommand中，然后这些请求在一个独立的线程中执行，每个依赖服务维护一个小的线程池（或信号量），在调用失败或超时的情况下可以断开依赖调用或者返回指定逻辑
熔断：当HystrixCommand请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务，断路器保持在开路状态一段时间后(默认5秒)，自动切换到半开路状态(HALF-OPEN)，这时会判断下一次请求的返回情况， 如果请求成功, 断路器切回闭路状态(CLOSED)，否则重新切换到开路状态(OPEN)
降级：服务降级是指当请求后端服务出现异常的时候, 可以使用fallback方法返回的值

基本的容错模式

1.主动超时：Http请求主动设置一个超时时间，超时就直接返回，不会造成服务堆积
2.限流：限制最大并发数
3.熔断：当错误数超过阈值时快速失败，不调用后端服务，同时隔一定时间放几个请求去重试后端服务是否能正常调用，如果成功则关闭熔断状态，失败则继续快速失败，直接返回。（此处有个重试，重试就是弹性恢复的能力）
4.隔离：把每个依赖或调用的服务都隔离开来，防止级联失败引起整体服务不可用
5.降级：服务失败或异常后，返回指定的默认信息

Hystrix Dashboard断路器监控，是作为断路器状态的一个组件，提供了数据监控和友好的图形化界面。通过配置Hystrix Dashboard,我们可以通过浏览页面看运行情况

4.zuul网关

1.Zuul相关概念
Zuul是netflix开源的一个API Gateway 网关, 本质上是一个web servlet应用，用来做统一认证与鉴权、动态路由、监控、弹性、安全等边缘服务的框架，它的核心是做服务转发。

2.为什么需要网关
使用微服务架构后，大型系统往往会拆分为多个微服务，前端页面可能有商品，评价，广告、推荐模块等等，如果没有网关，前端页面就需要自己关心后端各个服务模块的地址，如果服务发布多个节点，或者发布地址变更后，前端页面要对应改过来，这就会很复杂。有了网关后，前端只需要向网关发起请求，不需要关心服务是否发布多份，服务地址是否变动，屏蔽后端的复杂性，它还能将多个API调用逻辑进行聚合，从而减少客户端的请求数

3.Zuul的工作原理
Zuul的核心是一系列的filters,它能在进行 HTTP请求或者响应时执行相关操作，其作用可以类比Servlet框架的Filter，它主要有以下几点特性：

Filter类型：pre、post、route、error，类型决定filter在Filter链中的执行顺序
Filter执行顺序：同一类型的Filter执行顺序通过 filterOrder()方法设定
Filter的执行条件：决定该filter是否执行，为true就会执行，为false就不执行
Filter的run方法，执行filter 实际上就是运行run()方法中的代码
Filter过滤链数据传递是通过RequestContext共享的，它内部是线程ThreadLocal实现

4. Zuul 与 Spring Cloud Zuul
   Zuul是Netflix 2012年3月开源的，最开始1.0版本，默认是Servlet开发的（同步阻塞模式），原生Zuul是支持动态过滤器的，因为网关发布后，它承受大量流量，不能经常重启，能支持动态添加过滤器就会很方便，动态过滤器是通过Groovy脚本，也就是java代码，能动态编译、执行。

   Zuul2.0版本是 Netfilx 2018-5月开源的，它把 Servlet换成了 Netty，事件处理器（handler）Netty Server接收请求，Netty Client响应（异步非阻塞），至于对比1.x版本有性能的提升，netfilx官方和网友都有测试，同时支持WebSocket和其他特性.

   Spring Cloud Zuul 是Pivotal 整合 Netfilx Zuul 到Spring Cloud 生态中，命名为Spring Cloud Zuul，它阉割了原生zuul的动态过滤器功能，整合与优化某些功能，如：使用注解就能启用Zuul网关，大大提高了开发效率

5.Gateway

网关的基本功能

• 网关核心功能是路由转发，因此不要有耗时操作在网关上处理，让请求快速转发到后端服务上
• 网关还能做统一的熔断、限流、认证、日志监控等

gateway与zuul的简单比较：gateway使用的是异步请求，zuul是同步请求，gateway的数据封装在ServerWebExchange里，zuul封装在RequestContext里，同步方便调式，可以把数据封装在ThreadLocal中传递。

Spring Cloud Gateway有三个核心概念：路由、断言、过滤器
过滤器：gateway有两种filter：GlobalFilter、GatewayFilter，全局过滤器默认对所有路由有效。

引用hystrix依赖，在filters下加入熔断降级配置，设置降级后返回的路由，同时配置默认使用信号量隔离、3秒主动超时

集成限流，Spring Cloud Gateway默认集成了Redis限流，可以对不同服务做不同维度的限流，如：IP限流、用户限流 、接口限流
本文演示的是 IP限流 ，先添加redis依赖，添加KeyResolver，再添加配置，需启动redis

/**
 * 路由限流配置
 * @date 2019/1/15
 */
@Configuration
public class RateLimiterConfig {

    @Bean(value = "remoteAddrKeyResolver")
    public KeyResolver remoteAddrKeyResolver() {
        return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
    }
}

// 用户限流，使用这种方式限流，请求路径中必须携带userId参数
@Bean
KeyResolver userKeyResolver() {
    return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("userId"));
}


// 接口限流，获取请求地址的uri作为限流key
@Bean
KeyResolver apiKeyResolver() {
    return exchange -> Mono.just(exchange.getRequest().getPath().value());
}

在真实场景中，限流数的调整需要依赖配置中心，当网站做活动时，动态调整限流数，新服务上线时，通过配置中心做动态路由等

前面分别对 Spring Cloud Zuul 与 Spring Cloud Gateway 进行了简单的说明，它门是API网关，API网关负责服务请求路由、组合及协议转换，客户端的所有请求都首先经过API网关，然后由它将匹配的请求路由到合适的微服务，是系统流量的入口，在实际生产环境中为了保证高可靠和高可用，尽量避免重启，如果有新的服务要上线时，可以通过动态路由配置功能上线。

本篇拿 Spring Cloud Gateway 为例，对网关的动态路由进行简单分析，下一篇将分享动态路由的进阶实现

1.gateway配置路由主要有两种方式，1.用yml配置文件，2.写在代码里。而无论是 yml，还是代码配置，启动网关后将无法修改路由配置，如有新服务要上线，则需要先把网关下线，修改 yml 配置后，再重启网关。

2.gateway网关启动时，路由信息默认会加载内存中，路由信息被封装到 RouteDefinition 对象中，配置多个RouteDefinition组成gateway的路由系统，仔细的同学可能看到RouteDefinition中的字段与上面代码配置方式比较对应。