【面试】SpringCloud

目录

什么是SpringCloud？

SpringCloud常用组件

什么是Eureka?

Eureka与Nacos的区别？

如何避免Eureka注册中心挂掉？

Eureka的工作原理

Spring Cloud【微服务】的优缺点？

什么是服务雪崩？

如果服务挂了，注册中心要等到90s后剔除，那么在剔除前的这段时间内，挂掉的服务有可能还是会被调用，怎么处理？

你知道EurekaClient服务发现和服务续约每隔30s做一次请求是用什么技术实现的吗？

Ribbon是什么，Ribbon的工作原理讲一下？

Ribbon有哪些负载均衡算法，怎么配置

OpenFeign和Ribbon的区别

OpengFiegn的工作流程（原理）

为什么要使用Eureka

为什么要使用Ribbon

为什么要使用config配置中心

介绍一下Hystrix[熔断器]

Hystrix熔断器中的核心技术，什么是资源隔离？

资源隔离：信号量和线程池的区别？？？

Eureka【服务注册与发现】和Zookeeper【分布式协调服务】的区别？

对于CAP理论，Eureka选择的是AP还是CP？它保证了一致性还是可用性？

那些满足了CP？那些满足了AP？

说一下Eureka的自我保护【防止误删】

什么是Zuul？为什么需要zuul？

Zuul有哪几类Filter,他们的执行顺序是怎么样的【Zuul的执行流程】？

在Zuul中如何实现登录检查？

在Zuul中如何做限流？

网关【Zuul/GateWay】可以用来做什么？

GateWay和Zuul的区别？

GateWay的断言有哪些方式

EureakServer的搭建流程

Ribbon的整合流程【负载均衡】

Feign的整合流程【负载均衡】

Hystrix的整合流程

feign整合Hystrix：

Zuul的整合流程

ConfigServer的整合流程

浏览器发起一个请求，在你的微服务项目中的怎么去执行的？

说下Ribbon和Feign的区别呢

Spring,SpringBoot和SpringCloud的关系以及区别

SpringCloud和SpringCloudAlibaba的区别

SpringCloud几大痛点

Sentinel和Hystrix的区别?为什么要使用Sentinel？

https://blog.csdn.net/m0_37542889/article/details/82428193什么是Sentinel？

Sentinel【哨兵-流量防卫兵】可以如何限流（流量控制）？

Sentinel的 流控模式 有哪些？

Sentinel的 流控效果 有哪些？

---

---

什么是微服务？

        微服务目前没有一个统一的定义，但通常而言，微服务是一种架构模式/风格。

        微服务也是一个分布式系统，它将一个单体应用进行拆分成多个微服务，每个微服务独立开发、维护和部署，每个服务也都可以有自己的数据库，服务之间使用HTTP通信，互相协调完成整个系统的业务。

        它的优点是服务之间解耦合，不同的服务可以有不同的编程语言，支持分布式和集群能够承载更大的服务器压力，支持敏捷开发

        他的缺点是分布式事务很复杂【要保证两个业务同时成功或者同时失败】，部署麻烦，技术成本高（使用多种语言进行编程），服务间通信对性能也有一定的损耗（因为使用了http进行通信）

什么是SpringCloud？

        Spring Cloud是一系列框架的有序集合。Spring Cloud由众多子项目组成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系统及微服务常用的工具，如服务发现注册Eureka、配置中心Config、消息总线Bus、负载均衡Ribbon/openfeign、断路器（熔断器）Hystrix、网关Zuul,链路追踪Sleuth等，满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）。都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

SpringCloud常用组件

EurekaServer注册中心：做服务注册与发现，用来解决服务之间通信（调用） 问题，

Ribbon/OpenFeign（对Ribbon进行包装）负载均衡器：负载均衡器接收客户端的发送的一个请求通过负载均衡算法分配给一个后端服务器（已经使用集群部署的服务器）进行处理，达到负载均衡的效果。（如果当远程服务通过openfeign接口调用出现异常或超时会触发Hystrix熔断机制和降降级策略，返回兜底数据返回给调用方）

Hystrix熔断器：使用Hystrix熔断器的熔断机制、降级策略来解决服务雪崩问题（避免造成堵塞，造成其他服务器也崩了），当服务器出现异常，直接进行熔断降级，快速失败，使用降级策略返回兜底数据给客户端。

Zuul网关：微服务网关是介于客户端和服务器端之间的中间层, 用来接收客户端的所有请求，可以用来实现登录、权限检查等业务【Zuul的主要功能是通过路由和断言对请求进行转发到对应的微服务中进行处理】，

