SpringCloud面试总结

Mynah886

已于 2023-02-09 19:00:38 修改

阅读量822

点赞数

于 2019-09-26 13:39:57 首次发布

本文链接：https://blog.csdn.net/Mynah886/article/details/101437717

版权

面试专栏收录该内容

12 篇文章 0 订阅

订阅专栏

1. 异常的处理

2. AOP利用-参数统一打印输出，判断拦截返回值是否格式一致

3.Fegin调用实现

4. 配置注解

5. GateWay 和 Zuul

6. SpringCloud的5大核心组件

7. Hystrix

7.1 histryic熔断机制

8. 注册中心ZooKeeper、Eureka 哪个更合适

9.4 feign是客户端负载还是服务端负载

1. 异常的处理

     @ControllerAdvice("com.beyondsoft.rdc.cloud.msa")
    @ExceptionHandler(Exception.class)
   @RestControllerAdvice ---包括@ControllerAdvice + @ResponseBody

2. AOP利用-参数统一打印输出，判断拦截返回值是否格式一致

    @Aspect
   @Pointcut("@within(org.springframework.web.bind.annotation.RestController)")
   @Before("webLog()")
   @AfterReturning(returning = "obj", pointcut = "webLog()")

3.Fegin调用实现

A. @FeignClient(value = "fnb-shopmgr", fallback = DownloadWeChatFileServiceImpl.class)
---URL，方法名称，参数一致

B. @FeignClient(value = "${service.pgs-promotion.name}", url = "${service.pgs-promotion.url}",
fallbackFactory = IUserFeignFallbackFactory.class)

4. 配置注解

@Configuration
@AutoConfigureAfter(MybatisConfiguration.class)
@EnableTransactionManagement

@DependsOn 此注解可以用来控制bean的创建顺序，该注解用于声明当前bean依赖于另外一个bean。所依赖的bean会被容器确保在当前bean实例化之前被实例化。

@Order标注

@Order这个标注能进行加载顺序的控制

严格的说，不是所有的Bean都可以通过@Order这个标注进行顺序的控制。你把@Order这个标注加在普通的方法上或者类上一点鸟用都没有。

@Order注解用于切面的优先级指定；在 4.0 之后对它的功能进行了增强，支持集合的注入时，指定集合中 bean 的顺序，并且特别指出了，它对于当实例的 bean 之间的顺序，没有任何影响。

目前用的比较多的有以下3点：

控制AOP的类的加载顺序，也就是被@Aspect标注的类
控制ApplicationListener实现类的加载顺序
控制CommandLineRunner实现类的加载顺序

@AutoConfigureOrder只能改变外部依赖的@Configuration的顺序。如何理解是外部依赖呢。

能被你工程内部scan到的包，都是内部的Configuration，而spring引入外部的Configuration，都是通过spring特有的spi文件：spring.factories

换句话说，@AutoConfigureOrder能改变spring.factories中的@Configuration的顺序。

5. GateWay 和 Zuul

Zuul的工作原理，它本质上用了java.servlet API，实现了一个有网关功能的servlet。做了几件事：前置路由、路由、后置路由、异常处理。

Zuul处理的是http请求Zuul的抽象写的非常简单易，zuul-core包不依赖Spring，依赖的包很少，没有提供异步支持，流控等均由hystrix支持。同步io。使用的是阻塞式的 API，不支持长连接，比如 websockets。

   filterType()方法 return "per" ---在请求路由之前调用
   filterOrder()方法 return 0; ---数字越大越靠后
   shouldFilter()：返回一个boolean值来判断该过滤器是否要执行，true表示执行，false表示不执行。
四种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期。
(1) PRE 过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
(2) ROUTING 过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。
(3) POST 在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
(4) ERROR 在其他阶段发生错误时执行该过滤器。
除了默认的过滤器类型，Zuul还允许我们创建自定义的过滤器类型。例如，我们可以定制一种STATIC类型的过滤器，直接在Zuul中生成响应，而不将请求转发到后端的微服务。

