spring cloud alibaba

java
字数统计: 6.7k   |   阅读时长≈ 25 分钟

SpringCloud Alibaba

1、1. 微服务介绍

1.1、1.1 系统架构演变

  • 单体应用架构：起初当网站流量小，将所有功能都写在一个应用里面，对整个应用进行部署，以减少部署节点和成本。对于这个架构简化增删查改的工作量的数据访问框架（ORM）是关键
    • 优点：
      • 架构图简单易懂
      • 对于小项目开发、维护简单
      • 部署一个单点tomcat上后期维护方便
    • 缺点：
      • 对于大型项目来说维护困难
      • 模块之间紧密耦合。单点容错率低
      • 无法争对某一个模块进行水平扩展或优化
  • 垂直应用架构：当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆分成互不相干的几个应用，以提升效率，此时，用于加速前端页面开发的web框架（MVC）是关键
    • 优点：
      • 模块化，可以进行水平扩展和优化
      • 提高单点的容错率
    • 缺点：
      • 系统之间无法调用
      • 会有部分重复代码
  • 分布式架构：当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式框架（RPC）是关键。
    • 优点：
      • 抽取公共代码为服务层，增强代码复用性
    • 缺点：
      • 调用关系复杂，维护困难
  • SOA架构：当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键
    • 优点：
      • 使用服务治理中心帮我们维护复杂的调用关系
    • 缺点：
      • 服务有依赖性，可能会因为一个服务的问题，导致多个系统不可用（拆分的不够彻底）
  • 微服务架构
    • 优点：
      • 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
      • 微服务之间采用Restful等轻量级http协议相互调用
    • 缺点：
      • 分布式系统开发的技术成本高（容错、分布式事务等）

1.2、1.2 微服务架构的常用概念

1.2.1、1.2.1 服务治理

服务的自动化管理、其核心是服务的自动注册与发现

    - 服务注册
    - 服务发现
    - 服务剔除

1.2.2、1.2.2 服务调用

主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。

比较项 RESTful RPC
通信协议 HTTP 一般使用TCP
性能 略低 较高
灵活度 高 低
应用 微服务架构 SOA架构

1.2.3、1.2.3 服务网关

将所有API调用统一接入到API网关层，由网关层统一接入和输出。基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。

1.2.4、1.2.4 服务容错

核心思想：

- 不被外界环境影响
- 不被上游请求压垮
- 不被下游响应拖垮

1.2.5、1.2.5 链路追踪

对一次请求涉及的多个服务链路进行日志追踪，性能监控。

springboot、springcloud alibaba版本要对应

1.3、1.3 微服务项目构建

1
2
3
4
5
1. 服务注册中心 =======> Nacos
2. 服务间通信负载均衡 =======> HttpRest a.RestTemplate + Ribbon(Netfix) b. Openfeign(Spring)
3. 服务流控和服务降级 =======> Sentinel
4. 服务网关组件 ========> Gateway(Spring)
5. 统一配置中心组件 =======> Nacos

1.4、1.4 springcloud alibaba 环境搭建

  1. 创建全局父项目

    1
    2
    3
    - 维护 springcloud 依赖			Hoxton SR6
    - 维护 alibaba 依赖				2.2.1.RELEASE
    - 继承 springboot 父项目 2.2.5.RELEASE

  2. 父项目中依赖维护

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    <properties>
            <maven.compiler.source>8</maven.compiler.source>
            <maven.compiler.target>8</maven.compiler.target>
            <spring.cloud-version>Hoxton.SR6</spring.cloud-version>
            <spring.cloud.alibaba-version>2.2.1.RELEASE</spring.cloud.alibaba-version>
        </properties>

        <!--    继承 springboot 父项目-->
        <parent>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-parent</artifactId>
            <version>2.2.5.RELEASE</version>
        </parent>

        <!--    维护依赖-->
        <dependencyManagement>
            <dependencies>
                <!--    维护 springcloud-->
                <dependency>
                    <groupId>org.springframework.cloud</groupId>
                    <artifactId>spring-cloud-dependencies</artifactId>
                    <version>${spring.cloud-version}</version>
                    <!-- pom 记录其它组件的版本-->
                    <type>pom</type>
                    <scope>import</scope>
                </dependency>
                <!--    维护 springcloud alibaba-->
                <dependency>
                    <groupId>com.alibaba.cloud</groupId>
                    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                    <version>${spring.cloud.alibaba-version}</version>
                    <type>pom</type>
                    <scope>import</scope>
                </dependency>
            </dependencies>
        </dependencyManagement>

