吊打面试官-Springcloud面试题

1、Springcloud-alibaba有那些组件

Springcloud 提供了构建为服务系统所需要的一组通用开发模式以及一系列快速实现这些开发模式的工具

2、分布式事务如何处理？怎么保证事务一致性

分布式事务：将不同节点上的事务操作，提供操作院子性保证。 要点：在原本没有关联的事务之间建立联系

http链接：最大努力通知 --事后补偿 mq：事务消息机制 redis： seata: 通过tc在多个事务之间建立联系 两阶段提交：AT 核心：要锁定资源

三阶段：TCC 在2阶段的基础上，增加一个准备阶段，准备阶段不锁定资源

SAGA模式 类似熔断：业务实现正常操作和补偿操作逻辑

3、分布式事务的三个角色

• 事务协调器

• 事务管理者

• 资源管理者

4、怎么拆分为服务？

准则： 微服务之间不要有业务交叉 微服务之间通过接口获取数据 高内聚，低耦合 工具有：同步接口调用、异步事件驱动

5、什么是DDD？

DDD时面对软件复杂之道。 ​ 领域驱动设计Domain-Driven-Design ​ 以MVC的entity或domain为例，这种只包含数据不包含逻辑业务的类就叫做贫血模型（Anemic Domain Model）。 ​ 贫血模型将数据与操作分离，破坏了面向对象的封装特性，是一种典型的面向过程编程。 ​ ​ 充血模型（Rich Domain Model）正好相反，数据和对应的业务逻辑被封装到同一个类中。因此，这充血模型满足面向对象的封装特性

6、中台是什么？

所谓中台就是将各个业务线可以复用的一些功能抽取出来，形成可复用的组件。 大体上，可以分为数据中台，业务中台，技术中台。 大数据杀熟-数据中台 电商收银中台 支付风控中台 中台和DDD结合：DDD会通过限界上下文将系统拆分成一个个的领域，而这种限界上下文，天生就成为中台之间的逻辑屏障。 DDD在技术与资源调度方面都能给中台建设提供不错的指导 DDD分为战略设计和战术设计，上层的战略设计能够很好的指导中台划分，下层的战术设计 能够很好的指导微服务搭建

7、微服务链路追踪、持续集成、AB发布要怎么做？

链路追踪： 1、基于日志，形成全局事务id，落地到日志文件，elk 2、基于mq，需要架构支持，经过流失计算形成一些可视化结果

持续集成：maven pom > build > shell > jenkins

8、springcloud 和dubbo有啥区别

springcloud时一个大而全的框架，dubbo更侧重于服务调用，所以功能上，dubbo没有springcloud全面，但dubbo调用性能比springcloud高，但2者并不是队里的，可以结合一起使用的

9、什么是服务雪崩？什么是服务限流？

微服务调用链的下游影响上游。解决方式：服务降级和服务熔断 服务限流：高并发请求下，保护系统，可以对访问服务的请求进行数据量限制，防止系统不被大量请求压垮。

10、什么是服务熔断？什么是服务降级？区别是什么？

服务熔断：微服务上游保证自己不受下游影响，直接返回结果的方式 ​ 服务降级：系统压力过载，通过关闭一些不重要的服务或者限制某些服务的流量来减轻系统压力

相同点：

1、都是防止系统奔溃 ​ 2、让用户体验到某些功能暂时不可用 不同点：

熔断：下游服务故障触发的 ​ 降级：降低系统负载

11、SOA/分布式、微服务之间关系和区别？

• 分布式架构时将单体架构中的各个部分拆分，然后部署到不同机器或进程去，SOA/微服务都是分布式架构

• SOA是一种面向服务的架构，系统的所有服务都注册在总线上，调用服务从总线上查找服务信心然后调用

• 微服务是一种更彻底的面向服务的架构，将系统中各个功能个体抽成一个个小的应用程序，基本维持一个应用对应的一个服务的架构

12、链路追踪的功能

• 分布式调用链查询和诊断

• 应用性能实时汇总

• 分布式拓扑动态发现

• 多语言开发程序接入

13、EureKa:服务注册与发现