Gatway提供了非常丰富的filter实现和灵活的RoutePredicateFactory（route匹配规则）依赖spring-boot-starter-webflux和spring-cloud-starter，提供了异步支持；提供函数式编程api，使用起来方便快捷；提供了抽象流控，并默认实现了RedisRateLimiter；提供了抽象负载均衡；支持HttpClient、WebClient代理请求。

同点：底层都是servlet，两者均是web网关，处理的是http请求。

6. SpringCloud的5大核心组件

1) Eureka注册中心,实现服务治理（服务注册与发现）;由两个组件组成：Eureka服务端和Eureka客户端。Eureka服务端用作服务注册中心。支持集群部署。Eureka客户端是一个java客户端，用来处理服务注册与发现。在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。当eueaka掉线时，服务还能请求进来吗？不会，注册中心服务端会copy一份注册信息到注册中心客户端。

2) Zuul服务网关, 1) 网关维护着所有的微服务，客户端通过请求到网关，由网关分发到不同的微服务，这样客户端就只需要维护网关的域名即可。拦截请求、过滤非法请求、鉴权等。

3) Feign服务调用：微服务架构中，微服务之间调用的一个组件。进行服务间远程调用。

4) Ribbon负载均衡：分摊请求压力，提高响应速度，默认提供了轮循，随机等负载均衡的算法，同时我们也可以自定义负载均衡的算法。

a. 随机，通过随机选择服务进行执行，一般这种方式使用较少;

b. 轮训，负载均衡默认实现方式，请求来之后排队处理;

c. 加权轮训，通过对服务器性能的分型，给高配置，低负载的服务器分配更高的权重，均衡各个服务器的压力;

d. 地址Hash，通过客户端请求的地址的HASH值取模映射进行服务器调度。

e. 最小链接数;即使请求均衡了，压力不一定会均衡，最小连接数法就是根据服务器的情况，比如请求积压数等参数，将请求分配到当前压力最小的服务器上。

在分布式框架中负载均衡为客户端：

f 具体流程：A客户端负载均衡Ribbon从注册中心Eureka Server中获取服务列表

B客户端负载均衡Ribbon根据负载均衡算法分发请求

4.5 Hystix熔断器：在分布式框架中，当某个业务单元发生故障，通过熔断器的路由监控，像调用方返回一个错误响应，而不是长时间等待，导致故障服务被长时间占用。

7. Hystrix

防雪崩利器，具备服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）

服务降级: 优先核心服务，非核心服务不可用或弱可用。通过HystrixCommand注解指定。

fallbackMethod(回退函数)中具体实现降级逻辑。

7.1 histryic熔断机制

降级有个类似的词称为服务熔断，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。

服务降级就是当某个服务熔断后，服务端准备一个本地的回退回调，返回一个缺省值。

超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值.

熔断，当失败率(如因网络故障/超时造成的失败率高)达到阀值自动触发降级，熔断器触发的快速失败会进行快速恢复。通俗理解：熔断就是具有特定条件的降级。熔断是出错后如果开启了熔断将会一定时间不在访问application service。

保证服务链条的完整，避免服务雪崩。

8. 注册中心ZooKeeper、Eureka 哪个更合适

Eureka本身是Netflix开源的一款提供服务注册和发现的产品，并且提供了相应的Java封装。在它的实现中，节点之间相互平等，部分注册中心的节点挂掉也不会对集群造成影响，即使集群只剩一个节点存活，也可以正常提供发现服务。

哪怕是所有的服务注册节点都挂了，Eureka Clients（客户端）上也会缓存服务调用的信息。这就保证了我们微服务之间的互相调用足够健壮。

Zookeeper主要为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。曾经是Hadoop项目中的一个子项目，用来控制集群中的数据，目前已升级为独立的顶级项目。很多场景下也用它作为Service发现服务解决方案。

在分布式系统中有个著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；

Zookeeper是基于CP(数据一致性&分区故障的容错性)来设计的，即任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。从实际情况来分析，在使用Zookeeper获取服务列表时，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。所以说，Zookeeper不能保证服务可用性。

