作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO
联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬
学习必须往深处挖，挖的越深，基础越扎实！
阶段1、深入多线程
阶段2、深入多线程设计模式
阶段3、深入juc源码解析
码哥源码部分
码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】
码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】
码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】
码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】
打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】
1 介绍
在互联网电商场景中，我们经常会遇到有计划的流量洪峰，比如 双11、618购物节，积分竞拍和定时抢购的疯狂场景。
这种是在预期内的，知道会发生并有一定的准备。而那些预期之外的突发流量异常，才是真正给我们带来挑战的部分，比如：
-
硬件故障：如服务器宕机，机房断电，光纤被挖断等。
-
缓存击穿：一般发生在应用重启导致的缓存失效，以及短时间内大量缓存过期失效时。大量的无法命中，使请求直击后端服务，造成服务提供者超负荷运行，引起服务不可用。
-
程序BUG：如程序逻辑导致内存泄漏；JVM长时间FullGC等。
-
新功能上线：未经过评估，导致非预期流量上涨 （ 某次功能上线，未进行有效的容量评估，导致ws长连接翻数倍）。
单个服务因为流量变化变得不可用，这种不可用如果持续可能是出现水平和垂直双重的扩散。
在分布式系中的某个服务故障沿着调用链向上传递，出现整体的服务雪崩，如下图，这种情况如何提升系统的稳定性和健壮性是我们首要考虑的问题。
2 异常流量洪峰的常见治理手段
一般是采用限流或者熔断：避免预期外流量或故障导致的流量洪峰引起服务雪崩，沿调用向上传递，造成整个链路崩溃。
2.1 限流手段
限流部分，对来路流量做了限制，不允许超过预期峰值。执行过程说明：
-
这边以示例服务 Service A 向 Service B 发起访问为例子。
-
当Service A 感知到 Service B 的某个实例响应时间变慢或者异常返回变多之后，开始对Service B 发起限流。
-
比如使用令牌桶原理（定速流入），每秒钟只提供N个令牌，每个请求携带一个令牌标识前行，用完即限行。
-
或者使用漏桶算法（漏斗池算法），无论请求多少，请求的速率有多大，都按照固定的速率流出，对应的就是服务按照固定的速率处理请求。
-
这样就不会超过预期我们的服务能够承载的QPS，避免被打穿的风险 。
2.2 熔断手段
熔断部分，则是直接断流，流量就不会再负载过去了。执行过程说明：
- 这边以示例服务 Service A 向 Service B 发起访问为例子。
- 当Service A 感知到 Service B 的某个实例响应时间变慢或者异常数不符合我们预期的，开始对Service B 发起熔断。
- 熔断并不是对整个服务都熔断掉，而是对服务中的某个实例进行熔断，其他健康实例还是可以负载流量的。
- 这样就避免了我们的流量持续打到的异常的实例上，造成请求有损的体验 。
3 策略实现（Service Mesh方案）
注释比较清晰了，这边就不解释了。
# DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: xx-svc-b-vs
namespace: kube-ns-xx
spec:
host: svc_b.google.com # 治理发往svc_b服务的流量
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
connectionPool:
http:
http1MaxPendingRequests: 50000 # 等待队列，超额熔断
http2MaxRequests: 40000 # http请求数限制，超额熔断
maxRetries: 2 # 同一个请求的超时次数上限限制，超过即熔断。应用于当前所有的host。
tcp:
maxConnections: 40000 # 后端集群总的TCP连接数，超额熔断
4 总结
云基础场景下的治理手段各种各样，这边讲解了初级版的熔断/限流方案，让用户有一个更优良的使体验。
同时在系统大面积崩溃的时候，进行系统保护，不至于全面崩塌。
在后续的章节我们逐一了解下异常驱逐、异常自动重启等高级用法。
扫一扫
1310
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
