spring cloud 微服务

目录

1.单体架构

2.垂直应用架构

3 SOA应用架构

4 微服务应用架构

5.Spring Cloud

6 Eureka服务注册中心

7 Ribbon负载均衡

8 Hystrix熔断器

9 Feign远程调用

10 GateWay网

---

 

1.单体架构

        项目所有的功能模块都放在一个工程中编码、编译、打包并且部署在一个Tomcat容器中，这样的优点：架构既简单实用、便于维护，成本⼜低

优点：

1.高效开发：项⽬前期开发节奏快，团队成员少的时候能够快速迭代

2.架构简单：MVC架构，只需要借助IDE开发、调试即可

3.易于测试：只需要通过单元测试或者浏览器完成

4.易于部署：打包成单⼀可执⾏的jar或者打成war包放到容器内启动

缺点：

1.可靠性差： 某个应用Bug，例如死循环、内存溢出等， 可能会导致整个应用的崩溃

2.复杂性高： 以一个百万行级别的单体应用为例，整个项目包含的模块多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。使得整个项目非常复杂。

3.扩展能力受限： 单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU； 有的模块则是IO密集型的，需要更大的内存。 由于这些模块部署在一起，不得不在硬件的选择上做出妥协。

2.垂直应用架构

垂直划分的原则是基于现有的业务特性来做，核心目标标第⼀个是为了业务之间互不影响，第⼆个是在研发团队的壮⼤后为了提⾼效率，减少组件之间的依赖。

优点
1.系统拆分实现了流量分担，解决了并发问题
2.可以针对不同模块进⾏优化
3.⽅便⽔平扩展，负载均衡，容错率提⾼
4.系统间相互独⽴，互不影响，新的业务迭代时更加⾼效

 缺点
1.服务之间相互调⽤，如果某个服务的端⼝或者ip地址发⽣改变，调⽤的系统得⼿动改变
2.搭建集群之后，实现负载均衡⽐较复杂，如：内⽹负载，在迁移机器时会影响调⽤⽅的路由，导致线上故障
3.服务之间调⽤⽅式不统⼀，基于 httpclient 、 webservice ，接⼝协议不统⼀
服务监控不到位：除了依靠端⼝、进程的监控，调⽤的成功率、失败率、总耗时等等这些监控指标是没有的
 

3 SOA应用架构

面向服务的架构。

根据实际业务，把系统拆分成合适的、独立部署的模块，模块之间相互独立（通过Webservice/Dubbo等技术进行通信）。

优点：分布式、松耦合、扩展灵活、可重用。
缺点：服务抽取粒度较大、服务调用方和提供方耦合度较高（接口耦合度）

4 微服务应用架构

微服务架构可以说是SOA架构的一种拓展，这种架构模式下它拆分粒度更小、服务更独立。把应用
拆分成为一个个微小的服务，不同的服务可以使用不同的开发语言和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于微小、独立、轻量级通信。

微服务架构强调的⼀个重点是业务需要彻底的组件化和服务化

微服务架构设计的核心思想就是“微”，拆分的粒度相对比较小，这样的话单一职责、开发的耦合度
就会降低、微小的功能可以独立部署扩展、灵活性强，升级改造影响范围小。

优点:

微服务很小，便于特定业务功能的聚焦；每个微服务都可以被一个小团队单独实施（开发、测试、部署上线、运维），团队合作一定程度解耦，便于实施敏捷开发；便于重用和模块之间的组装；微服务很独立，不同的微服务可以使用不同的语言开发，松耦合微服务架构下，我们更容易引入新技术。

缺点：

微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂；分布式链路跟踪难等。

核心概念

服务注册：服务提供者将所提供服务的信息（服务器IP和端口、服务访问协议等）注册/登记到注册中心
服务发现：服务消费者能够从注册中心获取到较为实时的服务列表，然后根究一定的策略选择一个
服务访问

负载均衡：即将请求压力分配到多个服务器（应用服务器、数据库服务器等），以此来提高服务的性能、可靠性

熔断：即断路保护。微服务架构中，如果下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。

链路追踪：一个项目往往拆分成很多个服务，那么一次请求就需要涉及到很多个服务。不同
的微服务可能是由不同的团队开发、可能使用不同的编程语言实现、整个项目也有可能部署在了很多服务器上（甚至百台、千台）横跨多个不同的数据中心，链路追踪就是对一次请求涉及的很多个服务链路进行日志记录、性能监控

