SpringCloud-GateWay以及Seata分享

最新推荐文章于 2024-06-02 11:50:48 发布

程序小白-陌

最新推荐文章于 2024-06-02 11:50:48 发布

阅读量191

点赞数

文章标签： spring cloud gateway Powered by 金山文档

本文链接：https://blog.csdn.net/qq_48256906/article/details/129276968

版权

进行Wi-Fi操作的一些小方法

进行WiFi操作的一些相关指令

// 列出所有可用wifi netsh wlan show networks mode=bssid

// 添加配置文件 netsh wlan add profile filename=FILE_NAME

// 连接wifi netsh wlan connect name=SSID_NAME

// 导出配置文件 netsh wlan export profile key=clear

// 列出配置文件 netsh wlan show profile

// 删除配置文件 netsh wlan delete profile name=FILE_NAME

// 列出接口 netsh wlan show interface

// 开启接口 netsh interface set interface "Interface Name" enabled

进行获取WiFi的密码

在cmd文件当中首先是可以进行使用netsh wlan export profile key=clear可以进行获取这个电脑链接到的信息

进行输入 netsh wlan show networks mode=bssid可以进行获取到这个电脑可以链接的所有的wifi信息

输入netsh wlan show profiles name="wifi的名字" key=clear

SpringCloud

概念

Spring Cloud 被称为构建分布式微服务系统的“全家桶”，它并不是某一门技术，而是一系列微服务解决方案或框架的有序集合。它将市面上成熟的、经过验证的微服务框架整合起来，并通过 Spring Boot 的思想进行再封装，屏蔽调其中复杂的配置和实现原理，最终为开发人员提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。

SpringCloud包含什么，是什么？

Spring Cloud 中包含了 spring-cloud-config、spring-cloud-bus 等近 20 个子项目，提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。

Spring Cloud 本身并不是一个拿来即可用的框架，它是一套微服务规范。

SpringCloud实现的技术

Spring Cloud Netflix 是 Spring Cloud 的第一代实现，主要由 Eureka、Ribbon、Feign、Hystrix、zuul 等组件组成。

Spring Cloud Alibaba 是 Spring Cloud 的第二代实现，主要由 Nacos、Sentinel、Seata 等组件组成。

SpringCloud 组件——Gateway网关

概念

Spring Cloud Gateway 是 Spring 官方基于 Spring5.0 、 SpringBoot2.0 和 Project Reactor 等技术开发的网关旨在为微服务框架提供一种简单而有效的统一的 API 路由管理方式，统一访问接口。

Spring Cloud Gateway 作为 Spring Cloud 生态体系中的网关，目标是替代 Netflix 的 Zuul ，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全、监控 / 埋点和限流等等。

它是基于 Netty 的响应式开发模式。

Netty是由JBOSS提供的一个java开源框架。Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。

GateWay网关的构成

路由（ route ）：路由是网关最基础的部分，路由信息由一个 ID ，一个目的 URL 、一组断言工厂和一组 Filter 组成。如果断言为真，则说明请求 URL 和配置的路由匹配。

断言（ Predicate ）： Java8 中的断言函数， Spring Cloud Gateway 中的断言函数输入类型是Spring5.0 框架中的 ServerWebExchange 。 Spring Cloud Gateway 中的断言函数允许开发者去定义匹配来自 http Request 中的任何信息，比如请求头和参数等。

过滤器（ Filter ）：一个标准的 Spring WebFilter ， Spring Cloud Gateway 中的 Filter 分为两种类型：Gateway Filter 和 Global Filter 。过滤器 Filter 可以对请求和响应进行处理。

SpringCloud Gateway 与Zuul的区别

Zuul 1.x，是一个基于阻塞 IO 的API

Zuul 1.x 基于Servlet 2.5使用阻塞架构，它不支持任何长连接（如 WebSocket）。Zuul的设计模式和Nginx比较像，每次 IO 操作都是从工作线程中选择一个执行，请求线程被阻塞到工作线程完成，而JVM本身会有第一次加载较慢的情况，使得Zuul的性能相对较差。

Zuul 2.x理念更先进，想基于Netty非阻塞和支持长连接，Zuul 2.x的性能较Zuul 1.x 有较大提升。