注册：每个服务向Eureka登记自己的元数据，包括服务ip地址、端口号、版本号、通信协议等Eureka将各个服务维护在一个服务清单中（双层map，第一层key是服务名，第二层key是实例名、value是服务地址+端口）同时对服务维持心跳，剔除不可用服务，每个eureka结点都有这么一组服务清单。 ​ 发现：eureka注册的服务之间不需要指定服务地址，通过服务名向注册中心咨询，获取所有服务实例 清单，并缓存在本地，然后实现服务的请求访问 ​

14、Ribbon

服务间发起请求的时候，基于ribbon做负载均衡，通过发起http请求，进行调用。只不过是通过调用服务名的地址来实现的，虽然ribbon不用去具体请求服务实例的ip地址或域名了，但是每调用一个接口还要手动去发起http请求

15、Feign

基于feign动态代理机制，根据注解和选择的机器，拼接请求url地址。发起请求。简化服务间的调用，在ribbon的基础上进行了进一步封装，单独抽出的一个组件。调用远程和调用本地服务一样

16、zuul

• 请求转发

• 服务路由

• 过滤器机制

17、hystrix

• 分布式容错框架

• 阻止故障连锁反应，实现熔断

• 快速失败，实现优雅降级

• 提供实时监控和告警

发起请求通过hystrix的线程池走的，不同服务走不同线程池，实现不同服务的隔离。通过统计接口超时次数和返回默认值，实现服务熔断和降级。

资源隔离： 线程隔离： hystrix会给每一个command分配一个单独的线程池，这样在进行单个服务调用时候，就可以在独立线程池里进行，不会影响其他接口和请求。 信号量隔离： 客户端向依赖的服务发起请求时，首先要获取一个信号量才能真正发起调用，由于信号量数量有限，请求量超过信号量个数时，后续都会拒绝，进入fallback流程。信号量隔离主要是通过控制并发请求量，防止请求大面积阻塞，从而达到限流和防止雪崩。

熔断：是为了防止异常不扩散，保证系统稳定性 降级：编写好调用失败的补救逻辑，然后对服务直接停止运行，这些接口就无法正常调用，但又不至于直接报错，只是服务水平降低。

通过HystrixCommand或者HystrixObservableCommand将所有的外部系统（或依赖）包装起来，整个包装对象 就单独运行在一个线程之中打开断路器可以在一段时间内停止对特定服务的所有请求，如果服务错误百分比通过阈值，手动或自动关闭断路器请求被拒绝、链接超时或者断路器打开，直接执行fallback逻辑

18、distro协议、raft协议

Distro 协议是 Nacos 对于临时实例数据开发的⼀致性协议。其数据存储在缓存中，并且会在启动时进行全量数据同步，并定期进行数据校验。

在 Distro 协议的设计思想下，每个 Distro 节点都可以接收到读写请求。所有的Distro协议的请求场景主要分为三种情况：

当该节点接收到属于该节点负责的实例的写请求时，直接写入。 当该节点接收到不属于该节点负责的实例的写请求时，将在集群内部路由，转发给对应的节点，从而完成读写。 当该节点接收到任何读请求时，都直接在本机查询并返回（因为所有实例都被同步到了每台机器上）。 Distro 协议作为 Nacos 的内嵌临时实例⼀致性协议，保证了在分布式环境下每个节点上面的服务信息的状态都能够及时地通知其他节点，可以维持数十万量级服务实例的存储和⼀致性。

raft协议

一个完整的Paxos算法流程分为三个阶段：

（1）Prepare准备阶段

 Proposer向多个Acceptor发出Propose请求Promise（承诺）
 Acceptor针对收到的Propose请求进行Promise（承诺）

（2）Accept接受阶段

 Proposer收到多数Acceptor承诺的Promise后，向Acceptor发出Propose请求
 Acceptor针对收到的Propose请求进行Accept处理

（3）Learn学习阶段

 Proposer将形成的决议发送给所有Learners

19、OpenFeign的实现原理