Config分布式配置中心：用来统一管理所有微服务的配置文件。

Bus消息总栈：用来给各个微服务广播消息，可以实现各个微服务配置的自动刷新。

Sleuth链路追踪：用来实时监控各个微服务之间的调用关系，快速定位故障节点

什么是Eureka?

        Eureka是一个服务注册与发现组件,简单说就是用来统一管理微服务的通信地址的组件，它包含了EurekaServer 注册中心(也叫注册中心)和EurekaClient客户端两部分组成，EurekaServer是独立的服务，而EurekaClient需要集成到每个微服务中，解决服务之间的调用问题。

Eureka与Nacos的区别？

1.Nacos与eureka的共同点
        1.都支持服务注册和服务拉取
        2.都支持服务提供者心跳方式做健康检测

2.Nacos与Eureka的区别
        1.Nacos 支持注册中心主动检测客户端状态：临时实例采用心跳模式上报注册中ixn自己的状态，注册中心会进行主动检测 非临时实例【永久实例】是否健康
        2.临时实例心跳不正常会被剔除，非临时实例【永久实例】则不会被剔除
        3.Nacos 支持服务列表变更的消息推送模式（推送到客户端），服务列表更新更及时
        4.Nacos 集群默认采用 AP 【可用性，分区容错性】方式，当集群中存在非临时实例时，采用 CP【一致性，分区容错性】 模式； Eureka 采用 AP 方式

如何避免Eureka注册中心挂掉？

        对Eureka注册中心采用双节点注册（集群），从而来保证高可用，当其中一个Eureka注册中心挂掉，系统仍然能够正常的进行运行。

Eureka的工作原理

 1首先开启EurekaServer注册中心，微服务EurekaClient在启动的时候会将自己的ip地址，端口，服务名等信息提交到EurekaServer注册中心中，注册中心会形成一个微服务的通信地址列表。====>服务注册

2微服务EurekaClient会定时（默认30s）的从EurekaServer注册中心拉取一份微服务通信地址列表缓存到本地，当一个微服务中请求需要调用另一个微服务时，微服务中的Ribbon或者Openfeign就会根据注册中心的微服务通信地址列表通过负载均衡算法（默认使用轮询）的方式去调用一个微服务进行处理请求。===>服务发现。

3EurekaClient微服务会定时的向EurekaServer注册中心发送心跳请求进行续约（提交自己的健康状态。）从而注册中心就不会将当前微服务从微服务通信地址列表中进行剔除，如果长时间未向注册中心进行服务续约，注册中心就会将该微服务从微服务通信地址列表中进行剔除。===>服务续约

4微服务需要关闭服务并向注册中心发送下线请求，注册中心就会将该微服务从微服务通信地址列表中进行剔除。===》服务下架

Spring Cloud【微服务】的优缺点？

优点

• 服务之间无耦合【微服务是将一个单体应用拆分多个子应用，分别进行开发部署维护】，代码简单方便开发维护，服务之间升级维护互不影响

• 服务之间通过轻量级HTTP通信机制（以前是一个服务器需要通过注解注入对象，进行相互调用，现在多服务器之间通过openfeign负载均衡器封装Http请求进行通信），不同的服务（不同的技术选型）可以采用不同的编程语言，而且可以使用不同的数据库

• 有极强的扩展能力,业务量大的服务可以再次拆分服务，或者也可以集群部署

• 融合了当前比较流行并且实用的框架技术结合起来，Spring Cloud Netflix和Spring cloud alibaba

缺点

• 分布式事务（基于seata的2PC）繁琐【因为要管理多个数据库的执行结果，要么同时失败，要么同时成功】

• 部署麻烦，开发人员的学习成本高【使用了不同的编程语言和数据库】

• 技术成本高，开发人员需要花更多的时间学习相关技术

• 微服务之间的通信存在对性能的损耗问题【发送http请求等会有一定损耗】

什么是服务雪崩？

        就是当一个微服务出现异常时，导致大量请求堆积在该微服务上造成阻塞，从而导致其他需要调用该微服务的微服务也堆积大量的请求，从而导致整条链路的微服务都失败，这时候可以使用集群部署，或者再采用Hystrix熔断器，当当前微服务出现异常或超时，直接触发熔断机制和降级策略，访问该微服务的请求立即失败，返回兜底数据。【堵车....】

如果服务挂了，注册中心要等到90s后剔除，那么在剔除前的这段时间内，挂掉的服务有可能还是会被调用，怎么处理？

第一，可以修改注册中心剔除服务时间（时间改短一些），同时加快服务续约心跳请求的频率