2、2. Nacos Discovery – 服务治理

替换 springcloud 中 consul 、eureka 和 config 组件

2.1、2.1 服务治理

实现各个微服务的自动化注册与发现。

服务注册

在服务治理框架中，都会构建一个注册中心，每个服务单元向注册中心登记自己提供服务的详细信息。并在注册中心形成一张服务的清单，服务注册中心需要以心跳的方式去检测清单中的服务是否可用，如果不可用，需要在服务清单中剔除不可用的服务。

服务发现

服务调用方向服务注册中心咨询服务，并获取所有服务的实例清单，实现对具体服务实例的访问。

注册中心

在微服务架构中起到了协调者的作用

  1. 服务发现
    • 服务注册：保存服务提供者和服务调用者的信息
    • 服务订阅：服务调用者订阅服务提供者的信息，注册中心向订阅者推送提供者的信息
  2. 服务配置
    • 配置订阅：服务提供者和服务调用者订阅微服务相关的配置
    • 配置下发：主动将配置推送给服务提供者和服务调用者
  3. 服务健康检测
    • 检测服务提供者的健康情况，如果发现异常，执行服务剔除

2.2、2.2 nacos 实战

下载、启动

1
startup.cmd -m standalone	#单体模式启动

服务注册

  1. 添加nacos依赖

    1
    2
    3
    4
    5
    <!--nacos客户端-->
    <dependency>
    	<groupId>com.alibaba.cloud</groupId>
    	<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>

  2. 在主类上添加@EnableDiscoveryClient注解

  3. 在application.yml中添加nacos服务的地址

    1
    2
    3
    4
    5
    spring:
    	cloud:
    		nacos:
    			discovery:
    				server-addr:127.0.0.1:8848

    在nacos管理界面可以看到服务即代表注册成功

    注入 DiscoveryClient 对象

2.3、2.3 实现服务调用的负载均衡

​ 负载均衡就是将负载（工作任务，访问请求）进行分摊到多个操作单元（服务器、组件）上进行执行。

​ 根据负载均衡发生位置的不同，一般分为 服务端负载均衡 和 客户端负载均衡

​ 服务端负载均衡：发生在服务提供者一方，比如常见的 nginx 负载均衡

​ 客户端负载均衡：发生在服务请求的一方，也就是在发送请求之前已经选好了由哪个实例处理请求

2.4、2.4 基于 Ribbon 实现负载均衡

Ribbon 提供 DiscoverClient：服务发现的客户端 LoadBalanceClient：负载均衡的客户端 @LoadBalance

  • 在 RestTemplate 的生成方法上添加 @LoadBalanced 注解

    1
    2
    3
    4
    5
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
    	return new RestTemplate();
    }

  • 修改服务调用的方法

    使用微服务名代替地址

  • 负载均衡策略

    1. RoundRobinRule：轮询方式轮询选择 server
    2. RandomRule：随机选择一个 server
    3. BestAvailableRule：选择一个最小的并发请求的 server
    1
    2
    3
    4
    # 修改配置文件
    service-product:	# 调用的提供者的名称
    	ribbon:
    		NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

2.5、2.5 基于 Fegin 实现服务调用

​ Fegin 是 Spring Cloud提供的一个声明式的伪 Http 客户端，它使得调用远程服务就像调用本地服务一样简单，只需要创建一个接口并添加一个注解即可。

​ 在 Nacos 下使用 Fegin 默认就实现了负载均衡的效果。

  1. 加入 Fegin 的依赖

    1
    2
    3
    4
    5
    <--fegin组件-->
    <dependency>
    	<groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-openfeign</artifactId>
    </dependency>

  2. 在主类上添加 @EnableFeignClients 注解开启 Fegin

  3. 创建一个 service，并使用 Fegin 实现微服务调用

    1
    2
    3
    4
    5
    6
    7
    @FeignClient("service-product")//声明调用的提供者的name
    public interface ProductService{
        //指定调用提供者的哪个方法
        //@FeignClient + @GetMapping 就是一个完整的请求 http://service-product/product/{pid}
        @GetMapping(value = "/product/{pid}") //指定请求的 URI 部分
        Product finfByPid(@pathVariable("pid") Integer pid);
    }

