maxdoop作为目前最流行的开源物联网平台之一，可以实现物联网项目的快速开发、管理和扩展物联网项目, 是中小微企业物联网平台的不二之选。
一、特征

使用maxdoop，您可以：

    提供设备、资产和客户，并定义它们之间的关系。
    从设备和资产中收集并可视化数据。
    通过复杂的事件处理分析传入遥测和触发警报。
    使用远程过程调用（RPC）控制您的设备。
    基于设备生命周期事件、RESTAPI事件、RPC请求等构建工作流。
    设计动态和响应式仪表板，并向客户展示设备或资产遥测和见解。
    使用可自定义的规则链启用特定于用例的功能。
    将设备数据推送到其他系统。
    更多…

有关更多功能和特定功能文档的有用链接，请参阅maxdoop功能列表。

maxdoop旨在：

    可扩展：使用领先的开源技术构建的水平可扩展平台。
    容错：没有单点故障，集群中的每个节点都是相同的。
    健壮且高效：根据使用情况，单个服务器节点可以处理数万甚至数十万个设备。ThingsBoard集群可以处理数百万台设备。
    可自定义：使用可自定义的小部件和规则引擎节点可以轻松添加新功能。
    持久：永远不要丢失数据。

二、maxdoop架构
1、maxdoop 传输

maxdoop提供基于MQTT，HTTP，CoAP和LwM2M的API，可用于您的设备应用程序/固件。 每个协议API都由单独的服务器组件提供，并且是maxdoop“传输层”的一部分。 MQTT 传输还提供网关 API，供代表多个连接设备和/或传感器的网关使用。

传输从设备接收到消息后，将对其进行解析并将其推送到持久消息队列。 只有在消息队列确认相应的消息后，才会向设备确认消息传递。
2、maxdoop核心

maxdoop Core 负责处理 REST API 调用和 WebSocket 订阅。 它还负责存储有关活动设备会话的最新信息并监视设备连接状态。 maxdoop Core在后台使用Actor系统来实现主要实体的Actor：租户和设备。 平台节点可以加入集群，其中每个节点负责传入消息的某些分区。
3、maxdoop规则引擎

maxdoop规则引擎是系统的核心，负责处理传入的消息。 规则引擎在后台使用Actor系统来实现主要实体的Actor：规则链和规则节点。 规则引擎节点可以加入群集，其中每个节点负责传入邮件的某些分区。

规则引擎订阅来自队列的传入数据馈送，并仅在处理消息后确认消息。 有多种策略可用于控制消息处理的顺序或消息处理以及消息确认的条件。 有关更多详细信息，请参阅提交策略和处理策略。

maxdoop 规则引擎可以在两种模式下运行：共享模式和隔离模式。在共享模式下，规则引擎处理属于多个租户的消息。 在隔离模式下，规则引擎可以配置为仅处理特定租户的邮件。
4、maxdoop网页用户界面

maxdoop提供了一个使用Express.js框架编写的轻量级组件来托管静态Web UI内容。 这些组件是完全无状态的，没有太多可用的配置。 静态 Web UI 包含应用程序捆绑包。加载后，应用程序开始使用Maxdoop Core提供的REST API和WebSockets API。
三、消息队列

Maxdoop支持多种消息队列实现：Kafka，RabbitMQ，AWS SQS，Azure Service Bus和Google Pub/Sub。我们计划在未来扩展此列表。 使用持久且可扩展的队列允许 ThingsBoard 实现背压和负载平衡。在峰值负载的情况下，背压非常重要。我们在特定的队列实现上提供“抽象层”，并维护两个主要概念：主题和主题分区。 一个主题可能具有可配置的分区数。由于大多数队列实现不支持分区，因此我们使用主题 + “.” + 分区模式。

