学习笔记SpringCloud微服务架构

Posted 2023-04-03 BlackBox_

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了学习笔记SpringCloud微服务架构相关的知识，希望对你有一定的参考价值。

文章目录

SpringCloud微服务架构

一、认识微服务

1. 服务架构的演变

1.1 单体架构

将业务的所有功能集中在一个项目中开发，打成一个包部署。

优点：架构简单；部署成本低
缺点：耦合度高

1.2 分布式架构

根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。

优点：降低耦合度；有利于服务升级拓展

1.3 服务治理

分布式架构要考虑的问题：

服务拆分粒度如何？
服务集群地址如何维护？
服务之间如何实现远程调用？
服务健康状态如何感知？

1.4 微服务

微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征：

单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
面向服务：微服务对外暴露业务接口
自治：团队独立、技术独立、数据独立、部署独立
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

1.5 总结

单体架构特点？

简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统

分布式架构特点？

松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝

微服务：一种良好的分布式架构方案

优点：拆分粒度更小、服务更独立、耦合度更低
缺点：架构非常复杂，运维、监控、部署难度提高

2. 微服务技术对比

2.1 微服务架构

微服务这种方案需要技术框架来落地，全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。

2.2 微服务技术对比

2.3 企业需求

SpringCloud + Feign
- 采用SpringCloud技术栈
- 服务接口采用Restful风格
- 服务调用采用Feign方式
SpringCloudAlibaba + Feign
- 采用SpringCloudAlibaba技术栈
- 服务接口采用Restful风格
- 服务调用采用Feign方式
SpringCloudAlibaba + Dubbo
- 使用SpringCloudAlibaba技术栈
- 服务接口采用Dubbo协议标准
- 服务调用采用Dubbo方式
Dubbo原始模式
- 基于Dubbo老旧技术体系
- 服务接口采用Dubbo协议标准
- 服务调用采用Dubbo方式

3. SpringCloud

SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验：

服务注册发现
- Eureka，Nacos，Consul
服务远程调用
- OpenFeign，Dubbo
统一配置管理
- SpringCloudConfig，Nacos
统一网管路由
- SpringCloudGateway，Zuul
服务链路监控
- Zipkin，Sleuth
流控、降级、保护
- Hystix，Sentinel

二、微服务拆分案例

1. 服务拆分

1.1 服务拆分注意事项

不同微服务，不要重复开发相同业务
微服务数据独立，不要访问其他微服务的数据库
微服务可以将自己的业务暴露为接口，供其他微服务使用

2. 服务间调用

2.1 步骤

注册RestTemplate，将RestTemplate注入到Spring容器中

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication 

    public static void main(String[] args) 
        SpringApplication.run(OrderApplication.class, args);
    

    /**
     * 创建RestTemplate并注入spring容器
     */
    @Bean
    public RestTemplate restTemplate() 
        return new RestTemplate();

服务远程调用RestTemplate，发送url

@Service
public class OrderService 

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) 
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2. 利用RestTemplate发送http请求
        // 2.1 url路径
        String url = "http://localhost:8081/user/" + order.getUserId();
        // 2.2 发送http请求，实现远程调用
        User user = restTemplate.getForObject(url, User.class);
        // 3.封装user到order中去
        order.setUser(user);
        // 4.返回
        return order;

2.2 提供者和消费者

服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）
服务A调用服务B，服务B调用服务C，那么服务B是什么角色？
- 要相对来言。A对B说，B是提供者；B对C而言，B是消费者
一个服务可以是同时是服务者和消费者

三、eureka注册中心

1. 远程调用问题

服务消费者该如何获取服务提供者的地址信息？拉取服务
如果有多个服务提供者，消费者该如何选择？负载均衡算法
消费者如何得知服务提供者的健康状态？心跳续约

2. eureka原理

2.1 Eureka作用

消费者该如何获取服务提供者具体信息？
- 服务提供者启动时向eureka注册自己的信息
- eureka保存这些信息
- 消费者根据服务名称向eureka拉取提供者信息
如果有多个服务提供者，消费者该如何选择？
- 服务消费者利用负载均衡算法，从服务列表中挑选一个
消费者如何感知服务提供者健康状态？
- 服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
- eureka会更新记录服务列表信息，心跳不正常会被剔除
- 消费者就可以拉取到最新的信息

