发布于2026-08-20 阅读(0)
扫一扫,手机访问
在微服务中由于服务间相互依赖很容易出现连锁故障,连锁故障可能是由于整个服务链路中的某一个服务出现故障,进而导致系统的其他部分也出现故障。例如某个服务的某个实例由于过载出现故障,导致其他实例负载升高,从而导致这些实例像多米诺骨牌一样一个个全部出现故障,这种连锁故障就是所谓的雪崩现象
比如,服务A依赖服务C,服务C依赖服务D,服务D依赖服务E,当服务E过载会导致响应时间变慢甚至服务不可用,这个时候调用方D会出现大量超时连接资源被大量占用得不到释放,进而资源被耗尽导致服务D也过载,从而导致服务C过载以及整个系统雪崩

资源一旦耗尽,就可能引发高延迟、高错误率,或者导致相应数据不符合预期。这是资源耗尽时的必然现象,毕竟当负载持续上升直至过载,服务器不可能始终保持完全正常的运行状态。而CPU资源不足引发的负载上升,在我们的工作中最为常见。一旦CPU资源无法满足请求负载,通常所有请求都会变慢,CPU负载过高还会产生一系列副作用,主要包括以下几个方面:
由此可见防止服务器过载的重要性不言而喻,而防止服务器过载又分为下面几种常见的策略:
今天我们主要讨论的是第二种防止服务器过载的方案,即在过载的情况下主动拒绝请求,下面我统一使用”过载保护“来表述,过载保护的大致原理是当探测到服务器已经处于过载时则主动拒绝请求不进行处理,一般做法是快速返回error