诚然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是zookeeper设计成CP的原因。但是对于服务发现场景来说，情况就不太一样了：针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下，也好过因为无法获取实例信息而不去消费。 （尝试一下可以快速失败，之后可以更新配置并重试）所以，对于服务发现而言，可用性比数据一致性更加重要——AP胜过CP。

Eureka: 而Spring Cloud Netflix在设计Eureka时遵守的就是AP原则。Eureka Server也可以运行多个实例来构建集群，解决单点问题，但不同于ZooKeeper的选举leader的过程，Eureka Server采用的是Peer to Peer对等通信。这是一种去中心化的架构，无master/slave区分，每一个Peer都是对等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的serviceUrl指向其他节点。每个节点都可被视为其他节点的副本。

如果某台Eureka Server宕机，Eureka Client的请求会自动切换到新的Eureka Server节点，当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行replicateToPeer（节点间复制）操作，将请求复制到其他Eureka Server当前所知的所有节点中。

一个新的Eureka Server节点启动后，会首先尝试从邻近节点获取所有实例注册表信息，完成初始化。Eureka Server通过getEurekaServiceUrls()方法获取所有的节点，并且会通过心跳续约的方式定期更新。默认配置下，如果Eureka Server在一定时间内没有接收到某个服务实例的心跳，Eureka Server将会注销该实例（默认为90秒，通过eureka.instance.lease-expiration-duration-in-seconds配置）。当Eureka Server节点在短时间内丢失过多的心跳时（比如发生了网络分区故障），那么这个节点就会进入自我保护模式。

什么是自我保护模式？默认配置下，如果Eureka Server每分钟收到心跳续约的数量低于一个阈值（instance的数量(60/每个instance的心跳间隔秒数)自我保护系数），并且持续15分钟，就会触发自我保护。在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学前面提到过，那就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。该模式可以通过eureka.server.enable-self-preservation = false来禁用，同时eureka.instance.lease-renewal-interval-in-seconds可以用来更改心跳间隔，eureka.server.renewal-percent-threshold可以用来修改自我保护系数（默认0.85）。

ZooKeeper基于CP，不保证高可用，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。Eureka基于AP，能保证高可用，即使所有机器都挂了，也能拿到本地缓存的数据。作为注册中心，其实配置是不经常变动的，只有发版和机器出故障时会变。对于不经常变动的配置来说，CP是不合适的，而AP在遇到问题时可以用牺牲一致性来保证可用性，既返回旧数据，缓存数据。

所以理论上Eureka是更适合做注册中心。而现实环境中大部分项目可能会使用ZooKeeper，那是因为集群不够大，并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题。

9. feign 使用和详解

9.1 feign是？

Feign是一个java的到http客户端绑定的开源项目。 Feign的主要目标是将Java Http 客户端变得简单。Feign 是对 Ribbon的封装，调用起来更简单，用注解来进行配置。Feign的源码地址：https://github.com/OpenFeign/feign

9.2 Feign工作原理

feign是一个伪客户端，即它不做任何的请求处理。Feign通过处理注解生成request，从而实现简化HTTP API开发的目的，即开发人员可以使用注解的方式定制requestApi模板，在发送httpRequest请求之前，feign通过处理注解的方式替换掉request模板中的参数，这种实现方式显得更为直接、可理解。

总结说，Feign的源码实现的过程如下：

a. 首先通过@EnableFeignCleints注解开启FeignCleint

b. 根据Feign的规则实现接口，并加@FeignCleint注解, 程序启动后，会进行包扫描，扫描所有的@FeignCleint的注解的类，并将这些信息注入到ioc容器中。

c. 当接口的方法被调用，通过jdk的代理，来生成具体的RequesTemplate. RequesTemplate再生成Request

d. Request交给Client去处理，其中Client可以是HttpUrlConnection、HttpClient也可以是Okhttp

e. 最后Client被封装到LoadBalanceClient类，这个类结合类Ribbon做到了负载均衡。

FeignClient标签的常用属性如下：

value: 服务名; path: 定义当前FeignClient的统一前缀