API 网关：

微服务架构下，不同的微服务往往会有不同的访问地址，客户端可能需要调用多个服务的接口才能
完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：

1.客户端需要调用不同的url地址，维护难度增加

2.会存在跨域请求的问题

3.每个微服务都需要进行单独的身份认证

API网关就可以较好的统一处理上述问题，API请求调用统一接入API网关层，由网关转发请求。API网关更专注在安全、路由、流量等问题的处理上（微服务团队专注于处理业务逻辑即可），它的功能有：

1）统一接入（路由）
2）安全防护（统一鉴权，负责网关访问身份认证验证，与“访问认证中心”通信，实际认证业务逻辑交移“访问认证中心”处理）
3）黑白名单（实现通过IP地址控制禁止访问网关功能，控制访问）
3）协议适配（实现通信协议校验、适配转换的功能）
4）流量管控（限流）
5）长短链接支持
6）容错能力（负载均衡）

5.Spring Cloud

简介：Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring Boot的开发风格做到一键启动和部署。

Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud 解决什么问题？

Spring Cloud 规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的一些问题，比如
微服务架构中的服务注册发现问题、网络问题（比如熔断场景）、统一认证安全授权问题、负载均衡问题、链路追踪等问题。

Spring Cloud 与 Spring Boot 的关系

Spring Cloud 只是利用了Spring Boot 的特点，让我们能够快速的实现微服务组件开发，否则不使
用Spring Boot的话，我们在使用Spring Cloud时，每一个组件的相关Jar包都需要我们自己导入配置以及需要开发人员考虑兼容性等各种情况。所以Spring Boot是我们快速把Spring Cloud微服务技术应用起来的一种方式。

Spring Cloud 与 Dubbo 对比

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，基于RPC调用，对于目前使用率较高的
Spring Cloud Netflix来说，它是基于HTTP的，所以效率上没有Dubbo高，但问题在于Dubbo体系的组件不全，不能够提供一站式解决方案，比如服务注册与发现需要借助于Zookeeper等实现，而Spring Cloud Netflix则是真正的提供了一站式服务化解决方案，且有Spring大家族背景。

6 Eureka服务注册中心

服务注册中心本质上是为了解耦服务提供者和服务消费

分布式微服务架构中，服务注册中心用于存储服务提供者地址信息、服务发布相关的属性信息，消
费者通过主动查询和被动通知的方式获取服务提供者的地址信息，而不再需要通过硬编码方式得到提供者的地址信息。消费者只需要知道当前系统发布了那些服务，而不需要知道服务具体存在于什么位置，这就是透明化路由。

主流服务中心对比

Zookeeper
        Dubbo + Zookeeper
        Zookeeper它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决
分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布
式应用配置项的管理等。
        简单来说zookeeper本质 = 存储 + 监听通知。
        Zookeeper 用来做服务注册中心，主要是因为它具有节点变更通知功能，只要客户端监听相
关服务节点，服务节点的所有变更，都能及时的通知到监听客户端，这样作为调用方只要使用
Zookeeper 的客户端就能实现服务节点的订阅和变更通知功能了，非常方便。另外，Zookeeper
可用性也可以，因为只要半数以上的选举节点存活，整个集群就是可用的，最少节点数为3。

Eureka
        由Netflix开源，并被Pivatal集成到SpringCloud体系中，它是基于 RestfulAPI 风格开发的服务
注册与发现组件。

Consul
        Consul是由HashiCorp基于Go语言开发的支持多数据中心分布式高可用的服务发布和注册服
务软件， 采用Raft算法保证服务的一致性，且支持健康检查。

Nacos
        Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。简单来说
Nacos 就是 注册中心 + 配置中心的组合，帮助我们解决微服务开发必会涉及到的服务注册 与发
现，服务配置，服务管理等问题。Nacos 是 Spring Cloud Alibaba 核心组件之一，负责服务注册
与发现，还有配置。

CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。
P：分区容错性：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务（一定的要满足的）
C：数据一致性：all nodes see the same data at the same time
A：高可用：Reads and writes always succeed
CAP不可能同时满足三个，要么是AP，要么是CP

        Application Service作为服务提供者向Eureka Server中注册服务，Eureka Server接受到注
