SpringCloud-易微帮

文章目录

Spring Cloud的理解

Spring Cloud是Spring官方推出来的一套微服务解决方案。
准确来说，我认为Spring Cloud其实是对微服务架构里面出现各种技术场景，定义了一套标准规范。
然后在这套标准里面，Spring集成了Netflix公司的OSS开源套件，比如
Zuul 实现应用网关、Eureka 实现服务注册与发现、Ribbon实现负载均衡、Hystrix实现服务熔断我们可以使用Spring Cloud Netflix这套组件，快速落地微服务架构以及解决微服务治理等一系列问题。
但是随着Netflix OSS相关技术组件的闭源和停止维护，所以Spring官方也自研了一些组件，
比如Gateway实现网关、 LoadBalancer实现负载均衡。
另外，Alibaba里面的开源组件也实现了Spring Cloud的标准，成为了Spring Cloud 里面的另外一套微服务解决方案。包括Dubbo做rpc通信、Nacos实现服务注册与发现以及动态配置中心、Sentinel实现服务限流和服务降级等等。以上就是我对Spring Cloud的理解，另外，我再补充一下，我认为Spring Cloud生态的出现有两个很重要的意义。
在Spring Cloud出现之前，为了解决微服务架构里面的各种技术问题，需要去集成各种开
源框架，因为标准和兼容性问题，所以在实践的时候很麻烦，而Spring Cloud统一了这样一个标准。
降低了微服务架构的开发难度，只需要在Spring Boot的项目基础上通过starter启动依赖
集成相关组件就能轻松解决各种问题。
Spring Cloud 是一套分布式微服务的技术解决方案它提供了快速构建分布式系统的常用的一些组件比如说配置管理、服务的注册与发现、服务调用的负载均衡、资源隔离、熔断降级等等
不过 Spring Cloud 只是 Spring 官方提供的而真正的实现
目前有两套体系用的比较多 Spring Cloud Netflix和 Spring Cloud Alibaba
Spring Cloud Netflix 是基于 Netflix 这个公司的开源组件集成的一套微服务解决方案，其中的组件有

Ribbon——负载均衡 2. Hystrix——服务熔断
3.Zuul——网关 4. Eureka——服务注册与发现
Feign——服务调用
Spring Cloud Alibaba 是基于阿里巴巴开源组件集成的一套微服务解决方案，其中包括
Dubbo——消息通讯 2. Nacos——服务注册与发现
3.Seata——事务隔离 4. Sentinel——熔断降级
有了 Spring Cloud 这样的技术生态

Spring Cloud核心组件

Eureka：服务注册中⼼，服务注册与发现，各个服务启动时，Eureka Client都会将服务注册到EurekaServer，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从⽽知道其他服务在哪⾥
Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。客户端负载均衡，特性有区域亲和、重试机制
服务间发起请求的时候，基于Ribbon做负载均衡，从⼀个服务的多台机器中选择⼀台，
客户端负载均衡器，用于实现客户端的软件负载均衡算法。（主要是后端的直接通信的负载均衡）
注意：Nginx：主要是前端到后端的负载均衡
Feign：声明式的HTTP客户端，用于简化远程调用代码，声明性的Web服务客户端，基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求，声明式服务调⽤，本质上就是Ribbon+Hystrix，基于接口的申明式的服务调用客户端，让调用变得更简单
Hystrix：断路器，熔断机制，发起请求是通过Hystrix的线程池来⾛的，不同的服务⾛不同的线程池，实现了不同服务调⽤的隔离，避免了服务雪崩的问题，提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。
Zuul：服务网关，网关管理。 API服务⽹关，功能有路由分发和过滤。如果前端、移动端要调⽤后端系统，统⼀从Zuul⽹关进⼊，由Zuul⽹关转发请求给对应的服务注册中⼼还可以⽤zookeeper。
Confifig：分布式统一配置管理，配置中心，用于集中管理配置文件，分布式配置中⼼，⽀持本地仓库、SVN、Git、Jar包内配置等模式
Spring Cloud Security：安全框架，用于提供认证和授权支持。
Spring Cloud Stream：消息驱动微服务，用于实现异步通信和事件驱动架构。
Spring Cloud Task：任务调度与执行，用于实现定时任务和后台任务管理。
Spring Cloud Contract：契约测试，用于实现服务的契约测试和验证。
Spring Cloud Kubernetes：基于Kubernetes的扩展，用于实现云原生应用的部署和管理。
Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。
Bus，消息总线，配合Config仓库修改的⼀种Stream实现，
Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。
Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。