很多微服务框架中都内置了过载保护能力,本文主要分析go-zero中的过载保护功能,我们先通过一个例子来感受下go-zero的中的过载保护是怎么工作的
首先,我们使用官方推荐的goctl生成一个api服务和一个rpc服务,生成服务的过程比较简单,在此就不做介绍,可以参考官方文档,我的环境是两台服务器,api服务跑在本机,rpc服务跑在远程服务器
远程服务器为单核CPU,首先通过压力工具模拟服务器负载升高,把CPU打满
stress -c 1 -t 1000此时通过uptime工具查看服务器负载情况,-d参数可以高亮负载的变化情况,此时的负载已经大于CPU核数,说明服务器正处于过载状态
watch -d uptime
19:47:45 up 5 days, 21:55, 3 users, load average: 1.26, 1.31, 1.44此时请求api服务,其中ap服务内部依赖rpc服务,查看rpc服务的日志,级别为stat,可以看到cpu是比较高的
"level":"stat","content":"(rpc) shedding_stat [1m], cpu: 986, total: 4, pass: 2, drop: 2"并且会打印过载保护丢弃请求的日志,可以看到过载保护已经生效,主动丢去了请求
adaptiveshedder.go:185 dropreq, cpu: 990, maxPass: 87, minRt: 1.00, hot: true, flying: 2, avgFlying: 2.07这个时候调用方会收到 "service overloaded" 的报错
通过上述试验可知,当服务器负载过高时,会触发过载保护,从而避免连锁故障引发雪崩。接下来,我们从源码角度分析过载保护的原理。go-zero在http和rpc框架中均内置了过载保护功能,其代码路径分别位于go-zero/rest/handler/sheddinghandler.go和go-zero/zrpc/internal/serverinterceptors/sheddinginterceptor.go。我们以rpc框架下的过载保护为例进行分析。在server启动时,会new一个shedder,代码路径为go-zero/zrpc/server.go:119。之后,当收到每个请求时,都会通过Allow方法判断是否需要进行过载保护。若err不等于nil,则表明需要进行过载保护,此时将直接返回error。
promise, err = shedder.Allow()
if err != nil {
metrics.AddDrop()
sheddingStat.IncrementDrop()
return
}实现过载保护的代码路径为: go-zero/core/load/adaptiveshedder.go,这里实现的过载保护基于滑动窗口可以防止毛刺,有冷却时间防止抖动,当CPU>90%的时候开始拒绝请求,Allow的实现如下
func (as *adaptiveShedder) Allow() (Promise, error) {
if as.shouldDrop() {
as.dropTime.Set(timex.Now())
as.droppedRecently.Set(true)
return nil, ErrServiceOverloaded // 返回过载错误
}
as.addFlying(1) // flying +1
return &promise{
start: timex.Now(),
shedder: as,
}, nil
}sholdDrop实现如下,该函数用来检测是否符合触发过载保护条件,如果符合的话会记录error日志
func (as *adaptiveShedder) shouldDrop() bool {
if as.systemOverloaded() || as.stillHot() {
if as.highThru() {
flying := atomic.LoadInt64(&as.flying)
as.avgFlyingLock.Lock()
avgFlying := as.avgFlying
as.avgFlyingLock.Unlock()
msg := fmt.Sprintf(
"dropreq, cpu: %d, maxPass: %d, minRt: %.2f, hot: %t, flying: %d, avgFlying: %.2f",
stat.CpuUsage(), as.maxPass(), as.minRt(), as.stillHot(), flying, avgFlying)
logx.Error(msg)
stat.Report(msg)
return true
}
}
return false
}判断CPU是否达到预设值,默认90%
systemOverloadChecker = func(cpuThreshold int64) bool {
return stat.CpuUsage() >= cpuThreshold
}CPU的负载统计代码如下,每隔250ms会进行一次统计,每一分钟没记录一次统计日志
func init() {
go func() {
cpuTicker := time.NewTicker(cpuRefreshInterval)
defer cpuTicker.Stop()
allTicker := time.NewTicker(allRefreshInterval)
defer allTicker.Stop()
for {
select {
case <-cpuTicker.C:
threading.RunSafe(func() {
curUsage := internal.RefreshCpu()
prevUsage := atomic.LoadInt64(&cpuUsage)
// cpu = cpuᵗ⁻¹ * beta + cpuᵗ * (1 - beta)
usage := int64(float64(prevUsage)*beta + float64(curUsage)*(1-beta))
atomic.StoreInt64(&cpuUsage, usage)
})
case <-allTicker.C:
printUsage()
}
}
}()
}其中CPU统计实现的代码路径为: go-zero/core/stat/internal,在该路径下使用linux结尾的文件,因为在go语言中会根据不同的系统编译不同的文件,当为linux系统时会编译以linux为后缀的文件
func init() {
cpus, err := perCpuUsage()
if err != nil {
logx.Error(err)
return
}
cores = uint64(len(cpus))
sets, err := cpuSets()
if err != nil {
logx.Error(err)
return
}
quota = float64(len(sets))
cq, err := cpuQuota()
if err == nil {
if cq != -1 {
period, err := cpuPeriod()
if err != nil {
logx.Error(err)
return
}
limit := float64(cq) / float64(period)
if limit < quota {
quota = limit
}
}
}
preSystem, err = systemCpuUsage()
if err != nil {
logx.Error(err)
return
}
preTotal, err = totalCpuUsage()
if err != nil {
logx.Error(err)
return
}
}在linux中,通过/proc虚拟文件系统向用户控件提供了系统内部状态的信息,而/proc/stat提供的就是系统的CPU等的任务统计信息,这里主要原理就是通过/proc/stat来计算CPU的使用率
本文主要介绍了过载保护的原理,以及通过实验触发了过载保护,最后分析了实现过载保护功能的代码,相信通过本文大家对过载保护会有进一步的认识,过载保护不是万金油,对服务来说是有损的,所以在服务上线前我们最好是进行压测做好资源规划,尽量避免服务过载
写作不易,如果觉得文章不错,欢迎 github star
项目地址:
https://github.com/tal-tech/go-zero
https://gitee.com/kevwan/go-zero
下一篇:我在阿里实习做开源
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
4
5
6
7
8
9