第2章：系统架构设计——智能家居分层架构与边缘云协同
做智能家居系统，我最怕听到的一句话就是：「先搭起来再说，架构后面再优化。」
嗯，这话我听过太多次了。结果呢？设备一多，网络一乱，数据一堵，整个系统就像老式电话交换机——谁都在喊，谁也听不清。今天这一章，咱们就把智能家居的骨架讲清楚。
2.1 为什么需要分层架构？
说白了，智能家居不是一台设备的事。它是一堆设备、一堆协议、一堆数据、一堆用户需求的大杂烩。如果不分层，你想想看——一个灯泡坏了，可能把整个系统搞崩。
我习惯把智能家居系统拆成四层：感知层、网络层、平台层、应用层。每一层各司其职，互不干扰。就像盖楼，地基归地基，水电归水电，装修归装修。
核心原则：上层依赖下层，下层不感知上层。这样换灯泡不用改App，换网关不用动传感器。
2.2 感知层——最接地气的一层
感知层就是那些「长眼睛、长耳朵」的设备。温度传感器、人体红外、门磁、烟雾报警器、摄像头……它们负责采集物理世界的数据。
我在项目中遇到过一个问题：一个客户家里装了50多个传感器，结果网关撑不住了。为什么？因为感知层设备太多，数据上报频率太高。后来我建议他把温度传感器改成「变化上报」模式——温度变化超过0.5度才上报，而不是每秒都报。问题立刻解决。
避坑指南：我曾经在选型时忽略了传感器的功耗。结果客户用了三个月就得换电池，投诉电话打爆了。记住：感知层设备往往是电池供电，低功耗设计是第一优先级。
感知层的关键技术点：
- 传感器选型：精度、量程、响应时间、功耗
- 数据采集策略：定时上报 vs 事件触发 vs 变化上报
- 本地预处理：简单的滤波、去噪、阈值判断可以在传感器端完成
2.3 网络层——数据的「高速公路」
网络层负责把感知层的数据传到平台层。这里最头疼的是协议选择。Wi-Fi、Zigbee、Z-Wave、BLE Mesh、Thread……每个协议都有自己的脾气。
我个人习惯这样选：
- Wi-Fi：适合高带宽设备（摄像头、音箱），但功耗高，不适合电池设备
- Zigbee：低功耗、自组网，适合传感器和开关，但需要网关
- BLE Mesh：手机直连方便，但大规模组网稳定性不如Zigbee
- Thread：新秀，基于IPv6，但生态还不够成熟
注意：千万不要在一个系统里混用太多协议。我见过一个项目，Wi-Fi、Zigbee、BLE全上了，结果调试时光是协议转换就占了开发周期的一半。能统一就统一，不能统一就用网关做协议桥接。
网络层还有一个关键点：边缘计算。说白了，就是让数据在本地先处理一遍，别什么都往云端扔。
2.4 平台层——系统的「大脑」
平台层是核心。它负责设备管理、数据存储、规则引擎、用户管理、安全认证等等。你可以把它理解成智能家居的操作系统。
我参与过一个项目，平台层用的是自研的微服务架构。每个服务独立部署，比如设备管理服务、场景编排服务、告警服务。这样好处是：场景编排挂了，设备还能正常控制。坏处是：开发成本高，小团队玩不转。
平台层的核心模块：
| 模块 | 功能 | 我踩过的坑 |
|---|---|---|
| 设备管理 | 设备注册、状态同步、固件升级 | 设备离线重连时，状态不同步，导致App显示错误 |
| 规则引擎 | 条件触发、动作执行、场景编排 | 规则循环触发（A开灯→B关灯→A开灯），死循环了 |
| 数据存储 | 时序数据、设备日志、用户配置 | 时序数据库选型不当，查询历史数据慢得像蜗牛 |
| 安全认证 | 设备鉴权、用户登录、数据加密 | 设备证书过期，导致大批设备无法上线 |
我的建议：平台层尽量用成熟的开源方案，比如ThingsBoard、Kaa、SiteWhere。别自己从头造轮子，除非你团队有20个后端工程师。
2.5 应用层——用户看得见的部分
应用层就是App、小程序、语音助手、Web控制台这些。用户不关心底层是Zigbee还是Wi-Fi，他们只关心「我喊一声小爱同学，灯能不能亮」。
应用层设计有个原则：响应速度要快。你想想看，用户按一下开关，等3秒灯才亮，这体验能好吗？
我做过一个测试：从App发送指令到设备执行，端到端延迟超过500ms，用户就会觉得「卡」。所以，关键指令（开关灯、开关门锁）一定要走边缘计算，别绕到云端再回来。
2.6 边缘计算与云端协同——真正的实战要点
这是本章的重头戏。边缘计算和云端不是替代关系，是协同关系。我习惯这样分工：
- 边缘侧：实时控制、本地场景、设备联动、数据预处理
- 云端侧：大数据分析、远程访问、固件升级、AI训练
举个例子：你设置了一个场景「离家模式」——关灯、关空调、关窗帘、开启安防。这个场景如果走云端，万一网络断了，你离家时设备没关，多危险？
所以，关键场景一定要在边缘侧执行。网关或者中控屏上跑一个本地规则引擎，断网也能正常工作。
实战技巧：我曾经在网关里部署了一个轻量级的Node-RED，用来跑本地自动化规则。云端用Kafka接收边缘上报的数据，做长期分析和告警。这样既保证了实时性，又保留了云端的能力。
边缘计算的技术选型：
- 硬件：树莓派、RK3399、ESP32（轻量级）、NVIDIA Jetson（带AI推理）
- 软件：Node-RED、K3s（轻量K8s）、EdgeX Foundry、AWS Greengrass
- 通信：MQTT（首选）、CoAP、HTTP/2
注意：边缘设备的资源有限，别把云端的复杂逻辑直接搬过来。我曾经见过有人把TensorFlow模型直接跑在ESP32上，结果内存溢出，设备反复重启。边缘计算要做减法，只保留最核心的功能。
2.7 一个完整的架构示例
说了这么多，不如看一个实际的架构图（文字描述版）：
┌─────────────────────────────────────────────────────┐
│ 应用层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 手机App │ │ 语音助手 │ │ Web控制台 │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
├─────────────────────────────────────────────────────┤
│ 平台层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 设备管理 │ │ 规则引擎 │ │ 数据存储/分析 │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
├─────────────────────────────────────────────────────┤
│ 网络层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 边缘网关 │ │ 协议转换 │ │ 本地规则引擎 │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
├─────────────────────────────────────────────────────┤
│ 感知层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 传感器 │ │ 执行器 │ │ 摄像头/门锁 │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
└─────────────────────────────────────────────────────┘这个架构我用了好几年，从几十个设备的小项目到上千个设备的大项目，基本都能覆盖。核心就是：边缘扛实时，云端扛智能。
2.8 本章小结
嗯，这一章内容不少。我帮你捋一下重点：
- 分层架构是智能家居系统的基石，别偷懒
- 感知层关注功耗和采集策略，别让传感器把网关累死
- 网络层协议选择要统一，边缘计算要落地
- 平台层用成熟方案，别自己造轮子
- 应用层响应速度是关键，500ms是红线
- 边缘与云端协同：边缘做实时，云端做智能
下一章，咱们聊聊具体的场景编排引擎设计。到时候我会拿一个真实的项目案例来拆解，保证让你看完就能上手。