SpringBoot、SpringCloud常见⾯试题
Spring，SpringMVC，SpringBoot，SpringCloud有什么区别和联系？
Spring是⼀个轻量级的控制反转(IoC)和⾯向切⾯(AOP)的容器框架。Spring使你能够编写更⼲净、更可管理、并且更易于测试的代码。
Spring MVC是Spring的⼀个模块，⼀个web框架。通过Dispatcher Servlet, ModelAndView 和 View Resolver，开发web应⽤变得很容易。主要针对的是⽹站应⽤程序或者服务开发——URL路由、Session、模板引擎、静态Web资源等等。
Spring配置复杂，繁琐，所以推出了Spring boot，约定优于配置，简化了spring的配置流程。
SpringBoot是⼀个框架，⼀种全新的编程规范，它的产⽣简化了框架的使⽤，所谓简化是指简化了Spring众多框架中所需的⼤量且繁琐的配置⽂件，所以 SpringBoot是⼀个服务于框架的框架，服务范围是简化配置⽂件。
Spring Cloud构建于Spring Boot之上，是⼀个关注全局的服务治理框架。
Spring VS SpringMVC：
spring ioc注解
Spring是⼀个⼀站式的轻量级的java开发框架，核⼼是控制反转（IOC）和⾯向切⾯（AOP），针对于开发的WEB层(springMvc)、业务层(Ioc)、持久层(jdbcTemplate)等都提供了多种配置解决⽅案；
SpringMVC是Spring基础之上的⼀个MVC框架，主要处理web开发的路径映射和视图渲染，属于Spring框架中WEB层开发的⼀部分；SpringMVC VS SpringBoot：
SpringMVC属于⼀个企业WEB开发的MVC框架，涵盖⾯包括前端视图开发、⽂件配置、后台接⼝逻辑开发等，XML、config等配置相对⽐较繁琐复杂；
SpringBoot框架相对于SpringMVC框架来说，更专注于开发微服务后台接⼝，不开发前端视图；
SpringBoot和SpringCloud：
SpringBoot使⽤了默认⼤于配置的理念，集成了快速开发的Spring多个插件，同时⾃动过滤不需要配置的多余的插件，简化了项⽬的开发配置流程，⼀定程度上取消xml配置，是⼀套快速配置开发的脚⼿架，能快速开发单个微服务；
SpringCloud⼤部分的功能插件都是基于SpringBoot去实现的，SpringCloud关注于全局的微服务整合和管理，将多个SpringBoot单体微服务进⾏整合以及管理；SpringCloud依赖于SpringBoot开发，⽽SpringBoot可以独⽴开发；
总结下来：
Spring是核⼼，提供了基础功能；
Spring MVC 是基于Spring的⼀个 MVC 框架 ；
Spring Boot 是为简化Spring配置的快速开发整合包；
Spring Cloud是构建在Spring Boot之上的服务治理框架。
为什么要⽤ spring boot？
Spring Boot使编码变简单
Spring Boot使配置变简单
Spring Boot使部署变简单
Spring Boot使监控变简单
Spring的不⾜
spring boot 配置⽂件有哪⼏种类型？它们有什么区别？
Spring Boot提供了两种常⽤的配置⽂件，分别是properties⽂件和yml⽂件。相对于properties⽂件⽽⾔，yml⽂件更年轻，也有很多的坑。可谓成也萧何败萧何，yml通过空格来确定层级关系，使配置⽂件结构跟清晰，但也会因为微不⾜道的空格⽽破坏了层级关系。
什么是 spring cloud？
从字⾯理解，Spring Cloud 就是致⼒于分布式系统、云服务的框架。
Spring Cloud 是整个 Spring 家族中新的成员，是最近云服务⽕爆的必然产物。
Spring Cloud 为开发⼈员提供了快速构建分布式系统中⼀些常见模式的⼯具，例如：
配置管理
服务注册与发现
断路器
智能路由
服务间调⽤
负载均衡
微代理
控制总线
⼀次性令牌
全局锁
领导选举
分布式会话
集状态
分布式消息
spring cloud 断路器的作⽤是什么？
在Spring Cloud中使⽤了Hystrix 来实现断路器的功能，断路器可以防⽌⼀个应⽤程序多次试图执⾏⼀个操作，即很可能失败，允许它继续⽽不等待故障恢复或者浪费 CPU 周期，⽽它确定该故障是持久的。断路器模式也使应⽤程序能够检测故障是否已经解决，如果问题似乎已经得到纠正，应⽤程序可以尝试调⽤操作。
断路器增加了稳定性和灵活性，以⼀个系统，提供稳定性，⽽系统从故障中恢复，并尽量减少此故障的对性能的影响。它可以帮助快速地拒绝对⼀个操作，即很可能失败，⽽不是等待操作超时（或者不返回）的请求，以保持系统的响应时间。如果断路器提⾼每次改变状态的时间的事件，该信息可以被⽤来监测由断路器保护系统的部件的健康状况，或以提醒管理员当断路器跳闸，以在打开状态。
spring cloud 的核⼼组件有哪些？
①. 服务发现——Netflix Eureka
⼀个RESTful服务，⽤来定位运⾏在AWS地区（Region）中的中间层服务。由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器⽤作服务注册服务器。Eureka客户端是⼀个java客户端，⽤来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换⽀持。Netflix在其⽣产环境中使⽤的是另外的客户端，它提供基于流量、资源利⽤率以及出错状态的加权负载均衡。
②. 客服端负载均衡——Netflix Ribbon
Ribbon，主要提供客户侧的软件负载均衡算法。Ribbon客户端组件提供⼀系列完善的配置选项，⽐如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。
③. 断路器——Netflix Hystrix
断路器可以防⽌⼀个应⽤程序多次试图执⾏⼀个操作，即很可能失败，允许它继续⽽不等待故障恢复或者浪费 CPU 周期，⽽它确定该故障是持久的。断路器模式也使应⽤程序能够检测故障是否已经解决。如果问题似乎已经得到纠正，应⽤程序可以尝试调⽤操作。
④. 服务⽹关——Netflix Zuul
类似nginx，反向代理的功能，不过netflix⾃⼰增加了⼀些配合其他组件的特性。
⑤. 分布式配置——Spring Cloud Config
这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。
Spring Cloud和Dubbo的区别
Dubbo关注的领域是Spring Cloud的⼀个⼦集。Dubbo专注于服务治理，其在服务治理、灰度发布、流量分发⽅⾯⽐Spring Cloud 更全⾯。Spring Cloud覆盖整个微服务架构领域。
Dubbo使⽤RPC调⽤效率⾼⼀些，Spring Cloud使⽤HTTP调⽤效率低，使⽤更简单。
REST和RPC的区别
REST风格的系统交互更⽅便，RPC调⽤服务提供⽅和调⽤⽅式之间依赖太强。
REST调⽤系统性能较低，RPC调⽤效率⽐REST⾼。
REST的灵活性可以跨系统跨语⾔调⽤，RPC只能在同语⾔内调⽤。
REST可以和Swagger等⼯具整合，⾃动输出接⼝API⽂档。
SpringCloud如何实现服务的注册和发现
1. 服务在发布时 指定对应的服务名（服务名包括了IP地址和端⼝） 将服务注册到注册中⼼（eureka或者zookeeper）。
2. 这⼀过程是springcloud⾃动实现 只需要在main⽅法添加@EnableDisscoveryClient  同⼀个服务修改端⼝就可以启动多个实例。
3. 调⽤⽅法：传递服务名称通过注册中⼼获取所有的可⽤实例 通过负载均衡策略调⽤（ribbon和feign）
对应的服务。
Ribbon和Feign的区别：
Ribbon和Feign都是⽤于调⽤其他服务的，不过⽅式不同。
1. 启动类使⽤的注解不同，Ribbon⽤的是@RibbonClient，Feign⽤的@EnableFeignClients。
2. 服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象⽅法的接⼝中使⽤@FeignClient声明。
3. 调⽤⽅式不同，Ribbon需要⾃⼰构建http请求，模拟http请求然后使⽤RestTemplate发送给其他服务，步骤相当繁琐。
Feign则是在Ribbon的基础上进⾏了⼀次改进，采⽤接⼝的⽅式，将需要调⽤的其他服务的⽅法定义成抽象⽅法即可，
不需要⾃⼰构建http请求。不过要注意的是抽象⽅法的注解、⽅法签名要和提供服务的⽅法完全⼀致。
ribbon的负载均衡策略
1. RoundRobinRule: 轮询策略，Ribbon以轮询的⽅式选择服务器，这个是默认值。所以⽰例中所启动的两个服务会被循环访问;
2. RandomRule: 随机策略，也就是说Ribbon会随机从服务器列表中选择⼀个进⾏访问;
3. BestAvailableRule: 最⼤可⽤策略，即先过滤出故障服务器后，选择⼀个当前并发请求数最⼩的;
4. WeightedResponseTimeRule: 带有加权的轮询策略，对各个服务器响应时间进⾏加权处理，然后在采⽤轮询的⽅式来获取相应的服
务器;
5. AvailabilityFilteringRule: 可⽤过滤策略，先过滤出故障的或并发请求⼤于阈值的⼀部分服务实例，然后再以线性轮询的⽅式从过滤
后的实例清单中选出⼀个;
6. ZoneAvoidanceRule: 区域感知策略，先使⽤主过滤条件（区域负载器，选择最优区域）对所有实例过滤并返回过滤后的实例清单，
依次使⽤次过滤条件列表中的过滤条件对主过滤条件的结果进⾏过滤，判断最⼩过滤数（默认1）和最⼩过滤百分⽐（默认0），最后对满⾜条件的服务器则使⽤RoundRobinRule(轮询⽅式)选择⼀个服务器实例。
简述什么是CAP，并说明Eureka包含CAP中的哪些?
CAP理论：⼀个分布式系统不可能同时满⾜C (⼀致性),A(可⽤性),P(分区容错性).由于分区容错性P在分布式系统中是必须要保证的，因此我们只能从A和C中进⾏权衡.
Eureka 遵守 AP
Eureka各个节点都是平等的,⼏个节点挂掉不会影响正常节点的⼯作，剩余的节点依然可以提供注册和查询服务。
⽽Eureka的客户端在向某个Eureka 注册或查询是如果发现连接失败，则会⾃动切换⾄其他节点，只要有⼀台Eureka还在，就能保证注册服务可⽤(保证可⽤性)，只不过查的信息可能不最新的不保证强⼀致性)。
Eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？
Zookeeper保证了CP（C：⼀致性，P：分区容错性）
Eureka保证了AP（A：⾼可⽤）
1. 当向注册中⼼查询服务列表时，我们可以容忍注册中⼼返回的是⼏分钟以前的信息，但不能容忍直接down掉不可⽤。也就是说，服务
注册功能对⾼可⽤性要求⽐较⾼，但zk会出现这样⼀种情况，当master节点因为⽹络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集都不可⽤，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因⽹络问题使得zk集失去master节点是较⼤概率会发⽣的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可⽤是不能容忍的。
2. Eureka保证了可⽤性，Eureka各个节点是平等的，⼏个节点挂掉不会影响正常节点的⼯作，剩余的节点仍然可以提供注册和查询服
务。⽽Eureka的客户端向某个Eureka注册或发现时发⽣连接失败，则会⾃动切换到其他节点，只要有⼀台Eureka还在，就能保证注册服务可⽤，只是查到的信息可能不是最新的。除此之外，Eureka还有⾃我保护机制，如果在15分钟内超过85%的节点没有正常的⼼跳，那么Eureka就认为客户端与注册中⼼发⽣了⽹络故障，此时会出现以下⼏种情况：
Eureka不在从注册列表中移除因为长时间没有收到⼼跳⽽应该过期的服务。
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可⽤）。
当⽹络稳定时，当前实例新的注册信息会被同步到其他节点。
因此，Eureka可以很好的应对因⽹络故障导致部分节点失去联系的情况，⽽不会像Zookeeper那样使整个微服务瘫痪。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。