正文开始 ----------

2022 12月13日 每日面试题(SpringCloud)

1、什么是微服务架构

微服务架构就是将单体的应用程序分成多个应用程序，这多个应用程序就成为微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信。

这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。

2、为什么需要学习Spring Cloud

首先springcloud基于spingboot的优雅简洁，可还记得我们被无数xml支配的恐惧？可还记得springmvc，mybatis错综复杂的配置，有了spingboot，这些东西都不需要了，spingboot好处不再赘诉，springcloud就基于SpringBoot把市场上优秀的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理。

什么叫做开箱即用？即使是当年的黄金搭档dubbo+zookeeper下载配置起来也是颇费心神的！而springcloud完成这些只需要一个jar的依赖就可以了！

springcloud大多数子模块都是直击痛点，像zuul解决的跨域，fegin解决的负载均衡，hystrix的熔断机制等等等等

3、Spring Cloud 是什么

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

4、SpringCloud的优缺点

优点 ：

耦合度比较低。不会影响其他模块的开发。

减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发。

配置比较简单，基本用注解就能实现，不用使用过多的配置文件。

微服务跨平台的，可以用任何一种语言开发。

每个微服务可以有自己的独立的数据库也有用公共的数据库。

直接写后端的代码，不用关注前端怎么开发，直接写自己的后端代码即可，然后暴露接口，通过组件进行服务通信。

缺点 :

部署比较麻烦，给运维工程师带来一定的麻烦。

针对数据的管理比麻烦，因为微服务可以每个微服务使用一个数据库。

系统集成测试比较麻烦。

性能的监控比较麻烦。【最好开发一个大屏监控系统】

5、互联网应用架构演进

1）单体应用架构

在诞生之初，系统的用户量、数据量规模都比较小，项目所有的功能模块都放在一个工程中编码、编译、打包并且部署在一个Tomcat容器中的架构模式就是单体应用架构，这样的架构既简单实用、便于维护，成本又低，成为了那个时代的主流架构方式。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HKyLqs1r-1670980496829)(E:\百里半Java培训\5.微服务框架\Spring Cloud-new\day01\Spring Cloud微服务讲义.assets\image-20200921104303255.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NLS7RmiZ-1670980496830)(E:\百里半Java培训\5.微服务框架\Spring Cloud-new\day01\Spring Cloud微服务讲义.assets\image-20200921105052666.png)]

优点：

高效开发：项目前期开发节奏快，团队成员少的时候能够快速迭代

架构简单：MVC架构，只需要借助IDE开发、调试即可

易于测试：只需要通过单元测试或者浏览器完成

易于部署：打包成单个可执行的jar或者打成war包放到容器内启动

单体架构的应用比较容易部署、测试， 在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。

缺点：

可靠性差： 某个应用Bug，例如死循环、内存溢出等， 可能会导致整个应用的崩溃

复杂性高： 以一个百万行级别的单体应用为例，整个项目包含的模块多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。使得整个项目非常复杂。

扩展能力受限： 单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU； 有的模块则是IO密集型的，需要更大的内存。 由于这些模块部署在一起，不得不在硬件的选择上做出妥协。

业务量上涨之后，单体应用架构进一步丰富变化，比如应用集群部署、使用Nginx进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等，通过以上措施增强应对高并发的能力、应对一定的复杂业务场景，但依然属于单体应用架构。

2）垂直应用架构

为了避免上面提到的那些问题，开始做模块的垂直划分，做垂直划分的原则是基于系统现有的业务特性来做，核心目标第一个是为了业务之间互不影响，第二个是在研发团队的壮大后为了提高效率，减少组件之间的依赖。

优点

系统拆分实现了流量分担，解决了并发问题

可以针对不同模块进行优化

方便水平扩展，负载均衡，容错率提高

系统间相互独立，互不影响，新的业务迭代时更加高效

缺点

服务之间相互调用，如果某个服务的端扣或者ip地址发生改变，调用的系统得手动改变

搭建集群之后，实现负载均衡比较复杂，如：内网负载，在迁移机器时会影响调用方的路 由，导致线上故障

服务之间调用方式不统一，基于 httpclient 、 webservice ，接口协议不统一

服务监控不到位：除了依靠端口、进程的监控，调用的成功率、失败率、总耗时等等这些监 控指标是没有的

3）SOA应用架构

在做了垂直划分以后，模块随之增多，维护的成本在也变高，一些通用的业务和模块重复的越来越多，为了解决上面提到的接口协议不统一、服务无法监控、服务的负载均衡，引入了阿里巴巴开源的 Dubbo ，一款高性能、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。它提供了三个核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

