性能和可扩展性

概述

本节介绍 IoT 技术栈的性能指标和扩展能力。学习完成后，您将能够：

理解各组件的性能特性和瓶颈
评估 IoT 系统的容量和扩展方案
向客户解释系统性能指标和扩容路径
为客户提供合理的资源配置建议

System Performance Overview

各组件性能基准

组件	并发能力	吞吐量	启动时间	内存占用
Mosquitto	数千连接	~100K msg/s	< 1s	~10MB
EMQX	百万连接	~M msg/s	~5s	~100MB
Node-RED	数百 Flow	~1K msg/s	~3s	~50MB
InfluxDB	数百查询	~500K points/s	~5s	~200MB
Grafana	数百用户	取决于查询	~5s	~100MB

Horizontal vs Vertical Scaling

垂直扩展 (Vertical Scaling)

升级单台服务器:
┌──────────────────────┐
│    原始配置           │
│  2C4G → 4C8G → 8C16G│
└──────────────────────┘

优势:
- 简单，无需架构变更
- 所有组件在一台机器
- 维护成本低

限制:
- 单机上限 (~64C/512G)
- 成本非线性增长
- 单点故障

水平扩展 (Horizontal Scaling)

多服务器集群:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Node 1  │ │ Node 2  │ │ Node 3  │
│ Mosquitto│ │ Node-RED│ │ Node-RED│
│ Node-RED │ │ Grafana │ │ InfluxDB│
└─────────┘ └─────────┘ └─────────┘

优势:
- 理论上无限扩展
- 高可用（无单点故障）
- 成本线性增长

挑战:
- 架构复杂度增加
- 需要负载均衡
- 数据一致性管理

Component Performance Details

Mosquitto Performance

# 性能配置参数
listener 1883
max_connections 10000        # 最大连接数
max_inflight_messages 100    # 并行消息数
queue_qos0_messages 100      # QoS 0 队列大小
persistent_client_expiration 14d  # 持久会话过期

# 性能监控
connection_messages true
log_type all

客户端数量	消息吞吐量	CPU 使用	内存使用
500	~50K msg/s	20%	15MB
1,000	~80K msg/s	35%	25MB
5,000	~150K msg/s	60%	80MB
10,000	~200K msg/s	85%	150MB

Node-RED Performance

Flow 复杂度	消息延迟(P50)	消息延迟(P99)	最大吞吐量
简单转发	< 5ms	< 20ms	~5K msg/s
含 Function 处理	< 20ms	< 50ms	~2K msg/s
含 HTTP 调用	< 100ms	< 500ms	~500 msg/s
含 DB 写入	< 50ms	< 200ms	~1K msg/s

InfluxDB Performance

# 容量规划建议
# 100 设备，每分钟采样一次
# 100 points × 60min × 24h = 144,000 points/天
# 存储: ~10MB/天 (压缩后)
# 一年: ~3.6GB

# 1000 设备，每分钟采样一次
# 1000 points × 60min × 24h = 1,440,000 points/天
# 存储: ~100MB/天 (压缩后)
# 一年: ~36GB

Scalability Patterns

Pattern 1: Single Server (入门级)

# 配置: 2C4G
# 容量: 500 设备，每分钟采样
# 适用: PoC，小型项目

services:
  mosquitto:   # 50MB
  nodered:     # 100MB
  influxdb:    # 200MB
  grafana:     # 100MB

Pattern 2: Multi-Node (中型部署)

┌─────────────────────────────────┐
│    Load Balancer (NGINX/HAProxy) │
└────────────┬────────────────────┘
             │
    ┌────────┴────────┐
    │                  │
┌───┴───┐        ┌───┴───┐
│Broker │        │Broker │
│Node 1 │        │Node 2 │
│     (EMQX 集群) │       │
└───────┘        └───────┘
    │                  │
    └────────┬─────────┘
             │
    ┌────────┴────────┐
    │  Node-RED × N   │
    └────────┬────────┘
             │
    ┌────────┴────────┐
    │ InfluxDB × 2    │
    │ (主从/Read复制)  │
    └─────────────────┘

Pattern 3: Full HA (企业级)