2.6、2.6 统一配置中心

1. 管理配置文件的方式是在自己所在的服务器上形成一个版本库，不需要再创建远程版本库
2. nacos 作为统一配置中心管理配置文件时，同样也存在版本控制

步骤

  • 在 nacos 中新建配置文件，注意配置文件的命名

  • 在微服务中引入 nacos-config 依赖

    1
    2
    3
    4
    5
    <!-- nacos-config-client -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
    </dependency>

  • 配置文件配置拉取 nacos 中的哪个配置文件，配置文件命名为 bootstrap.properties

    1
    2
    3
    4
    5
    6
    7
    8
    # 配置 config server 地址
    spring.cloud.nacos.config.server-addr=47.99.77.213:8848
    # 配置从哪个组获取配置
    spring.cloud.nacos.config.group=DEFAULT_GROUP
    # 配置 拉取组里的哪个文件
    spring.cloud.nacos.config.name=configclient-prod
    # 配置 拉取组里的那个文件的后缀名
    spring.cloud.nacos.config.file-extension=properties

  • 细节

    • dataId：代表完整配置文件名称
    • 完整配置文件名称 = prefix（前缀）+ 环境（env）+ file -extension（后缀）
    • dataId = spring.cloud.nacos.config.name + spring.cloud.nacos.config.file-extension
    • dataId = spring.cloud.nacos.config.prefix + spring.profiles.active + spring.cloud.nacos.config.file-extension

2.7、2.7 nacos 持久化

持久化：管理的配置信息持久化

注意：默认 nacos 存在配置信息持久化，默认的持久化方式为内嵌数据库 debery

​ 官方推荐使用 mysql 数据库

2.8、2.8 nacos server 集群搭建

前置条件

  1. 需要一个负载均衡组件（SLB），将请求转发。

![nacos server集群](E:\desktop\typora-notes\图\nacos server集群.png)

  1. 需要配置 mysql 持久化

集群的搭建

  • 准备3个 nacos 节点，并连接 mysql 数据库。
  • 初始化 mysql 数据库
  • 修改 nacos conf 目录中 cluster.conf 文件中添加所有集群节点，写入节点的地址
  • 修改 nacos 各自的端口号

2.9、2.9 nacos 高可用

安装 nginx 配置 nginx.conf

1
2
3
4
5
6
7
8
9
10
upstream nacos-server{ # 负载均衡的节点
	server ip:端口;
	server ip:端口;
	server ip:端口;
	...
}

location / {
	proxy_pass http://nacos-servers/; # 对应上面的 u
}

3、3. entinel – 服务容错

​ 替换 springcloud 中的 Hystrix 组件

​ 高并发带来的问题：不能保证每个服务 100% 可以，单个服务出现问题，若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。

3.1、3.1 服务雪崩效应

​ 由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果

​ 雪崩效应发生的原因多种多样：不合理的容量设计、高并发下某一个方法响应变慢、某台机器资源耗尽。

3.2、3.2 服务容错思路

  • 隔离：将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。线程池隔离、信号量隔离
  • 超时：在上游服务调用下游服务时，设置一个最大响应时间，如果超过这个时间，下游未做出反应，就断开请求，释放掉线程。
  • 限流：限制系统的输入和输出流量已达到保护系统的目的。
  • 熔断：当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。
    • 熔断关闭状态（ Closed ）：服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制。
    • 熔断开启状态 （ Open ）：后续对该服务====口的调用不再经过网络，直接执行本地的 fallback 方法
    • 半熔断状态（Half-Open）：尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。
  • 降级：为服务提供一个托底方案，一旦服务无法正常调用，就使用托底方案。

容错组件：Hystrix、Resilience4J、Sentinel

3.3、3.3 Sentinel