SOA (Service-Oriented Architecture)，即面向服务的架构。根据实际业务，把系统拆分成合适的、独立部署的模块，模块之间相互独立（通过Webservice/Dubbo等技术进行通信）。

优点：分布式、松耦合、扩展灵活、可重用。

缺点：服务抽取粒度较大、服务调用方和提供方耦合度较高（接口耦合度）

4）微服务应用架构

微服务架构可以说是SOA架构的一种拓展，这种架构模式下它拆分粒度更小、服务更独立。把应用拆分成为一个个微小的服务，不同的服务可以使用不同的开发语言和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于微小、独立、轻量级通信。

微服务是在 SOA 上做的升华粒度更加细致，微服务架构强调的⼀个重点是业务需要彻底的组件化和服务化

微服务架构和SOA架构相似又不同

微服务架构和SOA架构很明显的一个区别就是服务拆分粒度的不同，但是对于系统的架构发展来说，我们所看到的SOA阶段其实服务拆分粒度相对来说已经比较细了（超前哦！），所以上述系统SOA到系统微服务，从服务拆分上来说变化并不大，只是引入了相对完整的新一代Spring Cloud微服务技术。自然，上述我们看到的都是系统架构演变的阶段结果，每一个阶段其实都经历了很多变化，系统的服务拆分其实也是走过了从粗到细，并非绝对的一步到位。

举个系统案例来说明SOA和微服务拆分粒度不同

我们在SOA架构的初期，“简历投递模块”和“人才搜索模块”都有简历内容展示的需求，只不过说可能略有区别，一开始在两个模块中各维护了一套简历查询和展示的代码；后期我们将服务更细粒度拆分，拆分出简历基础服务，那么不同模块调用这个基础服务即可。

6、SpringBoot和SpringCloud的区别？

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

SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来。

为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。

SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系。

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

7、Spring Cloud和SpringBoot版本对应关系

8、SpringCloud由什么组成

Spring Cloud Eureka：服务注册与发现

Spring Cloud Zuul：服务网关

Spring Cloud Ribbon：客户端负载均衡

Spring Cloud Feign：声明性的Web服务客户端

Spring Cloud Hystrix：断路器

Spring Cloud Config：分布式统一配置管理

等20几个框架，开源一直在更新

9、使用 Spring Boot 开发分布式微服务时，我们面临什么问题

与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。

服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。

冗余-分布式系统中的冗余问题。

负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。

性能-问题 由于各种运营开销导致的性能问题。

10、Spring Cloud 和dubbo区别?

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

注册中心：dubbo 是zookeeper springcloud是eureka，也可以是zookeeper

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

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

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

12、 什么是Eureka

Eureka作为SpringCloud的服务注册功能服务器，他是服务注册中心，系统中的其他服务使用Eureka的客户端将其连接到Eureka Service中，并且保持心跳，这样工作人员可以通过Eureka Service来监控各个微服务是否运行正常。

13、Eureka怎么实现高可用

通过集群，注册多台Eureka，然后把SpringCloud服务互相注册，客户端从Eureka获取信息时，按照Eureka的顺序来访问。

14、什么是Eureka的自我保护模式

默认情况下，如果Eureka Service在一定时间内没有接收到某个微服务的心跳，Eureka Service会进入自我保护模式，在该模式下Eureka Service会保护服务注册表中的信息，不在删除注册表中的数据，当网络故障恢复后，Eureka Servic 节点会自动退出自我保护模式。

15、DiscoveryClient的作用

可以从注册中心中根据服务别名获取注册的服务器信息。

16、Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别

ZooKeeper中的节点服务挂了就要选举 在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的， 选举就是改微服务做了集群，必须有一台主其他的都是从

Eureka各个节点是平等关系,服务器挂了没关系，只要有一台Eureka就可以保证服务可用，数据都是最新的。 如果查询到的数据并不是最新的，就是因为Eureka的自我保护模式导致的

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

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

ZooKeeper保证的是CP，Eureka保证的是AP

CAP： C：一致性>Consistency; 取舍：(强一致性、单调一致性、会话一致性、最终一致性、弱一致性) A：可用性>Availability; P：分区容错性>Partition tolerance;

17、什么是网关?

网关相当于一个网络服务架构的入口，所有网络请求必须通过网关转发到具体的服务。

18、网关的作用是什么

统一管理微服务请求，权限控制、负载均衡、路由转发、监控、安全控制黑名单和白名单等