2.2 总结

在Eureka架构中，微服务角色有两类：

EurekaServer：服务端，注册中心
- 记录服务信息
- 心跳监控
EurekaClient：客户端
- Provider：服务提供者，例如案例中的 user-service
  - 注册自己的信息到EurekaServer
  - 每隔30秒向EurekaServer发送心跳
- consumer：服务消费者，例如案例中的 order-service
  - 根据服务名称从EurekaServer拉取服务列表
  - 基于服务列表做负载均衡，选中一个微服务后发起远程调用

3. 搭建EurekaServer

3.1 步骤

创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖

<!--eureka服务器-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

编写启动类，添加@EnableEurekaServer注解

@EnableEurekaServer
@SpringBootApplication
public class EurekaApplication 

    public static void main(String[] args) 
        SpringApplication.run(EurekaApplication.class, args);

添加application.yml文件，编写下面的配置

server:
  port: 10086 # 服务端口
spring:
  application:
    name: eureka-server # eureka的服务名称
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka/ # eureka的地址信息

4. 服务注册

4.1 注册user-service步骤

在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖

<!--eureka客服端-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

在application.yml文件，编写下面的配置

spring:
  application:
    name: userservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka/ # eureka的地址信息

4.2 启动多实例时的问题

5. 服务发现

5.1 在order-service完成服务拉取

服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡

修改OrderService的代码，修改访问的url路径，用服务名代替ip、端口：
```
// 2.1 url路径
String url = "http://userservice/user/" + order.getUserId();
```

在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解：

/**
 * 创建RestTemplate并注入spring容器
 */
@Bean
@LoadBalanced // 负载均衡注解
public RestTemplate restTemplate() 
    return new RestTemplate();

6. 总结

搭建EurekaServer
- 引入eureka-server依赖
- 添加@EnableEurekaServer注解
- 在application.yml中配置eureka地址
服务注册
- 引入eureka-client依赖
- 在application.yml中配置eureka地址
服务发现
- 引入eureka-client依赖
- 在application.yml中配置eureka地址
- 给RestTemplate添加@LoadBalanced注解
- 用服务提供者的服务名称远程调用

四、Ribbon负载均衡原理

1. 负载均衡原理

1.1 负载均衡流程图

2. 负载均衡策略

2.1 IRule的实现图

Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则：

2.2 内置负载均衡规则类

内置负载均衡规则类	规则描述
RoundRobinRule	简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule	对以下两种服务器进行忽略：（1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。（2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。
WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
BestAvailableRule	忽略那些短路的服务器，并选择并发数较低的服务器。
RandomRule	随机选择一个可用的服务器。
RetryRule	重试机制的选择逻辑

2.3 调整负载均衡的规则

通过定义IRule实现可以修改负载均衡，有两种方式：

代码方式：在order-service中OrderApplication类中，定义一个新的IRule 【作用于全局的，不管orderservice调用哪一个服务，都是按照新的IRule执行】
```
@Bean
public IRule randomRule() 
    return new RandomRule();
```
配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则**【针对某个微服务而言】**
```
userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则 
```

3. 饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    clients: userservice # 制定对userservice这个服务饥饿加载
    enabled: true # 开启饥饿加载

4. 总结

Ribbon负载均衡规则
1. 规则接口是IRule
2. 默认实现是ZoneAvoidanceRule，根据zone选择服务列表，然后轮询
负载均衡自定义方式
1. 代码方式：配置灵活，但修改时需要重新打包发布
2. 配置方式：直观，方便，无需重新打包发布，但是无法做全局配置
饥饿加载
1. 开启饥饿加载
2. 指定饥饿加载的微服务名称

五、nacos注册中心

1. 认识和安装Nacos

在nacos的bin目录下启动cmd，输入指令 startup.cmd -m standalone开始单击模式

2. Nacos快速入门

2.1 服务注册到Nacos

在cloud-demo01父工程中添加spring-cloud-alibaba的管理依赖

<!--Nacos的管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.5.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

注释掉order-service和user-service中原有的eureka依赖。

添加nacos的客户端依赖：

<!-- nacos客户端依赖 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

修改user-service&order-service中的application.yml文件，注释eureka地址，添加nacos地址：
```
cloud:
  nacos:
    server-addr: localhost:8848
```
启动并测试：

