ThingLinks采用Spring Cloud 微服务架构,一款高性、高吞吐量、高扩展性的物联网平台! 单机可以支持百万链接,同时支持自定义扩展功能多种协议交互，支持插件化开发；向下支持连接海量设备，采集设备数据上云；向上提供北向输出功能和系统API，服务端可通过调用API将指令下发至设备端，实现远程控制。

　　6、时序数据库采用TDengine开源、高效的物联网大数据平台、处理物联网海量数据写入与负载查询。

　　系统管理：用户管理、角色管理、菜单管理、部门管理、岗位管理、字典管理、参数设置、通知公告、日志管理

　　系统监控：在线用户、定时任务、Sentinel控制台、Nacos控制台、Admin控制台、任务调度管理

　　设备集成：设备管理（支持MQTT协议、WebSocket协议、TCP-IP协议设备接入）、子设备管理、产品管理、协议管理、规则引擎（设备联动）

　　物联网是一组使用网络支持交换数据的物理对象 。这些对象可以是传感器，软件，板卡等。这是一个有趣的生态系统，其中的软件可以直接连接到真实的硬件或设备。可用于IoT项目的最著名的板是Arduino（具有多个版本）和Raspberry。

　　将这些设备与云平台集成在一起可以收集和分析数据，创建可以远程控制的“智能”对象 。控制此类设备的一种方法是使用智能手机，例如Android和iOS设备。像Arduino或Raspberry这样的板很便宜，每个人都可以试验IoT项目。

　　云数据存储使开发人员能够存储从不同板 （例如Arduino或Raspberry） 发送的数据 ；例如，可以存储从传感器读取的值。该信息可以使用图形显示或使用其他工具进行分析。事件逻辑是基于Web的编程逻辑 ，可用于在事件发生时触发某些操作。使用这种平台可以仅通过Web界面实现一些“业务逻辑”，而无需了解我们用于该项目的董事会。通常，逻辑类似于IF-THEN，例如，如果发生事件，请执行此操作。事件可以是从传感器读取的信号，而动作可以是电子邮件或SMS。平台集成是一组实现特定协议的“适配器”，因此无需编写代码即可混合使用不同的Internet服务来执行一系列操作。例如，当从传感器读取的值高于阈值水平时， 可以将具有Arduino屏蔽功能的Arduino通过SMS发送警报 。

　　Temboo ：这是一个非常有趣的平台，提供将Arduino，Raspberry和othef平台与不同的Internet服务（例如SMS，Email等）集成的服务。该平台使用作为外部服务连接器的choreos ，以便可以将Arduino中的事件（如传感器信号）转换为不同类型的事件。此外，它提供了一些类似IF-THEN的逻辑。

　　Carriots ：这是另一个有趣的功能，它使智能设备可以存储数据。它使用数据流概念使设备能够发送数据。此外，该平台还具有规则管理系统，因此您可以直接在Web上实现自定义逻辑。此外，它还可以发送电子邮件，短信和Twitter消息

　　NearBus ：针对其他平台提出了一种不同的方法。通常，IoT平台背后的基本概念是将设备（Arduino，Raspberry等）连接到云，以便这些板可以发送数据。NearBus提供了一种不同的方式：它将设备映射到云中，从而使其成为云本身的一部分。它使用代理来完成此任务，并且可以使用一组API从Web直接控制该代理。

　　Ubidots ：此平台支持多种开发板，可用于在云中存储数据。它提供数据捕获，带有内置仪表板的数据可视化，规则管理（或事件管理）。使用内置仪表板，可以实时查看基于设备发送的数据构建的图形。它支持多种可视化。

　　上表总结了这些平台的某些方面，我认为它们很重要。进行此比较的目的是提供有关现有物联网平台的一些高级信息，我邀请读者在使用它之前，先直接在各自的网站上仔细阅读每个平台的功能。

　　这里还有其他可以提及的平台，例如Xively或Sensorcloud，即使我还没有时间使用它们，它们也可以提供有趣的服务。

　　您会注意到，有几种类型的平台提供不同的服务，每个平台都有其独特的方面，开发人员和制造商应根据项目需求选择合适的平台。

　　ThingsKit物联网平台套件：可私有化部署的基础物联网平台，帮助企业轻松实现物联网设备管理、数据收集、设备控制、组态可视化以及行业应用扩展，适用于工业、农业、能源、环保等场景。了解更多，请访问：

　　近些年来物联网技术高速发展，广泛应用到了诸如智慧出行、智慧工业、智能家居等场景中，无论是何种场景的应用，都离不开对数据的“采集-处理-存储-分析”这套流程。但是不同的应用，其自身的数据特性和业务需求大不相同，那么对于实现上述流程所需的产品组件也会有所区别。总体来说，我们可以按照应用和数据特点分为三类场景：时序数据、消息数据、元数据。

　　如上图展示了物联网场景的三大类数据。以智能汽车场景为例，车辆定时会更新当前的最新状态信息，例如发动机当前转速、当前车速等，这些描述车辆最新状态信息的数据我们称之为元数据。而在智能汽车行驶过程中，车辆的状态数据会随着时间的变化而变化，例如车辆一段时间内的车速、胎压等，这些描述车辆历史状态信息的数据我们称之为时序数据。还有一种数据场景是对车辆行为进行控制的指令消息，例如调节车辆空调温度指令下发以及车辆执行命令后的结果反馈，这些控制指令的上下行我们称之为消息数据。不同类型的数据应用的场景各不相同，所以对存储系统的需求也有所不同。本文章主要分析设备元数据场景有哪些业务需求，以及如何选择合适的存储组件和实现方案。

