SpringCloud

1、SpringCloud入门概述

1.1、SpringCloud是什么

Spring官网： https://spring.io/


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

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

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

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

1.2、SpringCloud和SpringBoot的关系

• SpringBoot专注于快速、方便的开发单个个体微服务
• SpringCloud关注全局的服务治理
• SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
• SpringBoot可以离开SpringCloud独立实用，开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系

1.3、SpringCloud能干嘛

• Distributed/versioned configuration（分布式/版本控制配置）
• Service registration and discovery（服务注册与发现）
• Routing（路由）
• Service-to-service calls（服务到服务的调用）
• Load balancing（负载均衡配置）
• Circuit Breakers（断路器）
• Distributed messaging（分布式消息管理）
• …

2、Eureka服务注册与发现

2.1、什么是Eureka

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

2.2、Eureka的基本架构

• SpringCloud封装了Netflix公司开发的Eureka模块来实现服务注册和发现
• Eureka采用C-S的架构设计，EurekaServer作为服务注册功能的服务器，它是服务注册中心，而系统中的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳连接，这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，SpringCloud的一些其他模块就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑
• Eureka包含两个组件：EurekaServcer和EurekaClient
• EurekaServcer提供注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到
• EurekaClient 是一个java的客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的、使用轮询负载算法的负载均衡器，在应用启动后，将会向EurekaServcer发送心跳（默认周期为30秒）。如果EurekaServcer在多个心跳周期内没有接收到某个节点的心跳，EurekaServcer将会从服务注册表中把这个服务节点移除掉（默认周期为90秒）

2.3、Eureka的三大角色

• EurekaServcer：提供服务注册与发现
• ServiceProvider：将自身服务注册到Eureka中，从而使消费方能够找到
• ServiceConsumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务

2.4、Eureka对比Zookeeper

2.4.1、回顾CAP

RDBMS(Mysql、Oracle、sqlServer) ===>ACID
NoSQL(redis、mongdb) ===>CAP

2.4.1、ACID是什么？

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

2.4.1、CAP是什么？

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

CAP的三进二：CA、AP、CP

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

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

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

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

2.5.1、Zookeeper保证的是CP

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

2.5.2、Eureka保证的是AP

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

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

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

3、Ribbon

3.1、什么是Ribbon？

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

3.2、Ribbon能干什么？

• LB，即负载均衡(Load Balance)，在微服务或分布式集群中经常用的一种应用。
• 负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA (高可用)。
• 常见的负载均衡软件有Nginx, Lvs等等
• dubbo、SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义
• 负载均衡简单分类:

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

进程式LB：
	将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的
服务器。
	Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址

4、Feign负载均衡

4.1、什么是feign？

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controller调用service。SpringCloud集成了Ribbon和Eureka，可在使用Feign时提供负载均衡的http客户端。

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

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

• 微服务名字【ribbon】
• 接口和注解【feign】

4.2、feign能干什么？

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

4.3、feign集成了ribbon

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

5、Hystrix

5.1、分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败!

5.2、服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出"、如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应"。

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒中内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

这时候我们就需要“弃车保帅”

5.3、什么是Hystrix？

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

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

5.4、Hystrix能干什么？

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

5.5、dashboard流监控

Dashboard流监控技术：在高并发环境下, 服务器负担很重. 在服务器崩掉前及时做出调整很有必要, 为了能实时观察到服务器的压力和访问的具体情况,

6、zuul

6.1、什么是zuul？

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

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

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

提供:代理＋路由＋过滤三大功能!

6.2、zuul能干什么？

• 路由
• 过滤

7、SpringCloud config分布式配置

7.1、分布式系统面临的–配置文件的问题

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务，由于每个服务都需要必要的配置信息才能运行，所以一套集中式的，动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml，那上百的的配置文件要修改起来，岂不是要发疯!

7.2、什么是SpringCloud config分布式配置中心

Spring Cloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置。

Spring Cloud Config 分为服务端和客户端两部分;

服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密，解密信息等访问接口。

客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。

7.3、SpringCloud config分布式配置中心能干嘛

• 集中管理配置文件
• 不同环境，不同配置，动态化的配置更新，分环境部署，比如/dev /test/ /prod /beta /release -
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。
• 当配置发生变动时，服务不需要重启，即可感知到配置的变化，并应用新的配置
• 将配置信息以REST接口的形式暴露

7.4、SpringCloud config分布式配置中心与github整合

由于Spring Cloud Config默认使用Git来存储配置文件（也有其他方式，比如支持SVN和本地文件)，但是最推荐的还是Git ,而且使用的是http / https 访问的形式;