在 Spring 项目启动阶段，启动类上的@EnableFeignClients注解，会引入一个FeignClientsRegistrar（Feign客户端注册类），它会从指定的目录下扫描并加载所有被 @FeignClient 注解修饰的接口类（interface），然后将这些接口类型注册成 Bean对象，统一交给 Spring 来管理。 @FeignClient 修饰的接口类的方法，经过 MVC Contract 协议的解析后，放入 MethodMetadata（方法元数据）数组中。 然后创建一个动态代理对象Proxy ，指向了一个存放着key为@FeignClient 修饰的接口类的方法名，和 value为方法名对应的MethodHandler （MethodHandler 记录着MethodMetadata方法元数据的引用）的 HashMap。然后把动态代理对象Proxy添加到 Spring 容器中，并注入到对应的服务里。 当服务调用FeignClient接口类的方法时，从动态代理对象 Proxy 中找到一个 MethodHandler 实例，生成一个包含该方法URL的 Http请求（不包含服务的 IP）。 经过Ribbon负载均衡算法找到一个服务的 IP 地址，拼接出完整的 URL，并发起请求。被调用服务收到Http请求，就可以响应请求，返回数据给调用者了。

20、如何设计一个注册中心？

高可用：集群 ​ 高并发：响应时间、吞吐量、并发用户数等等 ​ 增加服务性能，扩展服务实例 ​ 高性能：程序处理速度 ​ 其他考量：数据存储结构、通信机制、集群同步 ​ 功能：

• 服务注册

• 服务发现

• 服务订阅

• 服务推送

• 服务检查

• 数据同步

21、Nacos1.x注册中心的原理

1、使用http发送注册 ​ 2、查询服务方列表 ​ 3、定时拉取（每隔10s） ​ 4、检测到服务提供者异常，基于UDP协议推送更新 ​ 5、定时心跳（5s)，检测服务状态 ​ 6、定时心跳任务检查 ​ 7、集群数据同步任务使用 distro ​

22、Nacos服务领域有那些？

NameSpace 实现环境隔离，默认public ​ group 不同service可以组成一个group，默认值default-group ​ service 服务名称 ​ cluster 微服务虚拟划分，默认值default ​ instance 服务具体实例

23、Nacos的 distro 协议

Nacos每个节点自己负责部分的写请求
每个节点会把自己负责的新增数据同步给其他节点
每个节点定时发送自己负责数据的校验值给其他节点来保持数据一致性
每个节点独立处理读请求，即使从本地发出响应
新加入的distro节点会进行全量数据拉去
（具体操作是轮询所有distro节点，发出拉去全量数据请求）

24、配置中心的技术选型

功能点： config apollo nacos 版本管理： 支持 支持 支持 实时推送： spring bus 支持 支持 配置回滚： 支持 支持 支持 灰度发布： 支持 支持 不支持 权限管理： 支持 支持 支持 配置生效时间： 重启 支持 支持 审计： 支持 支持 支持 多集群 支持 支持 支持 多环境 支持 支持 支持 client本地缓存：支持 支持 支持 监听查询： 支持 支持 支持 运维成本： 支持 支持 低 多语言： 仅java 支持，openApi 支持，openApi 配置项管理： 支持 支持 支持

25、Nacos1.x配置中心长轮询机制？

客户端会轮询向服务端发送一个长链接请求，最多30s超时，服务端接收请求向判断当前配置 ​ 是否有配置更新，有则立即返回，没有就hold住29.5s加入队列，最后0.5s检测配置文件无论是否更新 ​ 都正常返回，等待期间如果有更新则提前返回 ​

26、Nacos配置中心配置优先级？

#${application.name}-${profile}.${file-extension} nacos-config-prod.yaml ​ #${application.name}.${file-extension} nacos-config.yaml ​ #${application.name} nacos-config ​ #extensionConfigs 扩展配置文件 ​ #sharedConfigs 公共配置 ​

27、Nacos2.x客户端探活机制？

Nacos服务端会启动一个定时任务，3s执行一次，将车所有链接是否超过 ​ 20s没有通信，如果超过20s，就会向客户端发送一个请求进行探活， ​ 如果正常就标识这个服务为正常服务，反之则删除其链接。 ​

28、Ribbon底层怎么实现不同服务不同配置

为不同的服务创建不同的spring上下文

