SpringCloud
2023-05-19 07:45:25 1 举报
AI智能生成
登录查看完整内容
SpringCloud
作者其他创作
大纲/内容
单体
垂直
分布式服务架构(SOA)
微服务架构
互联网架构的演变
微服务是一种架构,这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能,包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机,同一个系统和同一个应用服务器中(分布式管理)。
什么是?
优缺点
为什么是?
微服务
解决了什么问题?
体系结构(组件协同工作机制)
Spring Cloud vs Dubbo
Spring Cloud
完成对整个微服务系统的 服务注册和服务发现,以及对服务健康状态的监控和管理功能。
【服务注册】对所有的微服务的信息进行存储,如微服务的名称、IP、端口等
【服务发现】在进行服务调用时通过服务发现查询可用的微服务列表及网络地址进行服务调用
【服务状态监控和管理】可以对所有的微服务进行`心跳检测`,如发现某实例长时间无法访问,就会从服务注册表移除该实例。
做了那些事
作用
基础架构
交互流程及原理
引入依赖
配置Eureka服务
@EnableEurekaServer
服务端 Eureka Server
配置服务
@EnbaleEurekaClient(专用) & @EnableDiscoveryClient(通用)
客户端 Eureka Client
通用配置
Eureka 可视化界面介绍
Eureka配置
Eureka服务端为了防止Eureka客户端本身是可以正常访问的,但是由于网路通信故障等原因,造成Eureka服务端失去于客户端的连接,从而形成的不可用。因为网络通信是可能恢复的,但是Eureka客户端只会在启动时才去服务端注册。如果因为网络的原因而剔除了客户端,将造成客户端无法再注册到服务端。
为什么要有?
Eureka 自我保护机制
yaml 配置
Eureka 高可用
主机名、IP地址、端⼝号等信息,这些信息都会被发布在服务注册表中,⽤于服务之间的调⽤。
标准元数据
可以使⽤eureka.instance.metadata-map`配置,符合KEY/VALUE的 存储格式
自定义元数据
Eureka 元数据
Jersey【Rest框架】 + 本地内存
Eureka源码解析
Eureka
consul是一个可以提供服务发现,健康检查+多数据中心,Key/Value存储等功能的分布式服务框架`,用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案,使用起来也较为简单。Consul用`Golang`实现,因此具有天然可移植性(支持Linux、Windows和Mac OS X);安装包仅包含一个可执行文件,方便部署。
简介
配置
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId></dependency>
默认情况下`font color=\"#b71c1c\
consul健康检查
Consul
Zookeeper
针对于微服务系统服务注册发现、配置管理、管理平台
是什么?
服务的注册发现及健康检查
服务的动态配置管理
动态DNS服务
针对于Nacos管理平台的功能来说,可以由页面管理服务的上下线、全中后、服务元数据【configMap】的配置
服务和元数据管理
即支持AP 额 支持 CP
特性
命名空间,对不同的环境进行隔离
NameSpace
将若干个服务分为一组,通常来说一个系统为一组
Group
具体服务实例
Service
具体的一个配置文件
DataId
Nacos的数据模型
服务列表
0-1 的一个浮点数,(健康的服务实例数 / 总的服务实例数)
如果某个服务的实例数的绝大多数实例都不健康,当服务请求来临时,Nacos之后返回健康的服务实例供调用,这有可能使得健康的服务实例请求资源超过系统的压力,导致系统崩溃,而且在微服务的多层调用链路下甚至会产生雪崩效应,造成其他服务的不可用
为什么需要?
当触发到保护阈值的情况下,Nacos会返回所有的服务列表(健康+非健康),这样做的目的是牺牲个别请求,保证整个系统的可用性。
怎么做?
保护阈值
服务详情
Nacos控制台
nacos中添加配置将数据持久化到Mysql
Nacos数据持久化
注册中心
配置中心
Nacos集群
注册中心-服务注册流程
注册中心-服务发现流程
配置中心-获取配置流程
配置中心-动态感知配置流程
源码分析
Nacos
常用的注册中心
注册中心区别
Eureka Zookeeper 的区别
Spring Cloud & Dubbo 的注册中心有什么不同
硬负载均衡(F5)
软负载均衡(Nginx)
服务端负载均衡
Ribbon
客户端负均衡
服务端 & 客户端负载均衡的区别
负载均衡方案
怎么用?
修改负载均衡策略
负载均衡策略
工作原理
负载均衡
RestTemplate
每次调用都需要写调用的代码,存在代码的冗余
服务地址如何更改,维护成本增高
使用不够灵活
存在的问题
Ribbon已经能够实现简化远程调用和负载均衡,但是还不够优化
feign是使用接口来封原有有字符串拼接的url,`Springcloud` 会对其创建一个`代理对象`,在我们使用`@Autowared`注入代理对象,使用代理对象调用其对应的方法,会通过接口获取到对于`服务`的`服务名、访问路径、参数、返回值`,通过这些服务的信息,底层可以使用 `restTemplate + ribbon`的方式进行远程调用。
Feign简介
OpenFeign是在Feign的基础上做了增强,增加了对MVC注解的支持
OpenFeign简介
使用open feign 的 Get 方式传递参数,参数变量必需通过 @RequetParam 注解
使用open feign 的 POST 方式传递参数,基本类型参数变量必需通过 @RequetParam 注解
如果传递是 MultipartFile 类型 需要用 @RequestPart 进行标识
Feign调用客户端
服务调用
Feign 底层依赖于 Ribbon 实现负载均衡和远程调用(Ribbon 默认 1s 超时)
设置OpenFeign的超时时间
Feign 底层依赖于 Ribbon 实现负载均衡和远程调用。所以可以直接设置 Ribbon的超时时间
设置Ribbon的超时时间
OpenFeign 超时设置
不记录任何日志
NONE
仅仅记录请求方法,url,响应状态代码及执行时间
BASIC
记录Basic级别的基础上,记录请求和响应的header
HEADERS
记录请求和响应的header,body和元数据
FULL
日志级别
配置日志展示
OpenFeign调用日志
OpenFiegn对于负载均衡的支持是基于Ribbon的
负载均衡的支持
Hystrix断路器的支持
Feign远程调用原理
OpenFeign
服务间通讯
在微服务之间进行服务调用是由于某一个服务故障,导致级联服务故障的现象[`级联调用失败`],称为雪崩效应。雪崩效应描述的是 `提供方不可用,导致消费方不可用并将不可用逐渐放大的过程。`
服务调用的扇入 & 扇出
微服务的雪崩效应
牺牲局部,保全整体
服务熔断
页面降级 —— 可视化界面禁用点击按钮、调整静态页面
延迟服务 —— 如定时任务延迟处理、消息入MQ后延迟处理
写降级 —— 直接禁止相关写操作的服务请求
读降级 —— 直接禁止相关读的服务请求
缓存降级 —— 使用缓存方式来降级部分读频繁的服务接口
从微服务全局视角
抛异常
返回NULL
调用Mock数据
调用Fallback处理逻辑
从后端业务代码
服务降级
多维度的限流
计数器(固定窗口)
计数器(滑动窗口)
FiFO队列 + 固定时间消费
漏桶
令牌桶
限流的算法
服务限流
雪崩效应的解决方案
异同
`Hystrix`是一个用于`处理分布式系统的延迟(超时)和容错(异常)`的开源库,在分布式系统中,许多依赖不可避免的会调用失败,超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障(服务雪崩现象),提高分布式系统的弹性。
定义
开启Hiystrix熔断
@EnableCircuitBreaker
对请求进行熔断策略的配置
@HystrixCommand
Hystrix配置类: HystrixCommandProperties
配置Eample
Hystrix配置
为什么要进行线程池隔离?
线程池隔离(默认)
信号量隔离
线程池隔离 & 信号量隔离的区别
线程池隔离(舱壁模式)
熔断器配置修改
利用Springboot actutor 查询 Hystrix状态
工作流程
Hystrix Dashboard
Hystrix Turbine聚合监控
Springboot自动装配+ Aspect切面编程 + RxJava响应式编程
Hystrix检原理
Hystrix
Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。 替代Hystrix,针对问题:服务雪崩、服务降级、服务熔断、服务限流
需要自己搭建DashBoard
没有提供管理页面进行对服务进行服务的熔断、服务降级等配置(需要我们在程序里提前配置好规则,入侵了原有的代码逻辑【入侵了源程序环境】)
独⽴可部署Dashboard/控制台组件
减少代码开发,通过UI界⾯配置即可完成细粒度控制(⾃动投递微服务)
Sentinel
与Hystrix对比
介绍
Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场 景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填⾕、 集群流量控制、实时熔断下游不可⽤应⽤等
丰富的应⽤场景
Sentinel 同时提供实时的监控功能。您可以在控制台中看到 接⼊应⽤的单台机器秒级数据,甚⾄ 500 台以下规模的集群的汇总运⾏情况。
完备的实时监控
Sentinel 提供开箱即⽤的与其它开源框架/库的整合模块,例 如与 Spring Cloud、Dubbo的整合。您只需要引⼊相应的依赖并进⾏简单的配 置即可快速地接⼊ Sentinel。
Sentinel的生态
⼴泛的开源⽣态
Sentinel 提供简单易⽤、完善的 SPI 扩展接⼝。您可以通过 实现扩展接⼝来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
完善的 SPI 扩展点
特征
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId></dependency>
依赖
服务使用
流量规则
降级规则
blockHandler:不满⾜Sentinel规则的降级兜底⽅法
fallback: Java运⾏时异常兜底⽅法
@SentinelResource
自定义兜底逻辑
Sentinel Dashboard中添加的规则数据存储在内存,微服务停掉规则数据就消失,在⽣产环境下不合适。我们可以将Sentinel规则数据持久化到Nacos配置中⼼,让微服务从Nacos获取规则数据。
<!-- Sentinel⽀持采⽤ Nacos 作为规则配置数据源,引⼊该适配依赖 --><dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId></dependency>
规则持久化(基于Nacos)
客户端服务注册流程 / 请求处理流程
限流流程
熔断器
接收一切外界请求,转发到后端的微服务上去
路由转发
在服务网关中可以完成一系列的横切功能,例如权限校验、限流以及监控等,这些都可以通过过滤器完成
过滤器
网关 = 路由转发 + 过滤器
什么是服务网关?
实现服务的统一管理
为什么需要网关?
Zuul
基于springboot2.x 和 spring webFlux 、Reactor 和 Netty 构建 `响应式异步非阻塞IO模型`
静态路由
动态路由
断言(predicate)
过滤器(Filter)
请求过滤
请求链路
查询网关路由列表
`gateway`的负载均衡也是通过 `ribbon` 实现的。
配置路由 & 负载均衡
常用路由断言 Predicate
内置Filter
自定义Filter
过滤器 Filter
Nginx + keepalived
高可用
RequestRateLimiterGatewayFilterFactory
redis + lua + GatewayFilter 过滤器
gateway + sentinel
限流
Gateway
网关
随着微服务的节点越来越多,节点中会出现很多相同的配置代码,出现配置重复,配置整体维护起来比较麻烦,而且程序的配置修改了需要重新启动项目才可以贾加载
Spring Cloud Config 解决了在分布式场景下多服务多环境配置文件的管理和维护
集中管理配置文件
不同环境不同配置,动态化的配置更新
配置信息改变时,不需要重启即可更新配置信息到服务
优点
@EnableConfigServer
@RefreshScope
在config client端加入刷新暴露端点management.endpoints.web.exposure.include=* #开启所有web端点暴露 [推荐使用这种]
- curl -X POST http://localhost:9099/actuator/refresh
手动刷新
自动刷新(借助Bus组件)
配置刷新
Config
Stream
问题驱动技术
feign原理
to do
SpringCloud
0 条评论
回复 删除
下一页