Spring Cloud Gateway 常见过滤器的基本使用

news2024/10/4 19:59:55

目录

1. 过滤器的作用

2. Spring Cloud Gateway 过滤器的类型

2.1 内置过滤器

2.1.1 AddResponseHeader

2.1.2 AddRequestHeader

2.1.3 PrefixPath

2.1.4 RequestRateLimiter

2.1.5 Retry

2.2 自定义过滤器

1. 过滤器的作用

过滤器通常用于拦截、处理或修改数据流和事件流，在数据流中执行特定的操作或转换。

过滤器主要在以下几个方面发挥作用：

  1. 功能扩展和定制：过滤器允许您自定义和扩展网关的功能，以满足特定需求，如请求和响应的修改、路由规则的动态配置等。

  2. 数据校验和过滤：通过过滤器，您可以检查、验证和过滤传入或传出的数据，确保请求和响应的合法性和一致性。

  3. 安全保护：过滤器可以用于实施安全策略，如认证、授权、防止攻击等，以增强网关的安全性。

  4. 性能优化：通过过滤器，您可以对请求和响应进行性能优化，如缓存、压缩、请求路由的智能选择，以提高网关的性能。

  5. 统一处理：过滤器允许您在网关层面执行共享的处理逻辑，如日志记录、监控、审计等，以确保整个微服务体系的一致性和可维护性。

  6. 逻辑复用：通过过滤器，您可以将一些常见的操作抽象出来，以实现逻辑的复用，减少重复代码和维护工作。

2. Spring Cloud Gateway 过滤器的类型

Spring Cloud Gateway 过滤器可以分为两大类：

1. 内置过滤器

  • 局部的内置过滤器
  • 全局的内置过滤器

2. 自定义过滤器

2.1 内置过滤器

内置过滤器常见的有以下几种：

  1. AddResponseHeader
  2. AddRequestHeader
  3. AddRequestParameter（和 AddRequestHeader 相似）
  4. PrefixPath
  5. RequestRateLimiter
  6. Retry

Spring Cloud Gateway 过滤器常见有这么几种，实际上它有30多种，可以借助官方文档加以了解：Spring Cloud Gateway

过滤器又分为前置过滤器和后置过滤器：

在目标方法返回之前执行的过滤器就叫做前置过滤器（AddRequestXXX），在目标方法返回之后执行的过滤器就叫做后置过滤器。（AddResponseXXX）

前置工作：准备 user-service 和 order-service 两个模块，并且配置好 naocs 连接信息。

① user-service：创建一个 controller

@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired  // 获取动态端口
    private ServletWebServerApplicationContext context;

    @RequestMapping("/getname")
    public String getName() {
        return context.getWebServer().getPort() +
                "--UserService：name=java-"+
                new Random().nextInt(100);
    }
}
server.port=0
spring.application.name=user-service-gateway
spring.cloud.nacos.discovery.server-addr=localhost:8848
spring.cloud.nacos.discovery.username=nacos
spring.cloud.nacos.discovery.password=nacos

② order-service：创建一个 controller

@RestController
@RequestMapping("/order")
public class OrderController {

    @RequestMapping("/getcount")
    public int getCount() {
        return new Random().nextInt(1000);
    }
}

server.port=0
spring.application.name=order-service-gateway
spring.cloud.nacos.discovery.server-addr=localhost:8848
spring.cloud.nacos.discovery.username=nacos
spring.cloud.nacos.discovery.password=nacos

2.1.1 AddResponseHeader

