SpringCloud Netflix-springcloudnetflix(四)

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介: SpringCloud Netflix-springcloudnetflix

SpringCloud Netflix-springcloudnetflix(三)https://developer.aliyun.com/article/1469570


Gateway新一代网关

gateway官网:https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/

他是什么?

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1vTkY1mr-1648908821921)(https://cdn.jsdelivr.net/gh/Doomwatcher2004/my-image-host@master/ img /image-20210911002632034.png)]

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 .0以上最新高性能版本进行集成,仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能
SpringCloud Gateway是基于WebFlux框架实现的,而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway的目标提供统一的路由方式且基于Filter链的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。

一句话概括就是:Spring Cloud Gateway 使用的Webflux中的reactor-netty响应式编程组件,底层使用了Netty通讯框架.

架构:

技术背景

有了Zuul了怎么又出来了gateway??

我们为什么选择Gatway?:

neflix不太靠谱,zuul2.0一直跳票,迟迟不发布

一方面因为Zuul1.0已经进入了维护阶段,而且Gateway是SpringCloud团队研发的,是亲儿子产品,值得信赖。而且很多功能Zuul都没有用起来也非常的简单便捷。
Gateway是基于异步非阻塞模型上进行开发的,性能方面不需要担心。虽然Netflix早就发布了最新的Zuul 2.x,但Spring Cloud貌似没有整合计划。而且Netflix相关组件都宣布进入维护期;不知前景如何 ? 多方面综合考虑Gateway是很理想的网关选择。

SpringCloud Gateway具有如下特性

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

技术对比

Zuul

Springcloud中所集成的Zuul版本,采用的是Tomcat容器,使用的是传统的Servlet lO处理模型。
学过尚硅谷web中期课程都知道一个题目,Servlet的生命周期?servlet由servlet container进行生命周
期管理。
container启动时构造servlet对象并调用servlet init)进行初始化;
container运行时接受请求,并为每个请求分配一个线程(一般从线程池中获取空闲线程)然后调用service()。container关闭时调用servlet destory0销毁servlet;

上述模式的缺点:

servlet是一个简单的网络IO模型,当请求进入servlet container时,servlet container就会为其绑定一个线程,在并发不高的场景下这种模型是适用的。但是一旦高并发(此比如抽风用jemeter),线程数量就会上涨,而线程资源代价是昂贵的(上线文切换,内存消耗大)严重影响请求的处理时间。

在一些简单业务场景下,不希望为每个request分配一个线程,只需要1个或几个线程就能应对极大并发的请求,这种业务场景下servlet模型没有优势

所以Zuul 1.X是基于servlet之上的一个姐塞式处理模型,即spring实现了处理所有request请求的一个servlet (DispatcherServiet)并由该servletse塞式处理处理。所以Springcloud Zuul无法摆脱servlet模型的弊端

gateway(webflux + netty)

传统的Web框架,比如说: struts2,springmvc等都是基于Servlet API与Servlet容器基础之上运行的。
但是
在Servlet3.1之后有了异步非阻塞的支持。而WebFlux是一个典型非阻塞异步的框架,它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说,它可以运行在诸如Netty, Undertow及支持Servlet3.1的容器上。非阻塞式+函数式编程(Spring5必须让你使用java8)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VA68uSuE-1648908821923)(https://cdn.jsdelivr.net/gh/Doomwatcher2004/my-image-host@master/ img /image-20210911003521718.png)]

Spring WebFlux是Spring 5.0引入的新的响应式框架,区别于Spring MVC,它不需要依赖Servlet API,它是完全异步非阻塞的,并且基于Reactor来实现响应式流规范。

Gateway三大核心概念

Route(路由)

路由是构建网关的基本模块,它由ID,目标URI,一系列的断言和过滤器组成,如果断言为true则匹配该路由

Predicate(断言):

参考的是java8的java.util.function.Predicate开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数),如果请求与断言相匹配则进行路由

Filter(过滤)

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

总体:

  • web请求,通过一些匹配条件,定位到真正的服务节点。并在这个转发过程的前后,进行一些精细化控制。
  • predicate就是我们的匹配条件;
  • flter,就可以理解为一个无所不能的拦截器。有了这两个元素,再加上目标uri,就可以实现一个具体的路由了

Gateway工作流程

核心逻辑: 路由转发+执行过滤器链

demo实战

新建模块: cloud-gateway-gateway9527

