SpringCloud知识点复习（第一次）

这个阶段的技术的名词优点多，我们一定要理清楚每一种的技术的名字以及对应的注解名字。如果记不住可以参考我说的以微服务要解决的四个问题为切入点进行记忆。还有就是这部分的学习和SpringBoot后半部分的学习一样，多看文档资料，多理解思想内涵

文章目录

1、微服务概述
2、基于Rest学习的环境搭建
3、Eureka
- 3.1、概念
- 3.2、原理部分
- 3.3、环境搭建
- 3.4、添加服务发现Discovery机制
- 3.5、配置计算机集群
4、Ribbon
- 4.1、负载均衡的概念
- 4.2、Ribbon概念
- 4.3、负载均衡环境搭建
- 4.4、修改、自定义负载均衡算法
5、Feign
6、Hystrix
- 6.1、服务熔断
- 6.2、服务降级
- 6.3、服务熔断与服务降级的比较
- 6.4、Dashboard流量监控
7、Zuul
8、SpringCloud Config分布式配置
- 8.1、基本概念
- 8.2、配置服务端
- 8.3、配置客户端
9、思维导图

1、微服务概述

其实在SpringBoot阶段，我们就已经开始了对微服务的讲解，只不过那时候我们讲的是Dubbo+ZooKeeper+SpringBoot这一套方案。而这个阶段我们主要学习的是SpringCloud Netflix这一套方案。

对于微服务开发，我们学习的SpringBoot已经够用了，而SpringCloud部分也只是对微服务开发的一种生化，毕竟架构不同，相应的管理方式，处理方式也就不一样了。在Spring阶段我们说过一句话，SpringBoot构建一切，SpringCloud协调一切，SpringCloud Date Flow连接一切。对于SpringCloud前期的概念学习，还是那句话，一定要多去看文档资料，这个阶段的学习已经不能仅仅局限于技术的学习了。

SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式

	Dubbo	Spring
服务注册中心	ZooKeeper	Spring Cloud Netfilx Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring Boot Admin
熔断器	不完善	Spring Cloud Netfilx Hystrix
服务网关	无	Spring Cloud Netfilx Zuul
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task

分布式架构会遇到的四个核心问题?

服务众多，客户端该如何去访问?
服务众多，服务之间如何进行通信?
服务众多，如何治理呢?
服务众多，服务出了故障怎么处理？

这四个问题一定要牢牢地理解并记住，这会贯穿我们整个SpringCloud阶段的学习。记住这几个问题后，对于我们后期出现的技术才不会乱。

2、基于Rest学习的环境搭建

大致步骤与SpringBoot阶段的学习相同，搭建步骤为：

搭建父项目：

配置对应的maven依赖

搭建实体类项目springcloud-api：

创建一个maven项目，并引入对应的依赖
新建数据库，并使用IDEA进行连接
编写对应的实体类

搭建提供者项目springcloud-provider-dept-8001：

创建一个maven项目，并引入对应的依赖
编写对应的核心配置文件信息
配置mybatis的配置文件
编写测试mybatis那一套代码（接口类、接口类的mapper文件、service层代码、controller层代码）
编写该项目的SpringBoot启动类
测试代码

搭建消费者项目springcloud-consumer-dept-80：

创建一个maven项目，并引入对应的依赖
修改核心配置文件，特别是修改端口，用来表示这是不同的程序
编写RestTemplate模板的配置类
根据提供者对应的路径，编写我们的消费者控制器层代码
测试代码

我们有消费者、有提供者，并且数据都来自不同的项目，我们依然能够完成项目的基本搭建。最终的项目也就是在这个上面完成，只不过项目更多更复杂，但是模板就是这样的。

3、Eureka

3.1、概念

前面的环境搭建可以对标Dubbo，Eureka我们可以对标ZooKeeper。

我们现在讨论的技术都是建立在微服务的基础之上，微服务又有一个CAP理论，即我们的分布式系统是无法同时满足C（一致性）A（可用性）P（分区容忍性）。我们的ZooKeeper选择了CP，而我们的Eureka选择了AP。

3.2、原理部分

其实对比着ZooKeeper，我们就能够很好的理解了。

Eureka包含两个组件：Eureka Server和Eureka Client，各个节点启动后，会在Eureka Server中注册，这样我们就能够在界面中值观的看到服务节点的信息。Eureka Client是一个java的客户端，应用启动后，会向Eureka Server发送心跳，如果长时间没有接受到心跳，那么我们就会在服务注册表中把这个服务节点进行移除。

Eureka的三大角色：

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

这三大角色应该不难想到，一个放资源的，一个拿资源的，一个管理资源的。

3.3、环境搭建

搭建注册中心项目springcloud-eureka-7001：

创建一个maven项目，并引入对应的依赖
配置对应的核心配置文件（端口配置、eureka配置）
编写对应的启动类
访问对应的端口号，查看后台

将8001项目服务注册进Eureka的步骤：

修改之前springcloud-provider-dept-8001项目，添加对应的eureka依赖
在核心配置文件中，添加对应的eureka配置
在启动类中添加Eureka支持的注解@EnableEurekaClient
启动项目，再次测试项目，观察服务是否被注册进注册中心