19、什么是Spring Cloud Zuul（服务网关）？

Zuul是对SpringCloud提供的成熟对的路由方案，他会根据请求的路径不同，网关会定位到指定的微服务，并代理请求到不同的微服务接口，他对外隐蔽了微服务的真正接口地址。 三个重要概念：动态路由表，路由定位，反向代理：

动态路由表：Zuul支持Eureka路由，手动配置路由，这俩种都支持自动更新

路由定位：根据请求路径，Zuul有自己的一套定位服务规则以及路由表达式匹配

反向代理：客户端请求到路由网关，网关受理之后，在对目标发送请求，拿到响应之后在 给客户端

它可以和Eureka,Ribbon,Hystrix等组件配合使用，

Zuul的应用场景：

对外暴露，权限校验，服务聚合，日志审计等

20、网关与过滤器有什么区别

网关是对所有服务的请求进行分析过滤，过滤器是对单个服务而言。

21、常用网关框架有那些？

Nginx、Zuul、Gateway

22、Zuul与Nginx有什么区别？

Zuul是java语言实现的，主要为java服务提供网关服务，尤其在微服务架构中可以更加灵活的对网关进行操作。Nginx是使用C语言实现，性能高于Zuul，但是实现自定义操作需要熟悉lua语言，对程序员要求较高，可以使用Nginx做Zuul集群。

23、既然Nginx可以实现网关？为什么还需要使用Zuul框架

Zuul是SpringCloud集成的网关，使用Java语言编写，可以对SpringCloud架构提供更灵活的服务。

24、如何设计一套API接口

考虑到API接口的分类可以将API接口分为开发API接口和内网API接口，内网API接口用于局域网，为内部服务器提供服务。开放API接口用于对外部合作单位提供接口调用，需要遵循Oauth2.0权限认证协议。同时还需要考虑安全性、幂等性等问题。

25、ZuulFilter常用有那些方法

Run()：过滤器的具体业务逻辑

shouldFilter()：判断过滤器是否有效

filterOrder()：过滤器执行顺序

filterType()：过滤器拦截位置

26、如何实现动态Zuul网关路由转发

通过path配置拦截请求，通过ServiceId到配置中心获取转发的服务列表，Zuul内部使用Ribbon实现本地负载均衡和转发。

27、Zuul网关如何搭建集群

使用Nginx的upstream设置Zuul服务集群，通过location拦截请求并转发到upstream，默认使用轮询机制对Zuul集群发送请求。

28、负载平衡的意义什么？

简单来说： 先将集群，集群就是把一个的事情交给多个人去做，假如要做1000个产品给一个人做要10天，我叫10个人做就是一天，这就是集群，负载均衡的话就是用来控制集群，他把做的最多的人让他慢慢做休息会，把做的最少的人让他加量让他做多点。

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

29、Ribbon是什么？

Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法

Ribbon客户端组件提供一系列完善的配置项，如连接超时，重试等。简单的说，就是在配置文件中列出后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随即连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。（有点类似Nginx）

30、Nginx与Ribbon的区别

Nginx是反向代理同时可以实现负载均衡，nginx拦截客户端请求采用负载均衡策略根据upstream配置进行转发，相当于请求通过nginx服务器进行转发。Ribbon是客户端负载均衡，从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端操作。

31、Ribbon底层实现原理

Ribbon使用discoveryClient从注册中心读取目标服务信息，对同一接口请求进行计数，使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。

@LoadBalanced注解的作用

开启客户端负载均衡

32、什么是断路器

当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应 当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）

断路器有三种状态

打开状态：一段时间内 达到一定的次数无法调用 并且多次监测没有恢复的迹象 断路器完全打开 那么下次请求就不会请求到该服务

半开状态：短时间内 有恢复迹象 断路器会将部分请求发给该服务，正常调用时 断路器关闭

关闭状态：当服务一直处于正常状态 能正常调用

33、什么是 Hystrix？

在分布式系统，我们一定会依赖各种服务，那么这些个服务一定会出现失败的情况，就会导致雪崩，Hystrix就是这样的一个工具，防雪崩利器，它具有服务降级，服务熔断，服务隔离，监控等一些防止雪崩的技术。

Hystrix有四种防雪崩方式:

服务降级：接口调用失败就调用本地的方法返回一个空

服务熔断：接口调用失败就会进入调用接口提前定义好的一个熔断的方法，返回错误信息

服务隔离：隔离服务之间相互影响

服务监控：在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。