册事件会在集群和分区中进行数据同步，Application Client作为消费端（服务消费者）可以从Eureka Server中获取到服务注册信息，进行服务调用。

        微服务启动后，会周期性地向Eureka Server发送心跳（默认周期为30秒，默认Eureka Server90S会将还没有续约的给剔除）以续约自己的信息

        Eureka Server在一定时间内没有接收到某个微服务节点的心跳，Eureka Server将会注销该微服务节点（默认90秒）

        每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的方式完成服务
注册列表的同步

        Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消
费者依然可以使用缓存中的信息找到服务提供者

Eureka通过心跳检测、健康检查和客户端缓存等机制，提高系统的灵活性、可伸缩性和高可用性。

Eureka细节详解

Eureka的元数据有两种：标准元数据和自定义元数据。
标准元数据：主机名、IP地址、端口号等信息，这些信息都会被发布在服务注册表中，用于服务之
间的调用。
自定义元数据：可以使用eureka.instance.metadata-map配置，符合KEY/VALUE的存储格式。这些元数据可以在远程客户端中访问。

Eureka客户端详解

服务提供者（也是Eureka客户端）要向EurekaServer注册服务，并完成服务续约等工作

服务注册详解（服务提供者）
1）当我们导入了eureka-client依赖坐标，配置Eureka服务注册中心地址
2）服务在启动时会向注册中心发起注册请求，携带服务元数据信息
3）Eureka注册中心会把服务的信息保存在Map中。

服务续约详解（服务提供者）

服务每隔30秒会向注册中心续约(心跳)一次（也称为报活），如果没有续约，租约在90秒后到期，
然后服务会被失效。每隔30秒的续约操作我们称之为心跳检测
Eureka Client ：30S续约一次，在Eureka Server更新自己的状态 (Client端进行配置)
Eureka Server：90S还没有进行续约，将该微服务实例从服务注册表（Map）剔除 (Client端进行
配置)
Eureka Client： 30S拉取服务最新的注册表并缓存到本地 (Client端进行配置)

Eureka服务端详解

服务下线：
1）当服务正常关闭操作时，会发送服务下线的REST请求给EurekaServer。
2）服务中心接受到请求后，将该服务置为下线状态

失效剔除：
Eureka Server会定时（间隔值是eureka.server.eviction-interval-timer-in-ms，默认60s）进行检查，如果发现实例在在一定时间（此值由客户端设置的eureka.instance.lease-expiration-duration-inseconds定义，默认值为90s）内没有收到心跳，则会注销此实例。

自我保护机制：
自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。

        自我保护机制的工作机制是：如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，此时会出现以下几种情况：
1. Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2. Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
3. 当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
        因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像ZK那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。

7 Ribbon负载均衡

负载均衡一般分为服务器端负载均衡和客户端负载均衡

        服务器端负载均衡，比如Nginx、F5这些，请求到达服务器之后由这些负载均衡器根据一定的
算法将请求路由到目标服务器处理。

        客户端负载均衡，比如我们要说的Ribbon，服务消费者客户端会有一个服务器地址列表，调用方在请求前通过一定的负载均衡算法选择一个服务器进行访问，负载均衡算法的执行是在请求客户端进行。

        Eureka一般配合Ribbon进行使用，Ribbon利用从Eureka中读取到服务信息，在调用服务提供者提供的服务时，会根据一定的算法进行负载。

Ribbon负载均衡策略

1.RoundRobinRule：轮询策略

默认超过10次获取到的server都不可用，会返回一个空的server

2.RandomRule：随机策略

如果随机到的server为null或者不可用的话，会while不停的循环选取

3.RetryRule：重试策略

一定时限内循环重试。默认继承RoundRobinRule，也支持自定义注入，RetryRule会在每次选取之后，对选举的server进行判断，是否为null，是否alive，并且在500ms内会不停的选取判断。RoundRobinRule失效的策略是超过10次，RandomRule是没有失效时间的概念，只要serverList没都挂。

4.AvailabilityFilteringRule：可用过滤策略

遍历serverList，选取出可用的且连接数最小的一个server。该算法里面有一个LoadBalancerStats的成员变量，会存储所有server的运行状况和连接数。如果选取到的server为null，那么会调用RoundRobinRule重新选取。Rule：最小连接数策略

8 Hystrix熔断器

雪崩效应：微服务中，一个请求可能需要多个微服务接口才能实现，会形成复杂的调用链路。服务雪崩效应：是一种因“服务提供者的不可用”（原因）导致“服务调用者不可用”（结果），并将不可用逐渐放大的现象。