但是，有的时候我们并不一定非要全部都用SpringCloud的这些组件，有的时候我们也可以选择其他的开源组件替代。比如经常用Dubbo/gRPC来代替Feign进行服务间调用。经常使用Nacos代替Config+Eureka来实现服务发现/注册及配置中心的功能。

Eureka注册中心

Eureka作为SpringCloud的服务注册功能服务器，他是服务注册中心，系统中的其他服务使用Eureka的客户端将其连接到Eureka Service中，并且保持心跳，这样工作人员可以通过EurekaService来监控各个微服务是否运行正常。
eureka的缺点
a. 某个服务不可⽤时，各个Eureka Client不能及时的知道，需要1~3个⼼跳周期才能感知，但是，由于基于Netflix的服务调⽤端都会使⽤Hystrix来容错和降级，当服务调⽤不可⽤时Hystrix也能及时感知到，通过熔断机制来降级服务调⽤，因此弥补了基于客户端服务发现的时效性的缺点。
注册中心心跳是⼏秒
1、Eureka的客户端默认每隔30s会向eureka服务端更新实例，注册中⼼也会定时进⾏检查，发现某个实例默认90s内没有再收到⼼跳，会注销此实例，这些时间间隔是可配置的。
2、不过注册中⼼还有⼀个保护模式（服务端在短时间内丢失过多客户端的时候，就会进⼊保护模式），在这个保护模式下，他会认为是⽹络问题，不会注销任何过期的实例。

Eureka server数据同步原理
Eureka是一个服务注册中心，在Eureka的设计里面，为了保证Eureka的高可用性，提供了集群的部
署方式。Eureka的集群部署采用的是两两相互注册的方式来实现，也就是说每个Eureka Server节点都需要发
现集群中的其他节点并建立连接，然后通过心跳的方式来维持这个连接的状态。Eureka Server集群节点之间的数据同步方式非常简单粗暴，使用的是对等复制的方式来实现数据同步。也就是说，在Eureka Server集群中，不存在所谓主从节点，任何一个节点都可以接收或者写入数据。一旦集群中的任意一个节点接收到了数据的变更，就直接同步到其他节点上。

这种无中心化节点的数据同步，需要考虑到一个数据同步死循环的问题，也就是需要区分EurekaServer收到的数据是属于客户端传递来的数据还是集群中其他节点发过来的同步数据。
Eureka使用了一个时间戳的标记来实现类似于数据的版本号来解决这个问题。
另外，从Eureka的数据同步方案来看，Eureka集群采用的是AP模型，也就是只提供高可用保障，而不提供数据强一致性保障。之所以采用AP，我认为注册中心它只是维护服务之间的通信地址，数据是否一致对于服务之间的通
信影响并不大。而注册中心对Eureka的高可用性要求会比较高，不能出现因为Eureka的故障导致服务之间无法通信的问题。Eureka虽然闭源了，但是在国内依然使用较为广泛。
当然有些公司逐步迁移到了Nacos上面，但是Eureka的整个框架设计上还是有非常多值得我们学习
的思想。多级缓存设计、集群之间的数据同步方案、多区域隔离以及就近访问的设计
多个消费者调用同⼀接口，eruka默认的分配方式是什么

