【Spring】SpringCloud（Gateway、Eureka、Ribbon、Hytrix、Feign等）面试题

Gateway

过滤器和网关的对比

过滤器：对单个服务器的请求进行拦截控制
网关：对所有的服务器的请求进行拦截控制

zuul 和 spring cloud gateway 的对比

zuul：是 Netflix 的，基于 servlet，阻塞式的 api，不支持长连接。
gateway：是 springcloud 的，基于 Spring5 构建，响应式非阻塞的 Api，支持长连接。

网关与 nginx 区别

相同点：都是可以实现对 api 接口的拦截，负载均衡、反向代理、请求过滤等，可以实现和网关一样的效果。
不同点：
Nginx 采用 C 语言编写，Gateway 是用 Java 语言编写的，能够更好让我们使用 java 语言来实现对请求的处理。
Nginx 属于服务器端负载均衡器，Gateway 属于本地负载均衡器。

Gateway 的组成

路由：网关的基本模块，有 ID，目标 URI，一组断言和一组过滤器组成；
断言：是访问该路由的访问规则，可以用来匹配来自 http 请求的任何内容，例如 headers 或者参数；
过滤器：这个就是我们平时说的过滤器，用来过滤一些请求的，gateway有自己默认的过滤器，我们也可以自定义过滤器，要实现两个接口，Ordered 和 Globalfilter。

Gateway的过滤器都有哪些

1. 局部过滤器GatewayFilter
   内置局部过滤器工厂：AddRequestHeader、AddRequestParameter、AddResponseHeader、Hytrix、RedirectTo、SaveSession等；
2. 全局过滤器GlobalFilter
   内置全局过滤器：
   • LoadBalanceClientFilter：通过负载均衡客户端，根据路由的url解析转换成真实的请求url；
   • NettyRoutingFilter、NettyWriteResponseFilter：通过HttpClient转发请求真实的url，并将响应写入到当前的请求响应中；
   • WebsocketRoutingFilter：负责处理Websocket类型的请求响应信息；
   • ForwardPathFilter：解析路径，并将路径转发；
   • RouteToRequestUrlFilter：转换路由中的uri
   • WebClientHttpRoutingFilter、WebClientWriteResponseFilter：通过WebClient转发请求真是的url，并将响应写入到当前的请求响应中。

怎么用Gateway做负载均衡

在gateway的配置文件中，使用lb配置服务，而非直接使用IP:PORT

routes: 
	- id: predicated_domo_route
	  uri: lb://spring-cloud-one-service
	  ……

Gateway配置文件说明