name：指定FeignClient的名称，如果项目使用了Ribbon，name属性会作为微服务的名称，用于服务发现

url: url一般用于调试，可以手动指定@FeignClient调用的地址

decode404:当发生http 404错误时，如果该字段位true，会调用decoder进行解码，否则抛出FeignException

configuration: Feign配置类，可以自定义Feign的Encoder、Decoder、LogLevel、Contract

fallback: 定义容错的处理类，当调用远程接口失败或超时时，会调用对应接口的容错逻辑，fallback指定的类必须实现@FeignClient标记的接口

fallbackFactory: 工厂类，用于生成fallback类示例，通过这个属性我们可以实现每个接口通用的容错逻辑，减少重复的代码原理如下：see below源码

9.3 源码

code很直观的看到真正发起服务请求调用的是 feign.Client#execute。

feign.Client 是一个接口，它有两个实现类：

feign.Client.Default

org.springframework.cloud.openfeign.ribbon.LoadBalancerFeignClient

其中LoadBalancerFeignClient为Ribbon负载均衡客户端实现类。

Feign是如何注册LoadBalancerFeignClient作为其客户端调用实现的。首先想到的就是自动配置类FeignRibbonClientAutoConfiguration。

a. @ConditionalOnClass({ ILoadBalancer.class, Feign.class }) 其中 ILoadBalancer.class 是 Ribbon 依赖中的类。换句话说，该配置需要 Ribbon 和 Feign 的相关依赖都引入才会生效。

b.@AutoConfigureBefore(FeignAutoConfiguration.class) 如果该自动配置类生效，则在 FeignAutoConfiguration 之前进行配置，因为 FeignAutoConfiguration 关联到了 Feign Client 的代理对象的实例化，而其中真实发起请求调用的 Client 对象实例在 Feign Client 调用 Fiegn.Build 进行实例化时 Client 实现对象需要提前实例化。换句话说，如果 Client 对应Ribbon 的实现类 LoadBalancerFeignClient 存在，就是用 Ribbon 的负载均衡客户端进行请求调用处理，反之，使用默认的 feign.Client.Default。

c.@Import({DefaultFeignLoadBalancedConfiguration.class}) DefaultFeignLoadBalancedConfiguration 是一个 Bean 配置类，对 LoadBalancerFeignClient 进行了实例化配置。

LoadBalancerFeignClient 如何衔接 Ribbon 实现客户端负载均衡:

前提是：Feign Client 最终执行调用的是Client#execute方法，而此时Client实现类是 LoadBalancerFeignClient。调用LoadBalancerFeignClient#execute需要传递两个参数：Request 和 Request.Options。 Request.Options 是进行 Ribbon 配置获取的选择条件

LoadBalancerFeignClient#execute：

public class LoadBalancerFeignClient implements Client {

@Override

public Response execute(Request request, Request.Options options) throws IOException {

// 根据条件参数 asUri = http://provider/user/save?userId=1

URI asUri = URI.create(request.url());

// 根据条件参数 clientName = provider

String clientName = asUri.getHost();

// 根据条件参数uriWithoutHout = http:///user/save?userId=1

URI uriWithoutHost = cleanUrl(request.url(), clientName);

// 根据 uriWithoutHost 构造 RibbonReuqest

FeignLoadBalancer.RibbonRequest ribbonRequest =

new FeignLoadBalancer.RibbonRequest( this.delegate, request, uriWithoutHost);

// 获取请求相关配置信息

IClientConfig requestConfig = getClientConfig(options, clientName);

// 执行操作

return

lbClient(clientName).executeWithLoadBalancer(ribbonRequest, requestConfig).toResponse(); } }

代码 LoadBalancerFeignClient#execute 大体流程如下：

Step1 封装Ribbon请求信息

step2 获取 Ribbon 请求相关配置信息 LoadBalancerFeignClient#getClientConfig

step3 根据封装的 RibbonRequest (ribbon请求) 和 requestConfig (ribbon请求配置属性) 发起请求。

9.4 feign是客户端负载还是服务端负载