RoundRobinRule:轮询策略，Ribbon以轮询的⽅式选择服务器，这个是默认值。所以示例中所启动的两个服务会被循环访问;
RandomRule:随机选择，也就是说Ribbon会随机从服务器列表中选择⼀个进⾏访问;
BestAvailableRule:最⼤可⽤策略，即先过滤出故障服务器后，选择⼀个当前并发请求数最⼩的;
WeightedResponseTimeRule:带有加权的轮询策略，对各个服务器响应时间进⾏加权处理，然后在采⽤轮询的⽅式来获取相应的服务器;
AvailabilityFilteringRule:可⽤过滤策略，先过滤出故障的或并发请求⼤于阈值⼀部分服务实例，然后再以线性轮询的⽅式从过滤后的实例清单中选出⼀个;
ZoneAvoidanceRule:区域感知策略，先使⽤主过滤条件（区域负载器，选择最优区域）对所有实例过滤并返回过滤后的实例清单，依次使⽤次过滤条件列表中的过滤条件对主过滤条件的结果进⾏过滤，判断最⼩过滤数（默认1）和最⼩过滤百分⽐（默认0），最后对满⾜条件的服务器则使⽤RoundRobinRule(轮询⽅式)选择⼀个服务器实例。
如果服务宕机或者⽆法访问了，我还去请求该服务，Eureka会怎么处理？会有什么现象
Eureka服务注册中⼼的失效剔除与⾃我保护机制：
Eureka是如何进⾏服务注册的
a. 每30s发送⼼跳检测重新进⾏租约，如果客户端不能多次更新租约，它将在90s内从服务器注册中⼼移除。
a. 注册信息和更新会被复制到其他Eureka 节点，来⾃任何区域的客户端可以查找到注册中⼼信息，每30s发⽣⼀次复制来定位他们的服务，并进⾏远程调⽤。
b. 客户端还可以缓存⼀些服务实例信息，所以即使Eureka全挂掉，客户端也是可以定位到服务地址的。

消费者获取到一个宕机地址，如何解决
为什么消费者会获取到一个宕机的地址呢：
1.非正常停止 springboot 项目：不会走回调方法不会主动通知注册中心删除该地址。
可以通过服务剔除来进行实现。
2.注册中心每间隔一段时间例如 5s 检查注册中心地址是否有续约，
如果没有续约的话则会将该地址直接从我们的注册中心移除。我们生产者
3.每隔一段时间发送心跳给我们注册中心告诉当前地址还是存活的状态。
4.如果注册中心在一段时间内没有收到该地址发送过来的心跳，则认为该地址已经
宕机直接从 map 集合中移除。
通过负载均衡算法直接故障转移获取下一个地址。

Eureka的保护机制
Eureka Server的⾃我保护机制会检查最近15分钟内所有Eureka Client正常⼼跳的占⽐，如果低于85%就会被触发。我们如果在Eureka Server的管理界⾯发现如下的红⾊内容，就说明已经触发了⾃我保护机制。
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING
INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN
THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED
JUST TO BE SAFE.
当触发⾃我保护机制后Eureka Server就会锁定服务列表，不让服务列表内的服务过期，不过这样我们在访问服务时，得到的服务很有可能是已经失效的实例，如果是这样我们就会⽆法访问到期望的资源，会导致服务调⽤失败，
所以这时我们就需要有对应的容错机制、熔断机制，我们在接下来的⽂章内会详细讲解这块知识点。
我们的服务如果是采⽤的公⽹IP地址，出现⾃我保护机制的⼏率就会⼤
⼤增加，所以这时更要我们部署多个相同InstanId的服务或者建⽴⼀套完整的
熔断机制解决⽅案。
⾃我保护开关
如果在本地测试环境，建议关掉⾃我保护机制，这样⽅便我们进⾏测
试，也更准备的保证了服务实例的有效性！！！
关闭⾃我保护只需要修改application.yml配置⽂件内参
数eureka.server.enable-self-preservation将值设置为false即可。

Feign