扇入：代表着该微服务被调用的次数，扇入大，说明该模块复用性好
扇出：该微服务调用其他微服务的个数，扇出大，说明业务逻辑复杂

扇入大是一个好事，扇出大不一定是好事

假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”

服务雪崩的过程可以分为三个阶段：
1. 服务提供者不可用
2. 重试加大请求流量
3. 服务调用者不可用

雪崩效应解决方案

服务熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，熔断该节点微服务的调用，进行服务的降级，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

服务降级：通俗讲就是整体资源不够用了，先将一些不关紧的服务停掉（调用我的时候，给你返回一个预留的值，也叫做兜底数据），待渡过难关高峰过去，再把那些服务打开。服务降级一般是从整体考虑，就是当某个服务熔断之后，服务器将不再被调用，此刻客户端可以自己准备一个本地的fallback回调，返回一个缺省值，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。

服务限流：服务降级是当服务出问题或者影响到核心流程的性能时，暂时将服务屏蔽掉，待高峰或者问题解决后再打开；但是有些场景并不能用服务降级来解决，比如秒杀业务这样的核心功能，这个时候可以结合服务限流来限制这些场景的并发/请求量

限流措施也很多，比如

1.限制总并发数（比如数据库连接池、线程池）
2.限制瞬时并发数（如nginx限制瞬时并发连接数）
3.限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速
率）
4.限制远程接口调用速率、限制MQ的消费速率等

Hystrix舱壁模式

线程池隔离策略

如果不进行任何设置，所有熔断方法使用一个Hystrix线程池（10个线程），如果方法A的请求把10个线程都用了，方法2请求处理的时候压根都没法去访问B，因为没有线程可用，并不是B服务不可用。

为了避免问题服务请求过多导致正常服务无法访问，Hystrix 不是采用增加线程数，而是单独的为每一个控制方法创建一个线程池的方式，这种模式叫做“舱壁模式"，也是线程隔离的手段。

9 Feign远程调用

        Feign是Netflix开发的一个轻量级RESTful的HTTP服务客户端（用它来发起请求，远程调用的），是以Java接口注解的方式调用Http请求，而不用像Java中通过封装HTTP请求报文的方式直接调用，Feign被广泛应用在Spring Cloud 的解决方案中。

服务消费者工程（静态化微服务）启动类使用注解@EnableFeignClients添加Feign支持