　　在工业生产过程中，通常设备会以某个固定的周期（或由某个事件触发）上报最新运转状态信息，这也就是上文提到的设备元数据，例如设备 ID，当前运转温度、湿度、压力值等。业务上根据设备元数据来管理设备，例如查询某台设备的当前运转状态，多条件在线检索设备，“圈选”出符合条件的设备集合。通过分析设备元数据来实时监控设备的运转状态，出现异常及时响应，避免故障发生等。下面对业务需求做一个小结：

　　元数据存储场景对数据库的规模、性能、查询能力等各个方面都有较高的要求。通常来说，关系型数据库 MySQL 都是作为存储选型的第一选项，这是因为 MySQL 是最为通用，大家也最为熟悉的数据库产品。然而 MySQL 一般只在小规模的数据存储（千万级）和低并发的数据更新（一万内 QPS）场景下表现优异，当规模变大时，MySQL 的性能会急剧下降，这显然不满足元数据存储的要求。到这里，大家可能会想到使用开源数据库 HBase，因为 HBase 的分布式架构能够支持大规模数据存储和写入，在这一点上是可以满足元数据存储需求的。但是 HBase 只支持了基于主键（RowKey）查询，无法在属性列上建索引查询，所以在设备检索、圈选时的效率极低，极端情况下可能会以全表扫描加数据过滤的这种方式来查询数据，这一点上无法满足上述的需求。最后我们来看下表格存储 Tablestore，Tablestore 是一款云原生 Serverless 的结构化数据存储，原生具备大规模的数据存储和低延迟数据更新，同时提供了多元索引功能，能够支持任意字段组合检索，是物联网平台底层依赖的核心数据存储系统，支撑了亿级设备的元数据管理。下面对上述几个存储产品在实现元数据存储场景中的能力做一个总结：

　　表格存储 Tablestore 是一款云上的结构化数据存储产品，具备极为丰富的产品功能和生态，提供了物联网存储 Iotstore、宽表引擎、多元索引等能力来满足时序数据、消息数据、元数据场景的需求。针对于时序与消息数据场景的解决方案不在本文章中展开讲解。下面我们来看一下 Tablestore 提供了哪些能力来满足元数据存储的场景需求。

　　其中宽表引擎是一个分布式的数据表，负责设备元数据的存储与更新。宽表引擎采用了多分区（shard）的分布式结构，每一个分区对应了一台 worker。在元数据写入的过程中，路由节点根据主键的范围将写入请求路由到不同的分区进行处理，当某个分区的负载达到瓶颈时，服务端会自动成多个分区，使得宽表引擎的整体吞吐能力能够线性提高。如下图所示：

　　相比于宽表引擎， 索引引擎底层采用了倒排索引、空间索引等存储结构，能够支持任意数据组合检索、聚合。索引引擎分别提供了两种查询接口： search 和 parallelScan。

　　Tablestore 提供了与 Flink 实时计算对接的能力，可作为 Flink 的数据源表，将实时变化的设备元数据推送到 Flink 中进行计算，从而实现元数据检测的业务场景。与此同时，支持将计算的结果再写入 Tablestore 的数据表中，来实现记录异常数据结果。

　　分享完元数据存储场景的需求和 Tablestore 的技术原理后，我们来看看如何搭建一个设备元数据场景的物联网架构。物联网数据上报网关后，根据不同的应用类型一般有三种数据流向，应用服务器订阅消费，持久化存储，转发到消息队列。设备元数据的主要需求是存储和计算，所以我们可以列出一个简单的数据流转过程：网关-存储-流计算。下面将介绍通过物联网平台 + Tablestore + Flink 来搭建元数据管理平台。

　　上述的架构图中包含了三个组成模块：物联网平台，表格存储 Tablestore、实时计算 Flink。各个模块在架构中承担的角色和功能如下：

　　假设某工业生产厂商现有一百万台智能设备，每台设备定时更新自身的温度、湿度、压力数据等状态数据，准备使用上述方案架构来搭建元数据管理平台。

　　在物联网平台控制台中创建产品（product_metadata），物模型（默认模块）、设备（test_deviceName）。一个产品相当于同类型设备的抽象，而物模型则是对设备上报数据结构的定义。

　　在物联网平台中创建解析器，解析器负责将设备元数据更新的 topic 进行自定义脚本处理后，写入到 Tablestore 中持久化存储。如下图所示：

　　创建解析器需要分别配置数据源、解析脚本和数据目的。通过物模型上报的设备元数据会汇聚到名为/产品名/设备名/thing/event/property/post的 topic 中作为数据源，也可以自定义一个 topic 。数据目的则是配置设备元数据需要写入的 Tablestore 实例名和表名等信息。解析脚本是可以自定义的，例如本案例中将设备的经纬度信息组合成一个坐标字符串写入 Tablestore，如下图所示：

　　通常设备上报数据是基于设备端 SDK 开发程序来上报数据到物联网平台中，但为了快速实现方案，本文中使用物联网平台提供的设备模拟器来进行数据上报操作。如下图的一个模拟设备上报了一条数据:

　　设备元数据经过解析器处理后存储到 Tablestore 中，到此我们已经完成了设备元数据采集与存储的所有操作。

　　由于设备模拟器只能模拟单台设备元数据产生的过程，为了更贴近真实的业务场景，我们直接在 Tablestore 中生成了一亿条设备元数据以供后续步骤的实现。通过上文我们可以得知，设备检索与圈选需要依赖 Tablestore 的多元索引功能，所以首先我们需要创建一个多元索引 device_meta_data_index：

　　Tablestore 提供了 SQL、控制台或 SDK 等多种数据访问方式。以 SQL 为例，首先通过 SQL 确认设备元数据已正确导入。

　　先来说设备检索，设备检索通常不会返回比较大的数据结果集，即使符合查询条件的数据量很。