第二，可以使用Hystrix的熔断机制和降级策略，当某个服务不可以访问，对访问当前服务器的请求立即失败，并返回兜底数据

第三。使用集群--解决单点故障，从而可以避免在一个服务器挂掉之后(单点故障)，整个系统崩掉。

你知道EurekaClient服务发现和服务续约每隔30s做一次请求是用什么技术实现的吗？

使用了ScheduledThreadPoolExecutor线程池定时任务来实现

服务发现是先判断是否开启了服务发现功能（默认是开启的），获取定时任务的间隔时间（默认是30s），然后初始化服务发现的定时任务，间隔时间可以在yml中修改

服务续约是先判断是否开启服务注册功能（默认是开启的），获取定时任务的间隔时间（默认是30s），然后初始化心跳请求的定时任务，间隔时间可以在yml中修改

Ribbon是什么，Ribbon的工作原理讲一下？

        Ribbon是一个客户端负载均衡器，当一个微服务有多个集群时，Ribbon会接收所有的请求并根据微服务集群中的每个服务器的负载能力，通过负载均衡算法（默认使用轮询）调用某个服务器进行执行该请求，通常结合RestTemplate【封装了Http请求（微服务之间的通信方式）】来使用，简化了服务之间的调用方式。

Ribbon有哪些负载均衡算法，怎么配置

RoundRobbonRule：简单轮询，ribbon默认规则

AvailabilityFilteringRule：忽略短路状态和并发过高的服务器【标记短路】

WeightedResponseTimeRule：根据服务器响应时间作为权重，响应时间越长权重越小

ZoneAvoidanceRule：根据区域选择可用的服务器

BestAvailableRule：忽略短路的服务器，选择并发较低的服务器

RandomRule：随机选择一个可用服务器

Retry：重试机制【当请求失败，重复对一个服务进行调用】【不建议】--//⽹络波动问题造成的请求失败，通过重试提⾼成功率

如何进行配置Ribbon的负载均衡算法：1 注解的方式 2yml中进行配置

1.在Client的config中添加bean

@Bean
public RandomRule getRandomRule(){
    return new RandomRule();
}

2在配置文件中添加

在application client的配置文件中添加
application-service是application service的spring.application.name
ribbon 固定的
NFLoadBalancecerRuleClassName 固定的
取值是负载均衡策略类的全限定路径

application-service:
  ribbon:
    NFLoadBalancecerRuleClassName: com.netflix.loadbalancer.RandomRule

OpenFeign和Ribbon的区别

        Ribbon和OpenFeign都是负载均衡器。当微服务集群之间进行调用的时候，我们不知道需要调用那一个微服务，就需要使用负载均衡器根据每个微服务的负载能力通过负载均衡算法调用其中的某个服务器。

        OpenFeign整合（封装）了Ribbon和Hystrix熔断器,Openfeign优化了Ribbon拼接URL发送Http请求，通过调用接口（feign接口）的方式，让服务调用变得更加简单，并且openfeign整合了Hystrix熔断器，直接在yml进行配置开启即可，可以有效避免一个微服务挂掉后，造成服务雪崩。推荐使用OpenFeign。

OpengFiegn的工作流程（原理）

【如何集成】

1 首先要导入openfeign的依赖和编写feign接口和feign接口的降级方法（类）

2启动类加上注解@EnableFeignClients【会扫描当前包及其子包上的的@FeignClient注解的接口，】根据参数中的服务名进行调用。

========================================

首先，当程序启动【启动类】时，@EnableFeignClients会扫描当前包及其子包下带有@FeignClient注解的接口（接口中的参数就是调用的服务名），并交给Spring容器进行管理。

当发起请求时，会使用jdk动态代理，并为每个方法都生成相应的RestTemplate，并且封装http请求，里面包括url和请求参数等，最后把RestTemplate交个HttpClient发送请求，使用ribbon负载均衡器通过负载均衡算法调用某一个微服务。

为什么要使用Eureka

Eureaka:首先Eureka包含两个组成部分EurekaServer（注册中心）和Eurekaclient（客户端）。在微服务系统中，各个服务之间是需要进行网络通信，那么他们相互调用就得知道对方的通信地址。eureka就是专门来做做服务注册与发现，解决服务之间的通信问题

为什么要使用Ribbon

Ribbon：当一个微服务做了集群，也就是同一个服务名会对应多个地址，那么我们在调用的时候，应该调用哪一个就成了问题，这时候，就出现Ribbion，Ribbon作为一个负载均衡器，根据每个微服务的负载能力通过负载均衡算法调用其中的某个微服务。

为什么要使用config配置中心