注意：
1）@FeignClient注解的name属性用于指定要调用的服务提供者名称，和服务提供者yml文件中
spring.application.name保持一致
2）接口中的接口方法，就好比是远程服务提供者Controller中的Hander方法（只不过如同本地调用了），那么在进行参数绑定的时，可以使用@PathVariable、@RequestParam、@RequestHeader等，这也是OpenFeign对SpringMVC注解的支持，但是需要注意value必须设置，否则会抛出异常
3) @FeignClient(name = "lagou-service-product")，name在消费者微服务中只能出现一次。（升级Spring Boot 2.1.0 Spring Cloud Greenwich.M1 版本后，在2个Feign接口类内定义相同的名字，
@FeignClient(name = 相同的名字 就会出现报错，在之前的版本不会提示报错），所以最好将调用一个微服务的信息都定义在一个Feign接口中。

Feign对负载均衡的支持
Feign 本身已经集成了Ribbon依赖和自动配置，因此我们不需要额外引入依赖，可以通过
ribbon.xx 来进 行全局配置,也可以通过服务名.ribbon.xx 来对指定服务进行细节配置配置（参考之前，此处略）
Feign默认的请求处理超时时长1s，有时候我们的业务确实执行的需要一定时间，那么这个时候，我们就需要调整请求处理超时时长，Feign自己有超时设置，如果配置Ribbon的超时，则会以Ribbon的为准

Feign对熔断器的支持

在Feign客户端工程配置文件（application.yml）中开启Feign对熔断器的支持

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

Feign的超时时长设置那其实就上面Ribbon的超时时长设置
Hystrix超时设置（就按照之前Hystrix设置的方式就OK了）

注意：
1）开启Hystrix之后，Feign中的方法都会被进行一个管理了，一旦出现问题就进入对应的回退逻辑处理
2）针对超时这一点，当前有两个超时时间设置（Feign/hystrix），熔断的时候是根据这两个时间的最小
值来进行的，即处理时长超过最短的那个超时时间了就熔断进入回退降级逻辑

Feign对请求压缩和响应压缩的支持

Feign 支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。通过下面的参数 即可开启请求与响应的压缩功能：

feign:
hystrix:
enabled: true
#开启请求和响应压缩
compression:
request:
enabled: true #默认不开启
mime-types: text/html,application/xml,application/json # 设置压缩的数据类型，
此处也是默认值
min-request-size: 2048 # 设置触发压缩的大小下限，此处也是默认值
response:
enabled: true #默认不开启

10 GateWay网

网关：微服务架构中的重要组成部分

        Spring Cloud GateWay是Spring Cloud的一个全新项目，目标是取代Netflix Zuul，它基于
Spring5.0+SpringBoot2.0+WebFlux（基于高性能的Reactor模式响应式通信框架Netty，异步非阻塞模型）等技术开发，性能高于Zuul，官方测试，GateWay是Zuul的1.6倍，旨在为微服务架构提供一种简单有效的统一的API路由管理方式。
        Spring Cloud GateWay不仅提供统一的路由方式（反向代理）并且基于 Filter(定义过滤器对请求过滤，完成一些功能) 链的方式提供了网关基本的功能，例如：鉴权、流量控制、熔断、路径重写、日志监控等。

网关在架构中的位置

 核心概念

 Spring Cloud GateWay天生就是异步非阻塞的，基于Reactor模型（同步非阻塞的I/O多路复用机
制）

一个请求—>网关根据一定的条件匹配—匹配成功之后可以将请求转发到指定的服务地址；而在这
个过程中，我们可以进行一些比较具体的控制（限流、日志、黑白名单）

路由（route）： 网关最基础的部分，也是网关比较基础的工作单元。路由由一个ID、一个目标
URL（最终路由到的地址）、一系列的断言（匹配条件判断）和Filter过滤器（精细化控制）组成。如果断言为true，则匹配该路由。

断言（predicates）：predicate是Java 8中引入的一个新功能，就和我们平时在项目中写单元测试时用到的Assertion差不多，Predicate接收一个判断条件，返回一个ture或false的布尔值结果，告知调用方判断结果。你也可以通过and（与），or（或）和negative（非）三个操作符将多个Predicate串联在一块共同判断。匹配Http请求中的所有内容（包括请求头、请求参数等）（类似于nginx中的location匹配一样），如果断言与请求相匹配则匹配该路由。

过滤器（filter）：一个标准的Spring webFilter，使用过滤器，可以在请求之前或者之后执行业务
逻辑。

GateWay工作流程

客户端（GateWay Client）<---->网关控制器映射(GateWay Handler Mapping)：找到与请求相匹配的路由，将其发送到Gateway web Handler   <——>网关Web控制器(Gateway web Handler)：通过指定的过滤器将请求发送到我们的实际的服务执行业务逻辑，然后返回 <—  过滤器(Filter)：执行前 pre：鉴权、参数校验、流量限制、日志记录 ， 执行后 post：响应内容、修改响应头、日志  —> 微服务（Proxied Service）

结合网关所在位置图片一起食用

官方介绍：
客户端向Spring Cloud GateWay发出请求，然后在GateWay Handler Mapping中找到与请求相匹配的路由，将其发送到GateWay Web Handler；Handler再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（pre）或者之后（post）执行业务逻辑。

Filter在“pre”类型过滤器中可以做参数校验、权限校验、流量监控、日志输出、协议转换等，在“post”类型的过滤器中可以做响应内容、响应头的修改、日志的输出、流量监控等。

 

GateWay路由规则详解

GateWay动态路由详解

动态路由实现步骤如下

1.pom.xml中添加注册中心客户端依赖（因为要获取注册中心服务列表，eureka客户端已经引入）

2.动态路由配置：uri以 lb: //开头（lb代表从注册中心获取服务），后面是需要转发到的服务名
称

GateWay过滤器

从过滤器生命周期（影响时机点）的角度来说，主要有两个pre和post：

pre:这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。

post：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的 HTTPHeader、收集统计信息和指标、将响应从微服务发送给客户端等。

从过滤器类型的角度：

GateWayFilter：应用到单个路由路由上

GlobalFilter：应用到所有的路由上（常用）

GateWay高可用

网关作为非常核心的一个部件，如果挂掉，那么所有请求都可能无法路由处理，因此我们需要做
GateWay的高可用。

GateWay的高可用很简单：可以启动多个GateWay实例来实现高可用，在GateWay的上游使用
Nginx等负载均衡设备进行负载转发以达到高可用的目的。