29、为什么Feign第一次调用服务耗时很长？

ribbon默认是懒加载的，只有第一次调用才会生成ribbon对应组件。 ​

30、ribbon的属性配置和类配置那个优先级高？

类的优先级高。 ​ RibbonClientConfiguration类， ​ @ConditionalOnMissingBean没有加载对应bean，则使用属性配置 ​

31、Feign的性能优化

1、Feign底层默认的是jdk自带的httpUrlConnection,他是单线程发送http请求，不能配置线程池。 ​ 我们可以使用Okhttp或者HttpClient发送http请求，替换httpUrlConnection ​ 2、数据压缩-gzip压缩 ​ 3、feign超时配置 ​ 4、设置合理的日志 ​

32、Feign实现认证传递

实现接口RequestInterceptor接口，通过header传递认证

33、谈谈sentienl中的限流算法

计数器法 ​ 滑动窗口 ​ 漏桶算法 ​ 令牌桶 ​

34、在gateway中怎么样实现服务的平滑迁移

使用weight路由的断言工厂进行服务权重配置，并将配置放到nacos中进行动态迁移 ​ weight路由断言工厂： ​ 包含2个参数：组group，权重weight，对于同一组中的多个uri地址， ​ 会根据设置的权重，按比例转发，实现负载均衡

35、seata支持那些事务模式?

seata是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式 ​ 事务服务。提供了AT,TCC,SAGA,XA事务模式。 ​ AT：无侵入自动补偿事务模式 注解方式开启全局事务 ​ 基于XA演进而来。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下， ​ 用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段， ​ Seata 框架会自动生成事务的二阶段提交和回滚操作。 ​ XA：支持已实现XA接口的数据的xa模式 ​ 事务管理器 TM 和局部资源管理器 RM 之间的接口 ​ TCC：应用层面的2pc，需要编写业务逻辑实现 ​ SAGA:长事务提供的解决方案 ​

36、简述2pc流程以及优缺点

准备阶段：锁定资源不提交 ​ 提交/回滚： ​ 优点：尽量保证数据强一致，成本低，mysql5.5开始支持xa ​ 缺点：1.单点问题：tm（事务管理器）角色很关键，如果宕机，比如第一阶段完成 ​ 第二阶段宕机，则会一直阻塞状态 ​ 2.同步阻塞：资源管理器的资源会一直阻塞，直到提交完成，释放资源 ​ 3.数据不一致：第二阶段，发出commit通知，但仅一部分参与者收到并执行commit，其他参与者一直阻塞状态，从而产生数据不一致问题。 ​

37、seata中的xid怎么通过feign全局传递？

全局事务xid通过feign的header进行传递 ​ SeataFeignClient.java 类中通过getModifyRequest方法设置 ​

38、简述CAP/BASE理论

在一个分布式系统中，Consistency（一致性），Availability(可用性)， ​ Partition tolerance（分区容错性），三者不可得兼。 ​ 一致性： ​ 写操作之后，进行读操作，无论在那个节点都需要返回写操作的数据 ​ 可用性： ​ 非故障节点在合理时间内返回合理的响应 ​ 分区容错性： ​ 出现网络分区后，系统能继续工作。 ​ 在分布式系统中，网络无法100%可靠，分区是一个必然现象。如果选择ca放弃p，则发生分区现象时， ​ 为了保证一致性，就必须拒绝请求，但是A又不允许，所以分布式系统理论上不可能选择ca架构， ​ 只能选择cp或ap架构 ​ cp：放弃可用性，追求一致性和分区容错性，zookeeper就是追求强一致算法 ​ ap：放弃一致性（强一致性），追求分区容错性和可用性。 ​

base：基本可用，软状态，最终一致性
即使无法做到强一致性，那么每个应用都可以根据自身特点，采用适当方式达到系统最终一致性
​
软状态：允许系统中的数据存在中间状态，并认为该状态不会影响系统的整体可用性。
最终一致性：系统数据最后一定是一致的

39、简述seata的at模式2阶段过程

