← 返回文章列表
架构评估

腾讯云智能顾问(TSA)架构评估实战：四轮故障注入验证云上架构健康度

腾讯云智能顾问 2026/4/6
腾讯云智能顾问(TSA)架构评估实战——四轮故障注入全景

一、实验背景与目的

在云原生时代，架构的健康度直接决定了业务的稳定性与用户体验。腾讯云智能顾问(TSA)是全球首款卓越架构 AI 治理平台，能够从多个维度对云上架构进行全面评估与实时监控。

本次评估实战的目标是：在真实运行的 SH-WEB 博客服务中，依次注入 4 个不同架构层次的故障，从三个维度验证通过智能顾问 CloudQ 进行服务异常诊断发现的能力：

  1. 架构评估维度：通过 Well-Architected 六大支柱评估，检测资源健康度变化和风险项增减
  2. 日志分析维度：通过 CLS（腾讯云日志服务）日志检索，直接从日志中定位故障根因
  3. 云监控维度：通过云监控指标查询，实时发现异常状态码和资源使用率变化

这不仅是对智能顾问 CloudQ 三维检测能力的一次全面实战检验，也是故障注入（Chaos Engineering）在云上运维中的最佳实践演示。

二、SH-WEB 架构概览

被测试的 SH-WEB 博客服务是一个典型的三层 Web 应用。经过四轮故障注入实验和后续的架构治理优化，当前架构已完成全面演进：

SH-WEB 最新架构

以下是 SH-WEB 架构在腾讯云智能顾问中的架构图视图：

SH-WEB 智能顾问架构图

当前架构组件：

组件 当前方案 演进说明
CLB公网负载均衡 (111.229.134.62)后端关联 AS 伸缩组，自动摘除/添加实例
CVM竞价实例 x2（AS 弹性伸缩组管理）从包年包月改为竞价实例，成本降低 60%-80%
Nginx + Node.js无状态应用（环境变量配置）配置外置化，新实例拉起即可服务
数据库TDSQL-C MySQL Serverless从 CDB MySQL 迁移，低负载自动暂停，成本降低 83%-94%
Redis标准版 256MB用于文章列表/详情缓存，降低数据库压力
静态资源COS 对象存储（公有读）从本地磁盘迁移至 COS，消除多实例图片同步问题
日志CLS 日志服务（6 个主题）覆盖 CLB、Nginx、应用、数据库全链路

三、智能顾问 CloudQ 三维检测能力

智能顾问 CloudQ 对 SH-WEB 架构的检测能力覆盖三个互补维度：

3.1 架构评估（Well-Architected）

通过智能顾问 TSA 对云资源进行六大支柱评估：

  • 安全性：访问控制、数据保护、高危命令限制
  • 可靠性：高可用、容灾备份、健康检查
  • 性能效率：资源利用率、响应延迟
  • 成本优化：资源配置合理性、闲置检测
  • 卓越运营：运维自动化、监控覆盖度
  • 可持续性：资源生命周期管理

3.2 日志分析（CLS）

通过腾讯云日志服务进行实时日志检索与分析，覆盖 6 个日志主题：

日志主题 来源 用途
shwebLogListenerNginx error.log + 应用 ERROR 日志
clb_topicCLB 访问日志状态码、延迟、后端健康
cloud_sh_cdb_topicTDSQL-C MySQL慢查询日志

3.3 云监控指标

通过云监控 API 查询 CLB 502/504 状态码、CVM CPU/内存使用率、后端健康检查状态等实时指标。

四、基线评估

在注入任何故障之前，通过智能顾问 CloudQ 建立健康基线。

4.1 架构评估基线

支柱 得分 风险项 状态
安全506高风险
可靠8710需关注
性能1004优秀
成本763需关注
卓越运营583需改进
可持续1001优秀
总分7927—

4.2 云监控基线

CLB 后端健康状态：
  ins-cmenipyj (172.17.0.9:80)  → Alive
  ins-cu05oexx (172.17.0.15:80) → Alive
CVM 资源使用率：
  ins-cmenipyj: CPU 1.29% | MEM 21.08%
  ins-cu05oexx: CPU 2.53% | MEM 20.27%
502/504 状态码：均为 0

五、实验一：Redis 缓存层 — 连接地址错误

5.1 故障描述

将 Redis 连接地址从正确的 172.17.0.14 修改为不存在的 172.17.0.199，模拟缓存服务不可达的场景。这是生产环境中常见的配置错误，可能发生在环境迁移、配置变更等操作后。

5.2 故障注入