Config配置中心：在微服务系统中，有很多的服务，而每个服务都有自己的配置文件，管理起来很麻烦。就需要使用config配置中心进行统一管理配置文件，它支持本地配置文件，也支持将配置文件放到远程仓库如git集中管理【我们现在使用的是Nacos对配置文件进行管理】

介绍一下Hystrix[熔断器]

熔断器是对服务链路的一种保护机制。其中又包含了熔断机制和降级策略。

熔断机制

简单理解就是当服务出现异常或超时等，就立马触发熔断机制，对服务进行降级并返回兜底数据，避免等待时间过长造成大量的请求阻塞，导致服务雪崩，从而导致整个服务瘫痪。

降级策略

降级策略，是当某个服务不可访问时，我们返回一些事先准备好的数据（兜底数据）给客户端，

比如说，友情提示服务暂不可用，请稍后重试，这样用户体验度就上去了

Hystrix一般分为三个状态，关闭状态【closed】，熔断状态，半熔断状态

        正常情况下，熔断器处于关闭状态(Closed)，如果请求到微服务失败的数量超过设定阈值（50%），熔断器进入熔断状态(Open)，这时候访问该服务上的所有请求都会立即失败（立马返回兜底数据不要让线程死等），后续一段时间内（5秒）的所有调用都会被拒绝(Fail Fast)，一段时间以后（withCircuitBreakerSleepWindowInMilliseconds=5s），熔断器会尝试进入半熔断状态(Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则进入闭合状态【closed】;

Hystrix熔断器中的核心技术，什么是资源隔离？

指的是限制请求去访问分布式服务的资源，可以理解为限制请求的数量。它包括线程池隔离和信号量隔离

线程池隔离ThreadPool，是指用一个线程池来存储当前的请求，可以通过设置线程池的最大线程数和最大排队数来限制请求数量，超过这个总数的请求立即进行失败，返回兜底数据。

信号量隔离semaphore：是指用一个计数器来记录当前有多少个线程在运行，如果请求进来计数器就增加1，结束一个请求就减1.超过最大信号量，立即进行失败，就返回兜底数据。

资源隔离：信号量和线程池的区别？？？

线程池方式是异步处理，它与调用线程不是同一个线程。

信号量方式是同步处理，与调用线程是同一个线程，需要等待其结果。

线程池方式由于需要排队，调度，线程切换，因此开销较大，

信号量方式不需要切换线程，就会避免线程切换所带来的性能损耗。

Eureka【服务注册与发现】和Zookeeper【分布式协调服务】的区别？

        Eureka是Netflix公司开源的一个服务注册与发现的组件，Eureka基于AP【可用性和分区容错性】，注重服务的可用性，即使某个服务器挂掉了，也不影响整个系统的正常使用，保持高可用。正常情况下，为了满足用户的体验，应该先选可用性【AP】

        Zookeeper是一种分布式协调服务，共享配置，提供命名服务,Zookeeper是基于CP【一致性和分区容错性】，注重数据的一致性，若主机挂掉则Zookeepr集群整体就不对外提供服务了，需要选一个新的leader出来（120s左右）才能继续提供服务，不保证可用。

对于CAP理论，Eureka选择的是AP还是CP？它保证了一致性还是可用性？

CAP理论指的是，一个分布式系统中的三要素，一致性，可用性，分区容错性，三个要素只能同时实现两点。Eureka是基于AP【可用性和分区容错性】，保证了可用性和分区容错性，放弃了数据一致性。主要可以用来保证客户端请求的快速响应，提高用户的体验度，而数据会遵守最终一致性（弱一致性）（只是时间问题）。

分布式容错：指的是分布式系统某个节点或网路分区出现故障的时候，不会影响整体的使用。

可用性：所有的节点都保持高可用性。【但是不会保证数据的一致性】。这里的高可用表示的是节点进行访问不会出现延迟，如果节点由于等待数据同步而进行了堵塞，那么该节点·就不满足高可用性。

一致性：在分布式系统中，读取数据应该是最新的数据【强一致性】，进行写操作后再去进行获取应该获取到最新的值，数据的一致性。

分区容错性是分布式系统的核心关键，如果一个节点或网络分区出现故障，整体就挂掉了，这就不叫作分布式系统。

那些满足了CP？那些满足了AP？

满足CP，也就是满足一致性和容错性，舍弃可用性，如果系统要保证数据地强一致性（必须等待数据同步才进行响应）就可以考虑。常见的如Redis，Nacos，ZooKeeper

满足AP，也就是满足可用性和容错性，舍弃一致性，如果系统允许数据的弱一致性（最终一致性即可，获取的数据不是最新的，但最终是一致的）可以考虑。常见的如MySQL，Eureka，RocketMQ
 

说一下Eureka的自我保护【防止误删】

        Eureka是Netflix公司开源的一个服务注册与发现的组件。为了防止注册服务被误删除，Eureka不会立即删除过时的服务数据。这种机制可能会导致客户端从注册中心获取到已经下线的服务并发起调用而导致错误，因此在开发阶段我们可以关闭自我保护机制（默认是开启的）。在生产环境中，我们需要打开自我保护，因为它可以防止因为网络波动，服务没有向注册中心及时续约而造成的服务误删除问题，如果是真正下线的时候，如果被调用，导致错误就直接返回兜底数据。

什么是Zuul？为什么需要zuul？

微服务网关是介于客户端和服务器端之间的中间层, 所有的外部请求都会先经过微服务Zuul网关【类似于所有请求的前门】。

为什么需要？

如果我们有很多的微服务，他们都需要登录之后才能访问，那么我需要在每个微服务都去做一套登录检查逻辑，这样是不是会存在大量重复的代码和工作量，我们希望的是把登录检查这种公共的逻辑进行统一的抽取，只需要做一套检查逻辑即可【类似于SpringAOP】

Zuul有哪几类Filter,他们的执行顺序是怎么样的【Zuul的执行流程】？

zuul按照执行顺序，分为pre前置过滤器，route路由过滤器【路由根据断言进行分发请求(到各个微服务进行处理)】，post后置过滤器，error异常过滤器

正常流程

是请求先经过前置过滤器【进行权限验证或者登录】，到达路由过滤器进行路由，路由到各种微服务执行请求，返回结果后经过后置过滤，返回用户

异常流程，

如果再整个过程中出现异常，都会进入error异常过滤器，处理完毕后经过post过滤器返回用户，

如果error自己出现异常，最终也会通过post过滤器返回用户，

如果post过滤器出现异常，也会跳转到error过滤器，然后直接返回用户

===========================

Zuul的主要功能是路由转发（只有满足断言的才能够进行转发）和过滤器（过滤到没有登录和全权限的服务），比如／api/user转发到到user服务，/api/shop转发到到shop服务。

在Zuul中如何实现登录检查？

可以通过自定义Filter继承ZuulFilter抽象类，然后重写ZuulFilter的4个方法，filterType用来指定Filter类型【指定是前置过滤器】，filterOrder用来指定执行顺序【数值越小，优先级越高】，shouldFilter方法中可以定义需要放行的资源（比如登录注册），run方法中检查请求头中的token信息是否有值，如果有，就放行。如果没有token，就响应到客户端未登录的信息，并跳转到登陆页面。

• filterType ：是用来指定filter的类型的（FilterConstants.PRE_TYPE;）

• filterOrder ：是filter的执行顺序，越小越先执行【包含了很多filter】

• shouldFilter ：是其父接口IZuulFilter的方法，用来决定run方法是否要被执行。

  return false，如果是要去登录或注册，就直接进行放行

  return true，如果不是去登录或注册等，就需要执行run方法进行判断

• run ：是其父接口IZuulFilter的方法，进行登录检查，判断请求头中是否有token。

@Component
public class LoginCheckFilter extends ZuulFilter {

    private static final Logger log = LoggerFactory.getLogger(LoginCheckFilter.class);

    //执行顺序
    private static final int ORDER = 1;

    //filter类型 : "pre"前置
    @Override
    public String filterType() {
        return FilterConstants.PRE_TYPE;	//pre
    }

    //执行顺序
    @Override
    public int filterOrder() {
        return ORDER;
    }

    //返回结果决定 是否要执行run方法
    @Override
    public boolean shouldFilter() {
        // /static/**  ，/login , /register 不需要做登录检查，返回false
        //1.获取request对象 ， 获取请求中的url
        HttpServletRequest request = RequestContext.getCurrentContext().getRequest();
        String url = request.getRequestURI();
        log.info("请求地址："+url);
        //2.判断是否包含在： static/**  ，/login , /register
        if(url.endsWith("/login ") || url.endsWith("/register ") || url.contains("/static/") ){
            return false;
        }
        //要做登录检查的返回true
        return true;
    }

    //核心业务方法 ： 登录检查 ， 如果请求头中有token，就是登录成功
    @Override
    public Object run() {
        //1.获取请求对象
        HttpServletRequest request = RequestContext.getCurrentContext().getRequest();

        //响应对象
        HttpServletResponse response = RequestContext.getCurrentContext().getResponse();


        //2.获取请求头中的 token
        String token = request.getHeader("token");

        //3.如果没有token，登录检查失败 ，
        if(!StringUtils.hasLength(token)){
            //3.1.返回登录检查失败的错误信息 :{ success:false, message:"登录检查失败，请重新登录"}
            Map<String,Object> resultMap = new HashMap<>();
            resultMap.put("success" , false);
            resultMap.put("message" , "登录检查失败，请重新登录");
            //中文编码
            response.setContentType("application/json;charset=utf-8");
            //把map转成json字符串，写到浏览器
            String resultJsonString = JSON.toJSONString(resultMap);

            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);

            try {
                response.getWriter().print(resultJsonString);
            } catch (IOException e) {
                e.printStackTrace();
            }

            //3.2.阻止filter继续往后执行
            RequestContext.getCurrentContext().setSendZuulResponse(false);

        }

        //这里的返回结果没有任何意义，不用管
        return null;
    }
}