在性能方面根据官方提供的基准测试，SpringCloud Gateway 的RPS(每秒请求数)是Zuul的1.6倍。

SpringCloud Gateway 建立在Spring Framework 5、Project Reactor 和 Spring Boot 2之上，使用非阻塞API。

Spring Cloud Gateway 还支持WebSocket，并且与Spring 紧密集成拥有更好的开发体验

SpringCloud的工作流程

客户端向Spring Cloud Gateway发出请求。如果网关处理程序映射确定请求与路由匹配，则将其发送到网关Web处理程序。此处理程序通过特定于请求的过滤器链运行请求。

过滤器被虚线分隔的原因是过滤器可以在发送代理请求之前和之后运行逻辑。执行所有“pre”筛选逻辑。然后发出代理请求。发出代理请求后，运行“post”筛选逻辑

使用的时候直接进行引入依赖即可

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencies>

微服务的配置文件

spring：
     gateway:
      discovery:
        locator:
          enabled: true #配置gateway可以发现nacos中的服务，并自动生成转发路由
      routes: #这个配置的就是我们其他微服务的服务的名字 以及uri和断言...
        - id: service-core
          uri: lb://service-core  #lb 表示可以进行负载均衡
          predicates: #断言
            - Path=/*/core/**
        - id: service-sms
          uri: lb://service-sms
          predicates:
            - Path=/*/sms/**

1，全局过滤器

SpringGate网关提供了31种过滤器，但每一种过滤器的作用都是固定的。如果我们希望拦截请求，做自己的业务逻辑则没办法实现。

1.1：全局过滤器作用

全局过滤器的作用也是处理一切进入网关的请求和微服务响应，与Gateway Filter的作用一样。

区别在于Gateway Filter通过配置定义，处理逻辑是固定的；

而Global Filter的逻辑需要自己写代码实现。

定义方式是实现GlobalFilter接口。

public interface GlobalFilter {
    /**
     *  处理当前请求，有必要的话通过{@link GatewayFilterChain}将请求交给下一个过滤器处理
     *
     * @param exchange 请求上下文，里面可以获取Request、Response等信息
     * @param chain 用来把请求委托给下一个过滤器 
     * @return {@code Mono<Void>} 返回标示当前过滤器业务结束，
     */
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

在filter中编写自定义逻辑，可以实现下列功能：

登录状态判断

权限校验

请求限流等

1.2：自定义全局过滤器

需求：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件：

查看请求路径是否匹配，如果匹配上模拟没有权限进行拦截

如果路径和判断条件不匹配进行放行，即可访问对应的服务

如果同时满足则放行，否则拦截

@Component
public class DemoFilter implements GlobalFilter, Ordered {//@Order(-1)//1、注解方式越小优先级越高 2、实现Ordered接口
@Component
@order（1）
public class AuthorizeFilter implements GlobalFilter,Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        //1、获取请求参数
        ServerHttpRequest request =exchange.getRequest();
        MultiValueMap<String,String> params = request.getQueryParams();
 
 
        //2、获取参数中的authorization参数
        String auth = params.getFirst("authorization");
        //3、判断参数""值是否等于 admin
        if ("admin".equals(auth)) {
            //4、是放行
           return chain.filter(exchange);
        } else {
            //5、设置状态码，拦截
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
 
 
    }
 
    @Override
    public int getOrder() {
        return -1;
    }
}

同时看到也实现了Ordered接口，该接口的作用是在一个项目中肯定不止一个全局过滤器如果存在多个全局过滤器该优先执行哪个吗？我们可以通过实现该接口控制全局过滤器执行优先级！

Gateway 通过 GlobalFilter 编写全局过滤器, 通过Ordered 编写过滤器的优先级（越大，优先级越低）

public interface Ordered {
    int HIGHEST_PRECEDENCE = Integer.MIN_VALUE;
    int LOWEST_PRECEDENCE = Integer.MAX_VALUE;

    int getOrder();
}

也可以不实现Ordered接口，实现注解方式

基本上进行使用的时候，进行使用注解的方式

@Order(-1)：-1可以进行更改，这里的数值越小，代表的权重越大