开源项目地址：链接
在Spring Cloud中使⽤Feign, 我们可以做到使⽤HTTP请求远程服务时能与调⽤本地⽅法⼀样的编码体验，开发者完全感知不到这是远程⽅法，更感知不到这是个HTTP请求
Feign 的英文表意为“假装，伪装，变形”，是一个http请求调用的轻量级框架，可以以Java接口注解的方式调用Http请求，而不用像Java中通过封装HTTP请求报文的方式直接调用。Feign通过处理注解，将请求模板化，当实际调用的时候，传入参数，根据参数再应用到请求上，进而转化成真正的请求，这种请求相对而言比较直观。
封装了Http调用流程，更适合面向接口化的变成习惯
Feign底层默认是使用jdk中的HttpURLConnection发送HTTP请求，feign也提供了OKhttp来发送请求，具体配置如下：

feign:
  client:
    config:
      default:
        connectTimeout: 5000
        readTimeout: 5000
        loggerLevel: basic
  okhttp:
    enabled: true
  hystrix:
    enabled: true

Feign解决了什么问题
封装了Http调用流程，更适合面向接口化的变成习惯
在服务调用的场景中，我们经常调用基于Http协议的服务，而我们经常使用到的框架可能有HttpURLConnection、Apache HttpComponnets、OkHttp3 、Netty等等，这些框架在基于自身的专注点提供了自身特性。而从角色划分上来看，他们的职能是一致的提供Http调用服务。具体流程如下：
在这里插入图片描述

Ribbon和Feign调用服务的区别
调用方式同：Ribbon需要我们自己构建Http请求，模拟Http请求然后通过RestTemplate发给其他
服务，步骤相当繁琐
而Feign则是在Ribbon的基础上进行了一次改进，采用接口的形式，将我们需要调用的服务方法定
义成抽象方法保存在本地就可以了，不需要自己构建Http请求了，直接调用接口就行了，不过要
注意，调用方法要和本地抽象方法的签名完全一致。

OpenFeign底层原理怎么实现的
动态代理+http
OpenFeign 是一个基于注解的声明式 HTTP 客户端，它的底层原理是通过动态代理实现的。
在使用 OpenFeign 时，我们会先定义一个接口（通常称为 Feign 客户端接口），然后使用 FeignClient 注解进行标记，指定其对应要访问的服务名和 URL 地址等配置信息。这样，在启动时，OpenFeign 会为这个接口生成代理对象（通常称为 Feign 客户端对象），并将其注册到 Spring 容器中。
当我们调用 Feign 客户端对象的方法时，实际上是调用了代理对象的方法。在这个方法中，OpenFeign 会根据 Feign 客户端接口中的注解信息（如 @RequestMapping、@GetMapping 等）生成对应的 HTTP 请求，并发送给指定的服务地址。同时，它还会处理请求和响应的数据，并将结果转换成指定的 Java 类型返回给调用方。
具体来说，OpenFeign 的动态代理实现主要包括以下几个步骤：

根据 Feign 客户端接口定义，在运行时创建一个代理类。
在代理类中，实现了 Feign 客户端接口的所有方法，并将这些方法的实现转化为 HTTP 请求，并将其发送给指定的服务地址。
代理类内部使用了 FeignClientFactory 工厂类，该类用于创建 Feign 客户端对象，并进行一些初始化和配置工作（如 RestClient、Decoder、Encoder 等）。
代理类还使用了 RequestTemplate 类，用于表示 HTTP 请求的所有信息（如请求头、请求参数等）。
代理类通过调用 FeignClientFactory 的 create 方法，在运行时动态地创建 Feign 客户端对象，并将其注入到 Spring 容器中。
在代理类的方法中，通过调用 Feign 客户端对象的方法来实现请求的发送和响应数据的处理。
总之，OpenFeign 的底层原理就是通过动态代理实现了对客户端接口的封装，使得客户端能够像调用本地接口一样简单、方便地访问远程服务。

OpenFeign 和 Feign的区别
OpenFeign 和 Feign 是两种 Java 中的 HTTP 客户端库，它们之间的关系可以理解为 OpenFeign 是 Feign 的升级和开放版本。

