2. 部署架构选型与硬件规划：单节点 vs 微服务架构、硬件资源估算（CPU/内存/磁盘/网络）、操作系统内核参数优化
在 ThingsBoard 生产部署中，架构选型直接决定系统的扩展能力与运维复杂度。本章从单节点与微服务架构的对比出发，给出硬件资源估算方法，并总结操作系统内核参数的调优要点，帮助你在项目初期做出合理决策。
2.1 单节点 vs 微服务架构：适用场景与核心差异
ThingsBoard 支持两种部署模式：单节点（Monolithic） 与 微服务（Microservices）。选择依据主要取决于设备规模、可用性要求与团队运维能力。
| 对比维度 | 单节点架构 | 微服务架构 |
|---|---|---|
| 设备接入量 | ≤ 10 万设备 | 10 万 ~ 1000 万+ 设备 |
| 消息吞吐 | ≤ 5 万 msg/s | 10 万 ~ 100 万+ msg/s |
| 高可用 | 需外部负载均衡 + 数据库主备 | 原生支持服务级冗余与自动故障转移 |
| 扩展方式 | 垂直扩展（升级单机硬件） | 水平扩展（增加服务实例） |
| 运维复杂度 | 低，单进程管理 | 高，需容器编排、服务发现、监控告警 |
| 适用阶段 | PoC、小规模生产、边缘节点 | 大规模生产、多租户、7×24 高可用 |
选型建议： 若设备数 < 5 万且允许短时停机维护，优先选择单节点架构以降低运维成本；若设备数 > 20 万或要求 99.99% 可用性，必须采用微服务架构。
2.2 微服务架构组件与数据流
微服务模式下，ThingsBoard 将核心功能拆分为独立服务，每个服务可独立扩缩容。下图展示了典型微服务部署的组件关系与数据流向。
2.3 硬件资源估算方法
硬件规划需结合设备数量、消息频率、规则链复杂度与数据保留策略。以下给出基于实际压测经验的估算公式与参考值。
2.3.1 CPU 估算
- 单节点基准： 每 1 万设备（每秒 1 条消息）约需 2 个 vCPU（2.5 GHz+）。
- 微服务拆分： 传输层服务（TB-Transport）对 CPU 敏感，建议按每 5 万设备分配 4 vCPU；规则引擎服务按规则链复杂度增加 30%~50% 额外 CPU。
- 公式：
总 vCPU ≈ (设备数 × 消息频率 / 10000) × 2 × (1 + 规则链系数)
2.3.2 内存估算
- JVM 堆内存： ThingsBoard 基于 Java 11/17，建议堆内存不低于 8 GB，每增加 1 万设备增加 2 GB 堆内存。
- Redis 缓存： 设备会话与最新遥测缓存，建议分配 4~16 GB，取决于设备活跃度。
- 操作系统预留： 保留总内存的 20% 给文件系统缓存与内核。
2.3.3 磁盘估算
- 元数据（PostgreSQL）： 每 10 万设备约需 50 GB，含设备信息、用户、仪表盘等。
- 时序数据（Cassandra/TimescaleDB）： 按每条遥测记录 200 字节计算，每日数据量 =
设备数 × 消息频率 × 86400 × 200 / 1024³ (GB)。 - Kafka 日志： 建议保留 72 小时，预留 500 GB~2 TB。
- 磁盘类型： 时序数据库与消息队列必须使用 NVMe SSD，元数据可使用 SSD 或高性能 HDD。
2.3.4 网络带宽估算
- 设备上行： 每 1 万设备每秒 1 条 1 KB 消息，上行带宽需求 ≈ 80 Mbps。
- 服务间通信： 微服务架构下，传输层到 Kafka、Kafka 到规则引擎的流量约为设备上行流量的 1.2~1.5 倍。
- 建议： 生产环境至少配备 10 Gbps 内网，跨机房部署时使用专线或 VPN 隧道。
硬件配置参考表（10 万设备，每秒 1 条消息）：
| 组件 | 单节点 | 微服务（最小集群） |
|---|---|---|
| TB 主服务 | 16 vCPU / 32 GB RAM | 8 vCPU / 16 GB RAM × 2 实例 |
| Kafka | —（内置队列） | 8 vCPU / 16 GB RAM × 3 节点 |
| PostgreSQL | 8 vCPU / 16 GB RAM | 8 vCPU / 16 GB RAM × 2（主备） |
| Cassandra | —（可选） | 16 vCPU / 32 GB RAM × 3 节点 |
| Redis | 4 vCPU / 8 GB RAM | 4 vCPU / 8 GB RAM × 2（哨兵模式） |
| 网络 | 1 Gbps | 10 Gbps 内网 |
2.4 操作系统内核参数优化
ThingsBoard 依赖 Java NIO、Netty 与 Kafka 等网络密集型组件，操作系统内核参数直接影响高并发下的连接稳定性与吞吐量。
2.4.1 文件描述符与连接数
# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576
* soft nproc 65536
* hard nproc 65536
# /etc/sysctl.conf
fs.file-max = 20971522.4.2 网络协议栈优化
# TCP 连接重用与快速回收
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
# 增大 TCP 读写缓冲区
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 连接积压队列
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
# 启用 TCP 快速打开（TFO）
net.ipv4.tcp_fastopen = 32.4.3 虚拟内存与 I/O 调度
# 降低 swap 使用倾向（Java 应用）
vm.swappiness = 10
# 增大脏页回写阈值，减少 I/O 抖动
vm.dirty_ratio = 30
vm.dirty_background_ratio = 5
# 磁盘 I/O 调度器（NVMe SSD 建议 none）
# 查看当前调度器：cat /sys/block/nvme0n1/queue/scheduler
# 临时修改：echo none > /sys/block/nvme0n1/queue/scheduler2.4.4 内核参数生效与验证
# 立即生效
sysctl -p
# 验证关键参数
sysctl net.ipv4.tcp_tw_reuse
sysctl vm.swappiness
ulimit -n
注意： 修改内核参数前请备份原配置文件。生产环境变更后需观察 24 小时，重点关注连接数、TCP 重传率与磁盘 I/O 延迟。若使用容器化部署，需在宿主机与容器内同时调整相关参数。
2.5 架构选型决策流程
以下流程图帮助你在项目初期快速确定部署架构方向。
2.6 本章小结
- 单节点架构 适合设备数 ≤ 10 万、允许短时停机的场景，运维简单，成本低。
- 微服务架构 适合大规模、高可用场景，各组件可独立扩缩容，但需要容器编排与监控体系支撑。
- 硬件估算 需综合考虑 CPU、内存、磁盘 I/O 与网络带宽，时序数据库与消息队列是性能瓶颈点。
- 内核参数优化 应作为部署标准步骤，重点调整文件描述符、TCP 协议栈与虚拟内存策略。