【Day02】Spring Cloud组件的使用--Nacos配置中心、sentinel流量控制、服务网关Gateway、RocketMQ、服务调用链路(Sleuth、zipkin)
阅读原文时间:2023年07月08日阅读:1

今日内容

一、配置中心

1、遗留问题

yml配置,每一次都需要重启项目

需要不重启项目拿到更新的结果

引出:配置中心

选择:Spring Cloud Config组件 / Alibaba的Nacos(注册中心、配置中心)

使用:Nacos可以同时当配置中心和注册中心

查看 :默认8848端口,可以查看配置中心和注册中心内容

2、实际创建

创建配置可以填写yml名称和内容

3、代码使用新的配置

步骤:

(1)导入依赖--之前的是discovery,现在使用config包

(2)配置:当前项目的Nacos作为配置中心所在的地址

通常创建配置文件内部

(6)写注解

引入让配置生效的依赖

写注解:加载想要使用外部配置文件的类上使用@RefreshScope注解

4、测试

就能够拿到配置的username:jack

5、实现功能

无需重启项目就能对配置文件进行更改

同时可以对配置文件进行多次修改

二、sentinel流量控制

1、遗留问题

大量访问接口的qps,会根据机器占用资源决定

需要对接口的流量进行控制(可以只让某个接口一个单位访问1000次)

解决方式:

  • 定义private int count = 0;被多个线程共享,就可以进行累加
  • 根据系统时间的计算,进行判断
  • 超过阈值,给客户端返回错误信息

原因:负载过大系统宕机,从而会影响上层服务(引起雪崩效应--影响上游服务)

下游服务不可用,级联影响上游服务

解决【有对应组件对其进行实现】:

  • 上述代码进行限流-避免服务不挂掉
  • 也可以降级--服务不可用,或希望其不可用,则调整其优先级

2、以Sentinel举例

Sentinel-server需要知道哪些服务要进行限流/降级

需要对其进行部署(jar包或源码)

当前目录输入cmd

查看启动日志,可以看到,默认绑定在8080端口

sentinel-sentinel

需要先把需要被保护的服务接口信息上报到sentinel

3、步骤

(1)指定服务下引入依赖

无需引入版本

(2)写配置

在yml文件中

告诉项目,sentinel-server的位置

默认不用配置用户名密码

也可以自定义指定认证信息,如Nacos

(3)不需要写注解

4、查看

实际上还没有,所以会有懒加载机制

一下子写入对sentinel-server压力大

只有访问了该资源,才会把接口信息写入sentinel-server

从而对其进行流量控制

可以捕获错误信息,返回页面给用户【sentinel的github上面】

4、监控

5、配置

降级后,不再提供服务,可以指定时间,或异常数

对集群部署,也可以对热点规则

6、总结

服务指定sentinel,进行懒加载方式进行流量控制

三、使用MQ进行流量削峰,缓存消息,解决并发量大的问题

1、存在问题

订单服务中的creteOrder()使用OpenFeign的方式调用微服务时

如调用count-Service服务,调用余额deduct

调用pay-service#payMethod()

调用扣减库存stroge-service#deduceKucun()

调用物流服务……

创建订单调用许多服务

例如余额挂掉

不用立即减少余额,可以等恢复时再减少余额

解决:消息发到MQ,对应用解耦,降低容错性【发到消息中间件,不用写到一个方法中】

将同步调用变为异步调用,使用MQ完成解耦逻辑

流量削峰:某个服务(userservice并发量大时),超过qps值,可以使用sentinel进行限流(提示客户端返回错误信息)

现在:使用MQ,qps=5000超过服务的1000,剩下4000对用户体验不好

请求不需要 落在userservice,从MQ中消费消息

进入5000qps,出来1000qps,让用户等待

其他应用场景:数据分发

2、选型

阿里RocketMQ【火箭】、RabbitMQ【兔子,提升性能】、K‘afka咖负咖、Pulsar、ActiveMQ【积极的】等

开发语言:Java、erlang、Scala……

功能扩展性等不同维度,适用场景不同

选择:RocketMQ

使用:观察者模式

3、搭建架构

4、过程及步骤Apache RocketMQ

(1)搭建server--集群式部署

(2)启动nameserver及broker

broker用于接收消息和处理消息

nameserver理解为RocketMQ的注册中心

先启动注册中心nameserver,后启动broker【绑定ip和端口,自动创建主题】

4、使用maven启动dashboard项目

查看默认主题

可以自己创建主题,选择生产者

5、使用过程--原生的api

(1)引入依赖

(2)使用demo测试--ProducerGroup

broker注册到nameserver上

异步生产消息、消费消息……操作

6、具体举例

user-service作为生产者,order作为消费者

(1)导入依赖,可以指定版本

(2)写配置

指定nameserver,和注册中心打交道

在user-service生产者中配置

(3)写注解--无

上述是针对producer

(4)编写接口发送消息

自动装配RocketMQTemplate

spring boot对其进行了封装

指定主题,指定发消息的内容

最终源码是对原生api的封装,即

访问时发送消息

7、消费者

(1)导入依赖

(2)写配置

(3) 写注解

获取感兴趣的消息

(4)测试生产消费

8、总结

优点:解耦、流量削峰

问题:

引入中间件,如果MQ挂掉,两个服务无法直接通信;