Feign：
○ Feign 是 Netflix 公司开发的一个声明式、模板化的 HTTP 客户端库，用于简化对 RESTful 服务的调用。
○ Feign 的设计理念是通过接口和注解的方式，定义和描述 HTTP API 的调用方式，然后通过动态代理技术，在运行时生成具体的 HTTP 请求。
○ Feign 支持多种编码器和解码器，可以自定义请求和响应的处理逻辑。
○ Feign 在使用上相对灵活，但需要开发者手动配置和管理。
OpenFeign：
○ OpenFeign 是 Spring Cloud 社区对 Feign 的增强和扩展版本，它在 Feign 的基础上提供了更多的功能和便利，同时与 Spring Cloud 紧密集成。
○ OpenFeign 提供了更加友好和易用的 API，支持 Spring Cloud 的注解和配置方式，如 @FeignClient 和 @RequestMapping。
○ OpenFeign 对负载均衡、熔断器（如 Hystrix）、服务发现等功能进行了集成和支持，使得在微服务架构中更加方便地调用其他服务。
○ OpenFeign 还提供了更加丰富的配置选项，如请求和响应的超时设置、重试机制等，使得开发者可以更灵活地控制 HTTP 请求的行为。
综上所述，OpenFeign 是对 Feign 的增强和扩展版本，在功能和易用性上相对于原始的 Feign 更加强大和方便，特别适用于基于 Spring Cloud 的微服务架构中的服务间通信。

Zuul网关Gateway

常用网关框架有那些
Nginx、Zuul、Gateway
Zuul与Nginx有什么区别
Zuul是java语言实现的，主要为java服务提供网关服务，尤其在微服务架构中可以更加灵活的对网
关进行操作。Nginx是使用C语言实现，性能高于Zuul，但是实现自定义操作需要熟悉lua语言，对
程序员要求较高，可以使用Nginx做Zuul集群。
网关与过滤器有什么区别
网关是对所有服务的请求进行分析过滤，过滤器是对单个服务而言
ZuulFilter常用有那些方法
Run()：过滤器的具体业务逻辑
shouldFilter()：判断过滤器是否有效
fifilterOrder()：过滤器执行顺序
fifilterType()：过滤器拦截位置
如何实现动态Zuul网关路由转发
通过path配置拦截请求，通过ServiceId到配置中心获取转发的服务列表，Zuul内部使用Ribbon实
现本地负载均衡和转发
Zuul网关如何搭建集群
使用Nginx的upstream设置Zuul服务集群，通过location拦截请求并转发到upstream，默认使用
轮询机制对Zuul集群发送请求。
Spring Cloud Gateway
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流
量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。
使用了一个RouteLocatorBuilder的bean去创建路由，除了创建路由RouteLocatorBuilder可以让
你添加各种predicates和fifilters，predicates断言的意思，顾名思义就是根据具体的请求的规则，
由具体的route去处理，fifilters是各种过滤器，用来对请求做各种判断和修改

Zuul和Gateway是专门用于构建微服务架构的服务网关，提供了丰富的功能和易于配置的路由规则。而Nginx是一个通用的Web服务器和反向代理服务器，可以用作网关，但不像Zuul和Gateway那样专注于微服务架构。

Ribbon负载平衡

Ribbon 是 Netflix 公司开发的一个客户端负载均衡器（Client-side Load Balancer），主要用于在微服务架构中实现对服务的负载均衡和故障转移。
要点包括：

