SpringCloudAlibaba学习笔记(自我学习笔记)

微服务远程调用

基于RestTemplate发起http请求实现远程调用
注册RestTemplate,在启动类里注入RestTemplate对象
利用RestTemplate里面的一个方法，getForObject(url,response)

EureKa注册中心

Eureka用于**服务注册,目前官网已经停止更新**

EurekaServer

记录服务信息
心跳监控

EurekaClient

服务提供者
服务消费者

消费者如何获取服务提供者的具体信息？

服务提供者启动时向eureka注册自己的信息
eureka保存这些信息
消费者根据服务名称向eureka拉取提供者信息

如果有多个服务提供者，消费者该如何抉择？

服务消费者利用负载均衡算法，从服务列表中挑一个

消费者如何感知服务提供者健康状态？

服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
eureka会更新记录服务列表信息，心跳不正常会被剔除
消费者就可以拉取到最新的信息

搭建EureKaServer

引入eureka-server依赖
添加@EnableEurekaServer注解
在application.yml中配置eureka地址

服务注册

引入eureka-client依赖
在application.yml中配置eureka地址

Ribbon负载均衡

IRule
指定负载均衡规则

或者在aplication.yml中配置规则

饥饿加载

Ribbon采用懒加载，第一次访问时请求时间会很长，改成饥饿加载，则会在项目启动时创建LoadBalanceClient,降低第一次访问的耗时

什么是ribbon

Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的
封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是
一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个Spring Cloud构建
的微服务和基础设施中。因为微服务间的调用，API网关的请求转发等内容，实际上都是通过Ribbon来实现的，包括后续我们将
要介绍的Feign，它也是基于Ribbon实现的工具。所以，对Spring Cloud Ribbon的理解和使用，对于我们使用Spring Cl
oud来构建微服务非常重要。

ribbon的作用

Ribbon其实就是一个软负载均衡的客户端组件，他可以和其他所需请求的客户端结合使用，可以结合eureka，zookeeper，
consul的做种服务注册组件。

ribbon的核心组件IRule

IRule:根据特定算法从服务列表中选取一个要访问的服务。
com.netflix.loadbalancer.RoundRobinRule 轮询
com.netflix.loadbalancer.RandomRule 随机
com.netflix.loadbalancer.RetryRule 先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会
进行重试
WeightedResponseTimeRule 对RoundRobinRule的扩展，响应速度越快的实例选择权重越大，越容易被选择
BestAvailableRule 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务
AvailabilityFilteringRule 先过滤掉故障实例，再选择并发较小的实例
ZoneAvoidanceRule 默认规则，复合判断server所在区域的性能和server的可用性选择服务器

OpenFeign

Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单。它的
使用方法是定义一个服务接口然后在上面添加注解。Feign也支持可拔插式的编码器和解码器。Sp
ring Cloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters。
Feign可以与Eureka和Ribbon组合使用以支持负载均衡
是一个声明式的web客户端,只需要创建一个接口,添加注解即可完成微服务之间的调用

Feign能干什么?

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

Feign集成了Ribbon

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

Hystrix

服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服多C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇
出”如果扇出的链路上

某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越岁的系统资源，进而引起系统崩溃，所谓的“雪崩
效应”。

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

通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异
常等，

Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

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

hystrix中的重要概念

服务降级

比如当某个服务繁忙,不能让客户端的请求一直等待,应该立刻返回给客户端一个备选方案

服务熔断

当某个服务出现问题,卡死了,不能让用户一直等待,需要关闭所有对此服务的访问然后调用服务降级**

服务限流

限流,比如秒杀场景,不能访问用户瞬间都访问服务器,限制一次只可以有多少请求

Gateway

Gateway是在Spring生态系统之上构建的API网关服务，基于Spring 5，Spring Boot 2和 Project Reactor等技术。
Gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器功能，例如:熔断、限流、重试等

SpringCloud Gateway是Spring Cloud的一个全新项目，基于Spring 5.0+Spring Boot 2.0和Project Reactor等技术开发的网关，它旨在为微服务架构
供—种简单有效的统一的API路由管理方式。
SpringCloud Gateway作为 Spring Cloud生态系统中的网关，目标是替代 Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.o以I上最新高
性能版本进行集成，仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能，SprincCloud Gatewav是基于WebFlux框架实现的，
而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway的目标提供统一的路由方式且基于Filter链的方式提供了网关基本的功能，例如:安全，监控/指标，和限流.

GateWay的特性