2.2 总结

Nacos服务搭建
1. 下载安装包
2. 解压
3. 在bin目录下运行指令：startup.cmd -m standalone
Nacos服务注册或发现
1. 引入nacos.discovery依赖
2. 配置nacos地址spring.cloud.nacos.server-addr

3. Nacos服务分级存储模型

3.1 Nacos服务分级存储模型

3.2 服务跨集群调用问题

服务调用尽可能选择本地集群的服务，跨集群调用延迟较高

本地集群不可访问时，再去访问其它集群

3.3 服务集群属性

修改application.yml，添加如下属性

cloud:
  nacos:
    server-addr: localhost:8848 # nacos服务地址
    discovery:
      cluster-name: BJ # 配置集群名称，也就是机房位置，例如：BJ代表北京

在Nacos控制台中可以看到集群的变化

总结
1. Nacos服务分级存储模型
  1. 一级是服务，例如userservice
  2. 二级是集群，例如杭州或上海
  3. 三级是实例，例如杭州机房的某台部署了userservice的服务器
2. 如何设置实例的集群属性
  1. 修改application.yml文件，添加spring.cloud.nacos.discovery.cluster-name属性即可

3.4 根据集群负载均衡

修改order-service中的application.yml，设置集群为HZ：

cloud:
  nacos:
    server-addr: localhost:8848 # nacos服务地址
    discovery:
      cluster-name: HZ # 配置集群名称，也就是机房位置

然后在order-service中设置负载均衡的IRule为NacosRule，这个规则优先会寻找与自己同集群的服务：

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则

3.5 Nacos集群访问特点

优先访问同集群
在同集群内采用随机方式访问实例
总结
1. NacosRule负载均衡策略
  1. 优先选择同集群服务实例列表
  2. 本地集群找不到提供者，才去其它集群寻找，并且会报警告
  3. 确定了可用实例列表后，再采用随机负载均衡挑选实例

3.6 实例的权重控制

Nacos控制台可以设置实例的权重值，0~1之间
同集群内的多个实例，权重越高被访问的频率越高
权重设置为0则完全不会被访问

4. Nacos环境隔离——namespace

4.1 介绍

Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离

4.2 设置namespace

创建好后记住命名空间ID，这个用于写入到服务的yaml文件中

