Spring Cloud面试题目集锦

1、什么是Spring Cloud？

Spring Cloud 就是微服务系统架构的一站式解决方案，它包括注册中心Eurake、负载均衡Ribbon、注册中心Spring Config、Histrix服务熔断、Gateway注册网关五大核心组件。

2、微服务与SOA的区别？

SOA的特点：

1、系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】
2、系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】（SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去，可以理解为一批服务的组合。SOA将原来的单体架构按照功能细分为不同的子系统，然后再由各个子系统依赖服务中间件来调用所需服务。使用SOA将系统切分为多个组件服务，这种通过多个组件服务来完成请求的方式有很多好处，比如不同团队的可以负责不同的子项目；模块拆分，使用通讯接口，降低了模块之间的耦合度等等。）
3、业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

SOA架构和微服务架构的区别

微服务：

1.通过服务实现组件化
开发者不再需要协调其它服务部署对本服务的影响。

2.按业务能力来划分服务和开发团队
开发者可以自由选择开发技术，提供 API 服务

3.去中心化
每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

4.基础设施自动化（devops、自动化部署）
的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。

二者区别
SOA和微服务的主要区别：

• 微服务剔除SOA中复杂的ESB企业服务总线，所有的业务智能逻辑在服务内部处理，使用Http（Rest API）进行轻量化通讯
• SOA强调按水平架构划分为：前、后端、数据库、测试等，微服务强调按垂直架构划分，按业务能力划分，每个服务完成一种特定的功能，服务即产品
• SOA将组件以library的方式和应用部署在同一个进程中运行，微服务则是各个服务独立运行。
• 传统应用倾向于使用统一的技术平台来解决所有问题，微服务可以针对不同业务特征选择不同技术平台，去中心统一化，发挥各种技术平台的特长。
• SOA架构强调的是异构系统之间的通信和解耦合；（一种粗粒度、松耦合的服务架构）
• 微服务架构强调的是系统按业务边界做细粒度的拆分和部署。

3、Eurake、Nacos、Zookeeper的区别，注册中心技术选型

CAP理论
CAP理论是分布式架构中重要理论

• 一致性(Consistency) (所有节点在同一时间具有相同的数据)
• 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
• 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

通常情况先，C，A，无法同时保证C，A，或者保证CP，或者保证AP

Apache Zookeeper -> CP

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。
从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。
当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。
但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。
因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好（淘宝的双十一，京东的618就是紧遵AP的最好参照）。
当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。

Spring Cloud Eureka -> AP

Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。
在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。
当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。
默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳（默认周期为30秒），Eureka Server 将会注销该实例（默认为90秒， eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置）。
当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。
Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；
Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；
当网络稳定时，当前实例新注册的信息会被同步到其它节点中；
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。

Nacos：

• Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。在Spring Cloud中使用Nacos，只需要先下载 Nacos 并启动 Nacos server，Nacos只需要简单的配置就可以完成服务的注册发现。
• Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
• 一句话概括就是Nacos = Spring Cloud注册中心 + Spring Cloud配置中心。

4，Ribbon负载均衡原理 调用流程

1、初始化阶段，通过自动装配将RestTemplate与LoadBalancerInterceptor绑定到一起；
2、获取负载均衡器，通过负载均衡器中配置的默认算法选择一个合适的Server；
3、解析URL，将服务名请求路径转换为IP+端口的请求形式

5、Eurake注册中心

• Register：服务注册
  当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。
• Renew：服务续约
  Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。
• Fetch Registries：获取注册列表信息
  Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

Cancel：服务下线
Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：
DiscoveryManager.getInstance().shutdownComponent()；

• Eviction 服务剔除
  在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除
• 自我保护
  服务注册到Eureka Server后，会维护一个心跳连接，告诉Eureka Server自己还活着。Eureka Server在运行期间会统计心跳失败的比例在15分钟以之内是否低于85%，如果出现低于的情况，Eureka Server会将当前实例注册信息保护起来，让这些实例不会过期。这样做会使客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的情况

Eureka工作流程 ：
Spring Cloud Eureka源码分析

6、Spring Config注册中心

一、Config Server和Client原理
备注：Spring Cloud Config和Spring Cloud Eurake相似，都有客户端和服务端。

1、ConfigServer(配置中心服务端)从远端git拉取配置文件并在本地git一份，ConfigClient（微服务）从ConfigServer端获取自己对应 配置文件；

2,、手动刷新？
通过actuator和@RefreshScope通过调用actuator/refresh

3、当远端git仓库配置文件发生改变，ConfigServer如何通知到ConfigClient端，即ConfigClient如何感知到配置发生更新？

Spring Cloud Bus会向外提供一个http接口，即图中的/bus/refresh。我们将这个接口配置到远程的git的webhook上，当git上的文件内容发生变动时，就会自动调用/bus-refresh接口。Bus就会通知config-server，config-server会发布更新消息到消息总线的消息队列中，其他服务订阅到该消息就会信息刷新，从而实现整个微服务进行自动刷新。

1、提交配置触发post请求给server端的bus/refresh接口
2、server端接收到请求并发送给Spring Cloud Bus总线
3、Spring Cloud bus接到消息并通知给其它连接到总线的客户端
4、其它客户端接收到通知，请求Server端获取最新配置
5、全部客户端均获取到最新的配置

7、Gate Way 网关

Spring Cloud Gateway

8、Histrix服务熔断

Spring Cloud Hystrix

9、Feign

RestTemplate是Spring提供的用于发送HTTP请求的客户端工具，它遵循Restful原则。

Feign是Spring Cloud组件中一个轻量级RESTful的HTTP服务客户端，Feign内置了Ribbon，用来做客户端负载均衡，去调用服务注册中心的服务。Feign的使用方式是：使用Feign的注解定义接口，调用接口，就可以调用服务注册中心的服务。

OpenFeign是Spring Cloud 在Feign的基础上支持了Spring MVC的注解，如@RequestMapping等等。
OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，
并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

1、基于面向接口的动态代理方式生成实现类
2、根据接口类注解的声明规则，使用Contract协议解析底层的MethodHandler，将其解析为Method元数据
3、根据元数据信息和注解信息，从中提取出相应的值，来构造Http Request 对象
4、将Request请求进行编码
5、拦截器负责对请求和返回做装饰处理
6、日志记录
7、接着是Response解码，
8、执行Response相关的MethodHandler
9、经由代理类返回最终结果。

10、BIO，NIO、AIO

浅谈“阻塞同步”，“BIO、NIO、AIO”