先量基线,再谈优化
迁移前连续采集 72 小时基线:请求量、P50/P95/P99 延迟、CPU 与内存水位。验收阈值:P95 波动不超过 ±8%,否则先排查噪声源再规划容量。
用一块褪色暖调的仪表盘,把分散在多云、边缘与自建机房的链路收拢成一条可读的智慧网络。 延迟、吞吐、成本三条曲线同屏比对,让「扩容还是回滚」不再靠感觉,而是靠分位数据说话。
按顺序执行,每步都有验收阈值,避免「上线当晚才发现指标不对」。
07 项迁移前连续采集 72 小时基线:请求量、P50/P95/P99 延迟、CPU 与内存水位。验收阈值:P95 波动不超过 ±8%,否则先排查噪声源再规划容量。
告警一律绑定 P95 与 P99,平均值只做趋势参考。经验值:P99 超过 P50 的 6 倍时,说明存在长尾热点,需检查连接池与慢查询。
扩容触发阈值设为 CPU 65%、持续 3 分钟;缩容阈值设为 35%、持续 10 分钟。冷却窗口过短会造成抖动,建议扩容 120s、缩容 300s。
给每个服务打上 team/env/sla 三类标签,按标签出成本报表。目标:月度单位请求成本环比下降 5%–10%,且 SLO 不回落。
发布节奏:1% → 10% → 50% → 100%,每档观察 15 分钟;错误率超过 0.5% 或 P95 上升 20% 立即回滚,回滚目标时间控制在 3 分钟内。
静态资源 TTL 建议 7 天并配合内容指纹;接口类响应 TTL 控制在 30–120 秒。缓存命中率目标 ≥ 90%,低于 80% 先查键设计与 Vary 头。
在 320px / 768px / 1440px / 1920px 四档视口回归,点按区不小于 44px,正文对比度不低于 4.5:1,横向溢出为 0 才算通过。
从用户到边缘、从边缘到区域中心、从中心到数据层,每一跳都留痕可查。
3 跳观测
把「延迟、吞吐、单位成本」放在同一行比较,扩容决策就不再是拍脑袋。下表为某内容型业务在三个区域的实测对照,可作为你排优先级时的参考模板。
| 区域 | P95 延迟 | 吞吐利用率 | 单位成本 |
|---|---|---|---|
| 华东 · 边缘 | 38ms | 62% | 基准 1.00 |
| 华南 · 区域中心 | 52ms | 78% | 0.92 |
| 华北 · 数据层 | 71ms | 45% | 1.14 |
结论:吞吐利用率超过 75% 的区域优先扩容,延迟高但利用率低的区域先做缓存与查询优化——两者别混着做,否则指标无法归因。
六项能力,各自对应一个可量化验收标准。
06 项按延迟与成本双权重打分选路,故障时 30 秒内切换备用区域。
暖调褪色界面降低夜间盯屏疲劳,关键分位指标一屏可读。
用像素艺术风格的状态块区分健康、降级、熔断,远距离也能辨认。
基于队列深度与 CPU 双指标触发,冷启动预热池缩短响应等待。
服务间双向校验加最小权限策略,密钥 90 天强制轮换。
从 320px 到 2560px 全覆盖,超大屏自动扩展为四列信息密度。
每个伙伴都标注了对接方式与已达成的一致性指标。
08 家把 10% 流量切到新架构,保留旧链路做对照;两周后按 P95 延迟、单位成本、错误率三项指标做取舍。达不到阈值就回滚,沉没成本不进入决策。