SpringCloud常见面试题

SpringCloud常见面试题

一、系统架构的演变

单机版

把我们的所有的模块都放置一个项目上，最后将项目打包成war包或者jar包部署到你的服务器上； ​

• 优点：1、方便开发；2、部署简单
• ​缺点：1、代码耦合，开发维护困哪；2、并发性差、容错率高；3、无法针对对不同的模块进行优化

分布式

不同的业务在不同的模块上，然后发布在不同的服务器上，物理上的分离，逻辑上的集中

• 优点：1、降低了代码的耦合度；2、相比提高了项目的并发、容错率；3、(相比微服务关系错综复杂) ​
• 缺点：1、比较难开发；2、部署较难

SOA：面向服务

微服务：SpringCloud Dubbo 两套解决方案

二、微服务

是什么？

• 将传统的一站式的引用，根据业务的不同 拆分成一个一个的服务，去降低耦合度；
• 每一个微服务提供单个业务功能的服务，一个服务做一件事。
• ​从技术的角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁。 ​
• 可以拥有独立的数据库；

根据业务的不同：拆分成怎么样，仁者见仁智者见智了；微服务是一种架构风格；

特点

• 单一职责；微；
• 面向服务：每个服务都要对象暴露Rest风格服务接口API,不在乎里面的实现技术 ​
• 自治：团队独立、技术独立、前后端分离、数据库分离、部署独立。

三、Dubbo与SpringCloud的区别？

本质区别

• dubbo是基于RPC(远程过程调用)
• SringCloud是基础Http协议(超文本传输协议)

RPC和Http的区别

• RPC：基于原生的TCP协议，工作于会话层，传输效率高；自定义数据格式；限定统一技术
• HTTP：传输协议，也是基于TCP，工作于应用层，传输效率较低；统一的数据格式；不限制技术，只需要提供rest风格接口；消息封装臃肿

• 如果你的公司是使用java技术栈，可以使用Dubbo
• 但是如果使用技术栈的多样化或者青睐于Spring，使用SpringCloud

四、Spring、Spring FrameWork、SpringBoot和SpringCloud是什么？

Spring

Spring是一个生态体系(技术体系)，是集大成者，包括了SpringFrame，SpringBoot、SpringCloud、Spring Data、SpringSecurity 等等

Spring Frame

是整个Spring的基石，是一个一站式的轻量级的Java开发框架，核心是控制反转(IOC)和面向切面(AOP),针对开发WEB层的SpringMVC，业务层的AOP，持久层的JDBCTemplate等配置解决方案。

SpringBoot

SpringBoot是一个快速整合第三方框架的框架；有着简化配置、自动配置、独立运行和应用监控等优点

SpringCloud

SpringCloud则是微服务架构的一套解决方案；关注的是宏观，将SpringBoot开发的一个个单体的服务整合并管理起来，它为各个服务提供了注册中心进行服务发现，配置管理，负载均衡，断电器路由，微代理

由很多组件组成：
Eureka：注册中心；服务的注册与发现；
Zuul：网关组件；路由的请求分发、过滤器(Ribbon. hystrix)
Ribbon：负载均衡组件
Hystrix：熔断组件
Fegin：远程调用组件

五、Eureka(注册中心)

服务注册中心(可以是一个集群)，对外暴露自己的地址

• ​ 提供方：使用eureka的客户端，启动向eureka注册自己的信息(地址、提供什么服务)
• ​ 消费者：向eureka订阅服务，Eureka会将对应的服务提供者的地址列表发送给消费者，并且定期拉取服务进行更新
• ​ 心跳(续约)：提供方会定期的通过http方式向eureka刷新自己的状态
• ​ 使用application.name即可访问服务器，其中还可做负载均衡、熔断；

使用步骤

• 注册中心：item-eureka

1、引入启动器； ​
2、配置spring.application.name = item-eureka
​ eureka.client.service-url.defaultZone=http://localhost:10086/eureka
​ // 当是eureka集群时，两两相互注册即可； ​ 关闭自我保护，定期清 除无效链接 ​
eureka.server: ​ eviction-interval-timer-in-ms: 5000
​ enable-self-preservation: false] ​
3、启动类添加注解 @EnableEurekaServer

• 客户端：itcast-service-provider itcast-service-consumer

• 1、引入启动类
• 2、覆盖默认配置 spring.application.name ​注册到eureka
  eureka.client.service-url.defaultZone=http://localhost:10086/eureka
  在服务提供方中，设置心跳时间
  eureka：
  instance:
  lease-renewal-interval-in-seconds: 5 # 心跳时间
  lease-expiration-duration-in-seconds: 15 # 过期时间
  在服务消费者，设置拉取服务间隔时间
  eureka. client:
  registry-fetch-interval-seconds: 5
• 3、启动类添加注解@EnableDiscoveryClient

六、Ribbon(负载均衡)

• 1、eureka已经集成了
• 2、无需覆盖默认配置
• 3、在RestTemplate 这个组件上添加注解 @LoadBalanced

使用的负载均衡策略

