• 第08篇_SpringCloud_Netflix

    第01章_微服务入门

    第一节 系统架构演变

    1. 传统的单体架构

    单体架构指将一个应用的全部功能都整合在一起,以减少部署节点和成本,对于小型应用来说非常适用。缺点是其不同模块间代码高度耦合,也无法进行水平扩展。

     

     

    2. 垂直应用架构

    当传统的单体架构无法满足日益增长的业务需求时,于是将应用按照不同的模块进行拆分,实现流量分担,并支持对不同的模块进行优化和水平扩展。缺点是系统间相互独立,会有很多的重复开发工作,影响开发效率。

     

     

    3. 分布式架构

    当垂直应用越来越多,应用之间交互不可避免,将核心业务或基础业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使应用能更快速的响应多变的市场需求。缺点是系统间耦合度变高,调用关系错综复杂,难以维护。

     

     

    4. 面向服务的架构(SOA)

    在分布式架构下,当部署的服务越来越多,需要增加一个统一的调度中心来对集群进行实时管理。此时,系统就会演变为面向服务的架构(SOA)。缺点是服务间关系复杂,相互依赖,一旦某个环节出错可能造成服务雪崩,而且运维、测试部署困难,不符合DevOps思想。

     

     

    5. 微服务架构

    微服务一词源于Martin Fowler的博文Microservices。简单地说,微服务是系统架构上的一种设计风格,它的主旨是将一个原本独立的系统拆分为多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建,并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立的部署机制。由于有了轻量级的通信协作基础,所以这些微服务可以使用不同的语言来编写。

     

     

     

    第二节 微服务技术选型

    1. SpringCloud简介

    微服务是一种架构设计思想,需要具体的技术进行落地。SpringColud是一个分布式微服务架构的一站式解决方案,是多种微服务架构技术落地的集合体,俗称微服务全家桶。

    1525575656796

     

     

    2. 新的微服务组件

    随着技术的不断迭代,出现了一些更优秀的微服务组件,将会在后续的章节中进行介绍。

    image-20220507151345144

     

     

    3. 版本选择

    打开SpringCloud官方文档,选择最新的一个稳定版本。

    image-20220507151850513

    然后点击Reference Doc,查看推荐的SpringBoot版本。

    image-20220507151930202

     

     

    第三节 微服务父工程搭建(聚合工程)

    1. 创建Maven工程

    image-20220507152847284

    image-20220507153007274

    image-20220507153115987

     

    2. 选择Maven版本

    image-20220507153228259

     

     

    3. 设置字符编码

    image-20220507153434089

     

    4. 开启注解处理器

    image-20220507153731962

     

    5. 选择编译版本

    image-20220507153903769

     

     

    6. POM文件配置

     

    7. 安装到本地仓库

    image-20220507155646223

     

    8. 注意事项

     

     

    第四节 业务工程搭建

    1. 通用模块搭建

    通用模块提供多个微服务共用的实体、工具和一些基础功能等。

     

    1) 新建SpringCloud-common模块

     

     

    2) 修改pom.xml文件

     

    3) 编写实体类

     

     

    4) 安装到本地仓库

     

    5) SQL脚本

     

     

    2. 服务提供者-支付服务搭建

    1) 新建SpringCloud-service-pay模块

     

    2) 修改pom.xml文件

     

    3) 配置application.yml

     

    4) 编写启动类PayApplication

     

    5) DAO层

     

     

    6) Mapper文件

    注意:Mapper文件必须放在mybatis.mapperLocations属性配置的路径下,默认值为Mapper接口的同级目录。

     

    8) Service层

     

     

    9) Controller层

     

    10) 测试支付服务

    启动支付微服务,点击http://localhost:8100/payment/get/1进行测试!

    image-20220513112755897

     

     

    3. 服务消费者-订单服务搭建

    1) 新建SpringCloud-service-order模块

     

    2) 修改pom.xml文件

     

    3) 配置application.yml

     

    4) 编写启动类OrderApplication

     

    5) 配置RestTemplate

     

    6) Controller层调支付

     

    7) 测试订单调支付

    启动支付和订单微服务,访问http://127.0.0.1:8200进行测试!

     

    image-20220513114044263

     

     

    4. 补充说明

    1) 开启Run DashBoard

    默认情况下,IDEA会在你启动多个微服务时自动打开Run DashBoard面板,也可以修改.idea/workspace.xml手动打开。

    image-20220513133004644

     

    2) 开启热部署

     

    image-20220513132839524

     

    image-20220513132906038

    image-20220513132914860

     

    3) mysql驱动说明

     

     

    第02章_服务注册发现

    服务治理指的对服务生命周期中一系列操作进行统筹管理,包括服务注册服务发现服务监测服务下线`服务之间的调用负载均衡等,是一种分布式架构的解决方案。

     

    第一节 Eureka

    1. Eureka简介

    Eureka是SpringCloud封装的一款服务治理组件,其采用了CS的设计架构,分为服务端(Eureka Server)客户端(Eureka Client),系统架构图如下:

    image-20220512203824504

    图中Eureka Server是服务治理中心,集中管理所有的微服务。服务提供者使用Eureka Client向Eureka Server注册服务并维持心跳,而服务消费者使用Eureka Client向Eureka Server拉取服务地址,随后进行远程调用。

     

     

    2. 搭建Eureka Server

    1) 新建SpringCloud-eureka-server模块

    image-20220512194924461

     

    2) 引入Eureka-Server启动器及其它依赖

    注意:老版本Eureka服务端和客户端使用同一个启动器,如下。

     

    3) 配置application.yml

     

    4) 编写启动程序EurekaServer.java

     

    5) 访问http://localhost:1000进行测试

    image-20220513134129013

     

     

    3. 使用Eureka Client注册微服务

    1) 改造支付服务,添加Eureka Client启动器

    注意:老版本Eureka服务端和客户端使用同一个启动器,如下。

     

    2) 修改application.yml,添加Eureka Cilent相关配置

     

    3) 修改启动类添加@EnableEurekaClient注解

     

    4) 依次启动EurekaServer、支付服务进行测试

    image-20220513134403297

     

     

    4. 使用Eureka Client拉取微服务

    1) 改造订单服务,添加Eureka Client启动器

     

    2) 修改application.yml,添加Eureka Cilent相关配置

     

    3) 修改启动类添加@EnableEurekaClient注解

     

    4) 依次启动EurekaServer、支付、订单服务进行测试

    image-20220513135551804

     

    image-20220512203501231

     

     

    5. Eureka集群

    为了防止Eureka产生单点故障,故将Eureka部署为集群,互相注册,相互守望,具备可用性。

     

    1) 配置多个Eureka Server形成集群

    复制2份单机版Eureka Server的application.yml配置文件,分别命名为application-cluster01.ymlapplication-cluster02.yml。修改server.port为特定的端口,instance.hostname为特定实例名称,client.service-url.defaultZone指向其它实例列表,以逗号分隔。

     

     

     

    2) 注册业务服务到Eureka集群

    分别复制一份支付和订单的application.yml配置文件,命名为application-eurekacluster.yml。修改client.service-url.defaultZone指向集群中的所有Eureka Server,以逗号分隔。

     

     

     

    3) 依次启动Eureka Server集群、支付、订单服务进行测试

    复制单机版的启动配置,修改Program arguments,添加--spring.profiles.include=Xxxx激活对应的配置进行启动。如启动1001端口的Eureka Server,复制启动配置如下:

    image-20220513144051925

     

    image-20220513144231915

     

    image-20220513144255229

     

     

     

    6. 服务提供者-支付服务集群

    同样的,为了解决服务提供者的单点故障问题,也需要部署集群。

     

    1) 配置多个支付服务形成集群

    复制2份单机版支付服务的application.yml文件,分别命名为application-cluster01.ymlapplication-cluster02.yml。修改server.port为特定的端口,添加eureka.instance.instance-id指定实例名称,配置eureka.instance.prefer-ip-address为true访问IP地址。

     

     

     

    2) 订单通过支付服务名调用集群

    之前订单调支付的PaymentSrv_URL是写死为http://127.0.0.1:8100的,如果8100端口宕机,则会造成单点故障。现在支付服务在8101和8102端口部署了集群,应使用服务名称来进行调用,并且进行负载均衡(默认为轮询)。

     

     

     

    3) 测试订单调用支付集群

    image-20220513152831879

     

    image-20220513152859488

    image-20220513152911878

     

     

    7. Eureka补充

    1) 服务发现Discovery

    对于注册进eureka里面的微服务,可以通过服务发现来获得该服务的信息。

     

     

     

    image-20220513154510372

    image-20220513154636640

     

    2) Eureka保护模式

    在学习过程中,经常在Eureka界面看到如下红色提示,说明Eureka进入了保护模式,将不会注销任何服务。

    image-20220513155203265

    因为在发生网络故障(延时、卡顿、拥挤)时,Eureka Server可能在一定时间内(90s)没有收到某个微服务实例的心跳,但此时这个微服务是健康的,不能注销。Eureka Server为解决该问题,检测当短时间内丢失过多的客户端时,将启动保护模式,不进行任何服务注销。

    使用eureka.server.enable-self-preservation=false可以关闭Eureka Server的保护模式。或者使用如下参数来调整Eureka Client的心跳间隔和超时等待时间。

     

     

     

    第二节 Zookeeper

    1. Zookeeper简介

    zookeeper是一个分布式协调工具,可以实现注册中心等功能,详细介绍请参考《ZooKpeer学习笔记(基础篇).md》。

     

     

    2. 服务提供者向ZK注册

    1) 新建服务提供者模块SpringCloud-zookeeper-provider

     

    2) 引入zookeeper及相关依赖

     

    3) 配置application.yml

     

    4) 编写启动类

     

    5) 编写Controller

     

    6) 测试

    image-20220516134538878

     

    image-20220516134620921

     

     

    3. 服务消费者向ZK注册

    1) 新建服务消费者模块SpringCloud-zookeeper-consumer

     

    2) 引入zookeeper及相关依赖

     

    3) 配置application.yml

     

    4) 编写启动类

     

    5) 编写配置类

     

    6) 编写Controller

     

    6) 测试

    image-20220516135242307

     

    image-20220516135136301

     

     

    4. 注意事项

    1) 关闭防火墙

     

    2) 排除冲突Jar包

    如果Zookeeper的Jar包出现冲突或与ZK服务器版本不匹配,可使用下面配置进行更换。

     

     

     

    第三节 Consul

    1. Consul简介

    Consul 是一套开源的分布式服务发现和配置管理系统,由HashiCorp公司用Go语言开发,提供了微服务架构中的服务治理配置中心控制总线等功能。

    img

     

     

    2.服务提供者向Consul注册

    1) 新建服务提供者模块SpringCloud-cosnul-provider

     

    2) 引入Cosnul及相关依赖

     

    3) 配置application.yml

     

    4) 编写启动类

     

    5) 编写Controller

     

    6) 测试

    image-20220517175422545

     

    image-20220517175506170

     

     

    3. 服务消费者向Consul注册

    1) 新建服务消费者模块SpringCloud-consul-consumer

     

    2) 引入Consul及相关依赖

     

    3) 配置application.yml

     

    4) 编写启动类

     

    5) 编写配置类

     

    6) 编写Controller

     

    6) 测试

    image-20220517175638917

     

    image-20220517175721361

     

     

    4. 补充说明

    1) 部署说明

    首先从Consul官网(https://www.consul.io/downloads.html)下载匹配的版本,再使用下面命令进行启动。

     

    2) 参考资料

     

     

    第03章_服务负载均衡

    第一节 Ribbon

    1. Ribbon简介

    Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡工具,引入Ribbon后的系统架构图如下:

    image-20220523161351286

    服务消费者(客户端)集成Ribbon,从注册中心查询可用服务列表,然后根据特定的路由算法选择其中一个服务实例进行调用。

     

     

    2. 客户端负载均衡

    1) 客户端导入Ribbon依赖

    注意:某些注册中心客户端(如spring-cloud-starter-netflix-eureka-client)自带了Ribbon依赖,可省略该步骤。

     

    2) 修改服务URL为服务名

     

    3) 添加@LoadBalanced进行负载均衡

     

    4) 使用RestTemplate进行调用

     

    5) 测试

    依次启动Eureka、支付集群、订单服务进行测试,发现进行轮询调用。

    image-20220523180534659

    image-20220523180546717

     

     

    3. 负载均衡算法

    1) 内置负载均衡算法

    Ribbon内置了一些常见的负载均衡算法,如下:

    LB算法实现类说明
    轮询RoundRobinRule默认算法,轮询可用服务列表进行调用
    随机RandomRule从可用服务列表中随机调用
    重试RetryRule 
    最低并发BestAvailableRule 
    可用过滤AvailabilityFilteringRule 
    响应时间加权WeightedResponseTimeRule 
    区域权衡ZoneAvoidanceRule 

     

    2) 通过属性修改负载均衡算法

     

    3) 通过Java配置修改负载均衡算法

    首先定义规则配置类如下:

    注意:

    1. 请勿将RibbonRule放置在包扫描路径下,如果被注册到容器中,将会替换掉默认的负载均衡算法。

    2. 通过@RibbonClients可以显式的指定默认负载均衡算法,初始值为轮询。

     

    然后在启动类使用@RibbonClient对指定的服务进行配置:

     

    4) 自定义负载均衡算法

    先继承AbstractLoadBalancerRule抽象类或实现IRule接口,算法实现可参考RandomRule等内置实现,再使用上述方式进行配置。

     

    第04章_服务远程调用

    第一节 openFeign

    1. openFeign简介

    openFeign是一个声明式WebService客户端,使用接口+注解的形式声明外部REST服务,使远程调用变得更加简单。

     

     

    2. 声明式服务调用

    1) 客户端添加openFeign依赖

     

    2) 启动类开启openFeign支持

     

    3) 声明RPC客户端及接口(@FeignClient)

     

    4) 使用RPC客户端调用远程服务接口

     

    5) 测试

    依次开启注册中心、支付服务集群和订单微服务,前端直接调订单服务,订单服务再通过openFeign调支付服务集群,并支持负载均衡。

    image-20220523232707221

    image-20220523232729427

     

     

    3. openFeign的相关配置

    1) 超时时间配置

     

    2) 调用日志配置

    首先通过Java配置openFeign的日志级别:

    openFeign支持的日志级别如下:

    • NONE:默认的,不显示任何日志;

    • BASIC:仅记录请求方法、URL、响应状态码及执行时间;

    • HEADERS:除了 BASIC 中定义的信息之外,还有请求和响应的头信息;

    • FULL:除了 HEADERS 中定义的信息之外,还有请求和响应的正文及元数据。

     

    然后在属性配置文件中指定对应类的日志级别:

     

    当发生远程调用时,可看到类似如下的日志信息:

     

     

    第05章_服务熔断降级

    第一节 Hystrix

    1. Hystrix简介

    Hystrix是一个处理分布式系统超时容错的开源库,用于保证一些服务出现异常时,不会导致整体服务出现级联故障(雪崩),以提高分布式系统的弹性。

    Hystrix处理非正常服务时有三种方案,分别是服务降级、服务熔断、服务限流:

     

     

    2. 服务端降级

    1) 添加hystrix依赖

    注意:某些注册中心客户端(如spring-cloud-starter-netflix-eureka-client)自带了Hystrix依赖,可省略该步骤。

     

    2) 开启Hystrix支持

     

    3) 配置方法支持降级

     

    4) 测试超时导致降级

    在方法中添加延时来模拟业务耗时,当延时时间大于设置的超时时间,将会触发降级处理。

    依次开启Eureka、支付服务,访问http://localhost:8100/payment/get/1进行测试:

    image-20220525151715411

     

    5) 测试异常导致降级

    在方法中添加一个异常来模拟业务异常,当异常抛出时,也会触发降级处理。

    依次开启Eureka、支付服务,访问http://localhost:8100/payment/get/1进行测试:

     

    6) @DefaultProperties注解补充

    @DefaultProperties注解可以在类上为需要降级的方法配置一些默认属性,以减少重复的降级配置。

     

     

    3. 客户端降级(结合openFeign)

    1) 添加Hystrix依赖

    注意:某些注册中心客户端(如spring-cloud-starter-netflix-eureka-client)自带了Hystrix依赖,可省略该步骤。

     

    2) 开启Hystrix支持

    注意: @EnableHystrix 是@EnableCircuitBreaker的组合注解。

     

    3) 打开openFeign的降级开关

     

    4) 针对FeignClient编写降级逻辑

     

    5) 配置FeignClient的降级处理类

     

    6) 测试服务端异常导致降级(超时、异常、宕机等)

    依次打开Eureka注册中心、支付服务、订单服务,先测试正常情形OK;随后关闭支付服务,测试服务端宕机情形,发现客户端调用时正确降级处理:localhost:8200/consumer/feign/payment/get/1

    img

     

     

    4. 服务熔断

    1) 熔断机制简介

    熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。当检测到该节点微服务调用响应正常后,再逐步恢复调用链路。其设计思想如下图所示,具体内容可参考https://martinfowler.com/bliki/CircuitBreaker.html

    img

    初始情况下,断路器处于关闭(closed)状态。当某一时间窗口请求次数失败率都达到阈值时,触发熔断,进入开启(open)状态,此后的所有请求直接进入降级逻辑,以减少响应时间。

    当熔断时间达到设置的阈值时,将会进入半开(half open)状态,释放少量的请求执行主逻辑,如果请求成功,则关闭断路器,恢复服务的正常访问,否则重置熔断时间,重新进入开启状态。

     

    2) 配置Hystrix熔断相关属性

    更详细的熔断属性配置可参考如下示例或官方文档:

     

    3) 测试熔断效果

    先访问http://localhost:8100/payment/get/1测试正常情形OK后,然后在10s内发起至少20次请求,并且失败率为50%以上(http://localhost:8100/payment/get/0);再次访问正常情形,发现已被熔断,等待一会后,断路器自动转为半开(全开)状态,正常情形又可访问。

    黄原鑫 6-14 14:52:11 img

    黄原鑫 6-14 14:52:23 img

     

     

    5. HystrixDashBoard

    1) 新建SpringCloud-hystrix-dashboard模块

     

    2) 引入HystrixDashBoard及相关依赖

     

    3) 配置application.yml

     

    4) 编写启动类

     

    5) 测试监控服务

    依次打开注册中心和支付服务,并对配置了服务降级的方法进行一些调用操作,然后打开Hystrix监控面板http://localhost:1101/hystrix,输入监控端点进行监控:

    image-20220614174327675

     

    下面是监控面板示例及相关说明:

    image-20220614174353051

     

     

    第06章_服务配置中心

    第一节 Config

    1. Config简介

    SpringCloud Config为多个微服务提供了集中化的外部配置支持,其部署架构图如下所示:

    img

    其中Config Server称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器(git/svn/本地),并为客户端提供配置信息以及加密和解密服务等。

    Config Client则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息。

     

    2. Config Server

    1) 新建SpringCloud-config-server模块

     

    2) 引入Config Server及相关依赖

     

    3) 编写启动类

     

    4) 从git拉取配置

     

    5) 测试

    首先在配置的Git仓库中准备一个master分支和slave分支,分别包含两个application-dev.yml和application-test.yml文件,然后依次启动注册中心和配置中心进行测试:

    img

     

    img

     

    6) 从本地拉取配置

     

    3. Config Client

    1) 支付服务添加Config Client依赖

     

    2) 配置bootstrap.yml文件

     

    3) 使用远程配置

     

    4) 测试

    访问http://localhost:8100/info/get获取远程配置信息:

    img

     

     

    4. 配置刷新

    经过如上配置,客户端可以在启动的时候从配置中心获取最新配置,但如果配置发生了修改,在不重启的情形下是无法实时生效的。下面方法可让配置实时生效:

     

    1) 支付服务引入actuator依赖

     

    2) 暴露监控端点

     

    3) 配置刷新注解

     

    4) 刷新配置实时生效

    修改Git仓库上的配置文件,Config Server会自动拉取,然后发送给各Client,使用如下命令即可刷新配置实时生效。

    img

     

     

    第07章_服务消息总线

    第一节 Bus

    1. Bus简介

    Spring Cloud Bus通过轻量级消息系统,将多个微服务链接起来,用于广播状态更改或其他管理指令(例如实现分布式配置的动态刷新),因此也被称为消息总线

    img

    提示:我们通常会使用消息中间件(RabbitMQ/Kafka)来构建一个主题,然后将微服务连接到这个主题上去,当我们向该主题发送消息时,所有订阅该主题的服务都会收到消息然后进行消费。

     

     

    2. 分布式配置的动态刷新

    1) 添加Bus依赖

    注意:配置中心服务端和客户端都需要添加该依赖,并且进行下面的消息中间件和端点配置。

     

    2) 配置消息中间件

    提示:RabbitMQ安装可参考:https://blog.csdn.net/lxw1844912514/article/details/122738713

     

    3) 暴露Bus刷新端点

     

    4) 测试动态刷新

    依次启动注册中心、配置中心和支付服务,修改Git上的配置文件,然后在配置中心服务端进行配置刷新(curl -X POST "http://127.0.0.1:1310/actuator/bus-refresh"),再测试支付服务(http://localhost:8100/info/get),发现也一起刷新了。

    img

    观察RabbitMQ(http://localhost:15672/),发现自动创建了一个主题,默认为SpringCloudBus。

    image-20220620172845016

    提示:如果只想刷新某一个微服务,可指定服务名和端口,如curl -X POST "http://127.0.0.1:1310/actuator/bus-refresh/cloud-payment-service:8100"。

    第08章_服务请求网关

    第一节 Zuul

    1. Zuul简介

    Zuul是Netflix公司开源的一款API网关产品,其将业务系统内部多个微服务进行封装,对外提供唯一的访问入口,实现系统内高内聚,系统间通过网关交互达到低耦合的效果。它可以和Eureka、Ribbon、Hystrix等组件配合使用,实现身份认证与安全、审查与监控、动态路由、压力测试、负载均衡、流量控制等功能。

    img

     

     

    2. 基本路由配置

    1) 新建SpringCloud-zuul-server模块

     

    2) 引入Zuul及相关依赖

     

    3) 配置application.yml

     

    4) 编写启动类

     

    5) 测试通过网关进行访问

    首先通过原访问地址http://localhost:8100/payment/get/1测试访问正常后,再拼接服务名前缀,通过网关进行访问:http://localhost:1210/cloud-payment-service/payment/get/1

    image-20220614194151896

     

     

    3. 路由映射规则

    1) 修改路由映射规则

     

    2) 测试路由映射

    img

     

    img

     

     

    4. Zuul过滤器

    1) 过滤器简介

    Zuul过滤器负责对请求过程进行额外的处理,是请求校验过滤及服务聚合的基础。其生命周期图解如下:

    在这里插入图片描述

    Zuul中定义了4种标准过滤器类型,这些过滤器类型对应于请求的典型生命周期:

    前置过滤器(PRE):在请求被路由之前调用。可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。 路由过滤器(ROUTING):在进行路由请求时调用。用于构建发送给微服务的请求,并使用Apache HttpClient或Netflix Ribbon请求微服务。 后置过滤器(POST):在请求被路由之后调用。用于为响应添加额外的响应头、收集统计信息和指标、将响应从微服务发送给客户端等。 错误过滤器(ERROR):在其他阶段发生错误时执行该过滤器。

    除了默认的过滤器类型,Zuul还允许创建自定义的过滤器类型。例如,可以定制一种 STATIC 类型的过滤器,直接在Zuul中生成响应,而不将请求转发到后端的微服务。

     

     

    2) 前置过滤器打印日志案例

    通过网关访问被代理的服务localhost:1210/api/zuul-pay/payment/get/1,发现控制台打印日志如下:

     

     

     

    第二节 Gateway

    1. Gateway简介

    Gateway是Spring官方基于Spring 5.0、Spring Boot 2.0和Project Reactor等技术开发的新一代API网关产品,旨在为微服务架构提供一种简单而有效的统一的API路由管理方式,并且基于Filter链的方式提供网关基本的功能,例如:安全、监控、埋点和限流等。

    Gateway由三大部分组成,分别是路由(Route)、断言(Predicate)和过滤器(Filter):

     

     

    2. 基本路由配置

    1) 新建SpringCloud-gateway-server模块

     

    2) 引入Gateway及相关依赖

     

    3) 配置application.yml

     

    4) 编写启动类

     

    5) 测试通过网关进行访问

    依次启动注册中心、支付服务集群、Gateway网关,先通过http://localhost:8101/payment/get/1http://localhost:8102/payment/get/1测试支付服务集群正常访问后,再通过网关进行访问:http://localhost:1220/payment/get/1,预期访问正常,并且默认进行轮询访问。

    img

     

    6) Java代码配置路由

    路由规则也可通过Java代码进行配置,示例如下:

     

     

    3. 路由断言

    Gateway支持多种不同类型的路由断言,除上述用到的Path外,常用的还有After、Cookie、Query类型等,它们之间通过"逻辑与"组合,实现各种精细的路由匹配规则。

     

    1) 路径断言(Path)

     

    2) 请求信息断言(Cookie、Header、Host、RemoteAddr、Method)

     

    3) 请求参数断言(Query)

     

    4) 时间断言(After/Before/Between)

    提示:时间格式可通过打印ZonedDateTime.now()获得。

     

    5) 权重断言(Weight)

     

    6) 综合案例

     

     

    4. 路由过滤器

    1) 内置过滤器

    路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应,Gateway有两种类型的路由过滤器,分别是GatewayFilter(作用于单个路由)和GlobalFilter(作用于全部路由),可以在路由之前执行(pre)或路由之后执行(post)。如下为一个GatewayFilter使用示例:

     

    2) 自定义过滤器

    除了Gateway内置的过滤器,你也可以定义自己的全局过滤器,如下:

    依次启动注册中心,支付服务、Gateway网关,通过网关进行支付服务访问,如果请求参数不存在userName,将返回406错误。

    http://localhost:1220/payment/get/1?userName=zhangsan

    img

    http://localhost:1220/payment/get/1

    image-20220617102020559

     

    第09章_服务链路追踪

    第一节 Sleuth

    Spring Cloud Sleuth 提供了一套完整的分布式链路追踪解决方案,并且支持Zipkin进行图形化展示。

     

    1. 安装Zipkin

    访问Github(https://github.com/openzipkin/zipkin)下载Zipkin的最新稳定版本,然后通过java -jar zipkin-server-2.23.16-exec.jar启动。

    img

    启动完成后,访问http://localhost:9411/zipkin/进入监控界面。

    img

     

    2. 支持链路追踪

    1) 引入Zipkin及相关依赖

    注意: 所有需要支持链路追踪的服务都需要引入该依赖及进行下面链路追踪配置。

     

    2) 链路追踪配置

     

    3) 测试链路追踪效果

    依次启动注册中心、支付服务、订单服务,先调用订单、支付服务的一些接口(http://localhost:8100/payment/get/1, http://localhost:8200/consumer/payment/get/1),然后打开Zipkin(http://localhost:9411/zipkin/)查看调用追踪信息。

    img

    img

     

     

    3. 调用链路图

    下面是一次链路追踪图解,其中Trace id作为链路的唯一标识,Span id标识链路中的某个调用节点,各Span id通过Parent id进行关联。

    img