Springcloud常见面试题

一、微服务的理解

微服务架构是一种架构模式或者说是一种架构风格.它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。
服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。

特点：

1、一组小的服务（大小没有特别的标准，只要同一团队的工程师理解服务的标识一致即可）

2、独立的进程（java的tomcat，nodejs等）

3、轻量级的通信（不是soap，是http协议）

4、基于业务能力（类似用户服务，商品服务等等）

5、独立部署（迭代速度快）

6、无集中式管理（无须统一技术栈，可以根据不同的服务或者团队进行灵活选择）

利：

强模块边界 。（模块化的演化过程：类-->组件/类库（sdk）-->服务(service)，方式越来越灵活）

可独立部署。

技术多样性。

弊：

分布式复杂性。

最终一致性。（各个服务的团队，数据也是分散式治理，会出现不一致的问题）

运维复杂性。

测试复杂性。

二、微服务解决方案

目前最流行的两种微服务解决方案是SpringCloud和Dubbo。

三、什么是springcloud

Spring Cloud 作为 Java 言的微服务框架，它依赖于 Spring Boot ，有快速开发、持续交付和容易部署等特点，巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。

springcloud思维导图简化版

springcloud思维导图详细版

四、spring cloud 的核心组件有哪些？

1、Eureka：服务注册于发现。
Netflix Eureka 是由 Netflix 开源的一款基于 REST 的服务发现组件，包括 Eureka Server 及 Eureka Client。

2、Feign：Feign是是一个声明式的Web Service客户端。基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。

3、Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。

4、Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。它提供了熔断器功能，能够阻止分布式系统中出现联动故障。

5、Zuul：网关管理，由 Zuul 网关转发请求给对应的服务。

6、Gateway
Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0、 Spring Boot 2.0 和 Project Reactor 等
技术开发的网关， Spring Cloud Gateway 旨在为微服务架构提供简单、 有效且统一的 API 路由
管理方式。

7、Config
Spring Cloud 中提供了分布式配置中 Spring Cloud Config ，为外部配置提供了客户端和服务器端的支持。

8、 Bus
使用 Spring Cloud Bus, 可以非常容易地搭建起消息总线。

9、OAuth2
Sprin Cloud 构建的微服务系统中可以使用 Spring Cloud OAuth2 来保护微服务系统。

10、Sleuth
Spring Cloud Sleuth是Spring Cloud 个组件，它的主要功能是在分布式系统中提供服务链路追踪的解决方案。

五、SpringBoot和SpringCloud关系

SpringBoot是Spring推出用于解决传统框架配置文件冗余,装配组件繁杂的基于Maven的解决方案,旨在快速搭建单个微服务
而SpringCloud专注于解决各个微服务之间的协调与配置,服务之间的通信,熔断,负载均衡等
技术维度并相同,并且SpringCloud是依赖于SpringBoot的,而SpringBoot并不是依赖与SpringCloud,甚至还可以和Dubbo进行优秀的整合开发

总结:

SpringBoot专注于快速方便的开发单个个体的微服务

SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,配置管理,服务发现,断路器,路由,事件总线等集成服务

SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系

SpringBoot专注于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架

六、Spring Cloud 和dubbo区别

1、服务调用方式 dubbo是RPC springcloud Rest Api

2、注册中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper

3、服务网关,dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。

七、服务注册和发现是什么意思？Spring Cloud 如何实现？

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。

Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

实现：

1.服务发布时，指定对应的服务名,将服务注册到 注册中心(eureka zookeeper)
2.注册中心加@EnableEurekaServer,服务用@EnableDiscoveryClient，然后用ribbon或feign进行服务直接的调用发现。

八、负载均衡的意义是什么?

在计算中，负载均衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。
负载均衡旨在优化资源使用，最大吞吐量，最小响应时间并避免任何单一资源的过载。使用多个组件进行负载均衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务进程。

九、什么是服务熔断?什么是服务降级

在复杂的分布式系统中,微服务之间的相互调用,有可能出现各种各样的原因导致服务的阻塞,在高并发场景下,服务的阻塞意味着线程的阻塞,导致当前线程不可用,服务器的线程全部阻塞,导致服务器崩溃,由于服务之间的调用关系是同步的,会对整个微服务系统造成服务雪崩

为了解决某个微服务的调用响应时间过长或者不可用进而占用越来越多的系统资源引起雪崩效应就需要进行服务熔断和服务降级处理。

服务降级（目的是为了提高用户体验）
在高并发情况下，防止用户一直处于等待状态（在tomcat中已经没有线程可以处理用户请求的时候，不应该让用户一直loading等待），使用服务降级的方式，返回一个友好的提示给客户端，不去处理请求，调用fallBack。比如秒杀场景，请求过多，就只返回“当前请求人数过多，请稍后再试”。

服务熔断（目的是为了保护服务）
在生活场景中，电闸里的保险丝达到极限的时候，就会被熔断然后跳闸，防止火灾发生。回到软件应用场景，在高并发情况下，如果请求数量达到一定极限（可以自己设置阈值），超出了设置的阈值，Hystrix会自动开启服务保护功能，然后通过服务降级的方式返回一个友好的提示给客户端。（服务熔断和服务降级是一起使用的）

十、什么是 Hystrix？它如何实现容错？

防雪崩利器，具备服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）
服务降级:
双十一 提示 哎哟喂，被挤爆了。 app秒杀 网络开小差了，请稍后再试。
优先核心服务，非核心服务不可用或弱可用。通过HystrixCommand注解指定。
fallbackMethod(回退函数)中具体实现降级逻辑。

Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。