在Zuul中如何做限流？

微服务Zuul实现限流保护_Been～You的博客-CSDN博客_zuul限制

方式三：令牌桶技术。常用，RateLimiter是Google开源的实现了令牌桶算法的限流工具（速率限制器），使用令牌桶算法【令牌桶: token bucket,原理：以相对恒定的速率向桶中加入令牌，请求可以在桶中取令牌，取到了就放行，没能取到令牌的请求则丢弃】

方式一：可以通过继承ZuulFilter抽象类自定义pre过滤器，加上限流算法来实现

方式二：可以通过hystrix的资源隔离模式，设置线程池最大连接数和最大排列数或者最大信号量来实现

网关【Zuul/GateWay】可以用来做什么？

        Gateway:gateway相当于所有服务的门户，将客户端与服务端进行分离，Gateway会接受客户端的所有请求通过定义的路由和断言进行转发，路由表示转发请求的地址，断言表示请求这些地址时所需要满足的条件（避免将服务器名称直接暴漏给外界），只有同时符合路由和断言才给予转发。

GateWay和Zuul的区别？

都是用来处理Http请求的

Zuul【同步阻塞】和GateWay【异步非阻塞模型】都是微服务网关。

Zuul是Netflix的开源项目，Springcloud收纳成自己的一个子组件。Zuul1.0用的是多线程阻塞模型【BIO】