![在这里插入图片描述](https://img-blog.csdnimg.cn/da7b4aca17aa45379ab6ac36bea318ec.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAQmxhY2tCb3hf,size_20,color_FFFFFF,t_70,g_se,x_16)

配置yaml文件，添加namespace：

cloud:
  nacos:
    server-addr: localhost:8848 # nacos服务地址
    discovery:
      cluster-name: HZ # 配置集群名称，也就是机房位置
      namespace: cac40efa-e6d8-424e-bcd3-1100a94539c4

重启order-service后，再来查看控制台
【注意】不同namespace下的服务是不可见的

4.3 nacos临时实例和非临时实例

cloud:
  nacos:
    server-addr: localhost:8848 # nacos服务地址
    discovery:
      cluster-name: HZ # 配置集群名称，也就是机房位置
      namespace: cac40efa-e6d8-424e-bcd3-1100a94539c4
      ephemeral: false # 是否是临时实例

4.4 Nacos和Eureka共同点

都支持服务注册和服务拉取
都支持服务提供者心跳方式做健康检测

4.5 Nacos和Eureka区别

Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式**（主动检测对服务器压力大）**
临时实例心跳不正常会被剔除，非临时实例则不会被剔除
Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

六、Nacos配置

七、Feign远程调用

八、Gateway服务网管

SpringCloud-Netflix入门学习笔记

狂神视频–SpringCloud

1、前言

1.1、回顾知识点

在这里插入图片描述

1.2、这个阶段该如何学

在这里插入图片描述

1.3、面试题

在这里插入图片描述

2、微服务概述

2.1、什么是微服务

在这里插入图片描述
微服务原文

汉化

在这里插入图片描述

2.2、微服务与微服务架构

在这里插入图片描述

2.3、微服务优缺点

优点
在这里插入图片描述
缺点

在这里插入图片描述

2.4、微服务技术栈有哪些？

在这里插入图片描述

2.5、为什么选择SpringCloud作为微服务架构

在这里插入图片描述

3、SpringCloud入门概述

3.1、SpringCloud是什么

spring官网
在这里插入图片描述

3.2、SpringCloud和SpringBoot关系

在这里插入图片描述

3.3、Dubbo和SpringCloud技术选型

3.3.1、分布式+服务治理Dubbo

目前成熟的互联网架构：应用服务化拆分+消息中间件
在这里插入图片描述

3.3.2、Dubbo和SpringCloud对比

看看社区活跃度，一直在跳动的就是经常改动，没有跳动的就是很久没用了
Dubbo
SpringCloud

在这里插入图片描述

总结

3.4、SpringCloud能干嘛

在这里插入图片描述

3.5、SpringCloud在哪下

SpringCloud官网

在这里插入图片描述

参考书

在这里插入图片描述

4、SpringCloud测试

4.1、总体介绍

在这里插入图片描述

4.2、SpringCloud版本选择

在这里插入图片描述

4.3、创建父工程

创建一个普通的maven项目作为父工程，可以将src文件夹都删了，只剩下一个pom.xml项目，pom.xml文件内容如下：
在这里插入图片描述

在这里插入图片描述

4.4、创建子工程作为一个微服务

在父工程中创建一个maven项目，导入子工程需要的依赖

在这里插入图片描述

2. 创建数据库，连接数据库

3. 创建表，插入数据

4. 实体类

4.5、创建子工程作为第二个微服务8001（提供服务）

在父工程中创建一个maven项目，导入子工程需要的依赖

在这里插入图片描述

导入依赖

2. 写配置文件application.yml
在mybatis文件夹下创建mybatis-config.xml文件然后再yml文件中写配置设置

mybatis-config.xml文件

写接口dao层
dao层java文件

编写对应dao层的xml文件
service层
serviceImpl层
controller层

注意：这里的queryAll()方法用的PostMapping会报错，要修改成GetMapping：
启动类
测试结果
list

4.6、创建子工程作为第三个微服务80（客户端）

在父工程中创建一个maven项目，导入子工程需要的依赖

在这里插入图片描述

导入依赖
在这里插入图片描述

写配置文件application.yml

在这里插入图片描述
3. 配置类config

在这里插入图片描述
4. controller层

注意：这里的controller层的注解要使用@RestController注解,否则在测试客户端和提供者的时候出现问题

问题

5. 启动类

启动的时候，先第二个微服务启动也就是提供方先启动，然后到客户端启动
6. 测试结果
在这里插入图片描述

5、Eureka服务注册与发现

5.1、什么是Eureka

在这里插入图片描述

5.2、原理讲解

上面的SpringCloud例子中的客户端要想使用提供者的服务，就要带上提供者的URL，现在可以使用Eureka去做这件事
在这里插入图片描述

Eureka的基本架构
在这里插入图片描述

三大角色

5.3、配置集群环境1–服务注册（第四个子工程7001搭建Erueka（搭建Erueka））

在4.3父工程创建一个子工程作为第四个微服务

在父工程中创建一个maven项目，导入子工程需要的依赖

在这里插入图片描述

导入依赖
在这里插入图片描述
2. 写配置文件application.yml

3. 注册启动类

4. 测试结果

5.4、优化上面代码

在4.5小节中的pom.xml文件中添加Eureka依赖
在4.5小节中的yml文件中添加如下代码
在4.5小节中的启动类中修改代码如下
先启动EureKa启动类再启动提供服务的启动类
测试结果
服务加载信息没有，需要去配置
配置服务加载信息
在4.5小节的提供服务那里的pom文件中加入以下依赖：

然后在4.5小节的提供服务那里的yml文件中添加如下信息：
重新启动，测试结果

5.5、自我保护机制

在这里插入图片描述

5.6、服务发现Discovery

在4.5的提供服务中添加Discovery

4.5的controller层添加如下代码
在4.5的启动类添加注解使上面的修改生效
启动4.5的服务
测试结果

6、集群环境配置（注册中心）

实现几个集群直接可以互通
在这里插入图片描述
可以将localhost改成对应的集群名字：

修改了localhost之后要修改5.3小节中集群1中的yml配置文件

6.1、配置集群环境2（第五个子工程7002）

在4.3父工程创建一个子工程作为第五个微服务

在父工程中创建一个maven项目，导入子工程需要的依赖

在这里插入图片描述

导入依赖：跟上面的集合环境的一样，所以复制一下就可以了
在这里插入图片描述
2. 写配置文件application.yml

注册启动类（改一下类名就可以了）

6.2、配置集群环境3（第六个子工程7003）

在4.3父工程创建一个子工程作为第六个微服务

在父工程中创建一个maven项目，导入子工程需要的依赖

在这里插入图片描述

导入依赖：跟上面的集合环境的一样，所以复制一下就可以了
在这里插入图片描述
2. 写配置文件application.yml（跟集群环境1一样，直接复制过来）

3. 注册启动类（改一下类名就可以了）

修改好三个集群环境之后还得在提供服务的那个子工程中将三个集群服务都注册，修改4.5小节中的yml配置文件如下：
在这里插入图片描述
4. 启动集群环境1，然后启动集群2，然后启动集群3，测试结果

5. 启动提供服务子工程
如果第三个服务崩了，因为在第一个和第二中都关联了第一个，那么访问第一个或者第二个都可以进入第三个服务中，因此即使他崩了也不至于导致整个系统全部崩掉。

7、Eureka与Zookeeper对比

7.1、ACID和CAP原则

回顾CAP原则
在这里插入图片描述
ACID是什么？

CAP是什么？

CAP百度百科

在这里插入图片描述

7.2、Zookeeper保证的是CP

在这里插入图片描述

7.3、Eureka保证的是AP

在这里插入图片描述

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

8、负载均衡与Ribbon

8.1、ribbon是什么

在这里插入图片描述

8.2、负载均衡

在这里插入图片描述

8.3、ribbon能干嘛

在这里插入图片描述

LVS百度百科

LVS作用之小例子分析：

小区中有些早上上网，有些中午上网还有的晚上上网，ABC三个小区中，A区一般早上上网，B区一般中午上网，C区一般晚上上网，如果网线是直接接到客户端，每个小区都是100m，早上的时候，BC取使用0m，A区使用超过100M，但是他连接的只有100M，所以最多也只能是100M，所以上网速度就差了。
在这里插入图片描述
提高效率
如果加了一个中间商，接了一条300M的中间商，小区都是直接接中间商，那么这几个小区就加起来使用300M，如果BC没有上网的时候，A区上网速度就最高可以达到300M，速度大大提升了。

8.4、体验Ribbon

修改4.6第三个子工程中的pom文件中添加如下依赖：
修改4.6第三个子工程中的yml配置文件如下：
修改4.6第三个子工程中的启动类加上一个注解：
修改4.6的第三个子工程中的config类：
修改4.6第三个子工程中的controller层代码如下：
测试4.6中的启动是否有问题：可以访问没有问题

Ribbon和Eureka整合以后，客户端可以直接调用，不用关心IP地址和端口号

小结
在这里插入图片描述

8.5、使用Ribbon实现负载均衡

在父工程中创建第七、八个子工程作为微服务，也是第二个提供服务2（8002），第三个提供服务3（8003端口）

在父工程中创建一个maven项目，导入子工程需要的依赖

在这里插入图片描述

在这里插入图片描述
导入依赖：将第一个提供服务者的依赖全部复制过来8002和8003中

在这里插入图片描述

跟第一个提供服务者一样创建数据库db02，db03，连接数据库
分别在db02，db03中创建表，插入数据（可以跟db01数据一样的）
将第一个提供服务者的yml配置文件拷贝到8002,8003这两个提供服务者的resources文件夹下。
将第一个提供服务的mybatis文件夹都拷贝到第二个、第三个服务那里。拷贝过来不需要修改里面的内容
将第一个提供服务的com.kuan.springcloud文件夹下的内容都拷贝到第二个，第三个提供服务那里，也就是controller，dao，service和启动类，只需要修改启动类中的有关第一个提供服务者的都改成第二，第三个对应的。
测试结果，启动集群1，也就是上面的7001端口对应的，要体验三个服务，所以不敢启动太多集群，怕电脑撑不了。然后将提供服务者三个都启动起来（如果启动不了就启动两个吧）因为在每一个提供服务都是往三个集群里注册服务的，没有开集群2,3也就是7002,7003，所以会有报错，但是没影响其他的，其他集群崩了就崩了，7001是可以进去的。如果要不报错那就得启动所有的集群
启动客户端也即是80那个端口号的，访问看结果
第一次访问结果：

第二次访问结果：

第三次访问结果：

负载均衡总结：一个集群环境开了三个服务，那么客户端发过来请求的时候，会使用ribbon默认负载均衡算法–轮询来实现去访问数据

在这里插入图片描述

8.6、自定义负载均衡算法

在客户端4.6小节中的config类中自定义负载均衡的算法
在这里插入图片描述
启动集群1，三个服务还有客户端，访问的时候就可以发现是按照我们定义的算法进行访问数据的。

正常情况下不应该将自定义的算法放到config中，应该在我的组件中去定义。

在客户端中添加一个组件：
在这里插入图片描述
然后再客户端启动类中使用到这个组件：

然后要将config中的自定义算法去掉，在组件类中自定义算法。
在这里插入图片描述

注意：
在这里插入图片描述

不要放在同一级，会被@SpringBootApplication扫描到，也就是spring会自动扫描到bean里，被扫描到了，如果那个组件你不想用，他也会生效的，被扫描到就不会被覆盖了，会被所有的RibbonClient客户端共享，如果想单独模块使用自己的策略，那就放到外面，就不会被共享到了。
在这里插入图片描述

9、Feign负载均衡

9.1、简介

在这里插入图片描述

9.2、Feign使用步骤

在4.3小节父工程中创建的子工程

创建一个跟4.6客户端一样的普通maven项目，作为第二个客户端
将第一个客户端中的pom依赖、yml配置文件和springcloud文件夹下的文件都拷贝到创建好的第二个客户端中，将自定义的负载均衡策略删掉，启动类名字改成第二个客户端对应的。

依赖还要添加一个feign依赖：
在第一个子工程也即是4.4小节中的子工程中的pom文件中也导入依赖feign
在第一个子工程也就是4.4小节的子工程中添加service层，代码如下：
在第二个客户端中的controller层调用上面设置到的service层服务。

对比一下第一个客户端中的controller层代码，可以发现第一个客户端是使用微服务名称进行调用的，而第二个客户端是使用feign访问的。这也是调用微服务访问的两种方式

第二个客户端的启动类添加如下代码：
启动第一个集群，启动注册服务8001,8002，启动feign第二个客户端（第二个客户端和第一个客户端的端口都是80，所以启动第二个客户端的时候记得先关闭第一个客户端，否则端口被占用）

如果出现超时错误，可以继续刷新一下就可以了
在这里插入图片描述

10、Hystrix

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

复杂的分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败！
在这里插入图片描述
在这里要是E2崩了，那么其他调用者就会等待E2的资源，这样一直等待就会占用资源。

10.2、服务雪崩

在这里插入图片描述

10.3、什么是Hystrix

Hystrix官网
在这里插入图片描述

10.4、Hystrix服务熔断

在这里插入图片描述
所有的项目都是在一开始建立的父工程下创建的子工程。
可以直接将第一个服务也即是8001那个服务的项目直接拷贝到父项目中，修改项目添加到父项目的pom文件中即可，要是怕直接拷贝整个项目出现问题，可以按照下面方法一步一步拷贝。

创建一个普通的maven子项目
将第一个服务8001中的pom文件拷贝到这个子项目中的pom文件中
将第一个服务8001中的resources下的资源都拷贝到子项目中的resources文件夹下。
将8001中的com.kuang.springcloud目录下的所有文件拷贝到新建的子项目中
启动类改变个名字
在子项目中pom依赖中再添加一个依赖：
修改yml配置文件：
修改controller层代码：

== 服务崩了会抛出异常，熔断截取这个异常，走另一个请求，只要不是Hystrix异常都可以截取的，再考虑另一种，我B服务崩了，但是我A服务没崩，我A服务去调用B服务，调用失败返回异常。==
修改启动类，添加注解
启动集群1，集群2，然后启动熔断，启动第一个客户端

10.5、Hystrix服务降级

以上是关于学习笔记SpringCloud微服务架构的主要内容，如果未能解决你的问题，请参考以下文章

SpringCloud-Netflix入门学习笔记

springcloud学习笔记day01

学习笔记（1):SpringCloud+Consul+Docker快速搭建微服务架构-场景选型及案例