# 修改 config/index.js 中 Redis 连接地址
redis.host: '172.17.0.14' → '172.17.0.199'
# 重启应用使配置生效
systemctl restart tech-blog

5.3 预期与实际影响

维度 影响
响应时间每次请求增加数秒（Redis 连接超时等待）
错误日志大量 Redis connection error: connect ECONNREFUSED 172.17.0.199:6379
数据库负载所有请求穿透到 MySQL，查询量翻倍
服务状态降级运行——服务仍可用但响应变慢

5.4 智能顾问 CloudQ 检测结果

架构评估：可靠性支柱检测到 Redis 连接异常风险

CLS 日志分析：

日志主题：shweb | 来源：应用日志
23:15:32 [ERROR] Redis connection error: connect ECONNREFUSED 172.17.0.199:6379
23:15:33 [ERROR] Redis connection error: connect ECONNREFUSED 172.17.0.199:6379
... 持续报错，每秒多条

智能顾问 CloudQ 诊断结论：Redis 缓存服务地址配置错误，连接被拒绝（ECONNREFUSED），所有缓存读写操作失败。应用依赖缓存降级策略（fallback 到 MySQL）维持服务可用，但响应延迟显著增大。建议立即修正 Redis 连接配置。

六、实验二：CDB 数据库层 — 无限制全表查询

6.1 故障描述

移除文章列表查询中的 LIMIT/OFFSET 分页限制，并额外查询包含完整 HTML 的 content 字段。模拟开发中常见的 SQL 查询未加限制的问题。

6.2 故障注入

修改前（正常查询）：
SELECT id, title, summary FROM articles ORDER BY published_at DESC LIMIT 12 OFFSET 0
修改后（全表查询）：
SELECT * FROM articles ORDER BY published_at DESC -- 无 LIMIT，包含 content 大字段

6.3 预期与实际影响

维度 影响
查询性能全表扫描 + 大字段传输，查询耗时显著增加
网络 I/OMySQL 到应用的数据传输量暴增
内存使用Node.js 持有大量文章内容，内存占用上升
服务状态性能劣化——首页加载缓慢，分页失效

6.4 智能顾问 CloudQ 检测结果

架构评估：性能效率 + 成本优化支柱评分下降

CLS 日志分析：

日志主题：cloud_sh_cdb_topic | 来源：TDSQL-C 慢查询日志
Query_time: 2.847s
Rows_examined: 全表
SQL: SELECT * FROM articles ORDER BY published_at DESC

智能顾问 CloudQ 诊断结论：文章列表查询缺少 LIMIT 限制，且 SELECT * 包含了大量 HTML content 字段，导致全表扫描和大量数据传输。建议添加分页限制并只查询必要字段。

七、实验三：应用层 — 事件循环阻塞

7.1 故障描述

在 /health 健康检查端点中注入一个同步阻塞循环，使每次健康检查耗时 5 秒。由于 Node.js 是单线程模型，健康检查阻塞期间所有其他请求都将被挂起。

7.2 故障注入

// routes/index.js — 健康检查端点
router.get('/health', (req, res) => {
  const start = Date.now();
  while (Date.now() - start < 5000) {} // 阻塞 5 秒
  res.json({ status: 'ok' });
});

7.3 预期与实际影响

维度 影响
健康检查CLB 探测超时，后端可能被标记为不健康
全局影响所有路由在健康检查执行期间被阻塞 5 秒
可用性服务间歇性不可用，用户体验严重劣化
服务状态间歇性中断——周期性卡顿

7.4 智能顾问 CloudQ 检测结果

架构评估：可靠性 + 性能效率支柱评分下降，检测到单点故障风险

CLS 日志分析：

日志主题：clb_topic | 来源：CLB 访问日志
timestamp HEAD /health → upstream_status: 504 | response_time: 5.002s
日志主题：shweb | 来源：Nginx error.log
timestamp [error] upstream timed out (110: Connection timed out) while reading response header from upstream

智能顾问 CloudQ 诊断结论：健康检查端点存在同步阻塞操作，单次执行耗时超过 CLB 超时阈值（2 秒），导致 CLB 探测超时返回 504。由于 Node.js 单线程特性，阻塞期间所有请求被挂起。建议将耗时操作改为异步执行或移出健康检查路径。

八、实验四：Nginx 反向代理层 — upstream 配置错误

8.1 故障描述

将竞价实例上 Nginx 反向代理的 upstream 端口从正确的 3000 修改为不存在的 3999。模拟运维配置变更过程中的人为错误，尤其在弹性伸缩架构下镜像更新时极易引入此类问题。

8.2 故障注入