1.3：过滤器执行顺序

请求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter

请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器：

排序的规则是什么呢？

每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。

GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定，（就是进行设置权重，数值越小代表越先进行运行）

路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。

当过滤器的order值一样时会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。

三者排序详细内容，可以查看Spring源码：

org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator
#getFilters()

方法是先加载defaultFilters，然后再加载某个route的filters，然后合并。

org.springframework.cloud.gateway.handler.FilteringWebHandler
#handle()

方法会加载全局过滤器，与前面的过滤器合并后根据order排序，组织过滤器链

2：跨域问题

2.1：什么是跨域问题

跨域：域名不一致就是跨域，主要包括：

域名不同：

www.taobao.com 和 www.taobao.org 和 www.jd.com 和 miaosha.jd.com

域名相同，端口不同：localhost:8080和localhost8081

浏览器端请求域名不一样，请求域名相同，服务的端口号又不一致就会造成跨域问题

跨域问题：浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题

解决方案：CORS （跨域资源共享）

2.2：示例跨域问题

可以在浏览器控制台看到下面的错误：

从localhost:8090访问localhost:10010，端口不同，显然是跨域的请求。

2.3：解决跨域问题

在gateway服务的application.yml文件中，添加下面的配置：

spring:
  cloud:
    gateway:
      # 。。。
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求 
              - "http://localhost:8090"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期

add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
像网关处理跨域采用的同样是CORS方案：这种方案采用的options请求也会被拦截，该请求会将浏览器端发起一次询问到服务器端，问问是否可以进行请求跨域，将该询问的请求放开即可！

allowedOrigins: # 允许哪些网站的跨域请求可以将具体允许得进行配置放行

allowedMethods: # 允许的跨域ajax的请求方式
像一些get，post，delete，put，等请求，可以进行配置

allowedHeaders: "*" # 允许在请求中携带的头信息允许请求头携带信息

allowCredentials: true # 是否允许携带cookie允许请求中携带cookie信息

maxAge: 360000 # 这次跨域检测的有效期
这个是上面说到，每次ajax请求都会通过CORS方案发起options请求方案进行询问，如果有个小伙子就想一直发ajax那么每次都会发送options显然会造成服务的压力增大，CORS方案性能会有一定损耗，为了减少这种损耗，设置有效期，有效期范围内不再进行请求询问！

'[/**]':拦截一切请求

简单的解决的方法，也就是配置文件的方法

@Configuration
public class CorsConfig {

    @Bean
    public CorsWebFilter corsWebFilter(){
    //解决跨域  跨域的代码多种写法
        CorsConfiguration config=new CorsConfiguration();
        config.addAllowedMethod("*");//允许的请求头
        config.addAllowedOrigin("*");//允许的请求源   就比如说 http://localhost:8080
        config.addAllowedHeader("*");//允许进行请求的方法 GET HEAD POST PUT DELECT ...
        config.setAllowCredentials(true);
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**",config);
        return new CorsWebFilter(source);
    }
}

跨源资源共享（CORS）

跨源资源共享（CORS，或通俗地译为跨域资源共享）是一种基于 HTTP 头的机制，该机制通过允许服务器标示除了它自己以外的其它源（域、协议或端口），使得浏览器允许这些源访问加载自己的资源。跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求，该机制通过浏览器发起一个到服务器托管的跨源资源的“预检”请求。在预检中，浏览器发送的头中标示有 HTTP 方法和真实请求中会用到的头。

SpringCloud Alibaba组件——Seata分布式事务

1.事务

事务就是一个操作单元，在这个操作单元中宿友操作最终要保持一致的行为，要么所有操作都成功，要么所有操作都被撤销。

简单来讲：事务提供了一种 "要么什么都不做，要么什么都做"这种机制.

2.本地事务

A 原子性提一个事务中所有的操作，要么全完成，要么全部不完成

C 一致性在一个事务执行执行之前和执行之后数据库都必须处于一致的状态

I 隔离性在并发环境下，当不同的事务同时操作相同的数据时，事务之间互不影响

D 持久性指的是只要事务成功结束，它对数据库所做的更新就永久的保存下来

本地事务"其实可以认为"是数据提供的事务机制

