参考博客:
【金三银四】Spring Cloud面试题(2021最新版)_麒麟来编程的博客-CSDN博客
Spring Cloud是一系列框架的有序集合。它利用Spring Boot简化了分布式系统基础设施的开发,如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子,它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
微服务架构就是将单体的应用程序分成多个应用程序,这多个应用程序就称为微服务。
每个微服务运行在自己的进程中,并使用轻量级的机制通信。这些服务围绕业务能力划分,并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言,不同数据库,以保证最低限度的集中式管理。
分布式: 将一个项目拆分成了多个模块,并将这些模块分开部署,就是分布式。
微服务:微服务可以理解为一种非常细粒度的垂直拆分。
例如,以上“订单项目”本来就是垂直拆分后的子项目,但实际上“订单项目”还能进一步拆分为“购物项目”、“结算项目”和“售后项目”,订单项目”,它完全可以作为一个分布式项目的组成元素,但就不适合作为微服务的组成元素了(因为它还能再拆,而微服务应该是不能再拆的“微小”服务,类似于“原子性”)。所以,大白话就是,微服务就是不可分割的分布式模块
springcloud就基于SpringBoot把市场上优秀的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理。
什么叫做开箱即用?即使是当年的黄金搭档dubbo+zookeeper下载配置起来也是颇费心神的!而springcloud完成这些只需要一个jar的依赖就可以了!
springcloud大多数子模块都是直击痛点,像zuul解决的跨域,fegin解决的负载均衡,hystrix的熔断机制等等。
优点:
1.耦合度比较低。不会影响其他模块的开发。
2.减轻团队的成本,可以并行开发,不用关注其他人怎么开发,先关注自己的开发。
3.配置比较简单,基本用注解就能实现,不用使用过多的配置文件。
4.微服务跨平台的,可以用任何一种语言开发。
5.每个微服务可以有自己的独立的数据库也有用公共的数据库。
6.直接写后端的代码,不用关注前端怎么开发,直接写自己的后端代码即可,然后暴露接口,通过组件进行服务通信。
缺点:
1.部署比较麻烦,给运维工程师带来一定的麻烦。
2.针对数据的管理比麻烦,因为微服务可以每个微服务使用一个数据库。
3.系统集成测试比较麻烦
4.性能的监控比较麻烦。【最好开发一个大屏监控系统】
总的来说优点大过于缺点,目前看来Spring Cloud是一套非常完善的分布式框架,目前很多企业开始用微服务、Spring Cloud的优势是显而易见的。
SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,
为各个微服务之间提供,配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目, 但是SpringCloud离不开SpringBoot ,属于依赖的关系。
SpringBoot专注于快速、方便的开发单个微服务个体,SpringCloud关注全局的服务治理框架。
(1)与分布式系统相关的复杂性-这种开销包括网络问题,延迟开销,带宽问题,安全问题。
(2)服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录,在该目录中注册服务,然后能够查找并连接到该目录中的服务。
(3)冗余-分布式系统中的冗余问题。
(4)负载平衡 --负载平衡改善跨多个计算资源的工作负荷,诸如计算机,计算机集群,网络链路,中央处理单元,或磁盘驱动器的分布。
(5)性能-问题 由于各种运营开销导致的性能问题。
(1)服务调用方式:dubbo是RPC,springcloud Rest Api
RPC和REST的区别_DreamCatcher的博客-CSDN博客_rest和rpc的区别
(2)注册中心:dubbo 是zookeeper,springcloud是eureka,也可以是zookeeper
(3)服务网关,dubbo本身没有实现,只能通过其他第三方技术整合,springcloud有Zuul路由网关,作为路由服务器,进行消费者的请求分发,springcloud支持断路器,与git完美集成配置文件支持版本控制,事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。
Eureka作为SpringCloud的服务注册功能服务器,他是服务注册中心,系统中的其他服务使用Eureka的客户端将其连接到Eureka Service中,并且保持心跳,这样工作人员可以通过EurekaService来监控各个微服务是否运行正常。
开始一个项目时,我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署,添加和修改这些属性变得更加复杂。有些服务可能会下降,而某些位置可能会发生变化。手动更改属性可能会产生问题。Eureka服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Eureka 服务器上注册并通过调用Eureka 服务器完成查找,因此无需处理服务地点的任何更改和处理。
集群,注册多台 Eureka ,然后互相注册,客户端从 Eureka 获取信息时,按照Eureka 的顺序来访问。
谈谈Eureka的自我保护模式_翻身了,咸鱼!的博客-CSDN博客_eureka自我保护模式
默认情况下,如果 Eureka Service 在一定时间内没有接收到某个微服务的心跳, Eureka Service 会进入自我保护模式,在该模式下Eureka Service 会保护服务注册表中的信息,不在删除注册表中的数据,当网络故障恢复后,Eureka Servic 节点会自动退出自我保护模式。
简单来说,就是某个服务非正常挂掉时,Eureka 不会将他直接删除,而是保护起来,认为他还是正常的。
优点:稳定,避免了因网络等问题频繁的上下线;节省时间,频繁的通信断开连接,花费时间大量。
所以想下线一个服务,必须使用正常的手段,走完微服务的生命周期。默认情况下,强制下线会触发自我保护机制。
可以从注册中心中根据服务别名获取注册的服务器信息。
ZooKeeper中的节点服务挂了就要选举,在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的, 选举就是改微服务做了集群,必须有一台主其他的都是从。
Eureka各个节点是平等关系,服务器挂了没关系,只要有一台Eureka就可以保证服务可用,数据都是最新的。 如果查询到的数据并不是最新的,就是因为Eureka的自我保护模式导致的。
Eureka本质上是一个工程,而ZooKeeper只是一个进程。
Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper 一样使得整个注册系统瘫痪。
ZooKeeper保证的是CP,Eureka保证的是AP
CAP原则,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。
一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
可用性(A):保证每个请求不管成功或者失败都有响应。
分区容忍性(P):系统中任意信息的丢失或失败不会影响系统的继续运作。
网关相当于一个网络服务架构的入口,所有网络请求必须通过网关转发到具体的服务。
统一管理微服务请求,权限控制、负载均衡、路由转发、监控、安全控制黑名单和白名单等。
Zuul是对SpringCloud提供的成熟对的路由方案,他会根据请求的路径不同,网关会定位到指定的微服务,并代理请求到不同的微服务接口,他对外隐蔽了微服务的真正接口地址。三个重要概念:动态路由表,路由定位,反向代理:
网关是对所有服务的请求进行分析过滤,过滤器是对单个服务而言。
Nginx 、 Zuul 、 Gateway
Zuul 是 java 语言实现的,主要为 java 服务提供网关服务,尤其在微服务架构中可以更加灵活的对网关进行操作。Nginx 是使用 C 语言实现,性能高于 Zuul ,但是实现自定义操作需要熟悉 lua 语言,对程序员要求较高,可以使用Nginx 做 Zuul 集群。
Zuul 是 SpringCloud 集成的网关,使用 Java 语言编写,可以对 SpringCloud 架构提供更灵活的服务。
使用 Nginx 的 upstream 设置 Zuul 服务集群,通过 location 拦截请求并转发到 upstream ,默认使用轮询机制对Zuul 集群发送请求。
集群:集群就是把一个的事情交给多个人去做,假如要做1000个产品给一个人做要10天,我叫10个人做就是一天,这就是集群。
负载均衡:用来控制集群,他把做的最多的人让他慢慢做休息会,把做的最少的人让他加量让他做多点。
在计算中,负载平衡可以改善跨计算机,计算机集群,网络链接,中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用,最大化吞吐量,最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件,例如多层交换机或域名系统服务器进程。
Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法。
Ribbon客户端组件提供一系列完善的配置项,如连接超时,重试等。简单的说,就是在配置文件中列出后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随即连接等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。(类似与Nginx)
Nginx是反向代理同时可以实现负载均衡,nginx拦截客户端请求采用负载均衡策略根据upstream配置进行转发,相当于请求通过nginx服务器进行转发。
Ribbon是客户端负载均衡,从注册中心读取目标服务器信息,然后客户端采用轮询策略对服务直接访问,全程在客户端操作。
Ribbon 使用 discoveryClient 从注册中心读取目标服务信息,对同一接口请求进行计数,使用 % 取余算法获取目标服务集群索引,返回获取到的目标服务信息。
@LoadBalanced注解的作用:开启客户端负载均衡。
当一个服务调用另一个服务由于网络原因或自身原因出现问题,调用者就会等待被调用者的响应。当更多的服务请求到这些资源导致更多的请求等待,发生连锁效应(雪崩效应)
断路器有三种状态
雪崩效应是在大型互联网项目中,当某个服务发生宕机时,调用这个服务的其他服务也会发生宕机,大型项目的微服务之间的调用是互通的,这样就会将服务的不可用逐步扩大到各个其他服务中,从而使整个项目的服务宕机崩溃。
发生雪崩效应的原因有以下几点:
因为 Tomcat 默认情况下只有一个线程池来维护客户端发送的所有的请求,这时候某一接口在某一时刻被大量访问就会占据tomcat 线程池中的所有线程,其他请求处于等待状态,无法连接到服务接口。
一般使用使用Hystrix框架,实现服务隔离来避免出现服务的雪崩效应,从而达到保护服务的效果。当微服务中,高并发的数据库访问量导致服务线程阻塞,使单个服务宕机,服务的不可用会蔓延到其他服务,引起整体服务灾难性后果,使用服务降级能有效为不同的服务分配资源一旦服务不可用则返回友好提示,不占用其他服务资源,从而避免单个服务崩溃引发整体服务的不可用。
在分布式系统,我们一定会依赖各种服务,那么这些个服务一定会出现失败的情况,就会导致雪崩,Hystrix就是这样的一个工具,防雪崩利器,它具有服务降级,服务熔断,服务隔离,监控等一些防止雪崩的技术。
Hystrix有四种防雪崩方式:
Hystrix实现服务降级的功能是通过重写HystrixCommand中的getFallback()方法,当Hystrix的run方法或construct执行发生错误时转而执行getFallback()方法。
Feign 是一个声明web服务客户端,这使得编写web服务客户端更容易。
他将我们需要调用的服务方法定义成抽象方法保存在本地就可以了,不需要自己构建Http请求了,直接调用接口就行了,不过要注意,调用方法要和本地抽象方法的签名完全一致。
Feign
RestTemplate
Feign和RestTemplate 的使用比较_闪耀太阳a的博客-CSDN博客_resttemplate和feign的区别
调用方式同:Ribbon需要我们自己构建Http请求,模拟Http请求然后通过RestTemplate发给其他服务,步骤相当繁琐
而Feign则是在Ribbon的基础上进行了一次改进,采用接口的形式,将我们需要调用的服务方法定义成抽象方法保存在本地就可以了,不需要自己构建Http请求了,直接调用接口就行了,不过要注意,调用方法要和本地抽象方法的签名完全一致。
我们通常会使用消息代理来构建一个主题,然后把微服务架构中的所有服务都连接到这个主题上去,当我们向该主题发送消息时,所有订阅该主题的服务都会收到消息并进行消费。使用 Spring Cloud Bus 可以方便地构建起这套机制,所以 Spring Cloud Bus 又被称为消息总线。Spring Cloud Bus 配合 Spring Cloud Config 使用可以实现配置的动态刷新。目前 Spring Cloud Bus 支持两种消息代理:RabbitMQ 和 Kafka
Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持,可以方便的对微服务各个环境下的配置进行集中式管理。Spring Cloud Config分为Config Server和Config Client两部分。Config Server负责读取配置文件,并且暴露Http API接口,Config Client通过调用Config Server的接口来读取配置文件。
Apollo 、 zookeeper 、 springcloud config 。
动态变更项目配置信息而不必重新部署项目。
springcloud config 实时刷新采用 SpringCloud Bus 消息总线。
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架,取代Zuul网关。网关作为流量的,在微服务系统中有着非常作用,网关常见的功能有路由转发、权限校验、限流控制等作用。
使用了一个RouteLocatorBuilder的bean去创建路由,除了创建路由RouteLocatorBuilder可以让你添加各种predicates和filters,predicates断言的意思,顾名思义就是根据具体的请求的规则,由具体的route去处理,filters是各种过滤器,用来对请求做各种判断和修改。
zuul:
早期在微服务中使用较广泛,是基于servlet实现的,阻塞式的api,不支持长连接。只能同步,不支持异步。不依赖spring—webflux,可以扩展至其他微服务框架。内部没有实现限流、负载均衡,其负载均衡的实现是采用Ribbon +Eureka来实现本地负载均衡。代码简单,注释多,易理解。
Gateway:
是springcloud自己研制的微服务网关,是基于Spring5构建,能够实现响应式非阻塞式的Api,支持长连接。支持异步。功能更强大,内部实现了限流、负载均衡等,扩展性也更强。Spring Cloud Gateway明确的区分了Router和Filter,并且一个很大的特点是内置了非常多的开箱即用功能,并且都可以通过SpringBoot配置或者手工编码链式调用来使用。依赖于spring—webflux,仅适合于Spring Cloud套件。
代码复杂,注释少。
nginx:
C语言编写,采用服务器实现负载均衡,高性能的HTTP和反向代理web服务器。Nginx适合于服务器端负载均衡,Zuul和gateway是本地负载均衡,适合微服务中实现网关。 Spring Cloud Gateway天然适合Spring Cloud生态。
在SpringCloud中做服务注册中心组件,类似Duboo的Zookeeper,还有Consul。
Nacos也是一个注册中心组件,不过它不仅仅是注册中心。也是一个配置中心,比如SpringCloud中的Config,将配置文件版本化管理。
总结为官网一句话就是:
一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
简单来说 Nacos 就是注册中心 + 配置中心的组合,提供简单易用的特性集,帮助我们解决微服务开发必会涉及到的服务注册与发现,服务配置,服务管理等问题。
现在的微服务生态中,已经有很多服务注册与发现的开源组件,如 Eurka,ZooKeeper,Consul,为什么还要用Nacos呢,我们看下这些框架的简单对比:
据说 Nacos 在阿里巴巴内部有超过 10 万的实例运行,已经过了类似双十一等各种大型流量的考验
相比之下,目前的Nacos无论是部署,还是使用上都简单,更重要的是文档资料齐全,社区活跃度高。
并且Nacos与目前主流的开源生态都提供了很好的支持: