分享｜五分钟了解 ThingsBoard 物联网平台多种部署场景

• 部署场景概览
  • 单机部署
    • 场景A-All in One
    • 场景B-外部数据库
  • 集群部署
    • 场景C-Docker 部署
    • 场景D-Docker Swarm 部署
    • 场景E-k8s部署
• 总结与建议
• 常见问题FAQ

ThingsBoard作为一款强大的物联网平台，支持多种部署架构，根据不同的需求和场景，用户可以选择最适合的部署方式。本文将快速概述ThingsBoard支持的三种主要部署场景，并对它们的优缺点以及使用场景进行简要介绍。

不同的部署方式取决于用户对性能要求

• 生产中或每年连接的设备、资产、客户、客户用户和租户的总数；

• 每台设备每天的最大和平均消息量；

• 设备有效负载的最大和平均大小；

• 每条消息中的平均数据点数量；

• 用于设备连接的通信协议或集成类型；

• 实体数据生命周期（以年为单位）。

示例：

100,000 个 LoRaWAN 设备每小时向云端发送一次消息。每个消息结构如下：

{
    "pulseCounter": 1234567, 
    "leakage": false, 
    "batteryLevel": 81
}

ThingsBoard 通过 HTTP 或 MQTT 从可用网络服务器之一接收上行链路消息。在这种情况下，ThingsBoard 持续维护 10,000 个设备，典型的消息速率为每秒 100,000 / 3600 = 28 条消息，每条消息传递 3 个数据点。

部署场景概览

单机部署

场景A-All in One

架构

• ThingsBoard 平台 与 PostgreSQL 数据库部署在一台机器中

• 默认的内存队列

硬件要求:

• 一台具备足够计算和内存资源的服务器，具体要求取决于设备和数据规模。推荐使用至少2核CPU和8GB RAM的服务器。

适用场景：

• 小规模应用： 单机部署适用于设备数量较少、数据流量相对较小的小规模应用场景。这可以包括家庭自动化系统、小型工业监控等。

• 开发和测试环境： 在开发和测试过程中，为了简化部署和调试，通常会选择单机部署。这有助于加速开发周期，快速验证新功能和设备接入。

优缺点

优点	缺点
简单易用： 单机部署是最简单的 ThingsBoard 部署方式之一，无需复杂的架构和配置。	可伸缩性有限： 单机部署的主要限制在于其有限的可伸缩性，当设备数量和数据流量增加时，可能会面临性能瓶颈。
资源消耗低： 单机部署相对较轻量，适用于资源有限的环境。	单点故障： 由于所有组件运行在单一服务器上，存在单点故障的风险。一旦服务器发生故障，整个系统将不可用。
快速启动： 由于只涉及一个服务器，启动和配置过程相对迅速。	不适用于大规模应用： 对于大规模 IoT 应用，单机部署可能无法满足高并发和大量设备管理的需求。

实施部署

关于如何进行单机部署，可以参考文章分享｜五分钟学会 ThingsBoard 本地编译运行和 Linux 部署

场景B-外部数据库

与场景A相似，但数据库运行在单独服务器中。

架构

• ThingsBoard 平台
• 外部托管的数据库（PostgreSQL或Cassandra）
• 内存队列或 MQ

硬件要求：

• 一台服务器用于运行 ThingsBoard 的核心组件。

• 一台独立的服务器用于运行数据库，需要足够的计算和内存资源。

适用场景：

• 外部数据库单机部署适用于需要独立管理数据库的场景，通常是因为对数据库性能、可用性和备份有更高要求。这种部署方式使得数据库可以独立于 ThingsBoard 服务器进行升级、维护和备份。

优缺点

优点	缺点
数据库独立性： 外部数据库的单机部署使得数据库可以独立于 ThingsBoard 服务器运行，提高了系统的灵活性和可维护性。	复杂性增加： 部署和管理两个独立的服务器（ThingsBoard 和数据库）可能会增加部署的复杂性。
性能和可用性： 可以通过专用的数据库服务器来优化数据库性能，提高可用性和容错性。	部署成本： 需要额外的硬件资源和维护成本，可能会增加整体部署的成本。
	单点故障： 由于所有组件运行在单一服务器上，存在单点故障的风险。一旦服务器发生故障，整个系统将不可用。

集群部署

场景C-Docker 部署

将 ThingsBoard 的各个核心微服务（如 Core、JS-Executor、Web-UI 等）进行容器化处理。在一台 Docker 主机上，构建、启动并连接这些微服务容器，形成一个高度整合的 ThingsBoard 环境。

架构

• 单服务器，支持 Docker 容器化部署
• ThingsBoard 微服务（传输、规则引擎等）
• Kafka 消息队列
• Cassandra 或 PostgreSQL 数据库

硬件要求：

• 用于运行 ThingsBoard 的多个微服务的 Docker 容器。

• 服务器需要足够的计算和内存资源。

• 根据预期的负载，可能需要使用负载均衡器。

