现在物联网服务平台比较多，也有一些比较好的或开源或商业化的物联网平台，这其中以MQTT为主，但不是所有的物联网设备都是需要双向通信的，考虑到MQTT的协议实现问题，目前基于传感器数据采集类的设备，尤其是已有的老设备还没有全部实现MQTT协议，因此这里分享的是一个小型化的基于TCP/UDP协议的物联网服务平台架构，这里的TCP/UDP是同时支持两种协议。

一、架构介绍

这里分享的是一个已经上线的一个实际案例，目前这个架构所支撑的关端设备在2000台左右，其中1600台左右的设备是采用的UDP，每天上传6次数据，每次上传3条，其余为TCP协议的设备，为双向通信，每5分钟上传一次数据，每次一条，就规模上来说，算是比较小型的服务平台。

系统逻辑架构图

交互层：系统的前端有PC端管理、手机APP管理端(普通用户)、手机APP实施端(这里是可设备安装的工人使用的APP)、第三方系统接口(设备数据透传接口)。

代理层：这里主要是通过Nginx对TCP、UDP、Http进行代理，后端所代理的关键服务至少部署两个以上的服务，这样做的好处不只是提高系统的可靠性和性能，最主要的还可以在应用升级时先停掉其中一个服务，升级完成后，再停掉另一个服务并完成升级，这样可以简单的实现不停止服务进行系统升级。

滚动升级示意图

应用层：这里的应用层实际上是分了两层，前置服务(IoT Service)主要是接收前端设备上传的数据，自身在ES里存一份原始数据，然后通过消息中间件分发出去，再由后端的各种消费服务对数据进行处理，这里的消息中间件主起到流量消峰作用，考虑到消费比生产要慢，所以一个生产者对应两个后端消费者，这里采用的竞争消费模型。

数据层：首先是数据存储服务，这里用了ES存储原始数据，用CitusData存储解析后的数据和业务数据，理论上来讲，存储设备上传的数据采用时序数据库更为合适，在测试了多个时序数据库后，最终还是放弃了时序数据库，主要有几方面的原因，一是现在的时序数据库开源的功能阉割的很严重，随着数据量上升，扩容更是没有办法，Apache上有几个比较新的时序数据库，但出来不久有各种问题，不敢用于生产环境。CitusData是基于PgSqL的，其本身比较成熟。

二、架构选型及实施落地

架构技术选型：

代理服务：Nginx

数据存储服务：Elasticsearch、CitusData

消息中间件：RabbitMQ

缓存及定时任务：Redis

前置服务：Jetty

服务基础架构：SpringBoot

在架构实施落地上主要考虑关键服务部署两个以上，前期以经济为主，主要在存储服务节点上前期部署较少，另外根据业务特点，不太关心两个月以前的数据，因此这里对设备数据先按设备类型分表，再按时间月分表。

架构部署逻辑结构图

这里Nginx只部署了一个实例，对后端的UDP、TCP、Http分别进行代理，ES只部署了一个实例，这里只是将原始数据先存起来，后期可以基于该数据进行分析。

IoT Service这里为设备数据的前置服务，主要是和设备进行数据通信，共部署了两个实例，每个实例上行的消息中间件是独立的，主要是为了增加吞吐量和稳定性，下行是共用一个消息中间件，这个平台下行数据非常少，且通信频率比较低。

DataService共部署了四个实例，每两个实例消费一个前置服务生产的消息，在这个平台中，IoTService和DataService都是关键服务，线上不停机，因此多个服务还以后的滚动升级做准备。

AppService服务主要平台的基础管理和设备指令的手工下发，操作不多，线上允许停机，因此只部署了一个实例。

这里有几个后关键服务没有画出来，一个是接口服务，这个是对第三方系统的，它从DataService中获取解析之后的数据透传到第三方系统中去，部署两个实例。

对于UDP和TCP设备都统一采用了通过心跳数据来判断设备是否在线，这里采用的Redis的数据过期通知来完成的，对于不同的设备，过期时间不同。

总结：

这个架构就目前的规模运行进还比较好，数据规模大概在20万条记录/每天，经过CitusData分表(总和最大的近1000万，每个分表在30万左右)后业务上数据的平均响应在1秒以下，比较理想。

这里有几个问题有待升级，一是Nginx的单点故障，二是后续对新设备的MQTT协议支持，三是后面或许有比CitusData更合适的数据存储服务可以考虑升级。CitusData对大表的切分比较考究，切分的纬度不好，会直接影响数据查询性能，但对写入不影响。

架构本身是一个不断演进的过程，好的架构是不断迭代出来的，不是搭建出来的，能满足自身应用就好，总体上来讲这个平台架构复杂，一般公司也能很好的运维下去，再大一点的应用需要考虑自动化运维。