Sentine 分为两个部分：

  • 核心库（java客户端）不依赖任何框架/库，能够运行于所有 java 运行时环境，同时对 Dubbo/Spring Cloud 等框架也有较好的支持。
  • 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

微服务集成 Sentinel

  1. 添加依赖

    1
    2
    3
    4
    <dependency>
    	<groupId>com.alibaba.cloud</groupId>
       <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
    </dependency>

  2. 运行控制台

    1
    java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.7.0.jar

  3. 配置文件

    1
    2
    3
    4
    sentinel:
    	transport:
    		port: 9999 #跟控制台交流的端口，随意指定一个未使用的端口即可
    		dashboard: localhost:8080 #指定控制台服务的地址

  4. 浏览器访问 8080端口

基本概念

  • 资源

    Sentinel 要保护的东西

    资源是 Sentinel 的关键概念，它可以是 Java 应用程序中的任何内容，可以是一个服务，也可以是一个方法，甚至可以是一段代码。

  • 规则

    规则就是用来定义如何保护资源的

    主要包括：流量控制规则、熔断降级规则以及系统保护规则

    • 流量控制：根据需要把随机的请求调整成合适的形状
    • 熔断降级：当检测到调用链路中某个资源出现不稳定的表现，例如请求响应时间长或异常比例升高的时候，则对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联故障。
      • 通过并发线程数进行控制
      • 通过响应时间对资源进行降级
    • 系统负载保护：当系统负载较高的时候，如果还持续让请求进入可能会导致系统崩溃，无法响应。在 集群环境下，会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候，Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。

在 Sentinel 的资源上配置各种各样的规则，来实现各种容错的功能

3.4、3.4 Sentinel 规则

流控规则：监控 QPS 或并发线程数

资源名：唯一名称

针对来源：指定对哪个微服务进行限流，默认 default，意思是不区分来源，全部限制

流控模式：

  • 直接：接口达到限流条件时，开启限流

  • 关联：当关联的资源达到限流条件时，开启限流（适合于应用的让步）

  • 链路：当某个接口过来的资源达到限流条件时，开启限流 

    1
    2
    3
    4
    5
    // 在方法上定义资源
    @SentinelResource("message")
    public String message(){
        return "message";
    }

    针对来源是针对上级微服务，而链路监控是针对上级接口，也就是说它的粒度更细

流控效果：当服务被流控，以什么样的效果去处理

  • 快速失败：直接失败，抛出异常，不做任何额外的处理
  • Warm Up：从开始阈值到最大 QPS 阈值会有一个缓冲阶段，一开始的阈值是最大 QPS 阈值的 1/3 ，然后慢慢增长，直到最大阈值，适用于将突然增大的流量转换为缓步增长的场景。
  • 排队等待：让请求以均匀的速度通过，单机阈值为每秒通过数量，其余的排队等待；它还会让设置一个超时时间，当请求超过超时时间还会处理，则会被丢弃。

降级规则

设置当满足什么条件时,对服务进行降级

  • 平均响应时间:当资源的平均响应时间超过阈值(以ms为单位)之后,资源进入准降级状态.如果接下来1s内持续进入5个请求,它们的RT都持续超过这个阈值,那么在接下的时间窗口(以s为单位,维持时间)之内,就会对这个方法进行服务降级.
  • 异常比例:当资源的每秒异常总数占通过量的比值超过阈值之后,资源进入降级状态,即在接下来的时间窗口(以s为单位)之内,对这个方法的调用都会自动的返回.异常比率的阈值范围时[0.0,1.0].

热点规则

热点参数流控规则是一种更细粒度的流控规则,它允许将规则具体到参数上,

代码示例

1
2
3
4
5
@RequestMapping("/order/message3")
@SentinelResource("message3")//必须添加此注解,否则热点规则不生效
public String message3(String name,Integer age){
    return name + age;
}

授权规则

根据调用来源来判断该次请求是否允许放行

  • 若配置白名单,则只有请求来源位于白名单内时才可通过
  • 若配置黑名单,则请求来源位于黑名单时不通过,其余的请求通过

来源判断: 实现接口 RequestOriginParser

系统规则（外界环境）

