簡介： 在各類場景中，關(guān)于上報數(shù)據(jù)的處理無處不在，而以上提到的場景都可以通過本方案的MQTT+FC+API Gateway的方式參考優(yōu)化來實現(xiàn)。

前言

?

最近幾年，我們在一些商場、圖書館、機(jī)場或港口環(huán)境里，經(jīng)常可以看到一些機(jī)器人在轉(zhuǎn)來轉(zhuǎn)去，它們被大家熟知的作用是對客戶進(jìn)行指引服務(wù)。不僅于此，事實上，一些先行的企業(yè)也會利用機(jī)器人來收集這些人流密集地的特征數(shù)據(jù)，通過上報這些特征數(shù)據(jù)，進(jìn)行快速的清洗加工處理，從而提供有意義的應(yīng)對梳導(dǎo)措施，或者指引信息（廣告）投放決策等商業(yè)上的轉(zhuǎn)化。

?

其中有一個主要場景是統(tǒng)計區(qū)域的熱力圖，并開放給特定的系統(tǒng)(也在考慮開發(fā)給終端用戶)進(jìn)行查詢加工處理。

?

這些機(jī)器人會在不同的時段進(jìn)行按需投放，且會在采集數(shù)據(jù)有較大變化或某固定周期內(nèi)進(jìn)行上報。數(shù)據(jù)采集變化大的時候，上報會趨于頻繁，后面的數(shù)據(jù)清洗處理任務(wù)需求也會同步增加。

?

我們將在本篇文章里探討下如何在技術(shù)選型上更適合地對這類場景進(jìn)行上報清洗與涉取的處理。

?

場景特點與要求：

?

1．?數(shù)據(jù)通道的連接能力：數(shù)據(jù)通道隨著業(yè)務(wù)的擴(kuò)展，機(jī)器人的投放也會同步增加，對于數(shù)據(jù)通道有足夠的擴(kuò)展靈活性，可以按需進(jìn)行擴(kuò)展，同時連接的級別能夠支持10W+級別的擴(kuò)展。

?

2．?簡潔數(shù)據(jù)清洗的能力：對于數(shù)據(jù)的處理，本質(zhì)上就是對數(shù)據(jù)的歸納統(tǒng)計，邏輯實現(xiàn)上并不復(fù)雜。對于數(shù)據(jù)本身的峰谷變化，能有最簡單有效的匹配擴(kuò)縮處理能力即可，在清洗上不希望為此引入復(fù)雜的傳統(tǒng)大數(shù)據(jù)級別的笨重方案。

?

3．?彈性數(shù)據(jù)訪問的能力：這里提到的的熱力圖信息，以后會考慮開放給終端用戶訪問，訪問量都是動態(tài)變化的，隨著不同的時間、節(jié)日、突發(fā)事件等都會有不可預(yù)知的幅度變化，所以在此業(yè)務(wù)中要求有彈性的訪問能力。業(yè)務(wù)方不希望通過限流方式來實現(xiàn)，因為會對業(yè)務(wù)量本身造成影響。

?

4．?性能優(yōu)越的存儲能力：此場景下，數(shù)據(jù)寫入與讀取并發(fā)量都高，客戶希望使用NoSQL的方式進(jìn)行存儲。NoSQL 類型能最好支持排序的功能，本文介紹的方案中使用Redis，不再做更多的分析介紹。

備選的技術(shù)方案分析

數(shù)據(jù)通道的連接能力

自建Kafka

優(yōu)點：

• Kafka作為通用的數(shù)據(jù)收集信息通道，使用面廣泛，接入方式多樣化。社區(qū)完善，學(xué)習(xí)成本低。
• Kafka本身搭建容易，與下游的大數(shù)據(jù)處理產(chǎn)品協(xié)調(diào)方案成熟。

缺點：

• 動態(tài)處理Kafka的擴(kuò)容復(fù)雜。
• 需要搭建額外處理集群的穩(wěn)定性配套方案。
• 外網(wǎng)網(wǎng)絡(luò)流量管理需要配合額外的方案。
• 主流方案是作為連接應(yīng)用的收集能力，對于終端的連接能力沒有規(guī)模級別的案例驗證。

