SpringCloud02

7.Gateway服务网关

7.1 概述

SpringCloud Gateway

SpringCloud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架。

特性

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

GateWay模型

WebFlux是一个典型非阻塞异步的框架，它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说，它可以运行在诸如Netty，Undertow及支持Servlet3.1的容器上。非阻塞式+函数式编程（Spring5必须让你使用java8）
Spring WebFlux 是 Spring 5.0 引入的新的响应式框架，区别于 Spring MVC，它不需要依赖Servlet API，它是完全异步非阻塞的，并且基于 Reactor 来实现响应式流规范。

7.2 三大核心概念

Route(路由)

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

Predicate(断言)

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

Filter(过滤)

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

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

7.3 工作流程

路由转发+执行过滤器链

客户端向 Spring Cloud Gateway 发出请求。然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。
Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。
过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。
Filter在“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等，在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等有着非常重要的作用。

7.4 入门配置

模块 --- POM --- YML

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true #开启从注册中心动态创建路由的功能，利用微服务名进行路由
      routes:
        - id: payment_routh #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
          #uri: http://localhost:8001          #匹配后提供服务的路由地址
          uri: lb://cloud-payment-service #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/get/**         # 断言，路径相匹配的进行路由

        - id: payment_routh2 #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
          #uri: http://localhost:8001          #匹配后提供服务的路由地址
          uri: lb://cloud-payment-service #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/lb/**         # 断言，路径相匹配的进行路由
            #- After=2020-02-21T15:51:37.485+08:00[Asia/Shanghai]
            #- Cookie=username,zzyy
            #- Header=X-Request-Id, \d+  
            # 请求头要有X-Request-Id属性并且值为整数的正则表达式

网关路由映射隐藏服务提供端将网关端口套在外面

配置说明

Gateway网关路由有两种配置方式：

yml配置
代码中注入RouteLocator的Bean

7.5 微服务名实现动态路由

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

7.6 Predicate

Spring Cloud Gateway将路由匹配作为Spring WebFlux HandlerMapping基础架构的一部分。
Spring Cloud Gateway包括许多内置的Route Predicate工厂。所有这些Predicate都与HTTP请求的不同属性匹配。多个Route Predicate工厂可以进行组合。

Spring Cloud Gateway 创建 Route 对象时，使用 RoutePredicateFactory 创建 Predicate 对象，Predicate 对象可以赋值给 Route。

Spring Cloud Gateway 包含许多内置的Route Predicate Factories。

所有这些谓词都匹配HTTP请求的不同属性。多种谓词工厂可以组合，并通过逻辑and。

常用的Route Predicate

After Route Predicate
Before Route Predicate
Between Route Predicate
Cookie Route Predicate
Header Route Predicate 两个参数：一个是属性名称和一个正则表达式，这个属性值和正则表达式匹配则执行。
Host Route Predicate 接收一组参数，一组匹配的域名列表，这个模板是一个 ant 分隔的模板，用.号作为分隔符。它通过参数中的主机地址作为匹配规则。
Method Route Predicate
Path Route Predicate
Query Route Predicate 支持传入两个参数，一个是属性名，一个为属性值，属性值可以是正则表达式。

7.7 Filter

路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应，路由过滤器只能指定路由进行使用。

Spring Cloud Gateway 内置了多种路由过滤器，他们都由GatewayFilter的工厂类来产生。

生命周期 ---- pre ---- post

种类

GatewayFilter
- 常用GatewayFilter AddRequestParameter
GlobalFilter
- 自定义 --- 实现 GlobalFilter,Ordered

8.Config分布式配置中心

8.1 概述

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。

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

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

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

作用：

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

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

8.2 Config服务端

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

github
- github 新建Repository： springcloud-config
- git@github.com:FremontXu/springcloud-config.git
- 本地 git clone ....
创建config-center模块 ----- POM
- 主启动类 @EnableConfigServer
windows下修改hosts文件，增加映射 127.0.0.1 config-3344.com
http://config-3344.com:3344/master/config-dev.yml
读取规则 label：分支(branch) name ：服务名 profiles：环境(dev/test/prod)
- /{label}/{application}-{profile}.yml
- /{application}-{profile}.yml
- /{application}/{profile}[/{label}]

8.3 Config客户端

创建客户端模块 ----- POM ---- bootstrap.yml

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

主启动 ----- 业务：读取

动态刷新：修改时避免重启刷新