Zuul2.0+用的是异步非阻塞模型（基于Netty）（但是Springcloud还没有进行整合）。

Gateway【异步非阻塞】是Springcloud自己的产物，就是来替代Zuul的，SpringCloud Gateway使用了高性能的Reactor模式通信框架Netty。

Spring Cloud Gateway 不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：`安全，监控/指标，和限流。

三个核心：Filter（过滤器） Route（路由） Predicate（断言）

路由的作用：把url请求路由到对应的资源(服务)，以前使用user-server/get ，现在只要user/get

过滤器的作用：可以在请求发出前后进行一些业务上的处理 ,这里分为两种类型的Filter，分别是Gateway Filter网关filter和Global Filter全局Filter,

Predicate（断言）的作用：处理HTTP请求的匹配 规则，满足条件才能进行访问资源。

GateWay的断言有哪些方式

Gateway 断言功能详解（Predict）_简单随风的博客-CSDN博客_gateway 断言

断言Predicate作用阶段：一个请求在抵达网关层后，首先就要进行断言匹配，在满足所有断言之后才会进入Filter阶段。

Predicate是接收一个判断条件，返回一个ture或false的布尔值结果，告知调用发判断结果。也可以通过and、or和negative(非)三个操作符多个Predicate串联在一块共同判断。

Predicate其实就是我们和Gateway对接的数据暗号，比如要求你的Request中必须带有某个指定的参数叫name，对应的值必须是一个指定的人名（Gavin），如果Request中没有包含name，或者名字不是Gavin，断言就失败了，只有标示和值都一样的情况下才会通过

说白了Predicate就是一种路由规则，通过Gateway中丰富的内置断言的组合，我们就能让一个请求找到对应的Route来处理。

EureakServer的搭建流程

第一步，导入eureka-server依赖，以及springboot的web环境依赖【因为web中有tomcat】。

第二布，在启动类上打注解@EnableEurekaServer，开启eurekaServer注册中心功能

第三步，在yml配置文件中，配置EurekaServer注册中心的端口号，主机名等信息，【然后其他的EurekaClient启动时就会将自己的ip地址端口号等信息发送个EurekaServer进行存储。】

Ribbon的整合流程【负载均衡】

第一步，导入ribbon依赖

第二部，给RestTemplate【拼接url，发送http请求】的Bean定义方法上，加上注解@LoadBalanced，让这个restTemplate有负载均衡的功能

第三步，修改restTemplate调用服务的url，将目标主机名【127.0.0.1】换成目标服务名【user-server】

Feign的整合流程【负载均衡】

第一步，导入openfeign依赖

第二部，启动类加注解，@EnableFeignClients，开启feign的支持

第三步，定义feign客户端接口，并加上注释@FeignClient("目标服务名")，接口中定义方法，该方法与目标服务的对应方法的方法名，返回值类型，形参列表，url路径（请求地址）要一致

Hystrix的整合流程

• 第一步，导入hystrix依赖

• 第二部，主启动类加注解，@EnableCircuitBreaker，开启熔断功能

• 第三步，在需要开启熔断功能的方法上，加注解@HystrixCommand(fallbackMethod="xxx")，xxx是降级方法

• 第四步，定义降级方法，方法名需要和fallbackMethod的值一致，形参列表和返回值类型需要和目标方法一致】

feign整合Hystrix：

• 第一步，因为feign集成了ribbon和hystrix，所以直接在yml中开启即可，feign.hystrix.enable=true，开启hystrix功能

• 第二部，@FeignClient标签中，定义fallback或者fallbackFactory，定义降级类

• 第三步，

如果是fallback，就实现feign接口，并覆写接口中的方法作为降级方法

如果是fallbackFactory，就实现FallbackFactory接口，同时指定泛型为feign接口，覆写create方法，返回一个feign接口的匿名内部类，类中写降级方法

Zuul的整合流程

第一步，导入zuul依赖

第二步，主启动类上加注解@EnableZuulProxy，开启zuul功能

第三步，yml中配置，统一访问前缀prefix，禁用通过服务名方式访问服务ignoredServices【设置为*，所有的请求都要经过zuul网关】，配置路由routes指定某个服务使用某个路径来访问

ConfigServer的整合流程

配置中心服务端配置：

第一步，导入config-server依赖

第二步，主启动类加注解，@EnableConfigServer，开启配置中心

第三步，配置文件中，配置远程仓库地址，仓库账号密码

客户端配置：

第一步，导入config-client依赖

第二步，创建bootstrap.yml配置文件，配置中心地址config.uri，要拉取的配置文件名name，环境名profile

浏览器发起一个请求，在你的微服务项目中的怎么去执行的？

        浏览器发起的所有请求首先通过Nginx负载均衡器通过负载均衡算法将请求发送给Gateway网关，进行登录校验和权限验证后，它会从EurekaServer配置中心拉取的通讯地址中，根据url匹配到对应的服务，然后使用ribbon/openfeign【负载均衡器】对服务器进行调用，最终将执行结果返回浏览器。

说下Ribbon和Feign的区别呢

Ribbon和Feign都是SpringCloud Netflix中实现负载均衡的组件，不同点在于Ribbon是需要我们手动构建http请求，根据目标服务名通过负载均衡算法【默认采用轮询】直接调用目标服务，

Feign是是通过调用接口的方式进行调用目标服务，将需要调用的目标服务方法定义成抽象方法（默认public abstract修饰），请求路径，服务名，形参列表，返回值类型需要与目标服务的接口（controller）保持一致。我们只需要调用接口中的方法就可以了。它会通过jdk动态代理，为每个方法生成RestTemplate对象并封装url和请求参数，使用负载均衡算法发起调用。

Ribbon的实现方式，一般配合RestTemplate发起http请求，我们需要在注册RestTemplate的Bean的方法上加@LoadBalanced，使它具有负载均衡的能力

Feign的实现方式，是在主启动类上加@EnableFeignClients，在客户端接口上加注解@FeignClient。

Spring,SpringBoot和SpringCloud的关系以及区别

Spring是一个开源的轻量级的基于控制反转IOC【DI是实现】和面向切面编程AOP的容器框架。轻量级是说它开发使用简单，功能强大。控制反转是指将对象的【生命周期】创建，属性注入，初始化，销毁控制交给ioc容器进行管理，方便解耦合，降低维护难度，面向切面编程是指将相同的逻辑横向抽取出来，可以对一些通用业务如事务，日志进行集中管理。

Springboot是一个基于spring的框架，Springboot是一个简化配置（文件）和快速搭建项目的框架，目的就是用来简化Spring应用的初始搭建和开发过程。对spring做了大量简化，使开发流程更快，更高效。比如它大量简化maven依赖，基于注解配置（JavaConfig）无需XML，内嵌Tomcat，部署流程简单，打包和部署更加灵活，允许独立运行

SpringCloud是基于SpringBoot实现的，用于微服务架构中管理和协调服务的，它是一系列框架的有序集合，它为开发者提供了一系列工具，服务发现注册Eureka、配置中心Config、消息总线Bus、负载均衡Ribbon/openfeign、断路器（熔断器）Hystrix、网关Zuul,链路追踪Sleuth，让微服务架构落地变得更简单**

SpringCloud和SpringCloudAlibaba的区别

SpringCloud几大痛点

SpringCloud 部分组件停止维护和更新，给开发者带来不便。

SpringCloud 部分环境搭建复杂，没有完善的可视化界面，我们需要大量的二次开发和定制。

SpringCloud配置复杂，难以上手，部分配置差别难以区分和合理应用。

SpringCloud Alibaba 的优势

阿里使用过的组件经历了考验，性能强悍(双十一，比如RocketMQ)，设计合理，现在开源出来给大家用。

成套产品搭配完善的可视化界面给开发运维带来了极大的便利。

搭建简单。

Sentinel和Hystrix的区别?为什么要使用Sentinel？

主要原因：Hystrix已经停止更新。而且Sentinel是Spring Cloud Alibaba 开源的。

Hystrix 的关注点是在 资源隔离（线程池隔离和信号量隔离） 和 熔断机制 为主的容错机制，超时或被熔断的调用会快速失败，并可以提供 fallback 机制【兜底方法】。

Sentinel的侧重点在于

• 多样化的流量控制

  【直接--快速失败:Sentinel默认的流控处理就是【直接->快速失败】，QPS（Query per Second每秒查询次数）达到阈值，当前资源直接失败。

  关联（背锅):关联的资源达到某个阈值，限流自己，如：限流的资源是/user/delete ，关联的资源是/user/list，当/user/list达到阈值，限流user/delete ， 举例： 支付并发太高，可以限制下单的流量

  链路（甩锅):限流线路调用链路的入口，如 /user/list 资源中 调用了 /dept/list ，对/dept/list添加限流，当/dept/list达到阈值，其实限流的是/user/list，因为他是访问的入口

• 熔断降级，

• 系统负载和保护

• 实时监控和控制台

https://blog.csdn.net/m0_37542889/article/details/82428193


什么是Sentinel？

Sentinel是SpringCloudAlibaba的重要组件。主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。

限流的作用：就是在高并发的情况下限制服务器的大量请求访问服务器资源，避免导致服务器挂掉。

熔断的作用：就是如果某个服务不可访问，发生异常等，满足熔断机制则会对该服务进行熔断，并使用降级策略返回兜底数据（一些友好的提示）返回给客户端，不至于给用户直接抛出异常。

Sentinel【哨兵-流量防卫兵】可以如何限流（流量控制）？

流量控制（flow control），其原理就是监控流量的QPS【每秒请求数量】和并发线程数【同时请求的线程数量】等指标，当QPS达到指定阈值（最大值）是对流量进行控制，以避免瞬时的流量高峰冲垮，从而保障应用的稳定性。

Sentinel的 流控模式 有哪些？

直接--快速失败:Sentinel默认的流控处理就是【直接->快速失败】，QPS达到阈值，当前资源直接失败。

关联（背锅):关联的资源达到某个阈值，限流自己【从源头进行解决】，如：限流的资源是/user/delete ，关联的资源是/user/list，当/user/list达到阈值，限流user/delete ， 举例： 支付并发太高，可以限制下单的流量

链路（甩锅):限流线路调用链路的入口，如 /user/list 资源中 调用了 /dept/list ，对/dept/list添加限流，当/dept/list达到阈值，其实限流的是/user/list，因为他是访问的入口

Sentinel的 流控效果 有哪些？

1快速失败：【超出阈值，立即拒绝，抛出异常】

快速失败:(RuleConstant.CONTROL_BEHAVIOR_DEFAULT)是默认的流控方式，当流量达到阀值【最大值】直接返回异常，QPS达到任何规则阈值后，后续请求就会立即拒绝`，并抛出FlowException 异常。简单理解：并发太高，直接请求拒绝

2Warm Up预热【超出阈值，直接拒绝，】：**慢慢的增大处理并发的能力，避免高并发导致服务宕机

根据codeFactor（默认3）的值，从（阀值（最大值）/codeFactor）为初始阀值，经过预热时长，才到达设置的QPS的阀值，即预热/冷启动方式。简单理解：慢慢的增大处理并发的能力【先可以接收最大值的1/3的请求量，过了预热时间，全部开启】

3排队等待：

突发流量处理不过来，让请求排队。