3.4、添加服务发现Discovery机制

我们在真实的业务开发中，为了知晓开发者到底是谁，就会进行相应的配置，使得我们在开发的时能显示对应的开发者信息。

配置步骤：

在控制器类中添加对应的映射，以及编写对应的开发者信息
在启动类中添加对应的Discovery注解@EnableDiscoveryClient
访问控制器中新添的映射方法，就可能查看对应的开发者信息

3.5、配置计算机集群

前面我们说了Eureka就是一个注册中心，类似于ZooKeeper。当我们的系统访问压力过大时，Eureka会进行对应的调整，以此让我们的项目更加稳定的运行。

我们这里的配置集群，就相当于配置这个注册中心，让这个注册中心在三台服务器上共同合作，避免因为其中一个注册中心宕机，整个项目崩盘。（这里就体现出了Eureka的A属性，高可用，一部分节点发生故障，整个集群整体还能够相应客户端）

配置集群项目springcloud-eureka-7002与springcloud-eureka-7003的步骤：

创建两个maven项目，并引入对应的依赖
在对应的核心配置文件中进行相应的配置（我们应该将三个注册中心服务联合起来，我们我们在监控页面应该添加三个项目的端口）
同时开启三个服务，就可以测试效果了

4、Ribbon

4.1、负载均衡的概念

就是将用户的请求平坦的分配到多个服务上，从而达到系统的HA（高可用）

负载均衡简单分类：

集中式LB：在服务的消费方和提供方之间使用独立的LB设施，如Nginx（反向代理服务器），由该设施负责把访问请求通过某种策略转发至服务的提供方
进程LB：1）将LB逻辑集成到消费方，消费方从服务注册中心获得哪些地址是可用的，然后自己再从这些地址中选择一个合适的服务器。 2）Ribbon属于进程LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址

4.2、Ribbon概念

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

前面我们说了，当我们的系统访问压力过大时，Eureka会进行对应的调整，以此让我们的项目更加稳定的运行。这里的调整就可以是负载均衡，而用到的技术就是Ribbon。

4.3、负载均衡环境搭建

修改我们的springcloud-consumer-dept-80项目步骤：

在依赖中添加Ribbon、Eureka的依赖
添加一个负载均衡的配置类（使用SpringBoot默认的就行）
访问测试（由于此时只有一个后台服务器，我们无法看到具体的效果，但还是建议测试环境是否OK）

为了我们能够看到具体实现负载均衡的效果，我们需要使用三个不同的后台提供者服务，这样我们就能够准确的观测到实现负载均衡算法以后的项目访问变化

操作步骤：

将springcloud-provider-dept-8001项目复制两份
再创建两个不同的数据库（包含数据库名字字段的，这样我们就能更加值观的观测到变化）
修改对应的配置文件
运行项目（三个注册中心集群、三个后台服务器、一个消费者）

4.4、修改、自定义负载均衡算法

在我们的实际测试效果中，我们发现系统默认使用的是轮询算法。

但实际上，它还有很多的其他的算法，甚至是自定义算法

所以现在我们需要修改springcloud-consumer-dept-80项目中的Ribbon配置类

修改默认算法：我们可以将之前使用的默认的模板替换成随机查询算法
自定义算法：我们也可以继承AbstractLoadBalancerRule类，重写里面的choose方法

5、Feign

我们可以将Feign与Ribbon放在一起理解。

Feign 和 Ribbon 是 Spring Cloud的 Netflix 中提供的两个实现软负载均衡的组件，Ribbon 和 Feign 都是用于调用其他服务的，只是方式不同。Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，不需要自己构建 http 请求。Feign就是一个Ribbon的改良版。

可以对比使用Mybatis时，我们是使用注解还是xml文件。

配置步骤：

在springcloud-api项目中添加feign对应的依赖
在该项目中新建一个service层，并编写对应的接口类
新建一个springcloud-consumer-dept-feign项目，用于测试feign（大体内容与springcloud-consumer-dept-80类似）
修改我们的新的消费者项目的控制器层代码（获取到api项目中的接口类）
在启动类中添加对应的注解@EnableFeignClients(basePackages = {“xx”})
访问测试即可

6、Hystrix

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

作用：

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

6.1、服务熔断

在我们访问相应的资源时，如果突然出现资源无法获取的现象，那么一段时间以后，服务就会启动相应的熔断机制。用户能够看到到获取资源失败的现象

配置步骤：

明确服务熔断机制，是使用在提供者一方的
在提供者项目中添加相应的hystrix依赖
在控制器类中，为每一个方法编写一个熔断方法，即如果方法出错，那就调用熔断方法
在启动类中添加对应的注解支持@EnableCircuitBreaker
测试即可

6.2、服务降级

与熔断不同，在我们访问相应的资源时，如果资源突然无法获取，我们就会跳转到之前编写的服务降级方法中。这个过程中用户不会感受到程序的出错。

修改方式类似于Ribbon和Feign，两种不同的方式修改的地方不一样。