导入依赖

<dependencies>
        <!--新增gateway-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-gateway</artifactId>
        </dependency>
        <dependency>
            <groupId>com.atguigu.springcloud</groupId>
            <artifactId>cloud-api-commons</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
        
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

配置对应的yml

server:
  port: 9527
spring:
  application:
    name: cloud-gateway
  cloud:
    gateway:
      routes:
        - id: payment_routh #路由的ID,没有固定规则但要求唯一,建议配合服务名
          uri: http://localhost:8001   #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/get/**   #断言,路径相匹配的进行路由
        - id: payment_routh2
          uri: http://localhost:8001
          predicates:
            - Path=/payment/lb/**   #断言,路径相匹配的进行路由
eureka:
  instance:
    hostname: cloud-gateway-service
  client:
    service-url:
      register-with-eureka: true
      fetch-registry: true
      defaultZone: http://eureka7001.com:7001/eureka

编写主启动类:

@SpringBootApplication
@EnableEurekaClient
public class GateWayMain9527 {
    public static void main(String[] args) {
            SpringApplication.run( GateWayMain9527.class,args);
        }
}

构建好基本的网关模块之后,我们需要思考

9527网关如何做路由映射那???

我们打开服务提供者:cloud-provider-payment8001看看controller的访问地址

我们不想暴露8001服务端口,希望在8001外面套一层9527

于是乎

配置网管 9527的配置文件

server:
  port: 9527
spring:
  application:
    name: cloud-gateway
  cloud:
    gateway:
      routes:
    - id: payment_routh #路由的ID,没有固定规则但要求唯一,建议配合服务名
      uri: http://localhost:8001   #匹配后提供服务的路由地址
      predicates:
        - Path=/payment/get/**   #断言,路径相匹配的进行路由
    - id: payment_routh2
      uri: http://localhost:8001
      predicates:
        - Path=/payment/lb/**   #断言,路径相匹配的进行路由
eureka:
  instance:
    hostname: cloud-gateway-service
  client:
    service-url:
      register-with-eureka: true
      fetch-registry: true
      defaultZone: http://eureka7001.com:7001/eureka

这个时候我们可以来测试一下

添加网关前:http://localhost:8001/payment/get/1,我们访问会暴露出端口

添加网关后:http://localhost:9527/payment/get/1,我们访问网管,他会去找到配置文件对路由的匹配路由地址,之后断言按照规则匹配路由

通过微服务名实现动态路由

简单看到了网管效果之后,继续看看问题,我们现在的配置十分的膨胀,url是匹配死的,我们需要的是动态的,

默认情况下Gateway会根据注册中心的服务列表,以注册中心上微服务名为路径创建动态路由进行转发,从而实现动态路由的功能

这个时候我们启动 : 一个eureka7001+两个服务提供者8001/8002

此时我们要去继续修改9527的配置:

server:
  port: 9527
spring:
  application:
    name: cloud-gateway
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true  #开启从注册中心动态创建路由的功能,利用微服务名进行路由
      routes:
        - id: payment_routh #路由的ID,没有固定规则但要求唯一,建议配合服务名
          #uri: http://localhost:8001   #匹配后提供服务的路由地址
          uri: lb://cloud-payment-service
          predicates:
            - Path=/payment/get/**   #断言,路径相匹配的进行路由
        - id: payment_routh2
          #uri: http://localhost:8001   #匹配后提供服务的路由地址
          uri: lb://cloud-payment-service
          predicates:
            - Path=/payment/lb/**   #断言,路径相匹配的进行路由
eureka:
  instance:
    hostname: cloud-gateway-service
  client:
    service-url:
      register-with-eureka: true
      fetch-registry: true
      defaultZone: http://eureka7001.com:7001/eureka

PS :

  • 需要注意的是uri的协议为lb,表示启用Gateway的负载均衡功能。
  • lb://serviceName是spring cloud gateway在微服务中自动为我们创建的负载均衡uri

之后再次测试

http://localhost:9527/payment/lb

就可以发现采用了轮询的方式做负载均衡,在8001/8002两个端口切换

Predicate的使用断言的使用

断言是什么?

启动我们的gatewat9527

我们会看到他在启动的时候

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uTo0vBkk-1648908821924)(https://cdn.jsdelivr.net/gh/Doomwatcher2004/my-image-host@master/ img /image-20210911005125073.png)]

Route Predicate Factory 这个是什么东东?

Spring Cloud Gateway将路由匹配作为Spring WebFlux HandlerMapping基础架构的一部分。

  • Spring Cloud Gateway包括许多内置的Route Predicate工厂。所有这些Predicate都与HTTP请求的不同属性匹配。多个RoutePredicate工厂可以进行组合
  • Spring Cloud Gateway创建Route对象时,使用RoutePredicateFactory 创建 Predicate对象,Predicate对象可以赋值给Route。Spring Cloud Gateway包含许多内置的Route Predicate Factories。
  • 所有这些谓词都匹配HTTP请求的不同属性。多种谓词工厂可以组合

常用的Route Predicate

我们来看一下常用的断言:

- Path=/payment/lb/**   #断言,路径相匹配的进行路由
        #- After=2020-03-08T10:59:34.102+08:00[Asia/Shanghai]
        #- Cookie=username,zhangshuai #并且Cookie是username=zhangshuai才能访问
        #- Header=X-Request-Id, \d+ #请求头中要有X-Request-Id属性并且值为整数的正则表达式
        #- Host=**.atguigu.com
        #- Method=GET
        #- Query=username, \d+ #要有参数名称并且是正整数才能路由

说白了,Predicate就是为了实现一组匹配规则,让请求过来找到对应的Route进行处理

Filter的使用

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-G306Lawo-1648908821924)(https://cdn.jsdelivr.net/gh/Doomwatcher2004/my-image-host@master/ img /image-20210911005755967.png)]

路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应,路由过滤器只能指定路由进行使用。
Spring Cloud Gateway内置了多种路由过滤器,他们都由GatewayFilter的工厂类来产生

Spring Cloud Gateway的Filter

常用的GatewayFilter:AddRequestParameter

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OI1A2z64-1648908821925)(https://cdn.jsdelivr.net/gh/Doomwatcher2004/my-image-host@master/ img /image-20210911005929316.png)]

自定义全局GlobalFilter

两个主要接口介绍:

  • GlobalFilter  : 全局过滤器
  • Ordered :  执行顺序

能干嘛?

  • 全局日志记录
  • 统一网关鉴权
  • 等等等....

过滤器代码

@Component
@Slf4j
public class MyLogGateWayFilter implements GlobalFilter,Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        log.info("*********come in MyLogGateWayFilter: "+new Date());
        String uname = exchange.getRequest().getQueryParams().getFirst("username");
        if(StringUtils.isEmpty(username)){
            log.info("*****用户名为Null 非法用户,(┬_┬)");
            exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);//给人家一个回应
            return exchange.getResponse().setComplete();
        }
        return chain.filter(exchange);
    }
    @Override
    public int getOrder() {
        return 0;
    }
}

使用了这个之后

我们的请求如果是没有带有uname这个参数就会被过滤,可以用来作为一些必要参数的筛选和鉴权

config分布式配置中心

概述:分布式系统面临的配置问题?

微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。
SpringCloud提供了ConfigServer来解决这个问题,我们每一个微服务自己带着一个application.yml,上百个配置文件的管理.…

官网 : https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/

config是什么?

SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

怎么做?

SpringCloud Config分为服务端和客户端两部分:

  • 服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口
  • 客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容

我们用它可以做什么?

  • 集中管理配置文件
  • 不同环境不同配置,动态化的配置更新,分环境部署比如dev/test/prod/beta/release
  • 运行期间动态调整配置,不再需要在每个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置自己的信息
  • 当配置发生变动时,服务不需要重启即可感知到配置的变化并应用新的配置
  • 将配置信息以REST接口的形式暴露 : post、curl访问刷新均可....

前置条件

与Github整合配置

由于SpringCloud Config默认使用Git来存储配置文件(也有其它方式,比如支持svn和本地文件,但最推荐的还是Git,而且使用的是http/https访问的形式)

用你自己的账号在Github上新建一个名为sprincloud-config的新Repository

添加上这些:

本地硬盘上新建git仓库并clone

上手实战

Config服务端配置与测试

新建Module模块cloud-config-center-3344它既为Cloud的配置中心模块cloudConfig Center

导入依赖

<dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <dependency>
            <groupId>com.atguigu.springcloud</groupId>
            <artifactId>cloud-api-commons</artifactId>
            <version>${project.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

相关配置

server:
  port: 3344
spring:
  application:
    name: cloud-config-center
  cloud:
    config:
      server:
        git:
          uri:  填写你自己的github路径
          search-paths:
            - springcloud-config
      label: master
eureka:
  client:
    service-url:
      defaultZone:  http://localhost:7001/eureka

主启动

@SpringBootApplication
@EnableConfigServer
public class ConfigCenterMain3344 {
    public static void main(String[] args) {
            SpringApplication.run(ConfigCenterMain3344 .class,args);
        }
}

测试通过Config微服务是否可以从Github上获取配置内容

启动微服务3344  : http://config-3344.com:3344/master/config-dev.yml

读取规则

/{label}/{application}-{profile}.yml(最推荐使用这种方式)

成功实现了用SpringCloud Config 通过GitHub获取配置信息

Config客户端配置与测试

新模块 cloud-config-client-3355

依赖

<dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <dependency>
            <groupId>com.atguigu.springcloud</groupId>
            <artifactId>cloud-api-commons</artifactId>
            <version>${project.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

bootstrap.yml 为什么要这个样写

applicaiton.ym1是用户级的资源配置项bootstrap.ym1是系统级的,优先级更加高
I
Spring Cloud会创建一个“Bootstrap Context”,作为Spring应用的Application Context的父上下文。初始化的时候,BootstrapContext'负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment'。
'Bootstrap')属性有高优先级,默认情况下,它们不会被本地配置覆盖。Bootstrap context和Application Context有着不同的约定,所以新增了一个'bootstrap.yml'文件,保证Bootstrap Context和Application Context'配置的分离。
要将Client模块下的application.yml文件改为bootstrap.yml,这是很关键的,
因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml

server:
  port: 3355
spring:
  application:
    name: config-client
  cloud:
    config:
      label: master
      name: config
      profile: dev
      uri: http://localhost:3344
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka

主启动类

@SpringBootApplication
@EnableEurekaClient
public class ConfigClientMain3355 {
    public static void main(String[] args) {
            SpringApplication.run( ConfigClientMain3355.class,args);
        }
}

业务类

@RestController
public class ConfigClientController {
    @Value("${config.info}")
    private String configInfo;
    @GetMapping("/configInfo")
    public String getConfigInfo(){
        return configInfo;
    }
}

启动Config配置中心3344微服务并自测

http://config-3344.com:3344/master/config-dev.yml

就可以读取到 git 仓库中的配置文件信息

启动3355作为Client准备访问

http://localhost:3355/configInfo

访问到配置中心的配置信息

成功实现了客户端3355访问SpringCloud Config3344通过GitHub获取配置信息

问题随时而来,分布式配置的动态刷新

场景:Linux运维修改GitHub上的配置文件内容做调整

  • 刷新3344,发现ConfigServer配置中心立刻响应
  • 刷新3355,发现ConfigServer客户端没有任何响应
  • 3355没有变化除非自己重启或者重新加载

难道每次运维修改配置文件,客户端都需要重启??噩梦 !!!!!!!

Config客户端之动态刷新

避免每次更新配置都要重启客户端微服务3355

POM引入actuator监控

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

修改配置暴露全部的信息

server:
  port: 3355
spring:
  application:
    name: config-client
  cloud:
    config:
      label: master
      name: config
      profile: dev
      uri: http://localhost:3344
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka
management:
  endpoints:
    web:
      exposure:
        include: "*"

@RefreshScope业务类Controller修改

@RefreshScope
@RestController
public class ConfigClientController {
@Value("${config.info}")
private String configInfo;
@GetMapping("/configInfo")
public String getConfigInfo(){
    return configInfo;
}
}

配置好之后需要需要运维人员发送Post请求刷新3355

请求完之后

不用重启也可以动态的刷新配置

还有遗留问题

这个时候新的问题又来了

假如有多个微服务客户端3355/3366/3377。。。。

每个微服务都要执行一次post请求,手动刷新?

可否广播,一次通知,处处生效?

我们想大范围的自动刷新,求方法,有需求就会有人来解决

Bus 消息总线

一言以蔽之

  • 分布式自动刷新配置功能
  • Spring Cloud Bus配合Spring Cloud Config使用可以实现配置的动态刷新

Bus是什么?

他能干什么?

为什么称之为总线?

什么是总线:

在微服务架构的系统中,通常会使用轻量级的消息代理来构建一个共用的消息主题,并让系统中所有微服务实例都连接上来。由于该主题中产生的消息会被所有实例监听和消费,所以称它为消息总线。在总线上的各个实例,都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息。
基本原理:

ConfigClient实例都监听MQ中同一个topic(默认是springCloudBus)。当一个服务刷新数据的时候,它会把这个信息放入到Topic中,这样其它监听同一Topic的服务就能得到通知,然后去更新自身的配置。


SpringCloud Netflix-springcloudnetflix(五)https://developer.aliyun.com/article/1469572

相关实践学习
Serverless极速搭建Hexo博客
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
目录
相关文章
|
6月前
|
负载均衡 监控 算法
SpringCloud Netflix-springcloudnetflix(二)
SpringCloud Netflix-springcloudnetflix
57 3
|
6月前
|
消息中间件 Java 中间件
SpringCloud Netflix-springcloudnetflix(五)
SpringCloud Netflix-springcloudnetflix
67 1
|
6月前
|
运维 监控 Java
SpringCloud Netflix-springcloudnetflix(三)
SpringCloud Netflix-springcloudnetflix
66 1
|
6月前
|
Dubbo Java 应用服务中间件
SpringCloud Netflix-springcloudnetflix(一)
SpringCloud Netflix-springcloudnetflix
74 1
|
2月前
|
SpringCloudAlibaba API 开发者
新版-SpringCloud+SpringCloud Alibaba
新版-SpringCloud+SpringCloud Alibaba
|
3月前
|
资源调度 Java 调度
Spring Cloud Alibaba 集成分布式定时任务调度功能
定时任务在企业应用中至关重要,常用于异步数据处理、自动化运维等场景。在单体应用中,利用Java的`java.util.Timer`或Spring的`@Scheduled`即可轻松实现。然而,进入微服务架构后,任务可能因多节点并发执行而重复。Spring Cloud Alibaba为此发布了Scheduling模块,提供轻量级、高可用的分布式定时任务解决方案,支持防重复执行、分片运行等功能,并可通过`spring-cloud-starter-alibaba-schedulerx`快速集成。用户可选择基于阿里云SchedulerX托管服务或采用本地开源方案(如ShedLock)
105 1
|
19天前
|
JSON SpringCloudAlibaba Java
Springcloud Alibaba + jdk17+nacos 项目实践
本文基于 `Springcloud Alibaba + JDK17 + Nacos2.x` 介绍了一个微服务项目的搭建过程,包括项目依赖、配置文件、开发实践中的新特性(如文本块、NPE增强、模式匹配)以及常见的问题和解决方案。通过本文,读者可以了解如何高效地搭建和开发微服务项目,并解决一些常见的开发难题。项目代码已上传至 Gitee,欢迎交流学习。
Springcloud Alibaba + jdk17+nacos 项目实践
|
6天前
|
消息中间件 自然语言处理 Java
知识科普:Spring Cloud Alibaba基本介绍
知识科普:Spring Cloud Alibaba基本介绍
25 2
|
14天前
|
Dubbo Java 应用服务中间件
Dubbo学习圣经:从入门到精通 Dubbo3.0 + SpringCloud Alibaba 微服务基础框架
尼恩团队的15大技术圣经,旨在帮助开发者系统化、体系化地掌握核心技术,提升技术实力,从而在面试和工作中脱颖而出。本文介绍了如何使用Dubbo3.0与Spring Cloud Gateway进行整合,解决传统Dubbo架构缺乏HTTP入口的问题,实现高性能的微服务网关。
|
3月前
|
人工智能 前端开发 Java
【实操】Spring Cloud Alibaba AI,阿里AI这不得玩一下(含前后端源码)
本文介绍了如何使用 **Spring Cloud Alibaba AI** 构建基于 Spring Boot 和 uni-app 的聊天机器人应用。主要内容包括:Spring Cloud Alibaba AI 的概念与功能,使用前的准备工作(如 JDK 17+、Spring Boot 3.0+ 及通义 API-KEY),详细实操步骤(涵盖前后端开发工具、组件选择、功能分析及关键代码示例)。最终展示了如何成功实现具备基本聊天功能的 AI 应用,帮助读者快速搭建智能聊天系统并探索更多高级功能。
1151 2
【实操】Spring Cloud Alibaba AI,阿里AI这不得玩一下(含前后端源码)

热门文章

最新文章