簡介：在各類場景中，關于上報數據的處理無處不在，而以上提到的場景都可以通過本方案的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的方式參考優化來實現。

---

原文鏈接：https://developer.aliyun.com/article/782607?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。