POM引入actuator监控
暴露监控端点

management:
  endpoints:
    web:
      exposure:
        include: "*"

业务Controller @RefreshScope

9.Bus消息总线

9.1 概述

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

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

Spring Cloud Bus 配合 Spring Cloud Config 使用可以实现配置的动态刷新。

Spring Cloud Bus是用来将分布式系统的节点与轻量级消息系统链接起来的框架，它整合了Java的事件处理机制和消息中间件的功能。

Spring Clud Bus目前支持RabbitMQ和Kafka。

Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改、事件推送等，也可以当作微服务间的通信通道。

9.2 动态刷新全局广播

RabbitMQ配置 ---- 15672

新建模块client

设计思想

利用消息总线触发一个服务端ConfigServer的/bus/refresh端点，而刷新所有客户端的配置

服务端

<!--添加消息总线RabbitMQ支持-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

#rabbitmq相关配置
rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
#rabbitmq相关配置,暴露bus刷新配置的端点
management:
  endpoints: #暴露bus刷新配置的端点
    web:
      exposure:
        include: 'bus-refresh'

客户端

POM同上

# 暴露监控端点
management:
  endpoints:
    web:
      exposure:
        include: "*"

修改github ----- POST curl -X POST "http://localhost:3344/actuator/bus-refresh"

一次发送，处处生效

一次修改，广播通知，处处生效

9.3 动态刷新定点通知

指定具体某一个实例生效而不是全部

公式：http://localhost:配置中心的端口号/actuator/bus-refresh/{destination}

/bus/refresh请求不再发送到具体的服务实例上，而是发给config server并通过destination参数类指定需要更新配置的服务或实例

10.Stream消息驱动

10.1 概述

Spring Cloud Stream 是一个构建消息驱动微服务的框架。

应用程序通过 inputs 或者 outputs 来与 Spring Cloud Stream中binder对象交互。通过我们配置来binding(绑定) ，而 Spring Cloud Stream 的 binder对象负责与消息中间件交互。

通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。

Spring Cloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。

Spring Cloud Stream是用于构建与共享消息传递系统连接的高度可伸缩的事件驱动微服务框架，该框架提供了一个灵活的编程模型，它建立在已经建立和熟悉的Spring熟语和最佳实践上，包括支持持久化的发布/订阅、消费组以及消息分区这三个核心概念。

设计思想

生产者/消费者之间靠消息媒介传递信息内容
消息通道MessageChannel
消息通道MessageChannel的子接口SubscribableChannel，由MessageHandler消息处理器所订阅

stream统一底层差异

通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。
通过向应用程序暴露统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现。
通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离。

Binder

通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。Stream对消息中间件的进一步封装，可以做到代码层面对中间件的无感知，甚至于动态的切换中间件(rabbitmq切换为kafka)，使得微服务开发的高度解耦，服务可以关注更多自己的业务流程。
通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离。
Binder可以生成Binding，Binding用来绑定消息容器的生产者和消费者，它有两种类型，INPUT和OUTPUT，INPUT对应于消费者，OUTPUT对应于生产者。

Stream消息通信方式遵循发布-订阅模式

Topic主题进行广播
在RabbitMQ是Exchange
在Kakfa中是Topic

Spring Cloud Stream标准流程套路

Binder 连接中间件，屏蔽差异
Channel 通道，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置
Source和Sink 从Stream发布消息就是输出，接受消息就是输入。

编码API和常用注解

Middleware 中间件只支持 RabbitMQ和Kafka
Binder 连接中间件动态改变消息类型 ---- 配置文件
@Input 标识输入通道 ---- 接收消息进入应用程序
@Output 标识输出通道 ---- 消息离开应用程序
@StreamListener 监听队列 ---- 消费者队列的消息接收
@EnableBinding 绑定通道channel和exchange

10.2 生产者

YML

spring:
  application:
    name: cloud-stream-provider
  cloud:
      stream:
        binders: # 在此处配置要绑定的rabbitmq的服务信息；
          defaultRabbit: # 表示定义的名称，用于于binding整合
            type: rabbit # 消息组件类型
            environment: # 设置rabbitmq的相关的环境配置
              spring:
                rabbitmq:
                  host: 192.168.102.128
                  port: 5672
                  username: admin
                  password: 123
        bindings: # 服务的整合处理
          output: # 这个名字是一个通道的名称
            destination: studyExchange # 表示要使用的Exchange名称定义
            content-type: application/json # 设置消息类型，本次为json，文本则设置“text/plain”
            binder: defaultRabbit # 设置要绑定的消息服务的具体设置