负载均衡：Ribbon 可以将请求平均分配到多个服务实例上，以达到负载均衡的目的。它通过监控服务实例的健康状态和性能，并根据预定义的负载均衡策略，动态地选择合适的服务实例来处理请求。
故障转移：当某个服务实例发生故障或不可用时，Ribbon 可以自动将请求转发到其他可用的服务实例上，从而实现故障转移和容错处理。
集成性：Ribbon 可以与多种微服务框架（如 Spring Cloud、Netflix OSS 等）和服务发现组件（如 Eureka、Consul 等）集成使用，与 Spring Cloud Feign、OpenFeign 等组件配合使用，实现微服务架构中的服务间通信和负载均衡。
自定义策略：Ribbon 提供了多种负载均衡策略（如轮询、随机、权重等），同时也支持开发者自定义负载均衡策略，以满足不同场景下的需求。
配置灵活：Ribbon 提供了丰富的配置选项，可以灵活地配置负载均衡器的行为，如超时设置、重试机制等。
总的来说，Ribbon 在微服务架构中扮演着重要的角色，通过负载均衡和故障转移，帮助提高了系统的可用性、可靠性和性能。

Ribbon的工作流程

服务注册和发现：
在微服务架构中，服务通常会通过服务注册中心注册自己的地址和端口信息，以便其他服务能够发现和调用它。Ribbon 首先需要通过服务注册中心（如 Eureka、Consul 等）获取注册的服务列表。
负载均衡策略选择：
Ribbon 支持多种负载均衡策略，例如轮询、随机、权重等。在选择服务实例之前，Ribbon 需要根据预定义的负载均衡策略，选择合适的服务实例。
服务实例选择：
根据选定的负载均衡策略，Ribbon 会从服务实例列表中选择一个目标服务实例来处理请求。通常情况下，会考虑服务实例的健康状态、性能指标以及负载情况等因素。
执行请求：
一旦选择了目标服务实例，Ribbon 就会向该实例发出请求。这通常涉及到构建 HTTP 请求、设置请求头、选择合适的 HTTP 方法等操作。
响应处理：
当目标服务实例收到请求并返回响应时，Ribbon 会将响应返回给调用方。在接收到响应后，Ribbon 还可能进行一些后续的处理，例如重试、超时处理等。
故障转移和重试：
如果选择的服务实例发生故障或不可用，Ribbon 可能会根据预定义的策略进行故障转移，选择其他可用的服务实例。此外，Ribbon 还支持重试机制，以提高请求的成功率。
总的来说，Ribbon 的工作流程主要包括服务注册和发现、负载均衡策略选择、服务实例选择、执行请求、响应处理等步骤，通过这些步骤来实现对服务的负载均衡和故障转移。

Ribbon底层实现原理
● Ribbon使用discoveryClient从注册中心读取目标服务信息，对同一接口请求进行计数，使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。
如果没有Eureka，我能直接通过Ribbon进⾏服务请求吗可以的，需要导⼊ eureka-client-cat

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

@LoadBalanced注解的作用
开启客户端负载均衡。
springcloud心跳机制，以及消费端如何发现服务端（Ribbon）

Hystrix熔断降级

Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

当服务⽆法访问时，先降级，后熔断

怎么样才会出现熔断
熔断就跟保险丝⼀样，当⼀个服务请求并发特别⼤，服务器已经招架不住了，调⽤错误率飙升，当错误率达到⼀定阈值后，就将这个服务熔断了。熔断之后，后续的请求就不会再请求服务器了，以减缓服务器的压⼒。

Hystrix如何实现熔断
服务降级底层是如何实现的
● Hystrix实现服务降级的功能是通过重写HystrixCommand中的getFallback()方法，当Hystrix的run方法或construct执行发生错误时转而执行getFallback()方法。
Hystrix在运⾏过程中会向每个commandKey对应的熔断器报告成功、失败、超时和拒绝的状态，熔断器维护计算统计的数据，根据这些统计的信息来确定熔断器是否打开。如果打开，后续的请求都会被截断。然后会隔⼀段时间默认是5s，尝试半开，放⼊⼀部分流量请求进来，相当于对依赖服务进⾏⼀次健康检查，如果恢复，熔断器关闭，随后完全恢复调⽤。如下图：

