怎么使用MQTT与函数计算做热力图
本篇内容主要讲解"怎么使用MQTT与函数计算做热力图"，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习"怎么使用MQTT与函数计算做热力图"吧!
场景特点与要求：
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)};到此，相信大家对"怎么使用MQTT与函数计算做热力图"有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