• 1、默认使用的是：轮循
• ​2、可以使用 随机
  ​service-provider.ribbon:
  NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

七、Hystrix(熔断)

Hystrix是一个处理分布式系统的 延迟和容错开源库；在分布式系统里，许多依赖不可避免的会调用失败，你如超时、异常等，hystrix组件能够保证一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性

对比

• 之前：请求阻塞，一直阻塞会导致其他的服务器等不到响应，可能会级联故障，导致整个系统雪崩；
• 现在：用户的请求将不用直接访问服务，而是通过线程池中空闲的线程来访问服务，如果线程池已满，或者请求超时，则会进行服务降级；(比如向调用方返回一个响应；向调用方返回一个符合预期的、可处理的备选响应[FallBack]，而不是长时间的等待或者抛出调用方无法处理的异常)

服务降级:优先保护核心服务，而非核心服务不可用或弱可用

触发服务降级的条件

• 线程池已满；
• 请求超时

服务熔断：(断路器) 有三个状态

• Close：关闭状态，所有的请求都能正常的访问
• Open：打开状态，所有的请求都会被降级。Hystrix会对请求情况进行计数，当一定时间内请求次数达到20次以上并且失败次数的阈值达到了50%，则触发熔断，断路器会被打开；所有的请求都不能正常的访问；
• Half-Open：半打开状态；Open的状态不是永远的，当休眠5秒后会自动进去半打开状态；会释放部分请求通过，如果这些请求是成功的，那么就是完全关闭断路器；如果不成功，那么继续进行休眠5秒，重复流程；

八、Feign(远程调用)

Feign(伪装)：可以把Rest请求进行隐藏，伪装成SpringMVC的Controller一样，你不用在自己拼url和参数等，一切交给feign就可以

Feign也集成了Ribbon负载均衡(默认配置)和Hystix服务熔断(需要配置)；

使用流程

• ​1、引入openFeign启动器 ​
• 2、配置 feign.hystrix.enable = true ,开启我们的hystrix断路器； ​
• 3、配置启动类，@EnableFeignClients
• ​4、创建一个接口，添加注解@FeignClient(value,class=断路器的class)
• ​5、在接口中定义一些方法，这些方法的书写跟SpringMVC的controller类似，使用的都是SpringMVC的注解
• ​6、创建一个熔断类，实现feign接口，实现对应的方法，才能实现Feign进行熔断

九、Zuul(服务网关)

不论是来自客户端(PC端或移动端)的请求，还是服务内部调用，一切对服务的请求都必须经过Zuul服务网关组件，然后再由网关来实现动态路由、授权等等操作；Zuul就是我们服务的统一入门

Zuul 如果需要负载均衡 可以用nginx进行做负载均衡和反向代理

使用流程(路由)

• 1、引入Zuul启动器
• ​2、配置有4种方式

• 1、zuul.routes.<路由名称>.path=/service-provider/**
  zuul.routes.<路由名称>.url=http://localhost:8082
• 2、zuul.routes.<路由名称>.path=/service-provider/**
  zuul.routes.<路由名称>.serviceId=service-provider
• 3、zuul.routes.服务名 /随意item/**
• 4、不用配置，默认是服务id为开头，如provider就是 /provider/**

3. 在启动类(引导类)@EnableZuulProxy

过滤器

创建一个类继承ZuulFilter父类(基类) ​
重写其四个方法 ​

• 1、FilterType : Pre Route Post Error ​
• 2、FilterOrder：返回值越小执行的优先级越高
• ​3、shouldFilter：是否执行run方法，true为执行 ​
• 4、run 具体的拦截逻辑

Nginx

• 可做服务器也可做网关
• ​反向代理；负载均衡；动态路由；请求过滤

十、分布式微服务架构

十一、Eureka 和 Zookeeper 两个区别

CAP是什么？

• C：强一致性
• A：可用性
• P：分区容错性

分布式理论CAP

一个分布性系统不可能同时满足CAP；由于分区容错性P是分布式中必须要保证的；所以我们只能在A和C中进行权衡。

Zookeeper遵循CP

当一台Zookeeper挂了，那其他的Zookeeper会进行一次选取(要求强一致性；我一定要保证数据的一致性)；但是在选举的过程中Zookeeper是不可用的，而当前的体验不是很好；

Eureka遵循AP

• Eureka各个节点是平等的，几个节点挂掉并不会影响正常节点的工作，剩下的节点还能提供注册和查询的服务。
• 而Eureka的客户端在某个Eureka注册时发现失败，则会自动切换到其他的节点；只要有一台Eureka在，就能保证注册服务可用(保证可用性)；只不过查询到的信息可能不是最新(不能保证一致性)
• 除此之后，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳；(就是所有的eureka的都没有心跳)，那么eureka会认定注册中心出现了网络故障。会出现以下情况：
  • 1、Eureka不再从注册列表中移除因为长时间没收到心跳而过期的服务；
  • 2、Eureka能够接受新服务的注册和查询请求，但是不会被同步到其他节点(即保证当前节点的可用性)；
  • 3、当网络稳定时，当前节点新的注册信息会被同步到其他节点中。