适用场景：

• 小型到中型规模应用，开发、测试、以及小规模生产环境。

实施部署

关于使用微服务的方式部署ThingsBoard，上一篇文章分享｜五分钟快速学会 ThingsBoard 打包镜像和 Docker 部署中有简单的案例（虽然是单节点）。

场景D-Docker Swarm 部署

将 ThingsBoard 的各个微服务（包括 Core、JS-Executor、Web-UI等）容器化，并在多个 Docker 主机上构建 Swarm 集群，其中包括 Swarm Manager 和多个 Worker 节点。

架构

• Docker Swarm 集群
• ThingsBoard 微服务（传输、规则引擎等）
• Kafka 消息队列
• Cassandra 或 PostgreSQL 数据库

Docker单节点部署与Docker Swarm集群对比

特性	Docker Compose	Docker Swarm
部署复杂度	相对简单，小规模生产环境	较为复杂，适用于小型到中型生产环境
可扩展性	适用于小规模，不太适合横向扩展	提供横向扩展和自动化管理，适用于大规模应用
高可用性	对高可用性的支持相对较弱	多节点集群提供高可用性，无单点故障
学习成本	低，快速上手	较高，学习曲线较陡峭
资源需求	较低，适用于轻量级应用	需要更多硬件资源，适用于大规模复杂应用

场景E-k8s部署

支持微服务架构，可扩展到数百万台设备。

架构

• Kubernetes 集群
• ThingsBoard 微服务（传输、规则引擎等）
• Kafka 消息队列
• Redis 分布式缓存
• Cassandra 或 PostgreSQL 数据库

硬件要求：

• 用于运行 ThingsBoard 的多个服务的服务器群集。

• 每个服务器需要足够的计算和内存资源。

• 根据预期的负载，可能需要使用负载均衡器。

适用场景：

• 微服务架构集群部署适用于大规模 IoT 应用，其中包含大量设备、高并发数据处理和复杂的业务逻辑。这种部署方式允许横向扩展，以适应不断增长的设备和数据负载。

优缺点

优点	缺点
高度可伸缩： 微服务架构允许根据需要添加或移除微服务实例，以适应负载的变化。	部署和管理复杂性： 微服务架构的部署和管理相对复杂，需要了解容器编排和微服务治理的概念。
灵活性和模块化： 微服务可以独立开发、部署和维护，提高了系统的灵活性和模块化程度。	资源消耗较大： 相对于单机部署，微服务架构可能需要更多的硬件资源。
容器化部署： 使用容器化技术，可以更方便地部署、升级和管理微服务。
高可用性： 部署在集群中的微服务可以通过负载均衡器提高系统的可用性和容错性。

总结与建议

不同场景适用于不同规模和需求的物联网解决方案。单机部署适用于开发环境和初创公司，而微服务架构集群部署适用于大规模的物联网应用。选择正确的部署场景取决于TCO、性能和高可用性的要求。在投入生产之前，建议设置数据备份脚本并定期将数据库快照上传到持久存储，以确保系统的可靠性和稳定性。希望本文对您理解ThingsBoard的部署场景提供了帮助。

常见问题FAQ

Q：Docker Swarm 与 Kubernetes（K8s）如何取舍？

A：Docker Swarm 适用于轻量级、简单的部署，相较于 K8S 更简单，适用于较小规模和较简单的部署需求。
以下是我总结的两者间的对比：

使用 Kubernetes（K8s）	使用 Docker Swarm
使用场景	使用场景
大规模集群管理： 当需要部署和管理大规模的微服务集群时，K8s提供了强大的自动化和调度功能，适用于复杂的场景。	简单部署需求： Docker Swarm 更适合对部署要求相对简单的场景，特别是对于初学者或小规模的部署。
优点	优点
强大的自动化和编排： K8s 提供了强大的自动化能力，包括自动扩展、滚动升级、服务发现等。	简化的架构： Docker Swarm 的架构相对简单，易于理解和使用，适用于小规模团队和简单应用场景。
广泛的社区支持： K8s 有庞大的社区，提供了大量的文档、教程和支持资源。	集成 Docker： 与 Docker 无缝集成，对于已经使用 Docker 的用户来说更加直观。
多云环境适用性： K8s 能够在多云环境中运行，使其成为跨云平台部署的理想选择。	启动速度快： 相对于 K8s，Docker Swarm 的启动速度更快，更适用于快速部署和测试。
缺点	缺点
学习曲线较陡峭： K8s 的学习曲线相对较陡峭，初学者可能需要一些时间适应。	功能相对简化： Docker Swarm 在功能上相对于 K8s 较为简化，可能在复杂场景下缺乏一些高级功能。
资源消耗较大： K8s 在一些较小规模的部署中可能显得过于繁重，对资源的要求较高。	生态系统相对狭窄： 相较于 K8s，Docker Swarm 的生态系统相对狭窄，可用的插件和工具相对较少。