ThingsBoard 消息生产者根据实体 ID 的哈希确定要使用的分区。 因此，同一实体的所有消息始终被推送到同一分区。 ThingsBoard 消息 使用者使用 Zookeeper 进行协调，并使用一致哈希算法来确定每个使用者应订阅的分区列表。 在微服务模式下运行时，每个服务还具有基于只有一个分区的唯一服务 ID 的专用“通知”主题。

    Maxdoop使用以下主题：
    tb_transport.api.requests：发送通用 API 调用以检查从传输到 ThingsBoard Core 的设备凭据。
    tb_transport.api.responses：接收从 ThingsBoard Core 到 Transmission 的设备凭据验证结果。
    tb_core：将消息从传输或规则引擎推送到 ThingsBoard 核心。消息包括会话生命周期事件、属性和 RPC 订阅等。

tb_rule_engine：将消息从传输或 ThingsBoard 核心推送到规则引擎。消息包括传入遥测、设备状态、实体生命周期事件等。

注意：所有主题属性（包括名称和分区数）都可以通过 maxdoop.yml 或环境变量进行配置。 从 Maxdoop3.4 开始，我们可以通过 UI 配置规则引擎队列，请参阅文档。

注意：从版本 2.5 开始，我们已经从使用 gRPC 切换到消息队列来处理 maxdoop 组件之间的所有通信。 主要思想是牺牲较小的性能/延迟损失，以支持持久可靠的消息传递和自动负载平衡。
四、内部部署与云部署

Maxdoop支持本地和云部署。 maxdoop在全球运行着5000多台maxdoop服务器，在AWS，Azure，GCE和私有数据中心的生产环境中运行。 可以在完全无法访问互联网的专用网络中启动maxdoop。
五、独立模式与群集模式

平台设计为水平可扩展，并支持自动发现新的ThingsBoard服务器（节点）。 群集中的所有 Maxdoop 节点都是相同的，并且共享负载。 由于所有节点都相同，因此没有“主”或“协调器”进程，并且没有单点故障。 您选择的负载均衡器可以将来自设备、应用程序和用户的请求转发到所有 Maxdoop 节点。
六、整体式与微服务架构

从 Maxdoop v2.2 开始，可以将平台作为整体应用程序或一组微服务运行。 支持这两个选项需要一些额外的编程工作，但是，由于与各种现有安装的向后兼容性，因此至关重要。

大约 80% 的平台安装仍在使用单片模式，因为支持工作、知识和硬件资源最少，用于进行设置和维护工作也很少。

但是，如果您确实需要高可用性或想要扩展到数百万台设备，那么微服务是一种选择。 还有一些挑战可以通过微服务架构解决，并适用于更复杂的部署和使用场景。 例如，运行需要更精细隔离的多租户部署，以防止：

    不可预测的负载峰值;
    不可预测的规则链配置错误;
    单个设备由于固件错误而打开 1000 个并发连接;
    和许多其他情况。

请点击下面列出的链接了解更多信息并选择正确的体系结构和部署选项：

    整体式：了解有关在单体模式下部署、配置和运行 ThingsBoard 平台的更多信息。
    微服务：了解有关在微服务模式下部署、配置和运行 ThingsBoard 平台的更多信息

七、SQL vs NoSQL vs 混合数据库方法

Maxdoop使用数据库来存储实体（设备，资产，客户，仪表板等）和遥测数据（属性，时间序列传感器读数，统计信息，事件）。 平台目前支持三个数据库选项：

    SQL - 将所有实体和遥测数据存储在 SQL 数据库中。Maxdoop的作者建议使用PostgreSQL，这是ThingsBoard支持的主要SQL数据库。 可以将HSQLDB用于本地开发目的。我们不建议将 HSQLDB 用于除运行测试和启动具有最小可能负载的开发实例之外的任何操作。
    NoSQL（已弃用）
    Hybrid （PostgreSQL + Cassandra） - 将所有实体存储在PostgreSQL数据库中，并将时间序列数据存储在Cassandra数据库中。
    Hybrid （PostgreSQL + TimescaleDB） - 将所有实体存储在PostgreSQL数据库中，并将时间序列数据存储在Timescale数据库中。

可以使用 Maxdoop.yml