┌──────────────────────┐
│    DNS Round Robin    │
└──────────┬───────────┘
           │
    ┌──────┴──────┐
    │  Load Balancer  │
    │  (Active Check) │
    └──────┬──────┘
           │
    ┌──────┴──────────────────┐
    │  EMQX Cluster × 3      │
    │  (自动故障转移)         │
    └──────┬──────────────────┘
           │
    ┌──────┴──────────────────┐
    │  Node-RED Cluster × N   │
    │  (带状态: Redis/MariaDB) │
    └──────┬──────────────────┘
           │
    ┌──────┴──────────────────┐
    │  InfluxDB Cluster × 3   │
    │  (复制 + 自动故障转移)   │
    └─────────────────────────┘

Resource Planning Guide

配置推荐

部署规模	设备数量	服务器配置	推荐架构
微型	< 50	1C2G / 2C4G	单机 Docker Compose
小型	50-500	2C4G / 4C8G	单机 + 数据备份
中型	500-5000	4C8G × 2	EMQX + 多 Node-RED
大型	5000-50000	8C16G × 4	EMQX 集群 + 负载均衡
企业级	50000+	16C32G × 8+	全集群 + HA + DR

存储规划

# 估算存储需求
# 公式: 存储 = 设备数 × 采样频率 × 数据大小 × 保留天数

# 示例: 100 设备，每分钟采样，每条记录 100 字节，保留 30 天
# = 100 × 60 × 24 × 30 × 100 = 432,000,000 bytes ≈ 432MB
# InfluxDB 压缩比例 ~10:1 → 实际 ~43MB

# 增加设备到 1000:
# = 1000 × 60 × 24 × 30 × 100 ≈ 4.3GB
# 压缩后 ≈ 430MB

Bottleneck Analysis

常见瓶颈

瓶颈点	症状	原因	解决方案
MQTT Broker	连接超时	连接数超限	升级 EMQX / 增加节点
Node-RED	消息延迟	复杂处理逻辑	拆分 Flow / 增加实例
InfluxDB	写入变慢	索引过大	优化标签设计 / 降采样
Grafana	查询超时	数据量大	增加查询缓存 / 预聚合
网络	丢包	带宽不足	升级带宽 / 数据压缩

Common Customer Questions

Q1: 这个系统能支撑我们的项目需求吗？

A: 需要评估设备数量和采样频率：

500 设备以下 → 单机方案完全够用
500-5000 设备 → EMQX + 分布式架构
5000 以上 → 全集群方案

Q2: 性能瓶颈在哪里？

A: 首要瓶颈通常是 MQTT Broker 的连接数，其次是 Node-RED 的 Flow 执行效率。建议先使用 Mosquitto 做 PoC，后续根据需求升级。

Q3: 如何确保系统高可用？

A: 关键组件配置冗余：

EMQX 集群（N+1）
Node-RED 多实例
InfluxDB 数据复制
Grafana 无状态（数据源持久化）

最佳实践

✅ 推荐做法:

从单机开始，按需扩展
使用 InfluxDB 降采样减少存储
合理设置数据保留策略
监控关键性能指标
提前做好容量规划

❌ 避免做法:

一开始就搭建复杂集群
忽略数据压缩和降采样
无监控就上生产
过度预留资源

Summary

单机方案足够覆盖大多数中小型 IoT 项目
垂直扩展简单有效，水平扩展解决更大规模
MQTT Broker 是首要考虑的性能瓶颈
合理的数据保留策略显著降低存储成本
从 PoC 到生产，按需演进架构

性能和可扩展性

概述

System Performance Overview

各组件性能基准

Horizontal vs Vertical Scaling

垂直扩展 (Vertical Scaling)

水平扩展 (Horizontal Scaling)

Component Performance Details

Mosquitto Performance

Node-RED Performance

InfluxDB Performance

Scalability Patterns

Pattern 1: Single Server (入门级)

Pattern 2: Multi-Node (中型部署)

Pattern 3: Full HA (企业级)

Resource Planning Guide

配置推荐

存储规划

Bottleneck Analysis

常见瓶颈

Common Customer Questions

Q1: 这个系统能支撑我们的项目需求吗？

Q2: 性能瓶颈在哪里？

Q3: 如何确保系统高可用？

最佳实践

Summary

References