1阶段：开启全局事务，注册分支事务，存储全局锁，业务数据和回滚日志进行提交 ​ 2阶段：事务协调者根据所有分支情况，觉得本次全局事务是commit还是rollback（2阶段是 ​ 完全异步删除undolog日志，全局事务，分支事务，存储的全局锁） ​

40、简述eureka自我保护机制

eureka服务端会检查最近15分钟内所有eureka实例正常心跳占比，低于85%就会触发自我保护机制。 ​ 将暂时失效的服务保护起来，不让其过期，但这些服务也并不是永远不会过期。 ​ eureka启动完成之后，每隔60s会检查一次服务健康状态，如果这些失效的服务过一段时间后，还没有恢复（90s） ​ 则会剔除。在此期间，服务恢复了，并且实例心跳占比高于85%，就会自动关闭自我保护机制。 ​

自我保护机制更改条件：服务注册，服务下架，服务初始化，15分钟更新一次

41、简述eureka集群架构

register（服务注册） 把自己ip和端口注册给eureka ​ renew（服务续约） 发送心跳包，30s一次， ​ cancel（服务下线） provider关闭时向eureka发送消息，把自己从服务列表中删除 ​ get registry（获取服务注册列表） 获取其他服务列表 ​ replicate（集群数据同步） 集群数据复制与同步 ​ make remote call（远程调用） 远程调用 ​

42、eureka迁移到nacos的方案

1.确定springboot版本依赖关系 ​ 2.更换依赖jar ​ 3.更换配置 ​ 4.使用@EnableDiscoveryClient开启注解 ​ 5.平滑迁移 ​

43、apollo整体架构

config service:提供配置读取，推送等功能，服务对象客户端 ​ admin service:提供配置修改，发布等功能，服务端管理界面 ​ 在config service和admin service都是多实例，无状态部署，需要注册到eureka中保持心跳 ​ 在eureka之上封装了一层meta server用户封装eureka的服务发现接口 ​ client 通过域名访问meta server 获取config service 列表，然后通过ip+port访问服务，同时在client侧做load balance、错误重试 ​ portal 通过域名访问meta server 获取admin service 列表，。。。 ​ 为了简化部署，config service 、eureka 和meta server3个逻辑角色部署在同一个jvm进程中。 ​

44、apollo整体架构的可靠性分析

config service 单台下线， 无影响 ​ 所有config service 下线， 客户端无法读取最新配置，可使用本地缓存，portal无影响 ​ admin service单台下线， 无影响 ​ 所有admin service 下线， 客户端无影响，portal无法更新配置 ​ 某台portal下线 其他portal可以继续使用 ​

45、apollo配置发布后的实时推送设计

portal端操作配置发布 ​ portal调用admin service接口操作发布 ​ admin service 发布配置后，发送releaseMessage给各个config service ​ config service 通知相应客户端

46、apollo客户端设计

1、客户端和服务端保持了一个长链接，能第一时间获取配置更新的推送 ​ 2、客户端定时拉去apollo配置中心应用最新配置 ​ 3、客户端从apollo配置中心应用最新配置，会保存在内存中，本地也会存一份 ​ 4、应用程序从apollo客户端获取最新配置，订阅配置更新通知 ​

47、zuul有哪几种过滤器类型？

4种过滤器 ​ 1、pre：请求被路由前调用。比如：身份验证等 ​ 2、routing：请求路由到微服务。构建发送给微服务的请求，并使用HttpClient或Netfilx ribbon请求 ​ 3、post：过滤器在路由到微服务以后执行。这种过滤器可用来作为响应添加标准http header，收集统计 ​ 信息和指标，将响应从微服务发送给客户端 ​ 4、error：其他阶段发生错误时执行 ​ ​

48、说说 RPC 的实现原理

首先需要有处理网络连接通讯的模块，负责连接建立、管理和消息的传输。其次需要有编解码的模块，因为网络通讯都是传输的字节码，需要将我们使用的对象序列化和反序列化。剩下的就是客户端和服务器端的部分，服务器端暴露要开放的服务接口，客户调用服务接口的一个代理实现，这个代理实现负责收集数据、编码并传输给服务器然后等待结果返回。

49、说说 Dubbo 的实现原理

