SpringCloud基础概念学习笔记(Eureka、Ribbon、Feign、Zuul)

SpringCloud入门

参考：

• https://springcloud.cc/spring-cloud-netflix.html
• 中文API文档：https://springcloud.cc/spring-cloud-dalston.html
• SpringCloud中国社区 http://springcloud.cn/
• SpringCloud中文网 https://springcloud.cc

SpringCloud是什么

SpringCloud, 基于SpringBoot提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。

SpringCloud利用SpringBoot的开发便利性，巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等，他们都可以用SpringBoot的开发风格做到一键启动和部署。

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

SpringCloud 是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。

SpringCloud和SpringBoot关系

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

SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。

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

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

Eureka服务注册与发现

什么是Eureka？

Eureka：怎么读？（拼音读法：yi rui ka，伊瑞咔）

Netflix 在设计Eureka 时，遵循的就是AP原则

CAP原则又称CAP定理，指的是在一个分布式系统中
一致性（Consistency）
可用性（Availability）
分区容错性（Partition tolerance）
CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于Dubbo的注册中心，比如Zookeeper。

原理讲解

Eureka的基本架构：

SpringCloud 封装了NetFlix公司开发的Eureka模块来实现服务注册和发现。

Eureka采用了C-S的架构设计，EurekaServer 作为服务注册功能的服务器，他是服务注册中心。

而系统中的其他微服务。使用Eureka的客户端连接到EurekaServer并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，SpringCloud的一些其他模块（比如Zuul）就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑。

Eureka 包含两个组件：Eureka Server 和 Eureka Client 。

Eureka Server 提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

Eureka Client是一个Java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉（默认周期为90秒）

三大角色

• Eureka Server：提供服务的注册于发现。
• Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到。
• Service Consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务。

Eureka的自我保护机制

自我保护机制：好死不如赖活着

一句话总结：某时刻某一个微服务不可以用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存！

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与Eureka之间无法正常通行，以上行为可能变得非常危险了--因为微服务本身其实是健康的，此时本不应该注销这个服务。Eureka通过 自我保护机制 来解决这个问题--当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。

在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话：好死不如赖活着。

综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮和稳定。

在SpringCloud中，可以使用 eureka.server.enable-self-preservation = false 禁用自我保护模式 【不推荐关闭自我保护机制】

对比Zookeeper

回顾CAP原则

RDBMS （Mysql、Oracle、sqlServer）--->ACID
NoSQL（redis、mongdb）---> CAP

ACID是什么？

• A（Atomicity）原子性
• C（Consistency） 一致性
• I （Isolation）隔离性
• D（Durability）持久性

CAP是什么？

• C（Consistency）强一致性
• A（Availability）可用性
• P（Partition tolerance）分区容错性

CAP的三进二：CA、AP、CP

CAP理论的核心

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
• 根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类：
  • CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
  • CP：满足一致性，分区容错性的系统，通常性能不是特别高
  • AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

作为服务注册中心，Eureka比Zookeeper好在哪里？

著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）、P（容错性）。由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。

• Zookeeper保证的是CP
• Eureka保证的是AP

Zookeeper保证的是CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Ribbon负载均衡

Ribbon是什么？

Ribbon：怎么读？（拼音读法：rui ben，瑞本）

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。

简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如：连接超时、重试等等。简单的说，就是在配置文件中列出LoadBalancer（简称LB：负载均衡）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法！

Ribbon能干嘛？

LB，即负载均衡（Load Balance），在微服务或分布式集群中经常用的一种应用。

负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）。

常见的负载均衡软件有 Nginx，Lvs 等等

Dubbo、SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义

负载均衡简单分类：

• 集中式LB

  • 即在服务的消费方和提供方之间使用独立的LB设施
  • 如之前学习的Nginx，由该设施负责把访问请求通过某种策略转发至服务的提供方！

• 进程式LB

  • 将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器。

  • Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址！

Ribbon的github地址 ： https://github.com/NetFlix/ribbon

Ribbon负载均衡

