1.1 收集基础指标:在最低可见延迟窗口内采集CPU、内存、磁盘IOPS、网络带宽、HTTP响应时延与错误率。常用工具:Prometheus + node_exporter、Grafana、iostat、vnstat、netstat、nginx stub_status。
1.2 建立基线:统计过去30天按小时的最大并发、平均RPS(每秒请求数)、95/99百分位延迟,确定“正常峰值”和“保守峰值(×1.5)”。所有后续容量规划以保守峰值为目标。
2.1 部署监控:安装Prometheus抓取节点指标,部署exporter(mysql_exporter, redis_exporter, blackbox_exporter),并搭建Grafana面板展示关键SLO指标。
2.2 配置告警:Alertmanager规则示例:CPU>80%持续5分钟、95p响应时间>1s、错误率>1%持续3分钟。设定告警分级与接收人(电话/短信/Slack)。
3.1 设计场景:模拟入住高峰(并发查询、预订下单、支付回调),按峰值并发乘以业务复杂度(例如数据库查询次数)制定脚本。
3.2 工具与执行:使用JMeter、Locust或k6在独立环境跑压测,记录最大RPS下的资源占用,计算每1k RPS需要的实例数和数据库连接数。
4.1 优先水平扩展:将应用设计为无状态(session存在Redis或JWT),方便横向扩容;数据库采用主从读写分离。
4.2 垂直扩展作为补充:对单机瓶颈(CPU或内存)短期内可通过升级实例规格解决,但不可作为长期唯一方案。
5.1 Kubernetes HPA:为Deployment设置requests/limits,开启HPA,命令示例:kubectl autoscale deployment web --cpu-percent=50 --min=3 --max=15。配置HorizontalPodAutoscaler YAML以支持自定义指标(Prometheus Adapter)。
5.2 集群扩容:启用Cluster Autoscaler(云上)或云厂商Auto Scaling Group(AWS/Alibaba),确保新节点启动时间与镜像拉取速度可接受,并预留启动容错时间。
6.1 应用层缓存:将热点API(房态查询、价格表)放入Redis,并设置合理TTL和缓存降级策略;对静态资源使用CDN并配置Cache-Control。
6.2 反向代理缓存:在Nginx上启用proxy_cache,示例指令:proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m inactive=60m max_size=1g;对可缓存接口设置proxy_cache_valid。
7.1 SQL调优:开启慢查询日志,优化索引与查询,批量写入改为异步或分批执行,避免长事务。
7.2 读写分离与连接池:部署只读从库并通过ProxySQL或HAProxy做读路由,调节应用端连接池(例如HikariCP)以匹配最大并发。
8.1 部署策略:采用蓝绿或金丝雀发布减少风险;每次发布保留快速回滚步骤并验证健康探针。
8.2 备份与故障切换:定期全量与增量备份数据库,演练故障切换(promote replica),记录恢复时间目标(RTO)和恢复点目标(RPO)。
9.1 高峰前准备:提前48小时执行容量预热(预生成缓存、拉起更多实例)、检查证书、升级补丁窗口外执行。
9.2 高峰期间与后处理:实时观察告警,必要时手动触发扩容或关闭非关键任务,峰后24小时内回收多余资源并分析事件记录。
10.1 事后分析:收集事中流量、错误、排队时长,进行Root Cause Analysis并输出改进任务。
10.2 持续改进:每次高峰后更新容量模型、调整HPA阈值、优化缓存策略,形成闭环SRE流程。
问题:什么时候应该手动扩容而不是完全依赖自动扩容?
回答:当预计流量突增且自动扩容反应有延迟(例如冷启动镜像、数据库连接耗尽)时,建议提前手动扩容并做预热;此外在非线性负载或第三方依赖瓶颈(支付网关)时也需人工介入。
问题:如何避免扩容导致的数据库连接耗尽?
回答:设置应用连接池上限、使用连接池代理(如ProxySQL)、对读操作走只读从库、通过中间层缓存减少直连频率,并在扩容步骤中逐步增加应用实例以观察连接增长。
问题:如何验证扩容策略在真实高峰中的有效性?
回答:在演练环境使用与生产相近的流量脚本进行压力测试并复现峰值,观察自动伸缩触发时间、冷启动时间与业务响应;结合演练结果调整HPA阈值与启动镜像优化,最终在低风险时段做一次灰度验证。