从应用级别的入口流量进行控制,从单台机器的总体Load、RT、入口QPS、CPU使用率和线程数五个维度监控应用数据，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量（进入应用的流量）生效。

  • Load（仅对 Linux/Unix-like 机器生效）：当系统load1超过阈值，且系统当前的并发线程数超过系统容量时，才会触发系统保护。系统容量由系统的maxQps * minRt计算得出。设定参考值一般是 CPU cores * 2.5.
  • RT：当单台机器上所有入口流量的平均RT达到阈值即触发系统保护，单位是毫秒。
  • 线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
  • 入口QPS：当单台机器上所有入口流量的QPS达到阈值即触发系统保护。
  • CPU使用率：当单台机器上所有入口流量的CPU使用率达到阈值即触发系统保护。

3.5、3.5 自定义异常返回

实现 UrlBlockHandler 类

从 BlockException 判断异常类型

3.6、3.6 @SentinelResource

可以指定出现异常时的处理策略。用于定义资源，并提供可选的异常处理和 fallback 配置项。

blockHandler 定义当资源内部发生了 BlockException 应该进入的方法（捕获的时 Sentinel 定义的异常）

fallback 定义当资源内部发生了 Throwable 应该进入的方法

3.7、3.7规则持久化

本地文件数据源会定时轮询文件的变更，读取规则。在应用本地直接修改文件来更新规则，也可以通 Sentinel 控制台推送规则。

首先 Sentinel 控制台通过 API 将规则推送至客户端并更新到内存中，接着注册的写数据源会将新的规则保存到本地的文件。

实现 InitFunc 类

3.8、3.8 Feign 整合 Sentinel

  1. 引入 sentinel 依赖

    1
    2
    3
    4
    <dependency>
    	<groupId>com.alibaba.cloud</groupId>
       <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
    </dependency>

  2. 在配置文件中开启 Feign 对 Sentinel的支持

    1
    2
    3
    feign:
    	sentinel:
    		enable: true

  3. 创建容错类，实现 ProductService 接口

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    //容错类要求必须实现被容错的接口，并为每个方法实现容错方案。
    @component
    @slfj4
    public class ProductServiceFallback implements ProductService{ 
        @Override
        public Product findByPid(Integer pid){
             //容错逻辑 
            Product product = new Product();
            product.setPid(-1);
            return product;
        }
    }

  4. 为被容器的接口指定容错类

    1
    2
    3
    4
    5
    6
    7
    8
    9
    //value用于指定调用nacos下哪个微服务
    //fallback用于指定容错类
    @FeignClient(value="service-product",
                 fallback=ProductServiceFallback.class,//二者选其一
                 fallbackFactory = ProductServiceFallbackFactory.class)
    public interface ProductService{
        @RequestMapping("/product/{pid}")//指定请求的URI部分
        product findByPid(@pathVariable Integer pid);
    }

  5. 从容器类中获取具体的错误，将容错类改写

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    @Service
    @slfj4
    //这是容错类，它要求我们要是实现一个FallbackFactory<要为哪个接口产生容错类>
    public class ProductServiceFallbackFactory implements FallbackFactory<ProductService>{ 
        @Override
        public ProductService create(Throwable throwable){//throwable 在 fegin 调用过程中产生的异常
            return new productService(){
                 @Override
        				public Product findByPid(Integer pid){
                 		//容错逻辑 
               		 	Product product = new Product();
                		product.setPid(-1);
                		return product;
        				}
            }
        }
    }

4、4. Gateway 服务网关

API 网关

系统的统一入口，它封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、路由转发等等。

4.1、4.1 Spring Cloud Gateway

旨在为微服务架构提供一种简单有效的统一的API路由管理方式。

不仅提供了统一的路由方式，并且基于 Filter 链的方式提供了网关的基本功能，例如：安全，监控和限流。

优点

  • 性能强劲
  • 功能强大：转发、监控、限流
  • 设计优雅，容易扩展

缺点

  • 其实现依赖Netty与WebFlux，不是传统的Servlet编程模型，学习成本高
  • 不能将其部署在tomcat、jetty等Servlet容器里，只能打成jar包 执行
  • 需要springboot 2.0及以上版本才支持