客户端负载均衡！什么是客户端负载均衡呢？在前面注册数据微服务里，注册8001和8002两个微服务，Ribbon会从注册中心获知这个信息，然后由Ribbon这个客户端自己决定是调用哪个，这个就叫做客户端负载均衡。Cloud有两种服务间调用的方式，Ribbon和Feign！

Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单, 它的使用方法是定义一个接口，然后在上面添加注解，同时也支持JAX-RS标准的注解。Feign也支持可拔插式的编码器和解码器。Spring Cloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

9.5 feigin 的优点

feign采用的是基于接口的注解; feign整合了ribbon，具有负载均衡的能力; 整合了Hystrix，具有熔断的能力

Ribbon添加maven依赖 spring-starter-ribbon 使用@RibbonClient(value="服务名称") 使用RestTemplate调用远程服务对应的方法

feign添加maven依赖 spring-starter-feign 服务提供方提供对外接口调用方使用在接口上使用@FeignClient("指定服务名")

Ribbon和Feign都是用于调用其他服务，不过方式不同。

1、启动类使用的注解不同，Ribbon使用的时@RibbonClient，Feign用的时@EnableFeignClients

2、服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口使用@FeignClient声明。

3、调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。

Feign则是在Ribbon的基础进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可。不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。

10. Ribbon原理详解和自定义扩展

Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是一个工具类框架，但它不像服务注册中心、配置中心、API网关那样需要独立部署。它几乎存在于每一个Spring Cloud构建的微服务和基础设施中。微服务间的调用、API网关的请求转发等内容，实际上都是通过Ribbon来实现的。包括Spring Cloud的另一种服务调用方式Feign，也是基于Ribbon实现的。

Ribbon负载均衡策略：核心组件是IRule，IRule是所有负载均衡策略的父接口，其子类有：

每一个子类就是一种负载均衡策略

•RandomRule：随机选取负载均衡策略，随机Random对象，在所有服务实例中随机找一个服务的索引号，然后从上线的服务中获取对应的服务。

•RoundRobinRule：线性轮询负载均衡策略。

•WeightedResponseTimeRule：响应时间作为选取权重的负载均衡策略，根据平均响应时间计算所有服务的权重，响应时间越短的服务权重越大，被选中的概率越高。刚启动时，如果统计信息不足，则使用线性轮询策略，等信息足够时，再切换到WeightedResponseTimeRule。

•RetryRule：使用线性轮询策略获取服务，如果获取失败则在指定时间内重试，重新获取可用服务。

•ClientConfigEnabledRoundRobinRule：默认通过线性轮询策略选取服务。通过继承该类，并且对choose方法进行重写，可以实现更多的策略，继承后保底使用RoundRobinRule策略。

•BestAvailableRule：继承自ClientConfigEnabledRoundRobinRule。从所有没有断开的服务中，选取到目前为止请求数量最小的服务。

•PredicateBasedRule：抽象类，提供一个choose方法的模板，通过调用AbstractServerPredicate实现类的过滤方法来过滤出目标的服务，再通过轮询方法选出一个服务。

•AvailabilityFilteringRule：按可用性进行过滤服务的负载均衡策略，会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，还有并发的连接数超过阈值的服务，然后对剩余的服务列表进行线性轮询。

•ZoneAvoidanceRule：本身没有重写choose方法，用的还是抽象父类PredicateBasedRule的choose。

自定义负载均衡策略：

代码自定义策略，代码自定义负载均衡策略需要注意，要避免Spring Boot的包扫描，自定义的规则必须在Eureka的规则实例化以后再实例化才会生效。

1.新建负载均衡策略配置类，在启动类SpringBootConsumerApplication的上层新建config包，然后新建LoadBalanced类。使用LoadBalanced类注册一个新的IRule来替换Eureka。这里我们想使用哪种策略就可以new哪种策略。

2.新建自定义负载均衡策略类, con.mynah.config包下新建loadbalancer包，再新建GlobalMyRule类，我自定义的负载均衡策略是始终取服务列表的第一个，其他自定义策略参考这种格式修改即可。