通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

思考以下微服务

假设如果上图中的微服务 9 失败了，那么使用传统方法我们将传播一个异常。但这仍然会导致整个系统崩溃。

随着微服务数量的增加，这个问题变得更加复杂。微服务的数量可以高达 1000.这是 hystrix 出现的地方 我们将使用 Hystrix 在这种情况下的 Fallback 方法功能。我们有两个服务 employee-consumer 使用由 employee-porducer公开的服务。

简化图如下所示

现在假设由于某种原因，employee-producer 公开的服务会抛出异常。我们在这种情况下使用 Hystrix 定义了一个回退方法。这种后备方法应该具有与公开服务相同的返回类型。如果暴露服务中出现异常，则回退方法将返回一些值。

十一、 Hystrix断路器简介与工作原理

Hystrix断路器简介与工作原理

十二、Eureka和ZooKeeper两个的区别

1、ZooKeeper保证的是CP（一致性和分区容错）,Eureka保证的是AP（高可用和分区容错）

ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的（一致性）

Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用**(高可用)**,而查询到的数据并不是最新的

自我保护机制会导致

Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务

Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)

当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper一样使得整个注册系统瘫痪

2、ZooKeeper有Leader和Follower角色,Eureka各个节点平等

3、ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题

4、Eureka本质上是一个工程,而ZooKeeper只是一个进程

Eureka和zookeeper的区别

十三、什么是Ribbon？

ribbon是一个负载均衡客户端，可以很好的控制htt和tcp的一些行为。feign默认集成了ribbon。

十四、 什么是feigin？它的优点是什么？

1、feign采用的是基于接口的注解
2、feign整合了ribbon，具有负载均衡的能力
3、整合了Hystrix，具有熔断的能力

使用:

1.添加pom依赖。
2.启动类添加@EnableFeignClients
3.定义一个接口@FeignClient(name=“xxx”)指定调用哪个服务

十五、Ribbon和Feign的区别？

1、Ribbon都是调用其他服务的，但方式不同。
2、启动类注解不同，Ribbon是@RibbonClient feign的是@EnableFeignClients
3、服务指定的位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
4、调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。Feign需要将调用的方法定义成抽象方法即可。

十六、什么是Spring Cloud Bus?

spring cloud bus 将分布式的节点用轻量的消息代理连接起来，它可以用于广播配置文件的更改或者服务直接的通讯，也可用于监控。
如果修改了配置文件，发送一次请求，所有的客户端便会重新读取配置文件。
使用:
1.添加依赖
2.配置rabbimq

十七、什么是SpringCloudConfig?

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。

使用：

1、添加pom依赖
2、配置文件添加相关配置
3、启动类添加注解@EnableConfigServer

十八、什么是Spring Cloud Gateway?

Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。

使用了一个RouteLocatorBuilder的bean去创建路由，除了创建路由RouteLocatorBuilder可以让你添加各种predicates和filters，predicates断言的意思，顾名思义就是根据具体的请求的规则，由具体的route去处理，filters是各种过滤器，用来对请求做各种判断和修改。

十九、微服务之间是如何独立通讯的

1、远程过程调用（Remote Procedure Invocation）：也就是我们常说的服务的注册与发现，直接通过远程过程调用来访问别的service。

优点：
简单，常见,因为没有中间件代理，系统更简

缺点：
只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应
降低了可用性，因为客户端和服务端在请求过程中必须都是可用的

2、消息：使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。

优点:
把客户端和服务端解耦，更松耦合
提高可用性，因为消息中间件缓存了消息，直到消费者可以消费
支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响

缺点:
消息中间件有额外的复杂

二十、REST 和RPC对比

rest与rpc之间的区别

1、RPC主要的缺陷是服务提供方和调用方式之间的依赖太强，需要对每一个微服务进行接口的定义，并通过持续继承发布，严格版本控制才不会出现冲突。
2、REST是轻量级的接口，服务的提供和调用不存在代码之间的耦合，只需要一个约定进行规范。

1、rest

REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源。

REST并没有创造新的技术，组件或服务，只是使用Web的现有特征和能力。 可以完全通过HTTP协议实现，使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

2、rpc

RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层，RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

3、rest优缺点

1、优点：耦合性低，兼容性好，提高开发效率，不用关心接口实现细节，相对更规范，更标准，更通用，跨语言支持
2、缺点：性能不如 RPC 高。

4、rpc优缺点

1、优点：
—调用简单，清晰，透明，不用像 rest 一样复杂，就像调用本地方法一样简单。
—高效低延迟，性能高
—自定义协议（让传输报文提及更小）
—性能消耗低，高效的序列化协议可以支持高效的二进制传输
—自带负载均衡
2、缺点：
----耦合性强

例如：
我们为每个微服务定义了各自的 service 抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并 install 之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。
而 REST 接口相比 RPC 更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然 REST 接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST 方式的服务依赖要比 RPC 方式的依赖更为灵活。

—无法跨语言，平台敏感
Java 写的 RPC 微服务无法给 Python 调用。需要再实现一层 REST 来对外提供服务

5、rest与rpc选择

RPC 适用于内网服务调用，对外提供服务请走 REST。

IO 密集的服务调用用 RPC，低频服务用 REST

服务调用过于密集与复杂，RPC 就比较适用