dubbo 作为 rpc 框架，实现的效果就是调用远程的方法就像在本地调用一样。如何做到呢？就是本地有对远程方法的描述，包括方法名、参数、返回值，在 dubbo 中是远程和本地使用同样的接口；然后呢，要有对网络通信的封装，要对调用方来说通信细节是完全不可见的，网络通信要做的就是将调用方法的属性通过一定的协议（简单来说就是消息格式）传递到服务端；服务端按照协议解析出调用的信息；执行相应的方法；在将方法的返回值通过协议传递给客户端；客户端再解析；在调用方式上又可以分为同步调用和异步调用；简单来说基本就这个过程

50、Nacos与Eureka的区别

相同点：

• 都支持服务注册和服务拉取。

• 都支持服务提供者心跳方式做健康检测。

区别： Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式

临时实例心跳不正常会被剔除，非临时实例则不会被剔除

Nacos支持服务列表变更的消息推送模式，服务列表更新更及时

Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

51、eureka、consul、nacos对比

	EUREKA	CONSUL	NACOS
集成入侵性	集成在应用内部	几乎没有	几乎没有
CAP	AP	CP 一致性导致了选举Leader期间整个consul不可用	CP+AP
版本迭代	否	是	是
配置中心	否	是	是，符合Spring boot的开发规范，支持动态刷新
访问协议	http	http/dns	http/dns/udp
集成支持	spring cloud	spring cloud/k8s	spring cloud/k8s/dubbo
上手程度	容易	复杂一点	极易，中文文档
雪崩保护	不支持	不支持	支持

52、配置中心Nacos与Apollo比较

对比项目	APOLLO	NACOS
开源时间	2016.5	2018.6
配置实时推送	支持（HTTP长轮询1s内）	支持（HTTP长轮询1s内）
版本管理	自动管理	自动管理
配置回滚	支持	支持
权限管理	支持（细粒度）	支持（粗粒度）
灰度发布	支持	支持
多集群多环境	支持	支持
监听查询	支持	支持
多语言	Go,C++,Python,Java,.net,OpenAPI	Python,Java,Nodejs,OpenAPI
分布式高可用最小集群数量	Config2+Admin3+Portal*2+Mysql=8	Nacos*3+MySql=4
配置格式校验	支持	支持
通信协议	HTTP	HTTP
单机读（tps）	9000	15000
单机写（tps）	1100	1800

结论

从配置中心角度来看，性能方面Nacos的读写性能最高，Apollo次之；功能方面Apollo最为完善，但Nacos具有Apollo大部分配置管理功能。Nacos的一大优势是整合了注册中心、配置中心功能，部署和操作相比 Apollo都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。

总的来看，Apollo和Nacos生态支持都很广泛，在配置管理流程上做的都很好。Apollo相对于Nacos在配置管理做的更加全面；Nacos则使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。

对于公司目前来说，修改配置的次数不是特别的频繁，对于配置权限的管理不是特别严格的，且对读写性能有一定要求的，可采用Nacos，反之使用Apollo。

53、Dubbo与Feign的区别

相同点：

• 都可以实现远程调用，

• 都依赖注册中心，

• 都支持负载均衡，服务熔断

区别：

Feign是基于Http协议。服务提供者需要对外暴露Http接口供消费者调用（例如我们用@openFeign注解来标识远程调用服务的接口时，需要加@RequestMapping）服务粒度是http接口级的。通过短连接的方式进行通信，不适合高并发的访问。Feign追求的是简洁，少侵入（因为就服务端而言，在SpringCloud环境下，不需要做任何额外的操作

Dubbo支持多传输协议(Dubbo、Rmi、http、redis等等)，Dubbo的服务端需要配置开放的Dubbo接口，通过TCP长连接的方式进行通信，服务粒度是方法级的。

负载均衡方面：

Feign默认使用Ribbon作为负载均衡的组件。

Dubbo和Ribbon（Feign默认集成Ribbon）都支持负载均衡策略，但是Dubbo支持的更灵活。

Dubbo和Ribbon对比：

Ribbon的负载均衡策略：随机、规则轮询、空闲策略、响应时间策略。