在分布式系统，我们一定会依赖各种服务，那么这些个服务一定会出现失败的情况，就会导致雪
崩，Hystrix就是这样的一个工具，防雪崩利器，它具有服务降级，服务熔断，服务隔离，监控等
一些防止雪崩的技术。
Hystrix有四种防雪崩方式:
服务降级：接口调用失败就调用本地的方法返回一个空
服务熔断：接口调用失败就会进入调用接口提前定义好的一个熔断的方法，返回错误信息
服务隔离：隔离服务之间相互影响
服务监控：在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。

在微服务中，如何保护服务?
一般使用使用Hystrix框架，实现服务隔离来避免出现服务的雪崩效应，从而达到保护服务的效
果。当微服务中，高并发的数据库访问量导致服务线程阻塞，使单个服务宕机，服务的不可用会蔓
延到其他服务，引起整体服务灾难性后果，使用服务降级能有效为不同的服务分配资源,一旦服务
不可用则返回友好提示，不占用其他服务资源，从而避免单个服务崩溃引发整体服务的不可用

服务雪崩效应产生的原因
因为Tomcat默认情况下只有一个线程池来维护客户端发送的所有的请求，这时候某一接口在某一
时刻被大量访问就会占据tomcat线程池中的所有线程，其他请求处于等待状态，无法连接到服务
接口

谈谈服务降级、熔断、服务隔离服务降级：当客户端请求服务器端的时候，防止客户端一直等待，不会处理业务逻辑代码，直接返
回一个友好的提示给客户端。
服务熔断是在服务降级的基础上更直接的一种保护方式，当在一个统计时间范围内的请求失败数量
达到设定值（
requestVolumeThreshold）或当前的请求错误率达到设定的错误率阈值
（errorThresholdPercentage）时开启断路，之后的请求直接走fallback方法，在设定时间
（sleepWindowInMilliseconds）后尝试恢复。
服务隔离就是Hystrix为隔离的服务开启一个独立的线程池，这样在高并发的情况下不会影响其他
服务。服务隔离有线程池和信号量两种实现方式，一般使用线程池方式。

Hystrix的工作原理
https://www.cnblogs.com/sglx/p/15771838.html
hystrix经常被我们用于服务的熔断，降级等领域，基于RxJava（一种基于观察者模式的响应式编程框架）实现，具备服务降级、服务熔断、线程与信号隔离、请求缓存、请求合并以及服务监控等强大功能。
Hystrix 提供了两个命令对象：HystrixCommand 和HystrixObservableCommand，它将代表你✁一个依赖请求任务，向构造函数中传入请求依赖所需要✁参数。

Bus 消息总线

Bus：消息总线组件，可以帮助应用程序实现分布式事件传递和消息广播。
Spring Cloud Bus就像一个分布式执行器，用于扩展的Spring Boot应用程序的配置文件，但也可
以用作应用程序之间的通信通道。
Spring Cloud Bus 不能单独完成通信，需要配合MQ支持
Spring Cloud Bus一般是配合Spring Cloud Confifig做配置中心的
Springcloud confifig实时刷新也必须采用SpringCloud Bus消息总线

Confifig

Spring Cloud Confifig为分布式系统中的外部配置提供服务器和客户端支持，可以方便的对微服务
各个环境下的配置进行集中式管理。Spring Cloud Confifig分为Confifig Server和Confifig Client两部
分。Confifig Server负责读取配置文件，并且暴露Http API接口，Confifig Client通过调用Confifig
Server的接口来读取配置文件
springcloud confifig实时刷新采用SpringCloud Bus消息总线
分布式配置中心有那些框架
Apollo、zookeeper、springcloud confifig。
分布式配置中心的作用
动态变更项目配置信息而不必重新部署项目。

Spring Cloud的工作原理

在这里插入图片描述

Spring Cloud Alibaba

Spring Cloud Alibaba是一个基于Spring Cloud的开源项目，提供了一系列与阿里巴巴生态系统相关的组件和解决方案。以下是Spring Cloud Alibaba中一些常用的核心组件：

