企业官网建设流程全解析

监控上报接口需要配置 LB 吗？滑动平均是什么？平滑加权又该如何落地？

两个问题看起来不相干，其实都踩在"负载均衡器怎么感知后端状态"这条线上：一个是健康检查接口要不要配、配在哪，一个是采集到的负载指标怎么平滑才不会让请求"倒来倒去"。本文把两个问题一次讲透。

上篇：监控上报接口（/actuator/metrics、/status）需要负载均衡器配置吗？在哪里配？

一、先分清：这俩接口到底归谁用

很多人一看到/actuator/metrics、/status就想"是不是该在 LB 里配一下"，根子在于把两件事搞混了：

关键认知：LB 配的不是"监控上报接口"，而是"健康检查接口"。/actuator/metrics是给监控系统看的，LB 一般不读它来做路由——LB 要的是"这台机器还活着吗"的 yes/no，不是"它当前 CPU 多少"的指标流。

所以问题要拆成两个独立的小问题：

1. LB 的健康检查接口要不要配？配在哪？—— 要，且必须配。
2. 业务监控接口（/actuator/metrics）要不要从 LB 走？—— 一般不从 LB 走，单独暴露给监控系统。

下面分别拆。

二、健康检查接口：LB 必须配，配在 LB 的"后端池/上游"配置里

LB 需要知道后端死没死，否则会继续往一台已经挂掉的机器转发请求。这个"探活"动作的配置位置，取决于你用的是哪种 LB。

1. Nginx（七层反向代理）

配在upstream块和对应的location里。Nginx 开源版默认没有主动健康检查，靠被动探活（请求失败到一定次数标记为不可用）；要主动探活得用nginx_upstream_check_module或商业版 Nginx Plus。