3 指定策略规则,SpringBootConsumerApplication类上新增注解@RibbonClient(name = "spring-boot-provider",configuration=cn.wbnull.config.LoadBalanced.class)表示spring-boot-provider服务使用con.mynah.config.LoadBalanced提供的负载均衡策略。

然后我们LoadBalanced类可以new一个GlobalMyRule : @Configuration

配置文件自定义策略: 上面我使用代码自定义策略，使用LoadBalanced类配置负载均衡，这种方式虽然能够实现自定义负载均衡策略，但当我们有大量配置类时，对每个Ribbon客户端的配置信息将会分散在这些配置类中，这样管理起来极其麻烦。Camden版本之后，Spring Cloud Ribbon对Ribbon客户端的个性化配置进行了优化，可以通过服务id名称.ribbon.参数=值的形式进行配置，如：spring-boot-provider.ribbon.

NFLoadBalancerRuleClassName. con.mynah.springbootconsumer.config.loadbalancer.GlobalMyRule

Ribbon配置的优先级：属性配置 > Java配置 > Netflix Ribbon默认配置

11. Gateway

Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul。在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。

使用了一个RouteLocatorBuilder的bean去创建路由，除了创建路由RouteLocatorBuilder可以让你添加各种predicates和filters，predicates断言的意思，顾名思义就是根据具体的请求的规则，由具体的route去处理，filters是各种过滤器，用来对请求做各种判断和修改。

工作原理

跟 Zuul相差不多，最大区别是 Gateway的 Filter 只有 pre 和 post 两种。

网关有三大概念。

路由：路由是构建网关的基本模块，它由ID，目标URI，一系列的断言Predicates和过滤器Filters组成，如果断言为true，则匹配该路由。

断言：参考Java8的java.util.function.Predicate，开发人员可以匹配HTTP请求中的所有内容，例如请求头或请求参数，如果请求与断言相匹配则进行路由。

过滤：Spring框架中GatewayFilter的实例，使用过滤器，可以载请求被路由前或者后对请求进行修改。

actuate中定义了一个叫GatewayControllerEndpoint的类，这个类提供一些对外的接口，可以获取网关的一些信息，比如路由的信息，改变路由地址等等

config中定义了一些启动时去加载的类，配置路由信息和读取你的配置文件就在这里完成

discovery中定义了注册中心相关的内容，包括注册中心的路由等

event定义了一些事件他们都继承自ApplicationEvent，对事件发布不了解的可以去看看spring的代码

filter中定义了spring cloud gateway实现的一些过滤器

handler中定义了很多Predicate相关的Factory

route就是我们路由的相关

support是工具包。

核心处理流程：

a. Gateway的客户端向Gateway发起请求，请求首先会被HttpWebHandlerAdapter进行提取组装成网关的上下文，然后网关的上下文会传递到DispatcherHandler。

b. DispatcherHandler是所有请求的分发处理器，DispatcherHandler主要负责分发请求对应的处理器，比如将请求分发到对应RoutePredicateHandlerMapping(路由断言处理器映射器）。

c. 路由断言处理映射器主要用于路由的查找，以及找到路由后返回对应的FilteringWebHandler。FilteringWebHandler主要负责组装Filter链表并调用Filter执行一系列Filter处理，然后把请求转到后端对应的代理服务处理，处理完毕后，将Response返回到Gateway客户端。

d. 在Filter链中，过滤器可以在转发请求之前处理或者接收到被代理服务的返回结果之后处理。所有的Pre类型的Filter执行完毕之后，才会转发请求到被代理的服务处理。被代理的服务把所有请求完毕之后，才会执行Post类型的过滤器。

Mynah886

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
2
评论
SpringCloud面试总结

1. 异常的处理 @ControllerAdvice("com.beyondsoft.rdc.cloud.msa") @ExceptionHandler(Exception.class) @RestControllerAdvice ---包括@ControllerAdvice + @ResponseBody2. AOP利用-参数统一打印输出，判断拦截返回值是否格式一致...
复制链接

扫一扫