3.分布式事务

分布式事务的基本理论

我们了解到了分布式事务的基础概念。与本地事务不同的是，分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同机器上，相互之间通过网络交互。

不能因为有一点网络问题就导致整个系统无法提供服务，网络因素成为了分布式事务的考量标准之一。因此，分布式事务需要更进一步的理论支持。

自己理解的：一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，

属于不同的应用分布式事务需要保证这些小的操作要么全部成功，要么全部失败!

什么是CAP？

CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍性。

一致性

1、由于存在数据同步的过程，写操作的响应会有一定的延迟。o'k

2、为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。

3、如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据。

可用性

1、所有请求都有响应，且不会出现响应超时或响应错误。

分区容错性

1、尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现松耦合。

2、添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。

4.分布式事务应用的场景

单体系统访问多个数据库

多个微服务访问同一个数据库

多个微服务访问多个数据库

5.分布式事务解决方案

AP Application 应用系统 (微服务)

TM (Transaction Manager) - 事务管理器(全局事务管理器)

RM (Resource Manager) - 资源管理器(数据库)

整个事务分成两个阶段

阶段一:表决阶段所有参与者都将本事务执行预提交，并将能否成功的信息反馈给协调者

阶段二 :执行阶段，协调者根据所有的参与者反馈啊，通知所有参与者，步调一致的徐静提交或者回滚操作。

这种操作

优点

提高了数据一致性的概率，实现成本较低

缺点

单点问题事务协调者宕机了

同步阻塞延迟了提交的时间，加长了资源阻塞的时间

数据不一致提交第二阶段，依然存在 commit结果未知的情况，有可能导致数据不一致

6.最大努力通知

1.有一定的消息重复通知机制。

因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。

2.消息校对机制

如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。

7.TCC事务 Try Confirm Cancel 它属于补偿型的分布式事务

Try 尝试待执行的业务

这个过程没并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需要的全部资源

Confirm 确认执行业务

确认下执行业务操作，不做任何的业务检查，只是使用Try阶段预留的业务资源 --》只要Try成功，Confirm一定成功

一旦Confirm阶段真的出错了，需要引入重试机制或者人工处理

Cancel 取消待执行的业务

8. Seata

网址：https://seata.io/zh-cn/docs/overview/what-is-seata.html

8.1简介

Seata是由阿里中间件团队发起的开源项目 Fescar，后更名为Seata，它是一个是开源的分布式事务框架

传统2PC的问题在Seata中得到了解决，它通过对本地关系数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。

主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务问题，它目前提供AT模式(即2PC)及TCC模式的分布式事务解决方案。

Seata 主要有三个重要的组件组成：

TC (Transaction Coordinator) - 事务协调者

维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM (Transaction Manager) - 事务管理器

定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM (Resource Manager) - 资源管理器

管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

8.2Seata的执行流程

Transaction Coordinator (TC)：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。

Transaction Manager（TM）：事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向TC发起全局提交或全局回滚的指令。

Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分支（本地）事务的提交和回滚。

1.A服务的TM向TC申请开启一个全局事务,TC就会创建一个全局事务并返回一个唯一的XID

2.A服务的RM向TC注册分支事务，并将其纳入XID对应的全局事务的管辖

3.A服务执行分支事务，向数据库做操作

4.A服务开始远程调用B服务,此时XID会在微服务的调用链上进行传播

5.B服务的RM向TC注册分支事务，并将其纳入XID对应的全局事务的管辖

6.B服务执行分支事务，向数据库做操作

7.依上进行执行C的微服务

8.全局事务调链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚

9.TC协调其管辖之下的所有分支事务决定是否回滚

所谓的XID就是一次事务的唯一id

下面Seata的部署文件

可以通过下面的链接直接进行下载

https://github.com/seata/seata/archive/refs/tags/v1.4.2.zip

程序小白-陌

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
SpringCloud-GateWay以及Seata分享

Spring Cloud Gateway 作为 Spring Cloud 生态体系中的网关，目标是替代 Netflix 的 Zuul ，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全、监控 / 埋点和限流等等。Transaction Coordinator (TC)：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。执行所有“pre”筛选逻辑。
复制链接

扫一扫