修改前：
upstream blog_app { server 127.0.0.1:3000; }
修改后：
upstream blog_app { server 127.0.0.1:3999; } ← 错误端口

8.3 预期与实际影响

维度 影响
CLB 502 状态码约 50%-70% 请求返回 502（轮询到故障实例时）
Nginx error.log大量 connect() failed (111: Connection refused) 指向 127.0.0.1:3999
健康检查CLB 健康检查最终将故障实例标记为不健康并摘除
服务状态间歇性 502 Bad Gateway，直到健康检查摘除故障实例

8.4 智能顾问 CloudQ 三维检测结果

维度一：云监控指标

智能顾问 CloudQ 云监控查询：CLB 502 状态码（1 分钟粒度）
| 23:28 | 0     | 23:29 | 0     |
| 23:30 | 15    | 23:31 | 11    |

维度二：CLS 日志分析

shweb — Nginx error.log：
[error] connect() failed (111: Connection refused) while connecting to upstream: "http://127.0.0.1:3999/"
clb_topic — CLB 访问日志：
GET /article/15 → upstream: 172.17.0.9:80 → status: 502 | response_time: 0.001s

维度三：Well-Architected 评估

评估已提前识别「CVM 竞价实例回收风险」和「单可用区部署」等相关风险项。

智能顾问 CloudQ 根因还原：

客户端 → CLB (111.229.134.62)
↓ WRR 轮询
Nginx (172.17.0.9:80)
↓ proxy_pass
127.0.0.1:3999 ← 端口无进程监听！
errno=111 → Nginx 502 → CLB 透传 502

智能顾问 CloudQ 诊断结论：根因为 Nginx upstream 配置错误，将代理端口指向了不存在的 3999 端口。应用服务运行在 3000 端口，Nginx 无法建立连接，每次请求立即返回 Connection refused（errno 111），导致 502。在弹性伸缩架构下，若此错误被写入镜像，所有新扩容实例都将携带相同故障。

九、四轮实验全景对比

对比维度 实验一
Redis 缓存层		 实验二
MySQL 数据库层		 实验三
Node.js 应用层		 实验四
Nginx 代理层
故障类型连接地址错误无限制全表查询事件循环阻塞upstream 端口错误
主要影响支柱可靠 + 性能性能 + 成本可靠 + 性能可靠 + 运营
Well-Architected✔✔✔✔
CLS 日志分析✔ ECONNREFUSED✔ 慢查询✔ upstream timeout✔ Connection refused
云监控指标———✔ 502 指标
服务影响降级运行性能劣化间歇中断50%+ 502
关键日志特征ECONNREFUSED
172.17.0.199:6379		Query_time > 2s
Rows_examined: ALL		upstream timed out
504 Gateway Timeout		errno=111 refused
502 Bad Gateway

十、架构演进成果

四轮故障注入实验验证了智能顾问 CloudQ 的多维检测能力后，我们基于实验发现的架构薄弱点进行了一系列优化改造：

改造项 改造前 改造后 成本变化
计算层2x CVM 包年包月竞价实例 + AS 弹性伸缩-60%~80%
数据库CDB MySQL 包年包月TDSQL-C Serverless-83%~94%
静态资源CVM 本地磁盘 + MySQL BLOBCOS 对象存储（公有读）< 1 元/月
应用层有状态（本地文件依赖）无状态 + 环境变量配置—
总月成本~580 元/月~90-190 元/月-67%~84%

十一、总结与启示

通过本次智能顾问 CloudQ 架构治理实战，我们完成了从发现问题到解决问题的完整闭环：

  1. 故障注入（Chaos Engineering）：分别在缓存层、数据库层、应用层、网络代理层注入 4 种典型故障
  2. 智能顾问 CloudQ 三维检测：验证了 Well-Architected 架构评估、CLS 日志分析和云监控指标三个维度的故障发现与定位能力
  3. 架构治理：基于实验发现的薄弱点，完成了数据库、静态资源、应用层、计算层的全面优化
  4. 成本优化：月成本从 ~580 元降至 ~90-190 元，节省 67%-84%

实践启示：智能顾问 CloudQ 的三维检测能力在弹性伸缩架构中尤为重要——

1. 预防（Well-Architected 评估）：在故障发生前识别竞价实例回收、单可用区等架构风险
2. 发现（云监控指标）：通过 502 状态码等指标实时感知异常
3. 定位（CLS 日志分析）：从 Nginx、CLB、应用、数据库全链路日志精确定位根因

这三个维度形成「预防 → 发现 → 定位」的完整闭环，结合故障注入验证和架构治理优化，持续提升云上架构的健康度。

← 返回文章列表