深色模式
网络成本优化
网络费用最容易被忽略，因为它在账单里分散在多个计费项。特点是：单价低但量大，架构一变就翻倍。
适用环境
- 有公网出入口（NAT 网关、负载均衡、EIP）
- 服务跨可用区/跨地域部署
- 有对象存储或 CDN 使用场景
bash
# 盘点网络出口
ip route | grep default
curl -s ifconfig.me # 确认出网 IP1
2
3
2
3
操作步骤
1. 先在账单里定位网络费用
python
import pandas as pd
df = pd.read_csv('bill-2026-10.csv')
net = df[df['服务'].str.contains('流量|带宽|NAT|CDN|负载均衡|IP', na=False)]
print(net.groupby('服务')['金额'].sum().sort_values(ascending=False))1
2
3
4
2
3
4
常见的四类网络费用：
text
1. 公网出向流量（出网带宽）
2. 跨可用区/跨地域流量（东西向）
3. NAT 网关（按处理的 GB 计费 + 实例小时费）
4. 负载均衡（实例费 + 流量费/LCU）1
2
3
4
2
3
4
2. 找出跨可用区调用
bash
# 统计服务间调用的来源与目标 AZ
kubectl get pods -A -o wide --no-headers \
| awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -201
2
3
2
3
text
优化原则：调用方与被调方尽量同可用区（可用拓扑感知路由实现）1
yaml
# Kubernetes Topology Aware Routing：优先同区转发
apiVersion: v1
kind: Service
metadata:
name: order-api
annotations:
service.kubernetes.io/topology-mode: Auto
spec:
selector:
app: order-api
ports:
- port: 80801
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
bash
kubectl get endpointslice -l kubernetes.io/service-name=order-api -o yaml | grep -A2 topology1
3. 用 CDN 卸载公网出向
text
优化前：所有静态资源从源站出网，按公网出向单价计费
优化后：静态资源走 CDN，CDN 单价通常低于源站出向，且减少源站带宽压力1
2
2
bash
# 判断哪些流量可卸载：统计静态资源占比
awk '{print $7}' access.log | grep -E '\.(js|css|png|jpg|woff2|mp4)$' | wc -l
awk '{print $7}' access.log | wc -l1
2
3
2
3
nginx
# 静态资源设置长缓存，提高 CDN 命中率
location ~* \.(js|css|png|jpg|webp|woff2)$ {
expires 30d;
add_header Cache-Control "public, immutable";
}1
2
3
4
5
2
3
4
5
4. 开启压缩减少传输量
nginx
gzip on;
gzip_types text/plain application/json application/javascript text/css;
gzip_min_length 1024;
gzip_comp_level 5;
# 或预压缩静态资源（CPU 开销更低）
gzip_static on;1
2
3
4
5
6
7
2
3
4
5
6
7
bash
# 验证压缩生效
curl -sI -H 'Accept-Encoding: gzip' https://example.com/app.js | grep -i content-encoding1
2
2
API 响应（JSON）通常可压缩到原来的 20%~30%，对大响应体收益明显。
5. 优化 NAT 网关费用
text
NAT 费用 = 实例小时费 + 处理流量费1
两条优化路径：
text
1. 访问同云的托管服务（对象存储、数据库）时用内网端点/VPC 终端节点，
流量不经过 NAT，可省掉数据处理费
2. 大流量出网场景评估专用出网网关或直连方案1
2
3
2
3
bash
# 统计 NAT 出向流量中，访问同云服务的占比（决定是否值得加终端节点）
# 从 VPC 流日志或 NAT 监控中按目标 IP 段聚合1
2
2
6. 减少无效流量
bash
# 检查大量 404/重定向/重复拉取
awk '{print $9}' access.log | sort | uniq -c | sort -rn | head1
2
2
text
1. 修复错误的重试逻辑（客户端重试风暴会成倍放大流量）
2. 图片用 WebP/AVIF 并按需裁剪尺寸
3. 大文件分片/断点续传，避免重复下载
4. 日志与备份传输走内网而非公网1
2
3
4
2
3
4
7. 估算收益
text
月流量费用 = Σ (各类流量 GB × 对应单价)
优化后：
静态流量 F_static：源站出向 → CDN（单价系数 k1 < 1）
跨区流量 F_cross：× 拓扑感知后可减少比例 r
响应体：× (1 - 压缩率)
示例：
总出向 100 TB，其中静态 70 TB
静态转 CDN 后节省 = 70 TB × (原单价 - CDN单价)
响应压缩 30% → API 流量再降 30%1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
验证
bash
# 1) CDN 命中率应 > 90%
# 2) 源站出向带宽应明显下降
sar -n DEV 1 5 | grep eth0
# 3) 跨区流量指标下降
# 4) P95 延迟未恶化（CDN 与压缩都会引入少量开销）1
2
3
4
5
2
3
4
5
常见坑
只看带宽费不看 NAT 处理费
NAT 网关按处理的数据量计费，单价可能高于公网出向本身。大量内网访问公网托管服务时这笔费用很惊人。
盲改路由引发跨区
为省成本把服务都堆到单可用区，会牺牲多 AZ 容灾能力。成本优化不能以降低可用性为代价，同区优先是"尽量"而非"强制"。
CDN 缓存配置错误导致回源暴涨
Cache-Control 未设置或命中率低（URL 带随机参数），CDN 会大量回源，反而增加一次跳转成本。上线后必须查命中率。
压缩的 CPU 开销被忽略
高 QPS 下 gzip 会吃掉可观 CPU。建议用 gzip_static 预压缩，或对大响应体才开启压缩（gzip_min_length）。