一、概念
1.1 什么是Spring Cloud？
- Spring Cloud就是微服务系统架构的一站式解决方案，在平时我们构建微服务的过程中需要做如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等操作，而Spring Cloud为我们提供了一套简易的编程模型，使我们能在Spring Boot的基础上轻松实现微服务项目的构建。
1.2 为什么考虑 Spring Cloud？
- 原因
- SpringCloud来源于Spring,质量、稳定性、持续性都可以得到保证。
- SpringCloud天然支持SpringBoot,更加便于业务落地。
- 相比于其它框架，Spring Cloud 对微服务周边环境的支持力度最大。
- 特性
- 分布式/版本化配置
- 服务注册和发现
- 路由
- 服务和服务之间的调用
- 负载均衡
- 断路器
- 分布式消息传递
1.3 springcloud 与dubbo有哪些区别？
- 相同点：可以实现RPC远程调用框架，可以实现服务治理。
- 不同点
- 服务调用方式 dubbo是RPC; springcloud Rest Api。
- 注册中心,dubbo: zookeeper;springcloud是eureka，也可以是zookeeper.
- 服务网关,dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事务总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QS3HcqEH-1595329132241)(en-resource://database/1249:2)]
1.4 请谈谈对SpringBoot 和SpringCloud的理解
- SpringBoot专注于快速方便的开发单个个体微服务。
- SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并整理起来，为各个微服务之间提供，配置管理，服务发现，断路器，路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。
- SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖的关系。
1.5 分布式系统面临的问题
- 复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。
- 服务雪崩多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其他的微服务，这就是所谓的扇出；如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”
- 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。
- 服务依赖保护的三种解决方案：
- 熔断模式：如果某个目标服务调用慢或者有大量超时，此时熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标情况好转则恢复使用。
- 隔离模式：例如可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的请求直接返回。例如一个服务拆开，对于重要的服务使用单独服务器来部署，或者最近推广的多中心。
- 限流模式：上述的熔断模式和隔离模式都属于出错后的容错处理机制，而限流模式可以称为预防模式。限流模式主要是提前对各个类型的请求设置QPS（每秒钟请求数）阈值，高于该阈值对请求直接返回。
2.1 负载均衡的意义
- 在计算中，负载均衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载均衡旨在优化资源使用，最大吞吐量，最小响应时间并避免任何单一资源的过载。使用多个组件进行负载均衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务进程。
二、SpringCloud组件
2.1 什么是服务熔断、服务降级、服务隔离？
- 服务熔断：一般是某个服务异常引起的，相当于“保险丝”，当某个异常条件被触发，直接熔断整个服务，不是等到此服务超时。
- 服务降级：降级一般是从整体负荷考虑，当某个服务熔断之后，服务器将不再被调用，客户端可自己准备一个本地的fallback回调，返回一个缺省值，虽然服务水平下降，但是能用，比直接挂掉要强
- 服务隔离：Hystrix为隔离的服务开启一个独立的线程池，这样在高并发的情况下不会影响其他服务。服务隔离有线程池和信号量两种实现方式，一般使用线程池方式。
2.2 什么是 Hystrix断路器？
- Hystrix是一个用于处理分布式系统的延迟和容错的开源库，Hystrix能保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
- 断路器本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个符合预期的、可处理的备选响应（FallBack）,而不是长时间的等待或者抛出调用方无法处理的异常。这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
- Hystrix可以进行服务熔断、服务降级、服务限流
2.3 什么是 Eureka？
- Eureka是Netflix的一个子模块，也是核心模块之一。它是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
- Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现。
- Eureka 采用了 C-S 的设计架构。Eureka包含两个组件： Eureka Server 和 Eureka Client；
- Eureka Server 作为服务注册功能的服务器，它是服务注册中心。EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
- EurekaClient是一个Java客户端用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。
2.4 作为服务注册中心，Eureka比Zookeeper好在哪里?
- 著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
- Zookeeper 保证的是CP
- ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的
- Eureka保证AP
- Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用,而查询到的数据并不是最新的
- Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时出现以下几种情况：
- Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上
- 当网络稳定时，当前实例新的注册信息会被同步到其他节点上
- 因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
- ZooKeeper有Leader和Follower角色,Eureka各个节点平等
- ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
- Eureka本质上是一个工程,而ZooKeeper只是一个进程
2.5 Ribbon负载均衡能干嘛？
- Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法
- 集中式LB即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件如F5,也可以是软件如Nginx）,由该设施负责把访问请求通过某种策略转发至服务的提供方。
- 进程内LB将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。
- Ribbon就属于进程内LB,它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。
2.6 Feign能干嘛？
- Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单，它的使用方法是定义一个接口，然后在上面添加
@FeignClient(name=“xxx”)注解，同时也支持JAX-RS标准的注解。Feign也支持可拔插式的编码器和解码器。Spring Cloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConvertes.Feign可以与Eureka和Ribbon组合使用以支持负载均衡。
2.7 Ribbon和Feign调用服务的区别
- Ribbon需要我们自己构建Http请求，模拟Http请求然后通过RestTemplate发给其他服务，步骤相当繁琐
- Feign则是在Ribbon的基础上进行了一次改进，采用接口的形式，将我们需要调用的服务方法定义成抽象方法保存在本地就可以了，不需要自己构建Http请求了，直接调用接口就行
- Feign调用方法要和本地抽象方法的签名完全一致
2.8 什么是 zuul路由网关？
- 网关相当于一个网络服务架构的入口，所有网络请求必须通过网关转发到具体的服务。
- 网关作用：统一管理微服务请求，权限控制、负载均衡、路由转发、监控、安全控制黑名单和白名单等。
- Zuul会根据请求的路径不同，定位到指定的微服务，并代理请求到不同的微服务接口，他对外隐蔽了微服务的真正接口地址。
- 动态路由表：Zuul支持Eureka路由，手动配置路由，这俩种都支持自动更新
- 路由定位：根据请求路径，Zuul有自己的一套定位服务规则以及路由表达式匹配
- 反向代理：客户端请求到路由网关，网关受理之后，在对目标发送请求，拿到响应之后在 给客户端
- 应用场景：对外暴露，权限校验，服务聚合，日志审计等
2.9 什么是 Spring Cloud Bus？
- 用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置信息。
- 简单来说就是修改了配置文件，发送一次请求，所有客户端便会重新读取配置文件。
- 需要利用中间插件MQ.
2.10 什么是 Spring Cloud Config？
- Config能够管理所有微服务的配置文件;
- 集中配置管理工具，分布式系统中统一的外部配置管理，默认使用Git来存储配置，可以支持客户端配置的刷新及加密、解密操作。
- 动态变更项目配置信息而不必重新部署项目。 但实时刷新需要采用SpringCloud Bus消息总线。
2.11 什么是 Spring Cloud Gateway？
- Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式，Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Netflix Zuul，其不仅提供统一的路由方式，并且还基于Filter链的方式提供了网关基本的功能，例如：安全、监控/埋点、限流等。
Spring Cloud Netflix
- Netflix OSS 开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。
- Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
- Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
- Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
- Feign：基于Ribbon和Hystrix的声明式服务调用组件；
- Zuul：API网关组件，对请求提供路由及过滤功能。
[1 ] https://baijiahao.baidu.com/s?id=1655329799036379323&wfr=spider&for=pc
[2 ] https://blog.csdn.net/ThinkWon/article/details/104397367
[3 ] https://blog.csdn.net/weixin_43122090/article/details/105463548
本文地址：https://blog.csdn.net/weixin_44301710/article/details/107496125
如对本文有疑问，
点击进行留言回复！！
我要评论
网友评论