业务类 ----- service 实现

@EnableBinding(Source.class) // 可以理解为是一个消息的发送管道的定义
public class IMessageProviderImpl implements IMessageProvider {
    @Resource
    private MessageChannel output; // 消息的发送管道
    @Override
    public String send() {
        String serial = UUID.randomUUID().toString();
        this.output.send(MessageBuilder.withPayload(serial).build()); // 创建并发送消息
        System.out.println("***serial: " + serial);
        return serial;
    }
}

10.3 消费者

YML

spring:
  application:
    name: cloud-stream-consumer
  cloud:
      stream:
        binders: # 在此处配置要绑定的rabbitmq的服务信息；
          defaultRabbit: # 表示定义的名称，用于于binding整合
            type: rabbit # 消息组件类型
            environment: # 设置rabbitmq的相关的环境配置
              spring:
                rabbitmq:
                  host: 192.168.102.128
                  port: 5672
                  username: admin
                  password: 123
        bindings: # 服务的整合处理
          input: # 这个名字是一个通道的名称
            destination: studyExchange # 表示要使用的Exchange名称定义
            content-type: application/json # 设置消息类型，本次为对象json，如果是文本则设置“text/plain”
            binder: defaultRabbit # 设置要绑定的消息服务的具体设置

业务类 Controller

@Component
@EnableBinding(Sink.class)
public class ReceiveMessageListenerController {
    @Value("${server.port}")
    private String serverPort;
    
    @StreamListener(Sink.INPUT)
    public void input(Message<String> message) {
        System.out.println("消费者1号,----->接受到的消息: " + message.getPayload() + "\t  port: " + serverPort);
    }
}

10.4 分组消费与持久化

新建消费者模块8003

8002和8003都接收到了8001的信息 -----重复消费 --- 消息持久化问题

Stream中的消息分组：

注意在Stream中处于同一个group中的多个消费者是竞争关系，就能够保证消息只会被其中一个应用消费一次。
不同组是可以全面消费的(重复消费)
同一组内会发生竞争关系，只有其中一个可以消费

消费者YML：input:group: atguiguA

同一个组的多个微服务实例，每次只会有一个拿到

持久化

设置分组的会监听原队列，没有分组的会新建监听队列

11.Sleuth分布式请求链路跟踪

11.1 概述

在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。

Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案，在分布式系统中提供追踪解决方案并且兼容支持了zipkin。

11.2 链路监控

11.2.1 zipkin

SpringCloud从F版起已不需要自己构建Zipkin Server了，只需调用jar包即可

cmd中运行 java -jar zipkin-server-2.12.9-exec.jar
http://localhost:9411/zipkin/

请求链路：

一条链路通过Trace Id唯一标识，Span标识发起的请求信息，各span通过parent id 关联起来

Trace:类似于树结构的Span集合，表示一条调用链路，存在唯一标识
span:表示调用链路来源，通俗的理解span就是一次请求信息

11.2.2 服务提供者

POM

<!--包含了sleuth+zipkin-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

YML

spring:
  application:
    name: cloud-payment-service
  zipkin:
    base-url: http://localhost:9411
  sleuth:
    sampler:
    #采样率值介于 0 到 1 之间，1 则表示全部采集
      probability: 1

11.2.3 服务消费者

同上

posted @ 2021-07-02 16:48 FremontUltimate 阅读(41) 评论(0) 收藏举报

刷新页面返回顶部

FremontUltimate

SpringCloud02

SpringCloud02

7.Gateway服务网关

7.1 概述

7.2 三大核心概念

7.3 工作流程

7.4 入门配置

7.5 微服务名实现动态路由

7.6 Predicate

7.7 Filter

8.Config分布式配置中心

8.1 概述

8.2 Config服务端

8.3 Config客户端

9.Bus消息总线

9.1 概述

9.2 动态刷新全局广播

9.3 动态刷新定点通知

10.Stream消息驱动

10.1 概述

10.2 生产者

10.3 消费者

10.4 分组消费与持久化

11.Sleuth分布式请求链路跟踪

11.1 概述

11.2 链路监控

11.2.1 zipkin

11.2.2 服务提供者

11.2.3 服务消费者

公告