在国外做电商网站,云南网站开发费用,安卓手机本地视频播放器,市场部职能中的网站建设目录 一、Sentinel
1.1、背景#xff1a;雪崩问题
1.2、雪崩问题的解决办法
1.2.1、超时处理
缺陷#xff1a;为什么这里只是 “缓解” 雪崩问题#xff0c;而不是百分之百解决了雪问题呢#xff1f;
1.2.2、舱壁模式
缺陷#xff1a;资源浪费
1.2.3、熔断降级
1.…目录 一、Sentinel
1.1、背景雪崩问题
1.2、雪崩问题的解决办法
1.2.1、超时处理
缺陷为什么这里只是 “缓解” 雪崩问题而不是百分之百解决了雪问题呢
1.2.2、舱壁模式
缺陷资源浪费
1.2.3、熔断降级
1.2.4、流量控制
误区那是不是只用流量控制就可以前面三种方法就不用了
1.3、Sentinel 和 Hystrix 的区别
a隔离策略
b熔断降级
c限流
d流量整形
e控制台
1.4、安装 Sentinel
1.5、微服务项目整合 Sentinel
1.5.1、引入微服务工程
1.5.2、整合 Sentinel 一、Sentinel 1.1、背景雪崩问题
雪崩问题就是指在微服务调用链路中某个服务出现故障结果引起整个链路的所有微服务都不可用.
在微服务中业务往往会比较复杂一业务服务可能会依赖多个服务. 比如有一个 服务a 内部会依赖 服务b、服务c、服务d. 现在假设 服务d 出现了故障那么 服务a 依赖于 服务d 的请求还能正常响应吗显然不能请求来了以后就要等待 服务d 的响应因为 服务d 出现故障了以后不能正常返回响应因此就会阻塞在这里导致 服务a 内部的业务阻塞在这里. 也就不会释放 tomcat 连接. 此时服务a 内部依赖的 服务b 或 c 的业务还可以正常运行但是如果依赖于 服务d 的请求肯定后续还会有多个他们都不会释放连接就导致把 a 内部所有连接都占用了连接资源也就耗尽了此时就导致依赖的 b 和 c 的服务故障了. 这还不是最严重的在微服务的调用关系中很复杂也就是说会有其他服务也依赖于 a 服务进一步导致其他依赖 a 的服务故障最后整个微服务群就垮了. 1.2、雪崩问题的解决办法
1.2.1、超时处理
超时处理设定一个超时时间当请求超过一定时间没有响应时就直接返回错误信息而不是无休止等待.
就拿刚才的栗子讲服务a 内部依赖 b、c、d此时 d 出现了故障a 内部依赖于 c 的所有业务都会阻塞假以时日 a 也就崩溃了. 那么 超时处理 会怎么做呢
他会在调用的业务上加一个超时时间比如说 1s也就是说a 依赖于 d 的业务他最多等 1s. 当 d 故障了以后等待时间超过 1s他就会立即结束这个请求不再等待返回会给用户提示请求失败那么这个就不会导致一直占用连接资源可以一定程度上缓解雪崩问题. 缺陷为什么这里只是 “缓解” 雪崩问题而不是百分之百解决了雪问题呢 假设他只是等待 1s 以后把资源释放了也就是说1s 释放一个连接那么如果现在请求来的速度比他释放的还要快比如 500ms 一个请求那么终有一天服务a 的资源也有可能被耗尽就像是一个蓄水池进水的速度比出水快终有一日水池的水会溢出.
因此 超时处理 并不能从根本上解决这个问题. 1.2.2、舱壁模式
舱壁模式的涉及来源于我们现实生活中~ 一些大型的轮船会利用隔板也叫舱壁把船体分隔成一个个独立的小空间因此空间彼此之间时隔离的. 假设现在船体的某个部位撞上了冰山漏水了那么最多也只是把部分船舱给他填满水了不会导致整个船体挂满水最后导致沉船提高了整艘船的容灾能力. 在程序涉及这边的做法是把 tomcat 看成整艘船限定每个业务能使用的线程数相当于舱壁隔离避免耗尽整个 tomcat 资源因此这个方法也叫做“线程隔离”.
这里还是拿刚刚的栗子来讲假设限定每个业务分配一个线程池限定线程最大数目为 10此时 服务d 故障了那么他最多也就只能占用 10 个连接资源避免占用其他业务的连接资源. 缺陷资源浪费 这种模式确实解决了雪崩问题但是资源上还是会有一定的浪费比如 服务d 真的宕机了明明知道他挂了但请求还是回来直到占满 10 个线程. 因此对 cpu 的资源也是一种浪费. 1.2.3、熔断降级
这种模式中会有一个 断路器它可以用来统计业务出现 故障的请求 和 正常请求 之间的比例是什么样子如果超出来看阈值就会熔断该业务拦截访问该业务的所有请求.
拿之前的栗子讲服务a 里有一个业务时访问 服务d 的然后呢第一次访问时正常的结果后面两次都出现了故障这个时候熔断器就会统计这个异常比例是怎么样的. 假设阈值时 50%而三个请求中两个都出了问题肯定超出了阈值这个时候就会出现熔断那么在 服务a 内部访问 服务d 的业务都会被拦截下来然后快速释放资源. 这种方式不仅解决了雪崩问题也解决了 舱壁模式 中资源浪费的情况. 因此熔断降级模式是解决雪崩问题中比较好的一种方案. 1.2.4、流量控制
流量控制就是限制业务访问的 qps每秒处理请求数量避免服务因流量突增而故障.
比如有一个微服务能承受的最大 qps 是 2也就是每秒钟最多处理两个请求但是现在有一百个请求涌过来了那他不得被达成筛子了但是 sentinel 会根据这个 qps 的限制去处理请求然后释放这就像是有大量的水要涌入的时候会先经过一个漏斗通过这个漏斗将水的流量限制住这个时候就可以有效的避免出现故障超出的请求会被拦截默认会报错但也可以配置成 排队等待、预热. 流量控制和前面三种方法不同前面三种方法是服务已经有故障了而流量控制是通过限制 qps避免出现故障. 误区那是不是只用流量控制就可以前面三种方法就不用了 当然不是因为高并发引起的服务故障只是故障的原因之一服务往往还会因为其他问题而引发故障比如网络问题或者是假死问题.
但是以上三种解决方式中我们重点学习的是 舱壁模式、熔断降级、流量控制. 1.3、Sentinel 和 Hystrix 的区别
Hystrix 是 SpringCloud 刚刚流行的这几年推荐大家使用的服务保护机制是由 Netflix 公司出品的只不过后来这个公司宣布停止对 Hystrix 的升级和维护逐渐就没落了于是人们都开始寻找一种新的方案.
这个时候阿里巴巴开源了一个项目就是 sentinel 并且成为了 SpringCloud 中服务保护的组件现在已经广泛的应用在国内的互联网公司.
这里我们来对比一下他们两个. Sentinel Hystrix 隔离策略 信号量隔离 线程池隔离/信号量隔离 熔断降级策略 基于慢调用比例或异常比例 基于失败比率 实时指标实现 滑动窗口 滑动窗口基于 RxJava 规则配置 支持多种数据源 支持多种数据源 扩展性 多个扩展点 插件的形式 基于注解的支持 支持 支持 限流 基于 QPS支持基于调用关系的限流 有限的支持 流量整形 支持慢启动、匀速排队模式 不支持 系统自适应保护 支持 不支持 控制台 开箱即用可配置规则、查看秒级监控、机器发现等 不完善 常见框架的适配 Servlet、Spring Cloud、Dubbo、gRPC 等 Servlet、Spring Cloud Netflix
主要是红字的差异.
a隔离策略
hystrix 底层是基于线程池和信号量实现的默认情况下是使用线程池. sentinel 底层是基于信号量来实现的. 这两种方式有什么差别呢
线程池隔离就是给每一个业务链上都有一个独立的线程池来处理请求但是一旦请求数量突增就会导致多出很多线程因此会给 cpu 带来一些额外的上下文切换的消耗线程不是越多越好就像之前讲过的 “一群滑稽吃鸡” 的栗子.
信号量隔离就不会创建单独的线程池而是使用一个大线程池在请求来了之后做一个统计统计当前业务已经使用了几个线程了然后限制一下当前业务使用的线程数目例如只能使用 10 个假设你也已经使用了 10 个那么再有新的业务来获取线程的时候就会阻止你. 池子就是那一个池子他默认不会创建新的线程因此性能不受影响.
这种方式相比于 线程池隔离隔离性略微逊色一点因此比较在同一个池子里只不过一个大锅饭每个人拿单独的碗成了性能比较高. 因此我们认为信号量这种方案更好一点. b熔断降级
在 sentinel 中除了可以统计异常请求的比例也可以统计慢调用的比例. 什么是慢调用呢
就是一个业务中10 个请求中有 8 个耗时都比较久可能导致拖慢整个服务因此这个时候就会去他熔断掉. c限流
在 sentinel 中是支持基于 qps 限流、调用关系限流、甚至还可以针对热点的参数去限流.
而在 hystrix 中没有专门的限流控制只是基于线程池设置池子的线程数上限来限流. d流量整形
在 sentinel 中支持流量整形就是让基于 慢启动预热模式 或者 匀速排队 让突发流量变成稳定的流速.
而 hystrix 中是不支持这样的功能的. e控制台
控制台也就是所谓的 可视化界面方便你去操作.
在 sentinel 中控制台这边不仅可以监控微服务查看运行状态还可以配置我们的降级规则先流规则并且设置完立即动态生效.
在 hystrix 中控制台只支持查看服务状态的功能.
因此相对来讲sentinel 控制台的功能要强大一些. 1.4、安装 Sentinel
Sentinel 官方提供了 UI 控制台方便我们对系统做限流设置.
a大家可以去 GitHub 上下载.
git clone https://github.com/alibaba/Sentinel.git
b下载好 jar 包以后把他拷贝到一个非中文的目录然后打开终端使用以下命令
java -jar sentinel-dashboard-1.8.1.jarPs官方教程中使用的端口是8080用户可以自定义更改. 如果要修改 Sentinel 的默认端口、账户、密码、可以通过以下配置 配置项 默认值 说明 server.port 8080 服务端口 sentinel.dashboard.auth.username sentinel 默认用户名 sentinel.dashboard.auth.password sentinel 默认密码
例如修改端口号为 8090
java -jar sentinel-dashboard-1.8.1.jar -Dserver.port8090c然后访问localhost:8080 即可看到控制台页面默认的账户和密码都是sentinel 登录成功以后可以看到只有一个欢迎页面这是因为我们还没有在微服务中配置 Sentinel 的信息. 1.5、微服务项目整合 Sentinel
1.5.1、引入微服务工程
项目结构如下
gateway网关.user-service用户服务涉及到用户表包含用户的 CRUD.order-service订单服务涉及到订单表查询订单 的时候会远程调用 用户服务 将订单和用户信息一起展示出来.feign-api用户服务对外暴露 feign 客户端、实体类. 用户表如下 订单表如下 1.5.2、整合 Sentinel
在 order-service 中整合 Sentinel并且连接 Sentinel 控制台步骤如下.
a在 order-service 中引入 sentinel 依赖
!--sentinel--
dependencygroupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId
/dependencyb配置控制台地址
spring:cloud: sentinel:transport:dashboard: localhost:8080
c访问 order-service 服务的任意端点触发 sentinel 监控. Ps启动微服务前记得启动 nacos 和 sentinel.