spring:
  cloud:
    nacos: # 配置注册中心
      discovery:
        server-addr: localhost:8848
        username: nacos
        password: nacos
    gateway: # 配置网关
      routes:
        - id: userservice
          uri: lb://user-service-gateway   # loadbalancer
          predicates:
            - Path=/user/**
          filters:
            - AddResponseHeader=My-Resp-Header, www.baidu
server:
  port: 10086

在配置过滤器之前，我在网关服务中引入 Nacos 和 LoadBalancer 之后，使用10086 端口去访问userservice服务时，查看对应的响应头：

配置了 AddResponseHeader 过滤器之后，再去访问userservice服务时，查看对应的响应头：

上述的设置，设置的是局部过滤器，如果此时在网关服务中再新增一组 id （如下），此时再去访问order-service服务时，响应头中就不会包含 My-Resp-Header 这个标头了。

spring:
  cloud:
    gateway: # 配置网关
      routes:
        - id: userservice  # 用户服务
          uri: lb://user-service-gateway   # loadbalancer
          predicates:
            - Path=/user/**
          filters:
            - AddResponseHeader=My-Resp-Header, www.baidu
        - id: orderservice  # 订单服务
          uri: lb://order-service-gateway
          predicates:
            - Path=/order/**

此时还想访问 orderservice 服务时，也在响应头中看到对应的标头，要么就把 filters 照搬到下面，但是这样做，代码就不具备维护性了，发生修改的时候，这将会是一个体力活；要么就使用全局过滤器。

全局过滤器的配置

spring:
  cloud:
    gateway: # 配置网关
      routes:
        - id: userservice  # 用户服务
          uri: lb://user-service-gateway   # loadbalancer
          predicates:
            - Path=/user/**
          filters:
            - AddResponseHeader=My-Resp-Header, www.baidu
        - id: orderservice  # 订单服务
          uri: lb://order-service-gateway
          predicates:
            - Path=/order/**
      default-filters:  # 全局过滤器
        - AddResponseHeader=MyApplication-Resp-Header, gateway.org

2.1.2 AddRequestHeader

spring:
  cloud:
    nacos: # 配置注册中心
      discovery:
        server-addr: localhost:8848
        username: nacos
        password: nacos
    gateway: # 配置网关
      routes:
        - id: userservice  # 用户服务
          uri: lb://user-service-gateway   # loadbalancer
          predicates:
            - Path=/user/**
          filters:
            - AddResponseHeader=My-Resp-Header, www.baidu
      default-filters:
        - AddRequestHeader=My-Req-Marking, www.baidu

如何拿到前置过滤器，可以在 userservice 服务里边写一个打印请求头的 controller：

@RequestMapping("/print-header")
public void printHeader(HttpServletRequest request) {
    Enumeration<String> headers = request.getHeaderNames();
    while(headers.hasMoreElements()) {
        String key = headers.nextElement();
        String value = request.getHeader(key);
        System.out.println(key +": " + value);
    }
}

此时运行userservice 和 gateway，去反问 print-header 接口, 查看 userservice 的控制台：

2.1.3 PrefixPath

spring:
  cloud:
    nacos: # 配置注册中心
      discovery:
        server-addr: localhost:8848
        username: nacos
        password: nacos
    gateway: # 配置网关
      routes:
      - id: userservice
        uri: lb://user-service-gateway
        predicates:
        - Path=/user/**
        filters:
        - PrefixPath=/v2

假设此时 userservice 中的 UserController 升级为了 v2 版本，但是我的接口 /user/** 已经 对外公布了，此时还想让 localhost:10086/user/getname 访问到 v2 版本的 controller，肯定是不允许再修改后端的接口了，也不能让前端跟着改，使用 PrefixPath 就可以很好的调整。

第一版代码：

@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired  // 获取动态端口
    private ServletWebServerApplicationContext context;

    @RequestMapping("/getname")
    public String getName() {
        return context.getWebServer().getPort() +
                "--UserService：name=java-"+
                new Random().nextInt(100);
    }
}

第二版代码： 

@RequestMapping("/v2/user")
@RestController
public class UserControllerV2 {
    @Autowired  // 获取动态端口
    private ServletWebServerApplicationContext context;

    @RequestMapping("/getname")
    public String getName() {
        return context.getWebServer().getPort() +
                "--V2：UserService：name=java-"+
                new Random().nextInt(10);
    }
}

当我们配置了 PrefixPath 之后，再使用原来的 localhost:10086/user/getname 去访问服务的时候，就可以正常的访问到 v2 版本的 controller 了，无需再去修改前后端接口。

2.1.4 RequestRateLimiter

这是 Spring Cloud Gateway 内置的网关限流过滤器，它使用了令牌桶的限流算法。

令牌桶限流算法：令牌桶限流算法通过固定速率生成令牌放入桶中，桶满则丢弃新令牌。请求到来时消耗令牌进行处理，桶内无令牌则等待或丢弃请求，从而平滑流量，防止网络拥堵。

Spring Cloud  Gateway 当前版本支持和 Redis 一起实现限流功能，Spring Cloud Gateway 选择 Redis 作为限流方案的一个重要支撑是因为 Redis 的一些特性可以很好地满足限流中对于性能、一致性和分布式处理的要求。

  1. 分布式环境：在微服务架构中，服务实例往往是分布式部署的，Redis 由于其天然的分布式特性，能够确保在不同的服务实例之间共享限流的状态，实现全局限流。

  2. 性能：Redis 是一个高性能的内存数据库，它的读写速度非常快，可以达到每秒数十万次的读写请求。这种性能上的优势使得 Redis 成为实现限流中维护和检查速率限制状态的理想选择。

  3. 原子操作：Redis 支持多种原子操作，这对于计数器来说非常重要。例如，使用 INCR 和 DECR 命令递增或递减计数器，可以保证即使在高并发的情况下，计数器的值也是准确的。

  4. 过期策略：Redis 允许为数据设置生存时间（TTL），这对于限流算法中的时间窗口非常有用。例如，在固定时间窗口算法中，可以设置令牌或计数器在特定时间后自动过期。

它的实现步骤总共分为三步：

  1. 添加 Redis 框架依赖
  2. 创建限流规则
  3. 配置限流过滤器

a.添加 Redis 框架依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

注意事项：Redis版本太低，此功能设置会无效，建议使用 Redis 版本 5.x+。

b.创建限流规则

限流规则，既可以针对某一个 IP 做限流，也可以针对 URL 进行限流（所有的 IP 访问 URL 都会限流）

创建一个类，根据IP进行限流：

@Component
public class IpAddressKeyResolver implements KeyResolver {
    @Override
    public Mono<String> resolve(ServerWebExchange exchange) {
        return Mono.just(exchange.getRequest().
                getRemoteAddress().getHostName());
    }
}

创建一个类，根据URL进行限流：

@Component
public class UrlKeyResolver implements KeyResolver {
    @Override
    public Mono<String> resolve(ServerWebExchange exchange) {
        // 获取请求的URI路径作为限流的key
        String path = exchange.getRequest().getURI().getPath();
        return Mono.just(path);
    }
}

c.设置限流过滤器

spring:
  cloud:
    nacos: # 配置注册中心
      discovery:
        server-addr: localhost:8848
        username: nacos
        password: nacos
    gateway: # 配置网关
      routes:
      - id: userservice
        uri: lb://user-service-gateway
        predicates:
        - Path=/user/**
        filters:
        - name: RequestRateLimiter
          args:
            redis-rate-limiter.replenishRate: 1  # 每秒请求数
            redis-rate-limiter.burstCapacity: 1  # 最大请求数
            key-resolver: "#{@ipAddressKeyResolver}"  # spEL表达式

  data:
    redis:
      host: 127.0.0.1
      port: 16379
      database: 0

注意，内置的限流过滤器 name 必须等于"RequestRateLimiter" ，其他参数的含义如下：

1. redis-rate-limiter.replenishRate：令牌填充速度（每秒允许请求数）

2. redis-rate-limiter.burstCapacity：令牌桶容量（最大令牌数）

3. key-resolver：根据哪个 key 进行限流，它的值是 spEL 表达式。

这三步完成之后，就表示每个 IP  每秒钟只能访问一次，如果刷新页面刷新的太快，就会出现如下页面：

2.1.5 Retry

在 OpenFeign 里面呢，也有个 Retry 超时重试，而且它还可以自定义重试规则，为什么 Gateway 还要有一个 Retry 呢 ？

OpenFeign里面的重试机制是服务调用层面的，它是用来帮助服务消费者处理调用远程服务时的问题的。而Spring Cloud Gateway的重试机制是在网关层面上，主要用于对所有通过网关的服务调用提供统一的重试策略，以处理上游服务可能出现的不稳定性（网络抖动）。两者虽都提供重试功能，但服务的层次不同，因此它们在微服务架构中各有其作用。

请求重试过滤器配置案例：

spring:
  cloud:
    nacos: # 配置注册中心
      discovery:
        server-addr: localhost:8848
        username: nacos
        password: nacos
    gateway: # 配置网关
      routes:
      - id: userservice
        uri: lb://user-service-gateway
        predicates:
        - Path=/user/**
        filters:
        - name: Retry  # 重试过滤器
          args:
            retries: 3
            statuses: GATEWAY_TIMEOUT
            methods: GET
            series: SERVER_ERROR
            backoff:
              firstBackoff: 10ms  # 第一次重试间隔
              maxBackoff: 50ms  # 最大重试间隔
              factor: 2  # firstBack * (factor ^ n)   # 重试系数
              basedOnPreviousValue: false  # 基于上次重试时间加上重试系数来计算

注意，重试过滤器的 name 必须等于 "Retry" ，因为 "Retry" 就是内置重试过滤器的名字，改为其他框架就无法识别了；其他参数的含义如下：

1. retries：尝试的重试次数。

2. statuses：重试的HTTP状态码。取值参考：HttpStatus (Spring Framework 6.1.2 API)

3. methods：重试的HTTP方法。取值：GET（默认值），HEAD，POST，PUT，PATCH，DELETE，OPTIONS，TRACE。

4. series：要重试的一系列状态码。默认值是 SERVER_ERROR，值是 5，表示 5xx，（ 5开头的状态码）。共有 5 个取值：

  • 1xx：INFORMATIONAL
  • 2xx：SUCCESSFUL
  • 3xx：REDIRECTION
  • 4xx：CLIENT_ERROR
  • 5xx：SERVER_ERROR

5. backoff：配置的重试策略。

  • firstBackoff：第一次的重试间隔
  • maxBackoff：最大重试间隔
  • factor：重试系数，firstBackoff *（factor ^ n），n= 1,2,3,4...
  • basedOnPreviousValue：默认关闭，如果设为 true，就表示基于上次的重试时间加上重试系数来计算，例如 firstBackoff 为 10，假设上一次重试是 10 * 2 ^ 1，那么下一次就不是 10 * 2 ^ 2，而是 20 * 2 ^ 2。

【案例演示】

在 userservice 服务中，写一个接口去触发 GATEWAY_TIMEOUT：

@RequestMapping("/504")
public void return504(HttpServletResponse response) {
    System.out.println("------- Do return504 method. ------");
    response.setStatus(504);
}

启动 userservice 模块和 gateway 模块，此时 userservice 服务自动注入到 nacos 中，使用原生服务接口访问：

原生服务接口：192.168.10.83:63129/user/504，触发 504 

此时查看控制台 ：打印了一次

再使用 Gateway 网关去访问 userservice 服务， localhost:10086/user/504，触发 504

此时查看控制台：打印了 4 次（清除上面的打印后）

可见重试过滤器确实生效了。

【注意事项】

1. 此处的超时重试和 OpenFeign 里面的超时重试不太一样，这里设置重试 3 次，就是真的重试 3 次，加上触发重试的 1 次，总共就是打印 4 次，而 OpenFeign 里面的超时重试，重试次数的下标是从 1 开始的，所以在 OpenFeign 里面，这样设置，只会重试 2 次，打印 3 次。

2. 上面重试过滤器的配置，像 method、series 这种参数，它都是有默认值的，比如说 series 的默认值是 5 开头的状态码，那么即使我们不设置这个参数，当我们触发 5 开头的异常时，并且没有与其他设置的参数相悖的时候，也会触发超时重试功能。

2.2 自定义过滤器

代码案例：使用 Spring Cloud Gateway 提供的全局过滤器实现统一认证授权。

@Component
public class AuthFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange,   // 执行的事件
                             GatewayFilterChain chain)     // 过滤器链
    {

        // 未登录判断逻辑，当参数中 username=admin && password=admin 继续执行，
        // 否则退出执行

        // 得到 Request 对象 (reactive web)
        ServerHttpRequest request = exchange.getRequest();
        // 得到 Response 对象 (reactive web)
        ServerHttpResponse response = exchange.getResponse();
        String username = request.getQueryParams().getFirst("username");
        String password = request.getQueryParams().getFirst("password");
        if (username != null && username.equals("admin")
                && password != null && password.equals("admin")) {
            // 已经登录，执行下一步
            return chain.filter(exchange);
        } else {
            // 设置无权限 401
            response.setStatusCode(HttpStatus.UNAUTHORIZED);
            // 执行完成，不用继续执行后续流程了
            return response.setComplete();
        }
    }
}

在访问相对应服务的时候，可以先不加用户名密码试一次，它会触发 401，再加上 username=admin&password=admin，就可以正常访问到相应服务了。

当有多个过滤器时，我们还可以给过滤器指定它的执行顺序：

假如说，此时有两个过滤器，一个用来验证登录，一个用来验证是否有权限。那么这个时候，需要先验证登录，才会再去验证是否有权限。如何实现？

  1. 实现 Ordered 接口
  2. 重写 getOrder 方法
@Override
public int getOrder() {
    // 此值越小越先执行
    return 1;
}

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1339596.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Springboot+vue的医疗报销系统（有报告），Javaee项目，springboot vue前后端分离项目

Springboot+vue的医疗报销系统（有报告），Javaee项目，springboot vue前后端分离项目

演示视频&#xff1a; Springbootvue的医疗报销系统&#xff08;有报告&#xff09;&#xff0c;Javaee项目&#xff0c;springboot vue前后端分离项目 项目介绍&#xff1a; 本文设计了一个基于Springbootvue的前后端分离的医疗报销系统&#xff0c;采用M&#xff08;model&a…
阅读更多...
百度沧海文件存储CFS推出新一代Namespace架构

百度沧海文件存储CFS推出新一代Namespace架构

随着移动互联网、物联网、AI 计算等技术和市场的迅速发展&#xff0c;数据规模指数级膨胀&#xff0c;对于分布式文件系统作为大规模数据场景的存储底座提出了更高的要求。已有分布式文件系统解决方案存在着短板&#xff0c;只能适应有限的场景&#xff1a; >> 新型分布式…
阅读更多...
【产品经理】axure中继器的使用——表格增删改查分页实现

【产品经理】axure中继器的使用——表格增删改查分页实现

笔记为个人总结笔记&#xff0c;若有错误欢迎指出哟~ axure中继器的使用——表格增删改查分页实现 中继器介绍总体视图视频预览功能1.表头设计2.中继器3.添加功能实现4.删除功能实现5.修改功能实现6.查询功能实现7.批量删除 中继器介绍 在 Axure RP9 中&#xff0c;中继器&…
阅读更多...
IntelliJ IDEA Apache Dubbo，IDEA 官方插件正式发布！

IntelliJ IDEA Apache Dubbo，IDEA 官方插件正式发布！

作者&#xff1a;刘军 最受欢迎的 Java 集成开发环境 IntelliJ IDEA 与开源微服务框架 Apache Dubbo 社区强强合作&#xff0c;给广大微服务开发者带来了福音。与 IntelliJ IDEA 2023.2 版本一起&#xff0c;Jetbrains 官方发布了一款全新插件 - Apache Dubbo in Spring Frame…
阅读更多...
matlab列优先与高维矩阵重构

matlab列优先与高维矩阵重构

由于matlab在列化a(:)以及reshape(a)等操作中是列优先的&#xff0c;所以要重构出新的高维度矩阵&#xff0c;通常要把reshape和permute结合起来使用。 先到 http://caffe.berkeleyvision.org/ 下载 训练好的model bvlc_reference_caffenet.caffemodel; 更多caffe使用也请参看…
阅读更多...
C#编程艺术：Fizzler库助您高效爬取www.twitter.com音频

C#编程艺术：Fizzler库助您高效爬取www.twitter.com音频

数据是当今数字时代的核心资源&#xff0c;但是从互联网上抓取数据并不容易。本文将教您如何利用C#编程艺术和Fizzler库高效爬取Twitter上的音频数据&#xff0c;让您轻松获取所需信息。 Twitter简介 Twitter是全球最大的社交媒体平台之一&#xff0c;包含丰富的音频资源。用…
阅读更多...
机器学习系列--R语言随机森林进行生存分析（1）

机器学习系列--R语言随机森林进行生存分析（1）

随机森林&#xff08;Breiman 2001a&#xff09;&#xff08;RF&#xff09;是一种非参数统计方法&#xff0c;需要没有关于响应的协变关系的分布假设。RF是一种强大的、非线性的技术&#xff0c;通过拟合一组树来稳定预测精度模型估计。随机生存森林&#xff08;RSF&#xff0…
阅读更多...
【Pytorch】学习记录分享8——PyTorch自然语言处理基础-词向量模型Word2Vec

【Pytorch】学习记录分享8——PyTorch自然语言处理基础-词向量模型Word2Vec

【Pytorch】学习记录分享7——PyTorch自然语言处理基础-词向量模型Word2Vec 1. 词向量模型Word2Vec)1. 如何度量这个单词的&#xff1f;2.词向量是什么样子&#xff1f;3.词向量对应的热力图&#xff1a;4.词向量模型的输入与输出![在这里插入图片描述](https://img-blog.csdni…
阅读更多...
solidity案例详解（七）复杂众筹合约

solidity案例详解（七）复杂众筹合约

自己原创智能合约&#xff0c;有作业需求可加下面的图片中的裙 1、在 Remix 中&#xff0c;以 Account1 完成“众筹项目”合约的编译和部署。&#xff08;显示合约、函数、状态变量、结构体、事件的命名&#xff09; 2、在 Remix 中&#xff0c;以 Account2 完成“参与众筹”合…
阅读更多...
【架构】企业信息安全体系架构详解

【架构】企业信息安全体系架构详解

企业信息安全体系架构来说，是包含技术、运维、管理3个层面。本文说的安全架构，主要集中讨论偏研发技术层面的安全架构。 安全性是软件研发技术体系，系统架构设计阶段的一个关键DFX能力，与可靠性、可服务性、性能等架构属性并列。由于安全性设计自身的特点，涉及到系统架构…
阅读更多...
【ARMv8M Cortex-M33 系列 2.1 -- Cortex-M33 使用 .hex 文件介绍】

【ARMv8M Cortex-M33 系列 2.1 -- Cortex-M33 使用 .hex 文件介绍】

文章目录 HEX 文件介绍英特尔十六进制文件格式记录类型hex 示例Cortex-M 系列hex 文件的使用 HEX 文件介绍 .hex 文件通常用于微控制器编程&#xff0c;包括 ARM Cortex-M 系列微控制器。这种文件格式是一种文本记录&#xff0c;用于在编程时传递二进制信息。.hex 文件格式最常…
阅读更多...
Python+OpenCV 零基础学习笔记(1):anaconda+vscode+jupyter环境配置

Python+OpenCV 零基础学习笔记(1):anaconda+vscode+jupyter环境配置

文章目录 前言相关链接环境配置&#xff1a;AnacondaPython配置OpenCVOpencv-contrib:Opencv扩展 Notebook:python代码笔记vscode配置配置AnacondaJupyter文件导出 前言 作为一个C# 上位机&#xff0c;我认为上位机的终点就是机器视觉运动控制。最近学了会Halcon发现机器视觉还…
阅读更多...
『Linux升级路』冯诺依曼体系结构与操作系统

『Linux升级路』冯诺依曼体系结构与操作系统

&#x1f525;博客主页&#xff1a;小王又困了 &#x1f4da;系列专栏&#xff1a;Linux &#x1f31f;人之为学&#xff0c;不日近则日退 ❤️感谢大家点赞&#x1f44d;收藏⭐评论✍️ 目录 一、冯诺依曼体系结构 &#x1f4d2;1.1为什么要有体系结构 &#x1f4d2;1.2…
阅读更多...
23款奔驰GLC260L升级原厂540全景影像 高清环绕的视野

23款奔驰GLC260L升级原厂540全景影像 高清环绕的视野

嗨 今天给大家介绍一台奔驰GLC260L升级原厂360全景影像 新款GLC升级原厂360全景影像 也只需要安装前面 左右三个摄像头 后面的那个还是正常用的&#xff0c;不过不一样的是 升级完成之后会有多了个功能 那就是新款透明底盘&#xff0c;星骏汇小许 Xjh15863 左右两边只需要更换…
阅读更多...
Next Station of Flink CDC

Next Station of Flink CDC

摘要&#xff1a;本文整理自阿里云智能 Flink SQL、Flink CDC 负责人伍翀&#xff08;花名&#xff1a;云邪&#xff09;&#xff0c;在 Flink Forward Asia 2023 主会场的分享。Flink CDC 是一款基于 Flink 打造一系列数据库的连接器。本次分享主要介绍 Flink CDC 开源社区在过…
阅读更多...
【TensorFlow 精简版】TensorFlow Lite

【TensorFlow 精简版】TensorFlow Lite

目录 一 TensorFlow Lite简介 二 开发 三 开始使用 一 TensorFlow Lite简介 TensorFlow Lite 是一组工具&#xff0c;可帮助开发者在移动设备、嵌入式设备和 loT 设备上运行模型&#xff0c;以便实现设备端机器学习。 针对设备端的机器学习进行的优化&#xff1a; ① 延时&…
阅读更多...
NLP 自然语言处理实战

NLP 自然语言处理实战

自然语言处理 ( Natural Language Processing, NLP) 是计算机科学领域与人工智能领域中的一个重要方向。它研究能实现人与计算机之间用自然语言进行有效通信的各种理论和方法&#xff0c;用于分析理解机器与人之间的交互&#xff0c;常用的领域有&#xff1a;实体识别、文本纠错…
阅读更多...
STM32 IIC开发学习

STM32 IIC开发学习

1IIC总线时序图 ① 起始信号 当 SCL 为高电平期间&#xff0c;SDA 由高到低的跳变。起始信号是一种电平跳变时序信号&#xff0c;而不是 一个电平信号。该信号由主机发出&#xff0c;在起始信号产生后&#xff0c;总线就会处于被占用状态&#xff0c;准备数据 传输。 ② 停止信…
阅读更多...
深度！把握这三点，即可选出适合能源行业的数据摆渡解决方案

深度！把握这三点，即可选出适合能源行业的数据摆渡解决方案

在能源行业中&#xff0c;网络隔离通常采用物理隔离方式&#xff0c;即将能源行业网络与外部网络进行物理隔离&#xff0c;避免外部网络对能源行业网络的攻击和入侵。 同时&#xff0c;网络隔离也可以采用逻辑隔离方式&#xff0c;即在能源行业网络和外部网络之间设置防火墙、入…
阅读更多...
【ES6】Class继承-super关键字

【ES6】Class继承-super关键字

目录 一、前言二、ES6与ES5继承机制区别三、super作为函数1、构造函数this1&#xff09;、首先要明确this指向①、普通函数②、箭头函数③、注意事项 2&#xff09;、其次要明确new操作符做了哪些事情 2、super()的用法及注意点1&#xff09;、用法2&#xff09;、注意点 四、s…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023