消息隊列MQTT方案

優(yōu)點：

• 支持百萬級別的連接，完成可以覆蓋業(yè)務(wù)發(fā)展的訴求，為業(yè)務(wù)留足了擴(kuò)展空間。
• MQTT的協(xié)議非常簡潔，在端與服務(wù)間的傳輸中有優(yōu)勢。支持各種消息觸達(dá)的QoS質(zhì)量。
• 支持各種客戶端接入實現(xiàn)語言。
• 可實時觀測客戶端的連接情況，方便發(fā)現(xiàn)異常情況。

缺點：

• 處理大數(shù)據(jù)的實踐沒有Kafka成熟，下游產(chǎn)品選型受一定的限制。

彈性數(shù)據(jù)清洗的能力

大數(shù)據(jù)方案（Storm、Spark、Flink等）

優(yōu)點：

• 開源的通用方案，資料眾多，方案成熟。

缺點：

• 搭建運維復(fù)雜，需要提供額外的監(jiān)控與恢復(fù)手段。
• 需要學(xué)習(xí)接受各種組件方式（下圖是以Storm為例）。
• 提前評估資源使用情況，無法按照實時數(shù)據(jù)量進(jìn)行相應(yīng)的擴(kuò)縮使用。

?

?

函數(shù)計算方案

優(yōu)點：

• 按需進(jìn)行擴(kuò)縮，百毫秒級的伸縮能力，適合數(shù)據(jù)量的脈沖峰谷變化。
• 不需要進(jìn)行清洗環(huán)境的管理。
• 概念簡單，學(xué)習(xí)成本低。
• 其它優(yōu)點參考下圖：

?

缺點：

• 函數(shù)計算是各個云廠商的產(chǎn)品。要求一定需要在云上運行。

彈性數(shù)據(jù)訪問的能力

傳統(tǒng)應(yīng)用的方案

優(yōu)點：

• 作為業(yè)務(wù)的一部分嵌在某個應(yīng)用實現(xiàn)中，技術(shù)成熟，學(xué)習(xí)成本低。

缺點：

• 需要自實現(xiàn)根據(jù)業(yè)務(wù)請求量來進(jìn)行彈縮處理，或者很多時候采用評估的方式進(jìn)行資源冗余處理。

API Gateway+函數(shù)計算方案

優(yōu)點：

• 根據(jù)客戶的請求量實時進(jìn)行彈縮處理。按需使用，不為高峰時段煩惱，不會閑置付費。
• 自動附帶專業(yè)的訪問監(jiān)控大盤。

缺點：

• 需要少量的學(xué)習(xí)成本。

綜述

在這個熱力圖信息收集清選與訪問業(yè)務(wù)中，可以參考使用下圖的解決方案完美實現(xiàn)。

?

重點接入步驟

MQTT到函數(shù)計算的介紹

請參考函數(shù)計算的微消息隊列MQTT服務(wù)集成方案。

?

API網(wǎng)關(guān)通過函數(shù)計算提取數(shù)據(jù)的介紹

詳情請參考API網(wǎng)關(guān)函數(shù)觸發(fā)實例。

以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提取數(shù)據(jù)的邏輯 }var response = {isBase64Encoded: false,statusCode: '200',headers: {'x-custom-header': 'header value'},body: content}; callback(null, response) };

后注

在當(dāng)前DT時代，各種脈沖數(shù)據(jù)上報的儀器非常多，例如新能源汽車的傳感器，公交位置上報，智能物管的開鎖，智慧停車場的車位管理，無人店鋪的銷售等等。在各類場景中，關(guān)于上報數(shù)據(jù)的處理無處不在，而以上提到的場景都可以通過本方案的MQTT+FC+API Gateway的方式參考優(yōu)化來實現(xiàn)。

作者：折松，阿里云解決方案架構(gòu)師

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載

總結(jié)

以上是生活随笔為你收集整理的使用MQTT与函数计算做热力图的实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。