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的方式參考優化來實現。

---

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