4.2、4.2 使用

  1. 新建一个微服务，引入依赖

    1
    2
    3
    4
    5
    <!--gateway网关-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>

  2. 创建主类

  3. 添加配置文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    spring:
    	cloud:
    		gateway:
    			routes: #路由数组[路由 就是指定当请求满足什么条件的时候转到哪个微服务，转发过程中还可以做一些手脚]
    			 - id: product_route #当前路由的标识，要求唯一
    				uri: http://localhost:8081 #请求要转发到的地址
    				order: 1 # 路由的优先级，数字越小级别越高
    				predicates: #断言（就是路由转发要满足的条件）
    				 	- path=/product-serv/** #当请求路径满足path指定的规则时，才进行路由转发
    				 	- Method=get # 当请求路径满足 Path 指定的规则时，此路由信息才会进行正常的转发
    				filters: # 过滤器，请求在传递过程中可以通过过滤器对其进行一定的修改
    					- StripPrefix=1 # 转发之前去掉一层路径
    localhost:7000/product-serv/product/1 转发之后 localhost:8081/product/1

与nacos结合

  1. 添加依赖
1
2
3
4
5
<!--nacos客户端-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

  1. 在主类上添加注解 @EnableDiscoveryClient

  2. 在配置文件上补充

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    spring:
    	cloud:
    		nacos:
    			discovery:
    				server-addr: 127.0.0.1:8848
    		gateway:
    			discovery:
    				locator:
    					enabled: true # 让gateway可以发现nacos中的微服务
    					# 上面 uri 可改写为 nacos 中的服务名称
    					uri: lb://service-product # lb指的是从nacos中按照名称获取微服务并遵循负载均衡策略

4.3、4.3 Gateway核心架构

路由（Route）是gateway中最基本的组件之一，表示一个具体的路由信息载体。

  • id，路由标识符。
  • uri，路由指向的目的地uri，即客户端请求最终被转发到的微服务。
  • order，用于多个 Route 之间的排序，数值越小排序越靠前，匹配优先级越高。
  • predicate，断言的作用是进行条件判断，只有断言都返回真，才会真正的执行路由。
  • filter，过滤器用于修改请求和响应信息。

执行过程

springgateway执行过程

断言

Predicate（断言，谓词）用于进行条件判断，只有断言都返回真，才会真正的执行路由。

就是说在 什么条件下 才能进行路由转发

  • 内置路由断言工厂

    • 基于 Datetime 类型的断言工厂
    • 基于远程地址的断言工厂
    • 基于 Cookie 的断言工厂
    • 基于 Header 的断言工厂
    • 基于 Host 的断言工厂
    • 基于 Method 请求方法的断言工厂
    • 基于 Path 请求路径的断言
    • 基于 Query 请求参数的断言工厂
    • 基于路由权重的断言工厂

  • 自定义路由工厂

    1. 在配置文件中添加一个 Age 的断言配置

    2. 自定义一个断言工厂，实现断言方法

      1
      2
      3
      4
      5
      //继承 AbstractRoutePredicateFactory<AgeRoutePredicateFactory.Config>
      //构造方法中调用父类的构造方法
      //shortcutFieldOrder方法 读取配置文件中的参数值 给他赋值到配置类中的属性上
      //apply方法 断言逻辑
      //Config 配置类，用于接收配置文件中的对应参数

过滤器

  1. 作用:过滤器就是在请求的传递过程中,对请求和响应做一些手脚

  2. 生命周期:Pre Post

  3. 分类:局部过滤器 和 全局过滤器

    在 Gateway中,Filter的生命周期只有两个: Pre 和 Post

    • Pre:在请求被路由之前调用,可以实现身份验证,在集群中选择请求的微服务,记录调试信息
    • POST:在路由到微服务之后执行,

5、RocketMQ 事件驱动

替换 springcloud 中的 bus 组件，实现消息总线

6、Message Bus 消息总线（异步处理）

7、Seata

实现 Distributed Transaction 分布式事务

8、Dubbo RPC

集成 Dubbo 实现服务间通信，替换原始项目中 RestTemplate Openfeign。缺点是 都必须使用 java 语言。

  • Copyrights © 2022-2023 hqz

请我喝杯咖啡吧~

支付宝
微信