使用 MQTT 与函数计算做热力图的实践

前言

最近几年，我们在一些商场、图书馆、机场或港口环境里，经常可以看到一些机器人在转来转去，它们被大家熟知的作用是对客户进行指引服务。不仅于此，事实上，一些先行的企业也会利用机器人来收集这些人流密集地的特征数据，通过上报这些特征数据，进行快速的清洗加工处理，从而提供有意义的应对梳导措施，或者指引信息（广告）投放决策等商业上的转化。

其中有一个主要场景是统计区域的热力图，并开放给特定的系统(也在考虑开发给终端用户)进行查询加工处理。

使用 MQTT 与函数计算做热力图的实践-LMLPHP

这些机器人会在不同的时段进行按需投放，且会在采集数据有较大变化或某固定周期内进行上报。数据采集变化大的时候，上报会趋于频繁，后面的数据清洗处理任务需求也会同步增加。

我们将在本篇文章里探讨下如何在技术选型上更适合地对这类场景进行上报清洗与涉取的处理。

场景特点与要求：

1． 数据通道的连接能力：数据通道随着业务的扩展，机器人的投放也会同步增加，对于数据通道有足够的扩展灵活性，可以按需进行扩展，同时连接的级别能够支持10W+级别的扩展。

2． 简洁数据清洗的能力：对于数据的处理，本质上就是对数据的归纳统计，逻辑实现上并不复杂。对于数据本身的峰谷变化，能有最简单有效的匹配扩缩处理能力即可，在清洗上不希望为此引入复杂的传统大数据级别的笨重方案。

3． 弹性数据访问的能力：这里提到的的热力图信息，以后会考虑开放给终端用户访问，访问量都是动态变化的，随着不同的时间、节日、突发事件等都会有不可预知的幅度变化，所以在此业务中要求有弹性的访问能力。业务方不希望通过限流方式来实现，因为会对业务量本身造成影响。

4． 性能优越的存储能力：此场景下，数据写入与读取并发量都高，客户希望使用NoSQL的方式进行存储。NoSQL 类型能最好支持排序的功能，本文介绍的方案中使用Redis，不再做更多的分析介绍。

备选的技术方案分析

数据通道的连接能力

自建Kafka

优点：

Kafka作为通用的数据收集信息通道，使用面广泛，接入方式多样化。社区完善，学习成本低。
Kafka本身搭建容易，与下游的大数据处理产品协调方案成熟。

缺点：

动态处理Kafka的扩容复杂。
需要搭建额外处理集群的稳定性配套方案。
外网网络流量管理需要配合额外的方案。
主流方案是作为连接应用的收集能力，对于终端的连接能力没有规模级别的案例验证。

消息队列MQTT方案

优点：

支持百万级别的连接，完成可以覆盖业务发展的诉求，为业务留足了扩展空间。
MQTT的协议非常简洁，在端与服务间的传输中有优势。支持各种消息触达的QoS质量。
支持各种客户端接入实现语言。
可实时观测客户端的连接情况，方便发现异常情况。

缺点：

处理大数据的实践没有Kafka成熟，下游产品选型受一定的限制。

弹性数据清洗的能力

大数据方案（Storm、Spark、Flink等）

优点：

开源的通用方案，资料众多，方案成熟。

缺点：

搭建运维复杂，需要提供额外的监控与恢复手段。
需要学习接受各种组件方式（下图是以Storm为例）。
提前评估资源使用情况，无法按照实时数据量进行相应的扩缩使用。

使用 MQTT 与函数计算做热力图的实践-LMLPHP

函数计算方案

优点：

按需进行扩缩，百毫秒级的伸缩能力，适合数据量的脉冲峰谷变化。
不需要进行清洗环境的管理。
概念简单，学习成本低。
其它优点参考下图：

使用 MQTT 与函数计算做热力图的实践-LMLPHP

缺点：

函数计算是各个云厂商的产品。要求一定需要在云上运行。

弹性数据访问的能力

传统应用的方案

优点：

作为业务的一部分嵌在某个应用实现中，技术成熟，学习成本低。

缺点：

需要自实现根据业务请求量来进行弹缩处理，或者很多时候采用评估的方式进行资源冗余处理。

API Gateway+函数计算方案

优点：

根据客户的请求量实时进行弹缩处理。按需使用，不为高峰时段烦恼，不会闲置付费。
自动附带专业的访问监控大盘。

缺点：

需要少量的学习成本。

综述

在这个热力图信息收集清选与访问业务中，可以参考使用下图的解决方案完美实现。

使用 MQTT 与函数计算做热力图的实践-LMLPHP

重点接入步骤

MQTT到函数计算的介绍

请参考函数计算的微消息队列MQTT服务集成方案。

API网关通过函数计算提取数据的介绍

详情请参考API网关函数触发实例。

以Node.js为例：

module.exports.handler = function(event, context, callback) {
   var event = JSON.parse(event);
   var content = {
     path: event.path,
     method: event.method,
     headers: event.headers,
     queryParameters: event.queryParameters,
     pathParameters: event.pathParameters,
     body: event.body
   // 您可以在这里编写您自己的逻辑。
   // 从Redis提取数据的逻辑
   }
   var response = {
        isBase64Encoded: false,
        statusCode: '200',
        headers: {
          'x-custom-header': 'header value'
        },
        body: content
      };
   callback(null, response)
};

后注

在当前DT时代，各种脉冲数据上报的仪器非常多，例如新能源汽车的传感器，公交位置上报，智能物管的开锁，智慧停车场的车位管理，无人店铺的销售等等。在各类场景中，关于上报数据的处理无处不在，而以上提到的场景都可以通过本方案的MQTT+FC+API Gateway的方式参考优化来实现。

作者：折松，阿里云解决方案架构师

原文链接

本文为阿里云原创内容，未经允许不得转载。

lblog_beahvznj