当前位置：首页 > news >正文

从一次线上故障复盘说起：我是如何用阿里云SLB+ECS+OSS架构，差点搞垮自己网站的

news 2026/4/29 6:12:53

阿里云架构实战：一次SLB健康检查引发的网站雪崩与深度修复

1. 故障现场：凌晨三点的报警风暴

那是个再普通不过的周三凌晨，我的手机突然开始疯狂震动。打开监控平台，满屏的HTTP 503错误像瘟疫般蔓延——公司核心电商网站正在大面积瘫痪。更可怕的是，这种故障呈现波浪式扩散：最初只是部分用户无法访问商品详情页，10分钟后整个支付网关开始超时，最终连首页都彻底失去响应。

关键故障现象：

阿里云监控显示SLB健康检查成功率从99.98%暴跌至12.3%
ECS CPU使用率异常：部分实例持续100%，另一些却低于5%
OSS外网流量激增300%，费用预警短信接踵而至

# 紧急排查时使用的SLB状态检查命令 aliyun slb DescribeHealthStatus --LoadBalancerId lb-bp1b6c719dfa08****

当我登录SLB控制台时，发现了更诡异的现象——同一个服务器组内的ECS实例，有的被标记为"正常"，有的却是"异常"。而这些实例运行的是完全相同的Docker镜像，理论上行为应该一致。

2. 抽丝剥茧：健康检查的致命陷阱

2.1 安全组配置的隐藏冲突

深入检查发现，问题根源在于安全组配置的精细度失控。我们为支付服务ECS配置的安全组规则中：

错误配置示例：

{ "SecurityGroupRule": { "IpProtocol": "tcp", "PortRange": "443/443", "SourceCidrIp": "0.0.0.0/0", "Policy": "accept" } }

看似开放的443端口，实际上与SLB健康检查机制产生了冲突。阿里云SLB的健康检查流量来自100.64.0.0/10地址段，而我们的安全组却：

未明确放行SLB专用IP段
未区分内网/外网访问策略
未设置健康检查专用端口

关键发现：SLB健康检查包被安全组误判为恶意流量，导致50%的ECS实例被错误隔离

2.2 多米诺骨牌效应

随着健康检查失败，SLB开始将流量集中到剩余正常实例上，引发连锁反应：

幸存ECS因流量过载出现HTTP 503
前端自动重试机制导致请求风暴
静态资源回源到OSS，产生巨额外网流量
CDN缓存失效加剧了OSS压力

流量激增对比表：

时间点	正常QPS	故障QPS	OSS流量(Mbps)
00:00	2,500	2,500	120
00:30	-	8,700	490
01:00	-	12,300	890

3. 紧急止血：三线作战的修复方案

3.1 立即措施：手动接管流量分配

SLB权重调整：

aliyun slb SetBackendServers --LoadBalancerId lb-bp1b6c719dfa08**** \ --BackendServers '[{"ServerId":"i-bp1g6zv0ce8o****","Weight":"100"}]'

安全组紧急更新：

# 使用Python SDK添加健康检查规则 import aliyunsdkcore from aliyunsdkecs.request.v20140526 import AuthorizeSecurityGroupRequest request = AuthorizeSecurityGroupRequest.AuthorizeSecurityGroupRequest() request.set_SecurityGroupId('sg-bp15ed6xe1yx****') request.set_IpProtocol('tcp') request.set_PortRange('80/80') request.set_SourceCidrIp('100.64.0.0/10') request.set_Policy('accept')

CDN预热关键静态资源：

# 使用OSSUTIL进行批量预热 ossutil64 prefetch oss://bucket-name/path/to/file --endpoint oss-cn-hangzhou.aliyuncs.com

3.2 架构优化：构建弹性防护体系

新版安全组设计原则：

分层隔离：web/应用/DB分别独立安全组
最小权限：精确到端口级的访问控制
健康检查专用通道

优化后的安全组规则矩阵：

类型	协议	端口	源IP	适用场景
SLB-HC	TCP	8088	100.64.0.0/10	健康检查专用
Internal-API	TCP	5000	10.0.0.0/16	内部服务通信
Public-WEB	TCP	443	0.0.0.0/0	对外HTTPS服务

3.3 成本控制：OSS流量治理方案

启用CDN全站加速：

-- 通过RAM配置CDN访问策略 { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "oss:GetObject", "Resource": "acs:oss:*:*:mybucket/*", "Condition": { "StringLike": { "acs:Referer": ["https://www.example.com/*"] } } } ] }

设置OSS生命周期规则：

<LifecycleConfiguration> <Rule> <ID>transition-to-ia</ID> <Prefix>logs/</Prefix> <Status>Enabled</Status> <Transition> <Days>30</Days> <StorageClass>IA</StorageClass> </Transition> </Rule> </LifecycleConfiguration>

4. 防患未然：构建四层监控体系

4.1 实时健康检查看板

使用云监控CMS搭建的监控看板应包含：

SLB健康检查成功率
ECS实例异常率对比
安全组规则命中次数
OSS外网流量突增告警

Prometheus监控规则示例：

groups: - name: slb_healthcheck rules: - alert: SLBHealthCheckCritical expr: sum(rate(slb_health_check_failed_total[1m])) by (slb_id) / sum(rate(slb_health_check_total[1m])) by (slb_id) > 0.3 for: 5m labels: severity: critical annotations: summary: "SLB {{ $labels.slb_id }} 健康检查失败率超过30%"

4.2 混沌工程测试方案

建立常态化故障演练机制：

网络隔离测试：

# 模拟安全组误操作 iptables -A INPUT -p tcp --dport 8088 -j DROP

负载突增测试：

# 使用Locust模拟流量激增 from locust import HttpUser, task class StressTest(HttpUser): @task def get_product(self): self.client.get("/product/123")

故障切换演练：

# Terraform模拟ECS实例故障 resource "alicloud_instance" "web" { count = 2 # ... } resource "null_resource" "kill_instance" { triggers = { instance_id = alicloud_instance.web[0].id } provisioner "local-exec" { command = "aliyun ecs StopInstance --InstanceId ${alicloud_instance.web[0].id}" } }