Spring Cloud Gateway具有如下特性:
基于Spring Framework 5, Project Reactor和Spring Boot 2.0进行构建;动态路由:能够匹配任何请求属性;
可以对路由指定Predicate(断言）和Filter (过滤器);集成Hystrix的断路器功能;
集成Spring Cloud服务发现功能;
易于编写的 Predicate(断言）和Filter (过滤器);请求限流功能;l
支持路径重写。

GateWay与zuul的区别

在SpringCloud Finchley 正式版之前，Spring Cloud推荐的网关是Netflix提供的Zuul:
1、Zuul 1.x，是一个基于阻塞I/O的API Gateway
2、Zuul 1.x基于Servlet 2.5f使用阻塞架构它不支持任何长连接(如WebSocket)Zuul的设计模式和Nginx较像，每次VО操作都是从工作线程中选择一个
执行，请求线程被明塞到工作线程完成，但是差别是Nginx用C++实现，Zuul用Java 实现，而VM本身会有第—次加载较慢的情况，使得Zuul的性能相
对较差。
3、Zuul 2.x理念更先进，想基于Netty非阻塞和支持长连接，但SpringCloud目前还没有整合。Zul 2.x的性能较Zul 1.x有较大提升。在性能方面，根据
官方提供的基准测试,Spring Cloud Gateway的RPS(每秒请求数）是Zuul的1.6倍。
4、Spring Cloud Gateway建立在Spring Framework 5、Project Reactor和Spring Boot2之上，使用非阻塞API。
5、Spring Cloud Gateway还支持WebSocket，并且与Spring紧密集成拥有更好的开发体验

GateWay的一些概念:

路由

路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由就是根据某些规则,将请求发送到指
定服务上

断言

参考的是Java8的ava.util.function.Predicate
开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数)，如果请求与断言相匹配则进行路由
就是判断,如果符合条件就是xxxx,反之yyyy

过滤

指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。

GateWay的工作原理:

Nacos

Nacos与其他服务注册的对比

Nacos它既可以支持CP,也可以支持AP,可以切换

何时选择使用何种模式?

既然支持cp和ap,那么如何选择?
一般来说,
如果不需要存储服务级别的信息且服务实例是通过nacos-client注册，并能够保持心跳上报，那么就可以选择AP模式。当前主
流的服务
如 Spring coud和Dubbo服务，都适用于AP模式，AP模式为了服务的可能性而减弱了一致性，因此AP模式下只支持注册临时
实例。
如果需要在服务级别编辑或者存储配置信息，那么CP是必须，K8S服务和DNS服务则适用于CP模式。
CP模式下则支持注册持久化实例，此时则是以Raft 协议为集群运行模式。该模式下注册实例之前必须先注册服务，如果服务不
存在,则会返回错误。
curl -X PUT "SNACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP’
使用Nacos作为配置中心:

Nacos同springcloud-config一样，在项目初始化时，要保证先从配置中心进行配置拉取,拉取配置之后，才能保证项目的
正常启动。
springboot中配置文件的加载是存在优先级顺序的,bootstrap优先级高于application
在Nacos添加配置信息:

Nacos的配置规则:

配置规则,就是我们在客户端如何指定读取配置文件,配置文件的命名的规则

默认的命名方式

prefix:
默认就是当前服务的服务名称
也可以通过spring.cloud.necos.config.prefix配置
spring.profile.active:
就是我们在application.yml中指定的,当前是开发环境还是测试等环境
这个可以不配置,如果不配置,那么前面的-也会没有
file-extension
就是当前文件的格式(后缀),目前只支持yml和properties

在web UI上创建配置文件

注意,DataId就是配置文件名字:

名字一定要按照上面的规则命名,否则客户端会读取不到配置文件

注意默认就开启了自动刷新:

客户端是可以立即更新的
因为Nacos支持Bus总线,会自动发送命令更新所有客户端

Nacos配置中心之分类配置

NameSpace默认有一个:public名称空间

这三个类似java的: 包名 + 类名 + 方法名


配置不同DataId:

通过配置文件,实现多环境的读取

此时,改为dev,就会读取dev的配置文件,改为test,就会读取test的配置文件

配置不同的GroupID:

直接在新建配置文件时指定组


在客户端配置,使用指定组的配置文件
这两个配置文件都要修改
重启服务,即可

配置不同的namespace:

客户端配置使用不同名称空间
要通过命名空间id指定

Nacos集群和持久化配置

Nacos默认有自带嵌入式数据库,derby,但是如果做集群模式的话,就不能使用自己的数据库

不然每个节点一个数据库,那么数据就不统一了,需要使用外部的mysql

单机版,切换mysql数据库

​
将nacos切换到使用我们自己的mysql数据库:
1,nacos默认自带了一个sql文件,在nacos安装目录下

将它放到我们的mysql执行
2,修改Nacos安装目录下的安排application.properties,添加:

3,此时可以重启nacos,那么就会改为使用我们自己的mysql

Linux上配置Nacos集群+Mysql数据库

官方架构图:
需要一个Nginx作为VIP

1,下载安装Nacos的Linux版安装包

2,进入安装目录,现在执行自带的sql文件

进入mysql,执行sql文件

3.修改配置文件,切换为我们的mysql

就是上面windos版要修改的几个属性

4,修改cluster.conf,指定哪几个节点是Nacos集群

这里使用3333,4444,5555作为三个Nacos节点监听的端口
5,我们这里就不配置在不同节点上了,就放在一个节点上

既然要在一个节点上启动不同Nacos实例,就要修改startup.sh,使其根据不同端口启动不同Nacos实例

可以看到,这个脚本就是通过jvm启动nacos

所以我们最后修改的就是,nohup java -Dserver.port=3344

6,配置Nginx:

7,启动Nacos:
./startup.sh -p 3333

./startup.sh -p 4444

./startup.sh -p 5555

7,启动nginx

8,测试:

访问192.168.159.121:1111

如果可以进入nacos的web界面,就证明安装成功了

9,将微服务注册到Nacos集群:

10,进入Nacos的web界面

可以看到,已经注册成功

Seata

是一个分布式事务的解决方案,
分布式事务中的一些概念,也是seata中的概念

setat原理

seata提供了四个模式

第一阶段:

二阶段之提交

:

二阶段之回滚:

断点

可以看到,他们的xid全局事务id是一样的,证明他们在一个事务下
before 和 after的原理就是
在更新数据之前,先解析这个更新sql,然后查询要更新的数据,进行保存