MQTT与函数计算作热力图实践

简介：在各种场景中，关于上报数据的处理无处不在，而以上提到的场景均可以经过本方案的MQTT+FC+API Gateway的方式参考优化来实现。

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

前言

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

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

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

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

场景特色与要求：

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

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

3． 弹性数据访问的能力：这里提到的的热力图信息，之后会考虑开放给终端用户访问，访问量都是动态变化的，随着不一样的时间、节日、突发事件等都会有不可预知的幅度变化，因此在此业务中要求有弹性的访问能力。业务方不但愿经过限流方式来实现，由于会对业务量自己形成影响。

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

备选的技术方案分析

数据通道的链接能力

自建Kafka

优势：

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

缺点：

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

消息队列MQTT方案

优势：

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

缺点：

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

弹性数据清洗的能力

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

优势：

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

缺点：

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

函数计算方案

优势：

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

缺点：

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

弹性数据访问的能力

传统应用的方案

优势：

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

缺点：

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

API Gateway+函数计算方案

优势：

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

缺点：

• 须要少许的学习成本。

综述

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

重点接入步骤

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的方式参考优化来实现。

---

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。