Nacos：服务注册与发现、配置管理中心，替代了Eureka和Config组件。
Sentinel：流量控制和熔断降级框架，用于保护微服务系统的稳定性。
RocketMQ：分布式消息队列，提供高可靠性的异步通信和数据同步能力。
Alibaba Cloud OSS：对象存储服务，用于存储和管理大规模文件和数据。
Alibaba Cloud ACM：应用配置管理服务，提供配置中心功能。
Alibaba Cloud SMS：短信服务，用于发送短信验证码和通知。
Alibaba Cloud OSS、OSS、ACM、SMS等客户端：用于在Spring Boot应用中使用对应的阿里云服务。
除了上述核心组件外，Spring Cloud Alibaba还提供了其他一些扩展组件和工具，如Dubbo Spring Cloud、Seata、Alibaba Cloud SDK等，以满足更加复杂的分布式系统需求。
需要注意的是，Spring Cloud Alibaba并不是Spring Cloud的官方子项目，而是由阿里巴巴团队提供的增强版Spring Cloud框架，专注于与阿里巴巴生态系统的集成。

SpringCloud主要项目

Spring Cloud的子项目，大致可分成两类，一类是对现有成熟框架"Spring Boot化"的封装和抽
象，也是数量最多的项目；第二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud
Stream扮演的就是kafka, ActiveMQ这样的角色
1.分布式服务注册中心（服务治理） Eureka、Zookeeper、Consule、Nacos、Redis、数据库等;
2.分布式配置中心 SpringCloud Config、携程阿波罗、Nacos Config
分布式事务解决方案(MQ 最终一致性/LCN(已经淘汰)/ Seata（阿里背书）
分布式任务调度平台(xxl-job、elastic job、阿里巴巴 Scheduler)
5.分布式日志采集系统 ELK+Kafka
6.分布式服务追踪与调用链 Zipkin、skywalking 等。
7.分布式锁(Redis（Redisson）Zookeeper（Curator）实现分布式锁)
8.服务的接口保护(hystrix/sentinel)

Spring Cloud优缺点

优点：
1.耦合度比较低。不会影响其他模块的开发。
2.减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发。
3.配置比较简单，基本用注解就能实现，不用使用过多的配置文件。
4.微服务跨平台的，可以用任何一种语言开发。
5.每个微服务可以有自己的独立的数据库也有用公共的数据库。
6.直接写后端的代码，不用关注前端怎么开发，直接写自己的后端代码即可，然后暴露接口，通过组件进行服务通信。
缺点：
1.部署比较麻烦，给运维工程师带来一定的麻烦。
2.针对数据的管理比麻烦，因为微服务可以每个微服务使用一个数据库。
3.系统集成测试比较麻烦
4.性能的监控比较麻烦。【最好开发一个大屏监控系统】
总的来说优点大过于缺点，目前看来Spring Cloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习Spring Cloud是一个不错的选择。

SpringBoot和SpringCloud的区别

SpringBoot专注于快速方便的开发单个个体微服务。SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务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完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。

dubbo和springcloud、springcloudAlibaba

（1）服务调用方式：dubbo是RPC springcloud Rest Api
（2）注册中心：dubbo 是zookeeper springcloud是eureka，也可以是zookeeper
（3）服务网关，dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。

Springcloud是一个微服务框架，提供了微服务领域中的很多功能件，
Dubbo-开始是一个RC调用框架核心是解决服务调用间的问题，
Soring Cloud是一个大而全的架Dubbo则更侧重于服务调用，所以Dubbo所提供的功能没有Springcloud全面，但界Dubbo的服务调用性能比Springcloud高

最大的区别：Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配合以 Hession 序列化完成 RPC 通信。
而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是 REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。

Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。
两者最大的区别是 Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP协议传输的，配合以 Hession 序列化完成 RPC 通信。
而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，相对来说，Http 请求会有更大
的报文，占的带宽也会更多。但是 REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。
最大的区别：Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。而SpringCloud是基于Http协议+Rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。

SpringCloud