spring: 
  cloud:
    gateway:
      routes: 
        - id: demo_route
          uri: lb://spring-cloud-one-service # 路由到one-service模块，要实现负载均衡，不能直接写IP和端口
          predicates: # 断言，如果有多个，必须同时满足
            - Path=/gateway/**
            - Parameter=emailAddr
          filter: 
            - StripPrefix=1 # 表示去除1个前缀
      httpclient:
        connect-timeout: 1000 # 配置连接超时
        response-timeout: 5s # 配置响应超时

注册中心

CAP

一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）

Eureka和Zookeeper的区别

CAP

Eureka是AP的，Zookeeper是CP的。

节点宕机处理

Zookeeper会出现一种情况，就是当master节点宕掉，需要重新进行leader选举，这个时间在30~120s，期间整个zk集群都是不可用的。
而Eureka有限保证了可用性，节点平等，几个节点挂掉也不会影响其他节点的正常工作。但是查到的信息可能不是最新的，不保证强一致性。
此外，Eureka还有一种自我保护机制：如果在15分钟内超过**85%**的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务；
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)；
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中。

Eureka和Nacos的区别

CAP

Eureka只支持AP；
Nacos支持CP和AP两种：如果注册Nacos的client节点注册时是ephemeral=true，即为临时节点，那么Nacos集群对这个client节点就是AP，反之不是临时节点，就是CP。

Nacos支持CP和AP两种：默认是AP，设置CP有两种方式：

1. curl -X PUT ‘$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP’；
2. 配置修改：

#false为永久实例，true表示临时实例开启，注册为临时实例
spring.cloud.nacos.discovery.ephemeral=false

连接方式

Eureka使用定时发送和服务进行联系，属于短连接；
Nacos使用的是Netty和服务直接进行了连接，属于长连接。

操作实例方式

Eureka仅提供了实例列表、状态、错误信息，相比于Nacos过于简单；
Nacos提供了Nacos Console可视化控制界面，可以对实例列表进行监听，对实例进行上下线、配置权重等，并且config server对服务实例提供配置中心，且可以对配置进行CRUD、版本管理。

自我保护机制

1. 保护方式不同
   Eureka保护方式：当在短时间内，统计续约失败的比例，如果达到一定阈值，则会出发自我保护机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关（eureka.server.enable-self-preservation: false）；
   Nacos保护方式：当域名健康实例占总服务实例的比例小于阈值时，无论实例是否健康，都会将这个实例返回给客户端。这样做虽然损失了一部分流量，但保证了集群的剩余健康实例能正常工作。
2. 范围不同
   Nacos的阈值是针对某个具体Service的，而不是针对所有服务的。但Eureka的自我保护阈值是针对所有服务的。

Nacos配置中心

spring:
  application:
    name: nacos-config
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        prefix: ${spring.application.name}
        file-extension: yml
        namespace: 0133bd1e-25c3-4985-96ed-a4e34efdea2e

DataId完整规则

${prefix}-${spring.profiles.active}.${file-extension}

多个项目配置一个共享的Nacos配置怎么实现

config:
  server-addr: 127.0.0.1:8848
  prefix: ${spring.application.name}
  file-extension: yml
  shared-dataids: shareconfig1.yml,shareconfig2.yml
  refreshable-dataids: shareconfig1.yml,shareconfig2.yml

配置多个Nacos的config

config:
  server-addr: 172.26.142.83:8850
    namespace: unify-passport-ci
    group: UP_GROUP
    file-extension: yaml
    extension-configs:
      - data-id: unify-passport-data.yaml
        group: UP_GROUP
        refresh: true
      - data-id: unify-passport-common.yaml
        group: UP_GROUP
        refresh: true

Nacos保存数据用的什么数据库，能不能改用MySQL

默认使用derby数据库，可以改为MySQL，步骤如下：

1. 创建一个数据库，并将nacos/conf目录下的几个sql文件执行；
2. 打开nacos/conf下的application.properties文件，其中有一个Config Module Related Configurations配置模块，按照提示配置即可；

   #*************** Config Module Related Configurations ***************#
   ### If use MySQL as datasource:
   spring.datasource.platform=mysql
   
   ### Count of DB:
   db.num=1
   
   ### Connect URL of DB:
   db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
   db.user.0=nacos
   db.password.0=nacos
   

Consul（了解）

用于实现分布式系统的服务发现与配置。
安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合。

Ribbon 负载均衡

Ribbon是什么

Ribbon的主要功能是提供客户端的软件负载均衡算法；

Nginx和Ribbon的区别

Nginx是反向代理同时实现，是服务端的负载均衡，Ribbon是客户端的负载均衡。

Ribbon实现原理

Ribbon使用discoveryClient从注册中心读取目标服务信息，对同一接口请求进行计数，使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。

Hytrix 断路器

为什么需要断路器

当一个服务调用另外一个服务因为网络缘由或自身缘由出现问题，调用者就会等待被调用者的响应。当更多的服务请求到这些资源致使更多的请求等待，发生连锁效应（雪崩效应）

Hystrix有四种防雪崩方式:

服务降级：接口调用失败就调用本地的方法返回一个空
服务熔断：接口调用失败就会进入调用接口提早定义好的一个熔断的方法，返回错误信息
服务隔离：隔离服务之间相互影响
服务监控：在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。

Feign

什么是Feign

• Feign 是一个声明web服务客户端，这使得编写web服务客户端更容易；
• 他将需要调用的服务方法定义成抽象方法保存在本地就能够了，不需要构建Http请求了，直接调用接口就好了。

Feign的实现原理

通过基于面向接口的动态代理方式生成实现类，将请求调用委托到动态代理的实现类。

Ribbon和Feign的不同

调用方式不同：Ribbon必须构建Http请求，而后经过RestTemplate发送请求；
而Feign是在Ribbon的基础上进行了一次改进，采用接口的形式，将需要调用的服务方法定义成抽象方法保存在本地，直接调用接口就好了。

BUS 消息总线

• Bus就像一个分布式执行器，用于扩展的Spring Boot应用程序的配置文件，但也能够用做应用程序之间的通讯通道。
• Bus不能单独完成通讯，须要配合MQ支持。
• Bus通常是配合Config作配置中心的。
• Config实时刷新也必须采用Bus消息总线。

Stream

轻量级事件驱动微服务框架，可使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka及RabbitMQ。

Config

什么是Config

为了方便对微服务各个环境下的配置进行集中式管理。Spring Cloud Config分为Config Server和Config Client两部分。Config Server负责保存配置文件，而且暴露Http API接口，Config Client经过调用Config Server的接口来读取配置文件。

是否可以实现实时刷新

可以，配合BUS

Security

作用

• 对Zuul代理中的负载均衡从前端到后端服务中获取SSO令牌；
• 资源服务器之间的中继令牌；
• 使Feign客户端表现得像OAuth2RestTemplate（获取令牌等）的拦截器；
• 在Zuul代理中配置下游身份验证。
• 在Spring Boot和Spring Security OAuth2的基础上，能够快速建立实现常见模式的系统，如单点登陆，令牌中继和令牌交换。

Sleuth 链路追踪 & Zipkin 跟踪系统

Sleuth功能

• 链路追踪
• 性能分析
• 数据分析优化链路
• 可视化

Zipkin说明

分布式的跟踪系统。致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。
zipkin会根据调用关系通过Zipkin UI生成依赖关系图，显示了多少跟踪请求通过每个服务，该系统让开发者可通过一个 Web 前端轻松的收集和分析数据，例如用户每次请求服务的处理时间等，可方便的监测系统中存在的瓶颈。
Zipkin提供了可插拔数据存储方式：In-Memory、MySql、Cassandra以及Elasticsearch。

Sleuth上报数据到Zipkin

spring.zipkin.enabled=true                     # 启用
spring.zipkin.base-url=http://127.0.0.1:9411/  # sleuth默认为上报为false， 现设置上报zipkin的服务地址
spring.sleuth.sampler.probability = 1          # span的采样率，默认为 0.1
spring.sleuth.sampler.rate = 10000

Admin

Admin是什么

Admin是基于SpringCloud微服务的开发平台，其中包含具备用户管理、资源权限管理、网关API管理等多个模块。

喜欢本文的朋友不要忘记点一个免费的赞哦，你的赞将是我最大的动力。