upstream backend { server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; # 被动：失败3次/30s内踢出 server 192.168.1.11:8080 max_fails=3 fail_timeout=30s; # 主动健康检查（需第三方模块 nginx_upstream_check_module） check interval=3000 rise=2 fall=3 timeout=2000 type=http; check_http_send "HEAD /actuator/health HTTP/1.1\r\nHost: backend\r\n\r\n"; check_http_expect_alive http_2xx http_3xx; }

• 配在哪：upstream块里的server行（被动参数）+check指令（主动探活）。
• 探活路径：/actuator/health（Spring Boot Actuator 默认健康端点）或自定义的/status、/health。
• 判断标准：HTTP 状态码 2xx/3xx 算活，其他算死。

2. Spring Cloud LoadBalancer / Ribbon（客户端 LB）

配在消费方的配置文件里，由HealthCheckSupplier/IPing周期性去戳后端的健康端点。

# Spring Cloud LoadBalancerspring:cloud:loadbalancer:health-check:enabled:true# 开启主动健康检查path:default:/actuator/health# 健康端点路径interval:30s# 探测间隔initial-delay:0s

# Ribbon（老版） <service-name>.ribbon.NIWSServerListFilterClassName=com.netflix.loadbalancer.ZoneAffinityServerListFilter eureka.client.healthcheck.enabled=true

• 配在哪：消费方application.yml，按服务名维度配置。
• Ribbon 走 Eureka 时，eureka.client.healthcheck.enabled=true让实例自己往注册中心上报健康状态，而不是仅靠心跳。

3. 硬件 LB（F5/A10）/ 云 LB（ALB/SLB）

在**管理控制台的后端服务器组（pool/pool member）**里配 Health Check：

• Health Check Path：/actuator/health或/status
• Interval / Timeout / Healthy Threshold / Unhealthy Threshold：间隔、超时、连续几次成功算活、连续几次失败算死
• HTTP Code：200 视为健康

不管哪种 LB，健康检查的配置位置永远是**“后端池/上游服务器组"那一层**，因为它描述的是"对每个后端实例怎么探活”，而不是"对某个外部请求怎么转发"。

三、健康检查接口 ≠ 监控指标接口，别混着用

新人最常犯的错：把/actuator/metrics当健康检查接口喂给 LB。后果：

正确做法是各司其职：

LB ──探活──▶ /actuator/health (轻量, 只看状态码) Prometheus ──拉指标──▶ /actuator/metrics 或 /actuator/prometheus (重量, 全量指标)

一个原则：健康接口越轻越好（一个状态码就够），监控接口越全越好（指标要够多）。两者不要互相替代。

四、业务监控接口（/actuator/metrics）要不要从 LB 走？

一般不走业务流量 LB，而是单独暴露给监控系统。理由：

1. 安全：/actuator/metrics会泄露 JVM 内存、线程数、DB 连接池等敏感运行时信息，不该暴露到公网 LB 后面。
2. 隔离：监控拉取是周期性大请求，混在业务流量里会干扰业务请求的 RT 统计（恰好就是上篇"性能最优"算法要用的那个 RT）。
3. 稳定性：监控系统要走的是固定的管理端口/管理路径，不随业务 LB 扩缩容而变化。

常见两种暴露方式：

第二种里，Nginx 把监控路径挡在 LB 外面（只允许内网监控系统 IP 访问）：

location /actuator/ { allow 10.0.0.0/8; # 只允许内网监控网段 deny all; proxy_pass http://backend; }

五、一句话回答上篇

• 监控上报接口需要 LB 配吗？不需要。LB 配的是健康检查接口（/actuator/health、/status），不是指标接口（/actuator/metrics）。
• 在哪配？配在 LB 的后端池/上游服务器组那一层：Nginx 的upstream块、Spring Cloud LoadBalancer 的loadbalancer.health-check配置、硬件/云 LB 的 pool Health Check 配置。
• /actuator/metrics 走 LB 吗？一般不走业务 LB，用独立管理端口或路径隔离暴露给监控系统，避免泄露和干扰业务 RT 采集。

下篇：滑动平均是什么？怎么做"平滑加权"避免请求倒来倒去？

一、先看"倒来倒去"是怎么发生的

动态负载均衡（按响应时间、连接数等动态调权重）如果不做平滑，会出现这种灾难：

t1: A 的瞬时 RT=50ms（最快） → 权重拉满 → 所有请求涌向 A t2: A 被打满, RT 飙到 200ms → A 变最慢 → 所有请求涌向 B t3: B 被打满, RT 飙到 200ms → 又涌回 A ...

请求在 A、B 之间反复横跳，权重剧烈震荡，LB 的"调度"反而成了系统不稳定的源头。这种现象叫权重抖动（weight flapping）。

根因：决策用的是"瞬时值"，而瞬时值噪声极大。一次 GC、一次网络毛刺、一条慢请求都能让某台机器的瞬时 RT 突刺。

解决思路：不直接用瞬时值，用它的"历史趋势"代替——这就是滑动平均。

二、滑动平均是什么

1. 直觉定义

滑动平均（Moving Average）：维护一个窗口，窗口里装最近 N 个采样值，用这些值的平均来代表"当前值"。

原始采样序列： 10, 12, 100(突刺), 11, 13, 12, 11, 14 ... 窗口大小 N=3： 第3步平均 = (10 + 12 + 100) / 3 = 40.7 ← 还是被突刺拉高 第4步平均 = (12 + 100 + 11) / 3 = 41.0 第5步平均 = (100 + 11 + 13) / 3 = 41.3 ← 突刺滑出窗口后会回落 第6步平均 = (11 + 13 + 12) / 3 = 12.0 ← 恢复正常

特点：突刺进窗口时把均值拉高、出窗口后均值回落——单点噪声被"摊平"在整个窗口上，不再单独决定结果。

2. 两种主流实现

下面分别讲怎么落地。

三、实现一：滑动窗口平均（SMA）

1. 思路

维护一个定长队列，新采样入队、老采样出队，均值 = 队列求和 / 队列长度。

2. 代码骨架

publicclassSlidingWindowAverage{privatefinallong[]window;// 定长环形数组privateinthead=0;// 下一个写入位置privatelongsum=0;// 维护累加和, 避免 O(N) 求和privateintcount=0;// 已填入的有效样本数privatefinalintsize;publicSlidingWindowAverage(intsize){this.size=size;this.window=newlong[size];}publicsynchronizedvoidrecord(longvalue){longold=window[head];window[head]=value;head=(head+1)%size;// 环形覆盖最老的sum+=value-(count==size?old:0);if(count<size)count++;}publicdoubleaverage(){returncount==0?0:(double)sum/count;}}

关键优化：维护一个sum变量，每次入队时sum += newValue - oldValue，避免每次算均值都遍历整个窗口。这是滑动窗口能在高频采样下用的前提。

3. Ribbon 里的对应实现

Ribbon 的ServerStats就是用这个套路：它内部维护successiveConnectionFailureCount、responseTimeDist等，按时间窗口（默认最近若干分钟）累计请求 RT，定时算平均。WeightedResponseTimeRule每次刷新权重读的就是这个滑动平均 RT。

四、实现二：指数加权移动平均（EWMA）—— 更常用

1. 为什么 EWMA 更受欢迎

SMA 的痛点：

• 要存 N 个值（内存 + 数据结构开销）。
• 窗口里所有样本权重相同：3 分钟前的采样和刚才的采样一视同仁，反应迟钝。
• 突刺要等"滑出窗口"才完全消失，回落慢。

EWMA 只存一个值，且越新的样本权重越大，既省内存又反应快，是工业界动态负载/动态权重的事实标准。

2. 公式

EWMA_new = α * 当前采样值 + (1 - α) * EWMA_old

• α ∈ (0, 1]：平滑因子。α 越大 → 越看重新值 → 响应越快但越不平稳；α 越小 → 越平滑但越迟钝。
• 只需要一个变量记住EWMA_old，新采样来了做一次加权混合即可。

3. 一段历史的"权重衰减"

展开看，第 t 次采样对当前 EWMA 的贡献是α * (1-α)^(历史步数)：

当前样本权重: α 上一次样本权重: α(1-α) 上上次样本权重: α(1-α)² ... 逐渐衰减

这是个指数衰减的权重曲线——老样本影响按指数衰减，自然被"淡忘"。这也是它叫ExponentiallyWeighted 的原因。

4. 代码骨架

publicclassEWMA{privatedoublevalue=Double.NaN;privatefinaldoublealpha;publicEWMA(doublealpha){// α 常取 0.1~0.3this.alpha=alpha;}publicvoidrecord(doublesample){if(Double.isNaN(value)){value=sample;// 第一个样本直接初始化}else{value=alpha*sample+(1-alpha)*value;}}publicdoublevalue(){returnvalue;}}

就十来行，没有数组，没有窗口维护，每次更新 O(1)。

5. α 怎么选

工程经验：动态权重场景 α 取 0.2~0.3 较常见。配合权重刷新间隔（如 30s 刷一次）双重平滑，足以压制绝大多数抖动。

6. 谁在用 EWMA

• Istio / Envoy：服务网格按调用维度算集群 outlier detection、负载权重，内部就是 EWMA。
• Prometheus：record类型 query 的rate/increase背后是基于计数器的区间平均；很多自适应算法用 EWMA。
• TCP RTT 估算：经典 RFC 6298 的 SRTT（平滑 RTT）就是 EWMA，SRTT = 7/8 * SRTT + 1/8 * RTT_sample，即 α=1/8。这是 EWMA 在网络协议层的祖宗级应用。

五、把滑动平均接到"平滑加权"里

滑动平均本身只是"把噪声指标平滑一下"。真正防抖动的是用平滑后的值去算权重，并配合权重刷新节流。完整链路：

┌──────────────┐ 采样: │ 每次请求记录 │ raw RT (含噪声) │ 后端 RT/负载 │ └──────┬───────┘ │ ▼ 平滑: ┌──────────────┐ │ EWMA / SMA │ smoothed = α·raw + (1-α)·old ← 滑动平均 └──────┬───────┘ │ ▼ (每隔 N 秒, 不是每请求) 刷新: ┌──────────────┐ │ 重算权重表 │ weight = f(smoothed) ← 平滑加权 └──────┬───────┘ │ ▼ 分配: ┌──────────────┐ │ 加权随机 │ r = random() * totalWeight └──────────────┘

三道闸门共同压制"倒来倒去"：

1. 采样层平滑（EWMA）：单点突刺被指数衰减稀释。
2. 刷新层节流（定时刷新）：即使 EWMA 略有波动，权重也不是每请求都重算，而是 30s 才刷一次，避免高频震荡。
3. 分配层加权随机：不是"100% 给最快那台"，而是按概率分流，最快的拿大头但不独占——从根本上避免"赢家通吃→被打满→反弹"的震荡环。

缺任何一道都会抖：只平滑不节流 → 高频小震荡；只节流不平滑 → 窗口边界跳变；只加权随机不平滑 → 权重表本身就在跳。

六、一个数值对比：平滑 vs 不平滑

3 台机器，真实瞬时 RT 序列（含一次突刺）：

时刻 1: A=50 B=100 C=80 时刻 2: A=50 B=100 C=80 时刻 3: A=250 B=100 C=80 ← A 被 GC 卡了一下(突刺) 时刻 4: A=50 B=100 C=80 时刻 5: A=50 B=100 C=80

不加平滑（直接用瞬时值算权重 weight = totalRT - avgRT）：

时刻3: weight(A) = 430-250=180, weight(B)=430-100=330 → A 权重瞬间被 B 反超 → 流量大量从 A 撤离涌向 B，A 一恢复又涌回 → 倒来倒去

加 EWMA（α=0.3）：

EWMA(A) 变化: 50 → 50 → 0.3*250+0.7*50=110 → 0.3*50+0.7*110=92 → 0.3*50+0.7*92=79 → A 的平滑值从 50 缓慢爬到 110 再缓慢回落, 没有跳变 → 权重表变化平缓, 流量不剧烈迁移

突刺被"摊"成一段缓坡，权重表平滑过渡，请求不会倒来倒去。

七、选型与陷阱

SMA vs EWMA 怎么选

• 要精确的"最近 N 个"统计、且不在乎内存：用 SMA（窗口语义明确，可解释）。
• 只要"平滑趋势"、内存敏感、采样高频：用 EWMA（一行状态、O(1)、自适应）。
• 动态负载均衡场景绝大多数选 EWMA，因为指标刷新高频、只需趋势不需精确窗口。

常见陷阱

1. α 设太大：平滑因子接近 1，等于没用滑动平均，抖动照旧。
2. 只平滑、不节流刷新：每条请求都重算权重表，平滑效果被高频刷新冲掉，仍然震荡。权重刷新必须定时（如 30s）。
3. 平滑窗口/α 与业务变化节奏不匹配：后端负载每秒剧变，却开了超大窗口/极小 α → 反应迟钝，跟不上真实变化。应让平滑时间常数 ≈ 你想容忍的"最短变化周期"。
4. 把滑动平均当万能药：它能削平噪声，但削不掉结构性变化（某台机器真的持续变慢）。持续变慢仍要被识别和降权，只是不要被一次毛刺误判。
5. 冷启动没兜底：新机器EWMA_old没值，要么初始化为 0（被当最快、被冲垮），要么初始化为 ∞（被当最慢、饿死）。应初始化为集群平均 RT 的中位数作为安全初值。

八、一句话回答下篇

• 滑动平均是什么？用"最近一段历史采样的平均"代替"当前瞬时值"，让单点噪声被摊平，不让一次突刺决定结果。主流两种：滑动窗口平均（SMA，存 N 个值取均）和指数加权移动平均（EWMA，只存一个值按α·新+(1-α)·旧滚动更新）。
• 怎么做平滑加权防抖动？三道闸门：EWMA 平滑采样值 → 定时（非每请求）刷新权重表 → 加权随机分配。任一缺失都会让请求"倒来倒去"。动态负载场景 α 常取 0.2~0.3，配合 30s 权重刷新间隔。