Dubbo的负载均衡策略：Dubbo支持4种算法，随机、权重轮询、最少活跃调用数、一致性Hash策略。而且算法里面引入权重的概念。

Dubbo可以使用路由策略，然后再进行负载均衡。

Dubbo配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。

Dubbo负载均衡的算法可以精准到某个服务接口的某个方法，而Ribbon的算法是Client级别的。Ribbon需要进行全局配置，个性化配置比较麻烦。

容错机制方面：

Feign默认使用Hystix作为服务熔断的组件。Hystix提供了服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）等功能。Feign是利用熔断机制来实现容错的，与Dubbo处理的方式不一样。

Dubbo支持多种容错策略，FailOver、FailFast、Failsafe、FailBack、Aviailable、Broadcast、Forking策略等，以及Mock。也引入了retry次数，timeout等配置参数。Dubbo自带了失败重试的功能。

从协议层选择看，Dubbo是配置化的，更加灵活。Dubbo协议更适合小数据高并发场景。

54、http1.0、http1.1及http2.0的区别

Http1.0 HTTP1.0默认使用 Connection:cloose，浏览器每次请求都需要与服务器建立一个 TCP 连接，服务器处理完成后立即断开 TCP 连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

Http1.1 HTTP1.1默认使用 Connection:keep-alive（长连接），避免了连接建立和释放的开销；通过 Content-Length 字段来判断当前请求的数据是否已经全部接受。不允许同时存在两个并行的响应。

Http1.1缺陷

（1）高延迟，带来页面加载速度的降低。（网络延迟问题只要由于队头阻塞，导致宽带无法被充分利用）

（2）无状态特性，带来巨大的Http头部。

（3）明文传输，不安全。

（4）不支持服务器推送消息。

HTTP2.0新特性 （1）二进制传输

http2.0将请求和响应数据分割为更小的帧，并且它们采用二进制编码(http1.0基于文本格式)。多个帧之间可以乱序发送，根据帧首部的流表示可以重新组装。

（2）Header压缩

Http2.0开发了专门的“HPACK”算法，大大压缩了Header信息。

（3）多路复用

http2.0中引入了多路复用技术，很好的解决了浏览器限制同一个域名下的请求数量的问题。

多路复用技术可以只通过一个TCP链接就可以传输所有的请求数据。

（4）服务端推送

HTTP2.0在一定程度上改不了传统的“请求-应答”工作模式，服务器不再完全被动地响应请求，也可以新建“流”主动向客户端发送消息。（例如，浏览器在刚请求html的时候就提前把可能会用到的JS，CSS文件发送给客户端，减少等待延迟，这被称为“服务端推送Server Push”）

服务器也不能随便将第三方资源推送给服务器，必须经过双方确认。

HTTP2.0缺点

（1）TCP以及TCP+TLS建立连接的延迟（握手延迟）

（2）TCP的队头阻塞没有彻底解决（http2.0中，多个请求是跑在一个TCP管道中的，一旦丢包，TCP就要等待重传（丢失的包等待重新传输确认），从而阻塞该TCP连接中的所有请求）

因为HTTP2.0存在这些缺点，所以出现了HTTP3.0。

总结 HTTP1.1的缺点：安全性不足和性能不高；

HTTP2.0完全兼容HTTTP1.0，是“更安全的HTTP，更快的HTTPS”，头部压缩，多路复用等技术充分利用了带宽，降低了延迟。

55、Zuul和Gateway的区别

相同点：

1、底层都是servlet

2、两者均是web网关，处理的是http请求

不同点：

1、内部实现：

　　gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件 　　zuul则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等。 2、是否支持异步 　　zuul仅支持同步 　　gateway支持异步。理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定 3、框架设计的角度 　　gateway具有更好的扩展性，并且其已经发布了2.0.0的RELESE版本，稳定性也是非常好的 4、性能 　　WebFlux 模块的名称是 spring-webflux，名称中的 Flux 来源于 Reactor 中的类 Flux。Spring webflux 有一个全新的非堵塞的函数式 Reactive Web 框架，可以用来构建异步的、非堵塞的、事件驱动的服务，在伸缩性方面表现非常好。使用非阻塞API。 Websockets得到支持，并且由于它与Spring紧密集成，所以将会是一个更好的 开发 体验。 　　Zuul 1.x，是一个基于阻塞io的API Gateway。Zuul已经发布了Zuul 2.x，基于Netty，也是非阻塞的，支持长连接，但Spring Cloud暂时还没有整合计划。

