跳转至

01 系统思维：先看问题，再看技术

难度：入门｜前置：无｜目标：建立整套课程的分析框架

为什么从这里开始

技术容易让人产生错觉：

设备多 → 用 Redis
请求慢 → 加缓存
任务复杂 → 上 MQ
AI 功能 → 用 Agent

这些答案可能对，也可能把问题变得更复杂。高级工程能力首先不是知道更多产品名，而是能把模糊问题拆清楚。

五个基本问题

1. 用户目标是什么

“查询设备”可能分别指：

  • 页面显示一页设备；
  • 统计在线数量；
  • 导出十万设备；
  • 查过去七天遥测；
  • 实时观察状态变化。

如果目标不同，方案就不同。

2. 系统的事实是什么

事实是业务必须相信和追溯的数据。

例如：

  • 设备最后一次心跳时间；
  • 工具调用的 operation_id；
  • 订单已支付；
  • Agent 某一步已完成。

缓存、统计值和页面结果往往只是由事实构造出的查询视图。

3. 数据怎样流动

画最短的数据流：

输入 → 接收 → 校验 → 处理 → 保存 → 输出

然后补上异步边界：

设备 → MQTT → 状态服务 → Redis
                    └→ MQ → 历史记录

4. 什么必须正确

系统要求不是只有“快”：

约束 问题
正确性 能不能重复创建或扣费？
一致性 用户是否允许短暂看到旧状态？
延迟 100ms 和 10s 有什么业务差别？
可用性 某个组件挂了是否还能提供核心服务？
可恢复 服务重启后任务从哪里继续？
安全 谁可以读取和操作？
成本 请求量扩大后花费是否可控？

5. 怎样知道它坏了

如果系统失败后只能等客户反馈，就还没有生产能力。至少要提前定义：

  • 成功率；
  • 延迟；
  • 错误类型；
  • 队列积压；
  • 状态漂移；
  • 资源和成本。

一个贯穿全课程的模型

以后遇到问题，按这个顺序回答：

场景
→ 规模
→ 事实
→ 数据流
→ 正确性约束
→ 失败方式
→ 监控指标
→ 扩展方案

例子：设备在线状态

  1. 场景：页面显示某租户的一页设备；
  2. 规模：10 万设备，30 秒心跳；
  3. 事实：last_seen 和连接事件；
  4. 查询视图：Redis 在线状态和在线集合；
  5. 正确性：重复心跳不能重复上线；
  6. 失败：断电、乱序、Redis 丢失；
  7. 指标：心跳延迟、在线数漂移、处理积压；
  8. 扩展：按租户或设备 ID 分片。

自测

  1. “十万设备查询慢”至少要先澄清哪三件事？
  2. 数据库里的 online=true 一定是事实吗？
  3. 为什么监控指标应该在设计阶段定义？

完成标准

  • 能不看文章说出八步分析模型
  • 能为自己做过的一个 IoT 功能画数据流
  • 能指出其中的事实、缓存和统计视图
  • 能列出至少三个失败方式

下一单元：网络与通信