使用中间件交互,复杂度高;

需要考虑重复消息,和消息是否丢失

四、网关

1、存在问题

微服务架构可以实现异步通信

不同服务的入口,无需暴露给客户端

解决:网关作为前置组件,做路由的转发,转发到后置服务-相当于Nginx的功能,更适用于java环境

功能:实现路由

2、选型--GateWay

zuul:BIO同步阻塞

gateway:nio--同步非阻塞IO,适用于并发量比较高的场景

可以实现具体路由的转发

3、使用GateWay

(1)创建一个单独的工程module

并将依赖的版本与之前保持一致(gateway默认版本比较新)

特性:

支持服务的注册发现

可以根据名称拿到URL地址

需要在网关中整合Nacos的依赖

(2)配置

修改为yml文件

配置应用在注册中心的名字

配置网关服务发现的能力Gateway-enable

(3)使用

定位网关、服务发现

有了服务发现的能力,就可以实现路由转发

Netty监听到了端口

(4)自定义路由规则

使用谓词和过滤器完成操作

指定路由匹配的条件Predicts和Filters、uri

4、其他功能

可以实现熔断、限流、路径重写、用户认证 、授权操作

五、链路追踪

1、存在问题

访问了一个链接,访问了多个服务

即:记录微服务的调用关系,以便后面对问题进行排查

方案:基于日志记录的思想,使用组件记录日志,或使用AOP切面自定义记录日志

使用Spring Cloud Sleuth组件,进行日志记录

查看日志记录的结果,使用zebkin进行图形化展示

2、介绍

zebkin-server进行图形化展示

(1)整合:在需要记录日志的服务里面导入zebkin依赖,自动导入Sleuth组件

(2)启动java -jar zebkin

默认9411端口

(3)写配置

配置zebkin的位置

将sleuth的采样概率改为100%(默认10%)

3、测试

重启项目:my-gateway、userservice、order-service

可以通过链路追踪到错误

4、其他选型

zebkin+sleuth

SkyWalking-功能强大,自动生成可视化图表(Apache,国人使用Java开发的)

可以搜索skywalking【支持ES、MySQL等】和sleuth的对比

六、事务管理-SEATA

1、其他问题

RPC/rest api调用时,需要保证事务性

方式:在当前类上添加@Transactional注解

源码底层会根据注解得到动态代理类,并根据createOrder进行增强,使用AOP对事务进行管理

分布式环境:该注解失效,会生成动态代理实现类,但问题在于三个服务使用的不是同一个数据源

管理事务的前提:基于同一个connection

分布式事务的管理:参考Seata架构

2、Seata的介绍

数据库事务-JDBC事务-Spring事务-分布式事务

明天讲原理,后天讲容器化内容

今日内容总结

今天主要学到的组件和功能,包括配置中心(Nacos、Config),流量控制(sentinel),服务网关(GateWay、zuul),消息中间件(RocketMQ)、服务调用链路(zipkin+sleuth)、分布式事务(seata)
1、对于配置中心主要有Config组件和阿里巴巴的Nacos组件
而Nacos可以充当配置中心和注册中心,所以使用了Nacos作为配置中心,默认端口是8848
配置中心主要实现不需要重启项目,就能够对配置文件进行修改

2、对于多个访问接口的资源占用,可以对接口进行流量控制,可以对服务进行一个限流或者降级,但是使用自定义变量的方式进行判断的话,可能会影响上层服务
因此使用了sentinel使用了懒加载的方式进行了流量控制,通过其图形化界面,可以实现流量控制规则的定义,降级的规则,热点的规则和授权的规则、熔断、降级等功能,此外,还可以对服务的访问量进行qps的监控同时可以对错误信息进行捕获,返回自定义页面。
3、使用了RocketMQ消息队列进行流量的削峰和缓存,来解决并发量大的问题,实现流量控制,不会请求过多而导致大量的请求访问失败的问题,可以传入消息队列,让请求进行等待,同时还有其他的场景,比如数据分发。通过图形化管理界面,可以自己创建主题,选择生产者,同时使用方法进行了测试,对于框架中使用了封装好的包,配置好监听的地址和端口以及主题后就可以发送消息了,发送到消息之后就能够监听到发送的消息

4、对于多个服务的入口,无需全部暴露给客户端,可以使用服务网关进行路由的转发,传递一个链接,将其转发到后置的服务,与之前的nginx 进行对比,不是一个单独的组件,更适用于开发环境,可以使用的选型包括zuulgateway,gateway是一个nio的路由,是用于并发量比较高的场景
如果使用GateWay的话,需要创建一个单独的工程,并在配置文件里面配置好注册中心,从而实现服务的发现及路由转发。此外,还可以使用自定义的路由规则,通过谓词和过滤器完成操作,实现指定路由的匹配,同时,GateWay还能实现熔断、限流、重写用户认证以及授权等操作

5、对于多个服务之间的链路追踪,可以使用日志记录的思想进行日志记录,使用了sleuth组件,该组件基于zipkin(包含sleuth)图形化展示组件,当请求发生错误的时候,就可以根据zip kin追踪到错误的来源,此外,除了zepkin之外,还有一些其他的组件也可以进行链路追踪,比如skywalking以及阿里的鹰眼和大众点评的cat
6、对于分布式事务管理,可以使用seata完成