总结 　　总的来说，在微服务架构，如果使用了Spring Cloud生态的基础组件，则Spring Cloud Gateway相比而言更加具备优势，单从流式编程+支持异步上就足以让开发者选择它了。 　　对于小型微服务架构或是复杂架构（不仅包括微服务应用还有其他非Spring Cloud服务节点），zuul也是一个不错的选择。

56、zipkin的工作原理

模块： Collector 接受或者收集各个应用传输的数据 Storage：负责存储接收到的数据，默认是存储在内存当中的，也可以支持存在MySQL当中 API：负责查询Storage中存储的数据，主要是提供给Web UI来使用 Web：主要是提供简单的web界面

工作流程： 一个应用的代码发起HTTP get请求，经过Trace框架拦截，然后把当前调用链的Trace信息添加到HTTP Header里面 记录当前调用的时间戳发送HTTP请求，把trace相关的header信息携带上，调用结束之后，记录当前调用话费的时间 然后把上面流程产生的 信息汇集成一个span，把这个span信息上传到zipkin的Collector模块

57、Zuul网关的作用

过滤器机制来实现以下功能

• 统一入口：未全部为服务提供一个唯一的入口，网关起到外部和内部隔离的作用，保障了后台服务的安全性。

• 鉴权校验：识别每个请求的权限，拒绝不符合要求的请求。

• 动态路由：动态的将请求路由到不同的后端集群中。

• 减少客户端与服务端的耦合：服务可以独立发展，通过网关层来做映射

工作流程

1. zuul作为一个netty服务端server

2. 接受Internet Request之后，出发netty inbound事件；

3. Request经过处理之后，经过Endpoint Filter拦截，获取到Request的特定Service Url

4. 特定service的Request route到特定的Netty Client

5. Netty Client经过一系列的处理，将Response返回给Filter

6. Filter返回给Netty Server 中间需要经过一系列Netty的ChannelHandlerAdapter以及底层内部协议栈，序列化Request和Response

58、Eureka 组件及作用

Eureka Server：注册中心服务端

• 服务注册：服务提供者启动时，会通过 Eureka Client 向 Eureka Server 注册信息，Eureka Server 会存储该服务的信息，Eureka Server 内部有二层缓存机制来维护整个注册表

• 提供注册表：服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表

• 同步状态：Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。

Eureka Client：注册中心客户端

• 服务注册

• 服务续约

• 服务剔除

• 服务下线

59、Eureka集群同步机制

1、初始化Eureka Server的时候，会从本地内存里面读取 注册信息，自动注册到本身的服务上 2、发起同步事件 Heartbeat ： 心跳续约 Register ： 注册 Cancel ： 下线 StatusUpdate ： 添加覆盖状态 DeleteStatusOverride ： 删除覆盖状态

流程：

1. 判断集群节点是否为空，为空则返回

2. isReplication 代表是否是一个复制请求， isReplication = true 表示是其他Eureka Server发过来的同步请求,这个时候是不需要继续往下同步的。否则会陷入同步死循环

3. 循环集群节点，过滤掉自身的节点

4. 发起同步请求 ，调用replicateInstanceActionsToPeers

说明：默认采用的是批量任务处理器，就是将task放入任务队列中，然后通过线程获取任务队列里面的任务，模仿ThreadExecutorPool的方式，生成线程，从队列里面抓取任务处理，统一批量执行，Eureka Server 那边也是统一接收，这样提高了同步效率批量处理的任务执行器是com.netflix.eureka.cluster.ReplicationTaskProcessor

60、gateway网关的使用场景，

• 反向代理

• 鉴权

• 限流

• 熔断

61、eureka核心流程

1. Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息

2. Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务

3. Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常

4. 当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例

5. 单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端

6. 当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式

7. Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地

8. 服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存

9. Eureka Client 获取到目标服务器信息，发起服务调用

10. Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除