架构说明：

Ribbon在工作时分成两步

• 第一步先选择EurekaServer，它优先选择在同一个区域内负载均衡较少的Server。
• 第二步在根据用户指定的策略，在从server去到的服务注册列表中选择一个地址。

其中Ribbon提供了多种策略，比如轮询（默认），随机和根据响应时间加权重...等等

总结：

• Ribbon其实就是一个软负载均衡的客户端组件，他可以和其他所需请求的客户端结合使用，和Eureka结合只是其中的一个实例。

Ribbon核心组件IRule

IRule：根据特定算法从服务列表中选取一个要访问的服务！

• RoundRobinRule【轮询】
• RandomRule【随机】
• AvailabilityFilterRule【会先过滤掉由于多次访问故障而处于断路器跳闸的服务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问】
• WeightedResponseTimeRule【根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大，被选中的概率越高，刚启动时如果统计信息不足，则使用RoundRobinRule策略，等待统计信息足够，会切换到WeightedResponseTimeRule】
• RetryRule【先按照RoundRobinRule的策略获取服务，如果获取服务失败，则在指定时间内会进行重试，获取可用的服务】
• BestAvailableRule【会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务】
• ZoneAvoidanceRule【默认规则，复合判断server所在区域的性能和server的可用性选择服务器】

Feign负载均衡

Feign是什么？

Feign：怎么读？（拼音读法：fei en 飞嗯）

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controller调用service。

Spring Cloud集成了Ribbon和Eureka，可在使用Feign时提供负载均衡的http客户端。

只需要创建一个接口，然后添加注解即可！

feign ，主要是社区，大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问的两种方法：

1. 微服务名字 【ribbon】
2. 接口和注解 【feign 】

Feign能干什么？

• Feign旨在使编写Java Http客户端变得更容易。

• 在使用Ribbon + RestTemplate时，利用RestTemplate对Http请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义，在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它（类似于以前Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可。）即可完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon时，自动封装服务调用客户端的开发量。

Feign集成了Ribbon

利用Ribbon维护了springcloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，通过Feign只需要定义服务绑定接口且以声明式的方法，优雅而且简单的实现了服务调用。

小结

Feign通过接口的方法调用Rest服务 ( 之前是Ribbon+RestTemplate )。

该请求发送给Eureka服务器，通过Feign直接找到服务接口，由于在进行服务调用的时候融合了Ribbon技术，所以也支持负载均衡作用！

feign其实不是做负载均衡的，负载均衡是ribbon的功能，feign只是集成了ribbon而已，但是负载均衡的功能还是feign内置的ribbon在做，而不是feign。

feign的作用是替代RestTemplate，性能比较低，但是可以使代码可读性很强。

Hystrix断路器

什么是Hystrix？

Hystrix：怎么读？（中英结合读法：hei si tree ke si，黑丝tree克丝）

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器” 本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个服务预期的，可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

Hystrix能干嘛

• 服务降级
• 服务熔断
• 服务限流
• 接近实时的监控
• .....

官网资料

https://github.com/Netflix/Hystrix/wiki

什么是服务熔断？

熔断机制是对应雪崩效应的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。

熔断机制的注解是 @HystrixCommand。

什么是服务降级？

整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。

服务降级处理是在客户端实现完成的，与服务端没有关系。

小结

• 服务熔断：一般是某个服务故障或者异常引起，类似现实世界中的 “保险丝” ， 当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时！
• 服务降级：所谓降级，一般是从整体负荷考虑，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。

服务监控

服务监控 hystrixDashboard

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求，多少成功，多少失败等等。

Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控，SpringCloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

Zuul路由网关

什么是Zuul？

Zuul：怎么读？（拼音读法：ru ou，入呕）

Zuul包含了对请求的路由和过滤两个最主要的功能：

其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

注意：Zuul服务最终还是会注册进Eureka

提供：代理 + 路由 + 过滤 三大功能！

Zuul能干嘛？

• 路由
• 过滤

官网文档：https://github.com/Netflix/zuul