言尽于此,完结
无论是一个初级的 coder,高级的程序员,还是顶级的系统架构师,应该都有深刻的领会到设计模式的重要性。
- 第一,设计模式能让专业人之间交流方便,如下:
程序员A:这里我用了XXX设计模式
程序员B:那我大致了解你程序的设计思路了
- 第二,易维护
项目经理:今天客户有这样一个需求…
程序员:明白了,这里我使用了XXX设计模式,所以改起来很快
- 第三,设计模式是编程经验的总结
程序员A:B,你怎么想到要这样去构建你的代码
程序员B:在我学习了XXX设计模式之后,好像自然而然就感觉这样写能避免一些问题
- 第四,学习设计模式并不是必须的
程序员A:B,你这段代码使用的是XXX设计模式对吗?
程序员B:不好意思,我没有学习过设计模式,但是我的经验告诉我是这样写的
从设计思想解读开源框架,一步一步到Spring、Spring5、SpringMVC、MyBatis等源码解读,我都已收集整理全套,篇幅有限,这块只是详细的解说了23种设计模式,整理的文件如下图一览无余!
搜集费时费力,能看到此处的都是真爱!
com.alibaba.cloud
spring-cloud-starter-alibaba-sentinel
application.yml修改:
spring:
cloud:
sentinel:
transport:
dashboard: 127.0.0.1:8080 # sentinel dashboard/console 地址
port: 8719 # sentinel会在该端口启动http server,那么这样的话,控制台定义的一些限流等规则才能发送传递过来,如果8719端口被占用,那么会依次+1
测试
接下来,我们测试一下。请求一个接口
http://localhost/api/user/login/1186154608@qq.com/123
可以看到已经可以监控查看啦。说明我们部署成功了。
资源:
它可以是 Java 应⽤程序中的任何内容,例如,由应⽤程序提供的服务,或由应⽤程序调⽤的其它应⽤提供的服务,甚⾄可以是⼀段代码。我们请求的 API 接⼝就是资源
规则:
围绕资源的实时状态设定的规则,可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整
Sentinel 流量规则模块
系统并发能⼒有限,⽐如系统A的QPS⽀持1个,如果太多请求过来,那么A就应该进⾏流量控制了,⽐如其他请求直接拒绝
资源名:默认请求路径
针对来源:Sentinel可以针对调⽤者进⾏限流,填写微服务名称,默认default(不区分来源)阈值类型/单机阈值
QPS:(每秒钟请求数量)当调⽤该资源的QPS达到阈值时进⾏限流
线程数:当调⽤该资源的线程数达到阈值的时候进⾏限流(线程处理请求的时候,如果说业务逻辑执⾏时间很⻓,流量洪峰来临时,会耗费很多线程资源,这些线程资源会堆积,最终可能造成服务不可⽤,进⼀步上游服务不可⽤,最终可能服务雪崩)
是否集群:是否集群限流
流控模式:
直接:资源调⽤达到限流条件时,直接限流
关联:关联的资源调⽤达到阈值时候限流⾃⼰
链路:只记录指定链路上的流量
流控效果:
快速失败:直接失败,抛出异常
Warm Up:根据冷加载因⼦(默认3)的值,从阈值/冷加载因⼦,经过预热时⻓,才达到设置的QPS阈 值
排队等待:匀速排队,让请求匀速通过,阈值类型必须设置为QPS,否则⽆效
流控模式之关联限流:
关联的资源调⽤达到阈值时候限流⾃⼰,⽐如⽤户注册接⼝,需要调⽤身份证校验接⼝(往往身份证校验接⼝),如果身份证校验接⼝请求达到阈值,使⽤关联,可以对⽤户注册接⼝进⾏限流。
流控模式之链路限流:
链路模式下会控制该资源所在的调⽤链路⼊⼝的流量。需要在规则中配置⼊⼝资源,即该调⽤链路⼊⼝的上下⽂名称。
⼀棵典型的调⽤树如下图所示:(阿⾥云提供)
上图中来⾃⼊⼝ Entrance1 和 Entrance2 的请求都调⽤到了资源 NodeA ,Sentinel 允许只根据某个调⽤⼊⼝的统计信息对资源限流。⽐如链路模式下设置⼊⼝资源为 Entrance1 来表示只有从⼊⼝ Entrance1 的调⽤才会记录到 NodeA 的限流统计当中,⽽不关⼼经 Entrance2 到来的调⽤。
流控效果之 Warm up:
当系统⻓期处于空闲的情况下,当流量突然增加时,直接把系统拉升到⾼⽔位可能瞬间把系统压垮,⽐如电商⽹站的秒杀模块。
通过 Warm Up 模式(预热模式),让通过的流量缓慢增加,经过设置的预热时间以后,到达系统处理请求速率的设定值。
Warm Up 模式默认会从设置的 QPS 阈值的 1/3 开始慢慢往上增加⾄ QPS 设置值。
流控效果之排队等待:
排队等待模式下会严格控制请求通过的间隔时间,即请求会匀速通过,允许部分请求排队等待,通常⽤于消息队列削峰填⾕等场景。需设置具体的超时时间,当计算的等待时间超过超时时间时请求就会被拒绝。
很多流量过来了,并不是直接拒绝请求,⽽是请求进⾏排队,⼀个⼀个匀速通过(处理),请求能等就等着被处理,不能等(等待时间>超时时间)就会被拒绝.
例如,QPS 配置为 5,则代表请求每 200 ms 才能通过⼀个,多出的请求将排队等待通过。超时时间代表最⼤排队时间,超出最⼤排队时间的请求将会直接被拒绝。排队等待模式下,QPS 设置值不要超过 1000(请求间隔 1 ms)。
Sentinel 降级规则模块
流控是对外部来的⼤流量进⾏控制,熔断降级的视⻆是对内部问题进⾏处理。
Sentinel 降级会在调⽤链路中某个资源出现不稳定状态时(例如调⽤超时或异常⽐例升⾼),对这个资源的调⽤进⾏限制,让请求快速失败,避免影响到其它的资源⽽导致级联错误。当资源被降级后,在接下来的降级时间窗⼝之内,对该资源的调⽤都⾃动熔断. 这⾥的降级其实是Hystrix中的熔断,还记得当时Hystrix的⼯作流程么
策略
Sentinel不会像Hystrix那样放过⼀个请求尝试⾃我修复,就是明明确确按照时间窗⼝来,熔断触发后,时间窗⼝内拒绝请求,时间窗⼝后就恢复。
- RT(平均响应时间 )
当 1s 内持续进⼊ >=5 个请求,平均响应时间超过阈值(以 ms 为单位),那么在接下的时间窗⼝(以 s 为单位)之内,对这个⽅法的调⽤都会⾃动地熔断(抛出 DegradeException)。注意 Sentinel 默认统计的 RT 上限是 4900 ms,超出此阈值的都会算作 4900 ms,若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。
- 异常⽐例
当资源的每秒请求量 >= 5,并且每秒异常总数占通过量的⽐值超过阈值之后,资源进⼊降级状态,即在接下的时间窗⼝(以 s 为单位)之内,对这个⽅法的调⽤都会⾃动地返回。异常⽐率的阈值范围是 [0.0, 1.0] ,代表 0% - 100%。
- 异常数
当资源近 1 分钟的异常数⽬超过阈值之后会进⾏熔断。注意由于统计时间窗⼝是分钟级别的,若 timeWindow ⼩于 60s,则结束熔断状态后仍可能再进⼊熔断状态。时间窗⼝ >= 60s
⽬前,Sentinel Dashboard 中添加的规则数据存储在内存,微服务停掉规则数据就消失,在⽣产环境下不合适。我们可以将 Sentinel 规则数据持久化到 Nacos 配置中⼼,让微服务从 Nacos 获取规则数据。
依赖
首先我们需要在项目中增加依赖
com.alibaba.csp
sentinel-datasource-nacos
增加配置
sentinel:
transport:
dashboard: 127.0.0.1:8080
port: 8719
Sentinel Nacos数据源配置,Nacos中的规则会自动同步到sentinel流控规则中
datasource:
自定义的流控规则数据源名称
flow:
nacos:
server-addr: ${spring.cloud.nacos.discovery.server-addr}
data-id: ${spring.application.name}-flow-rules
groupId: DEFAULT_GROUP
data-type: json
rule-type: flow # 类型来自RuleType类
自定义的降级规则数据源名称
degrade:
nacos:
server-addr: ${spring.cloud.nacos.discovery.server-addr}
data-id: ${spring.application.name}-degrade-rules
groupId: DEFAULT_GROUP
data-type: json
rule-type: degrade # 类型来自RuleType类
Nacos Server 中配置
接下来需要我们在 Nacos Server 中添加对应规则配置集(public命名空间—>DEFAULT_GROUP中添加)
流控规则配置
[{
“resource”:“/user/login/1186154608@qq.com/123”,
“limitApp”:“default”,
“grade”:1,
“count”:1,
“strategy”:0,
“controlBehavior”:0,
“clusterMode”:false
}]
所有属性来⾃源码 FlowRule 类
-
resource:资源名称
-
limitApp:来源应⽤
-
grade:阈值类型 0 线程数 1 QPS
-
count:单机阈值
结局:总结+分享
看完美团、字节、腾讯这三家的一二三面试问题,是不是感觉问的特别多,可能咱们真的又得开启面试造火箭、工作拧螺丝的模式去准备下一次的面试了。
开篇有提及我可是足足背下了Java互联网工程师面试1000题,多少还是有点用的呢,换汤不换药,不管面试官怎么问你,抓住本质即可!能读到此处的都是真爱
- Java互联网工程师面试1000题
而且从上面三家来看,算法与数据结构是必备不可少的呀,因此我建议大家可以去刷刷这本左程云大佬著作的 《程序员代码面试指南 IT名企算法与数据结构题目最优解》,里面近200道真实出现过的经典代码面试题。
- 程序员代码面试指南–IT名企算法与数据结构题目最优解
- 其余像设计模式,建议可以看看下面这4份PDF(已经整理)
- 更多的Java面试学习笔记如下,关于面试这一块,我额外细分出Java基础-中级-高级开发的面试+解析,以及调优笔记等等等。。。
以上所提及的全部Java面试学习的PDF及笔记,如若皆是你所需要的,那么都可发送给你!
[外链图片转存中…(img-aMO3u9R4-1715647348299)]
- 其余像设计模式,建议可以看看下面这4份PDF(已经整理)
[外链图片转存中…(img-SE12Ncyg-1715647348299)]
- 更多的Java面试学习笔记如下,关于面试这一块,我额外细分出Java基础-中级-高级开发的面试+解析,以及调优笔记等等等。。。
[外链图片转存中…(img-KQENXwFY-1715647348300)]
以上所提及的全部Java面试学习的PDF及笔记,如若皆是你所需要的,那么都可发送给你!