同样我们的服务熔断是修改提供者项目的代码，我们的服务降级则是修改api项目的代码

配置步骤：

在api项目中引入对应的依赖
在service层编写一个服务降级类，用来处理对应的SQL语句的降级方法（你可可以理解成mybatis中的SQL接口类，和接口类对应的mapper.xml文件）
在对应的接口类中添加对应的注解@FeignClient(value = “服务名字”,fallbackFactory = 服务降级类.class)
在消费者项目的核心配置文件中，开启服务降级

6.3、服务熔断与服务降级的比较

服务熔断：

当我们访问的服务对应的服务器因为超时或异常时，相应的节点就会进行服务熔断，并且返回相应的熔断信息。当我们的后台检测到异常恢复以后，再重新启用对应节点的服务。
由于某些原因，导致了我们的服务出现了过载现象，为了防止整个系统故障，从而采用了一种保护机制，即服务熔断
一般是某个服务（下游服务）故障引起

服务降级：

当我们需要访问的服务对应的服务器出现压力过大的时候，就会牺牲一部分的资源来保证我们核心功能的运行（比如春运的时候，会停止（不考虑减少）部分人流量少的线路，增加人流量大的线路）
由于某些原因，导致我们的服务出现过载的现象，这个时候我们就停止一部分的服务，让更多的资源去满足我们需要的核心的那几个服务
一般是从整体的负荷进行考虑

6.4、Dashboard流量监控

这个流量监控的界面是在消费者端进行配置

配置springcloud-consumer-hystrix-dashboard项目步骤：

创建一个含有dashboard监控页面的消费者maven项目
带入对应的依赖
修改核心配置文件（修改端口号，用于表示是不同的项目）
在对应的启动类中添加对应的流量监控注解@EnableHystrixDashboard
访问对应的端口，进行测试（仅仅测试流量监控页面是否配置成功）
修改我们的提供者项目中含有熔断的项目
在项目中添加对应的hystrix依赖
在该项目的启动类中，添加对应监控信息，即编写一个servlet，然后以Bean的形式注入容器中
启动7001注册中心项目、8001带熔断的提供者项目、9001带监控的消费者项目三个项目进行测试

启动成功后，访问对应的9001端口，我们就能够观测到我们服务的相应的信息。dashboard界面更加的直观，方便我们服务进行相应的后期操作。

7、Zuul

Zuul包含了对请求的路由和过滤两个主要的功能，Zuul服务最终还是会注册进Eureka

配置springcloud-zuul-9527项目步骤：

新建一个maven项目，并且添加对应的依赖
在对应的核心配置文件中，添加相应的信息（Eureka集群信息、端口号、开发者信息）
新建一个主启动类，并且开启对应的注解@EnableZuulProxy
开启需要的服务进行测试
此时我们会发现注册中心多了一个Zuul服务

我们会发现使用Zuul的路径也可以进行访问，但是我们真实的业务开发中，一般都会使用Zuul过滤掉我们正常的开发业务时的访问路径，继而转向Zuul过滤以后的新的访问路径

具体的配置步骤：

在zuul-9527项目的核心配置文件中配置相应的过滤路径
用我们希望让用户使用的访问路径替换掉我们后台开发时的路径
访问测试

8、SpringCloud Config分布式配置

8.1、基本概念

由于我们的项目采用的是分布式架构，所以项目就会十分的多，与此同时我们的配置文件和配置信息也就会越来越多。

那有没有一种方法能够集中对我们的项目运行环境进行一个集中的管理？

当然有，那就是我们的此处的知识。

由于Spring Cloud Config默认使用Git来存储配置文件（也有其他的方式，比如支持SVN和本地文件），但更推荐使用Git，所以我们的项目也就需要上传到GIt，这样我们不仅可以集中进行环境的配置，还可以多人远程协同开发。

8.2、配置服务端

我一般是使用码云。

配置步骤：

码云上新建一个仓库
将仓库克隆到本地（在项目中新建一个application.yaml核心配置文件，包含多种环境）
新建一个springcloud-config-server-3344项目，并导入相应的依赖
编写对应的核心配置文件（绑定对应的服务、配置对应的gitee地址）
在核心配置类中添加注解@EnableConfigServer
访问3344端口，我们就能够远程查看并切换项目的开发环境了

8.3、配置客户端

配置步骤：

在我们的本地仓库中新建一个config-client.yml配置文件（内含两套不同得端口信息和Eureka注册中心信息）
将我们的文件提交到远程的码云仓库
新建一个springcloud-config-client-3355项目，并添加对应的依赖
编写我峨嵋你的核心配置文件，此处使用的核心配置文件是bootstrap.yml，配置客户端的相关信息，并且配置服务端的uri
在该项目中新增加一个控制器类（controller层下建立）
编写3355项目对应的启动器
访问对应的端口

bootstrap.yml与application.yml都是能够被识别的配置文件，前者是属于系统级别的配置，后者属于用户级别的配置

这个阶段的核心大致就是，使用在Git技术的加持下，我们能够在远程进行环境的切换以及集中配置，个人觉得这个只多配置几次就熟练了！！！

9、思维导图