背景
最近幾年公司規劃了好幾個工業物聯網方面項目,由於前期團隊較小，資源有限比較少考慮技術複用和抽象的問題，後面隨着業務的不斷髮展，團隊規模組件擴大，爲了能夠更好的支撐後期業務的快速迭代和輸出，從整個研發體系出發不得不考技術沉澱，抽象複用的問題。
目標
根據公司業務特性，抽象提取出針對於設備連接、安全、數據分析和存儲等能力，形成公司技術沉澱和後期業務快速構建的基礎。提升開發效率。
分析
公司本身從事工業物聯網行業，所涉及的解決方案基本都會涉及到設備的連接和監控，不同設備具備不同的數據協議，在考慮對這塊能力進行抽象和提去的過程中，重點需要考慮設備從連接到上傳，到雲端數據存儲和最終分析展現數據的整個環節。
針對具體使用場景分析如下:
場景一:
此處以企業中央空調爲例:作爲物業的管理人員或是作爲空調的運維人員，希望能隨時隨地查看空調當前輸出溫度，本身運行溫度，連續運行時長，耗電等及時性的狀態。
場景二:
此處以城市智輝照明爲例:作爲城市管理人員想要監控到當前各個街道的路燈是否正常運行，或是否在運行。當大霧或是夜幕能夠通過手工或是自動化的機制遠程開啓路燈
場景三:
此處再列舉一個汽車例子:比如一輛小汽車，汽車使用者希望能時刻了解汽車的安全狀態，什麼時候該做保養，該加油，應該換剎車片，當前是否有行駛等。作爲一個汽車維修技師在爲車輛做檢查時也需要能夠知道汽車的重要部件是否有更換，運行狀態，都希望能有一些數據以供維修參考。
以上的三個場景，理論上是絕大部分物聯網解決方案需要能夠支持，總結主要在於三方面:
1. 設備實時狀態監控
2. 遠程設備控制
3. 設備數據分析
思路
對於這部分能力的抽象主要從設備的連接開始到最後設備數據分析的整個鏈路做組件的抽象和提取，通過領域的邊界的確定從而劃分出對應的職責邊界。
抽象
在這裏通過前期的分析和多個項目業務共性的抽象,整體規劃如下圖所示:
在圖中左邊部分主要是下端傳感器設備，傳感器設備可能通過低功耗網絡或是串口與工業網關進行通訊，在工業網關中去實現對應的應用程序，主要負責解析下端傳感器傳輸回來的數據，並對數據做一定量的分析和計算，然後將數據傳送到雲端服務器，在雲端經過一些列的處理和存儲，最終通過圖形化界面展示出設備的狀態及分析數據。
前面主要描述了設備端到雲端再到用戶端的整個過程，接下來根據目前的思路從設備端抽象-雲端抽象-用戶端抽象進行分層介紹
設備端抽象介紹
設備端一般分爲傳感設備和路由設備，一般所爲的傳感設備即爲不能直接聯網的物理設備，但是他本身可以產生數據，比如溫度傳感器，煙感，熱感，光感等。路由設備一般俗稱路由器，本身具備上網能力，無論這個能力是通過網線還是通過無線蜂窩網等，總之最後能讓設備連上網絡，我們的設備端抽象更多是聚焦於路由端，設備端的抽象相對比較簡答，主要是是抽象除了與雲端建立通訊的SDK，此SDK朱啊喲負責與雲端建立連接，接受消息，和對設備本身的集成應用提供對應的API接口。
雲端抽象介紹
接下來主要針對雲端處理做抽象的分析和介紹。
對於雲端的處理由圖可以看出來，主要分爲5部分:Iot Hub、數據分析、設備管理、規則引擎和安全；接下來將對這五部分做整體介紹和說明
Iot Hub介紹
在每個物聯網企業中大家對於Iot Hub的理解可能存在不一樣的定義，在本設計中對於IOT Hub主要解決設備連接的問題，因此也是成爲了所有設備連接的入口。
當然對於此部分的技術選型可以有很多，比如需要支持目前主流的物聯網通訊協議如:MQTT,CoAP,HTTP,XMPP,SoAP等，在這些協議中目前主流的應該是MQTT，可能還有一些大型設備是基於XMPP，因此在設計之初更多是考慮支持MQTT和XMPP這兩種，當然需要支持其他協議也是可以的，無非就是後期在Iot Hub增加對應的實現。理清楚了協議，就涉及到實現了，我們的實現並不一定要自己重頭造輪子，而是更多的調研和借鑑行業主流的中間件技術，除非真心找不到適合自身需要的。目前對於MQTT主流的中間件,可參考官網推薦產品:
https://github.com/mqtt/mqtt.github.io/wiki/server-support,對於產品之間的對比如下
| Server | QoS 0 | QoS 1 | QoS 2 | auth | bridge | $SYS | SSL | dynamic topics | cluster | websockets | plugin system |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2lemetry | ✔ | ✔ | ✔ | ✔ | ✔ | § | ✔ | ✔ | ✔ | ✔ | ✘ |
| Jmqtt | ✔ | ✔ | ✔ | ✔ | ✔ | § | § | ✔ | § | ✔ | ✔ |
| Apache ActiveMQ | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Apache ActiveMQ Artemis | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Bevywise IoT Platform | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | rm |
| emitter | ✔ | § | ✘ | ✔ | ✘ | ✘ | ✔ | ✔ | ✔ | ✔ | ✘ |
| emqttd | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| flespi | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ | ✔ | ✔ | ✔ | ✔ | ✘ |
| GnatMQ | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ | ✘ | ✔ | ✘ | ✘ | ✘ |
| HBMQTT | ✔ | ✔ | ✔ | ✔ | ✘ | ✔ | ✔ | ✔ | ✘ | ✔ | ✔ |
| HiveMQ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| IBM WIoTP Message Gateway | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| JoramMQ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Mongoose | ✔ | ✔ | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| moquette | ✔ | ✔ | ✔ | ✔ | ? | ? | ✔ | ? | rm | ✔ | ✘ |
| mosca | ✔ | ✔ | ✘ | ✔ | ? | ? | ? | ? | ✘ | ✔ | ✘ |
| mosquitto | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | § | ✔ | ✔ |
| MQTT.js | ✔ | ✔ | ✔ | § | ✘ | ✘ | ✔ | ✔ | ✘ | ✔ | ✘ |
| MqttWk | ✔ | ✔ | ✔ | ✔ | ✔ | ? | ✔ | ✔ | ✔ | ✔ | ✘ |
| RabbitMQ | ✔ | ✔ | ✘ | ✔ | ✘ | ✘ | ✔ | ✔ | ? | ? | ? |
| RSMB | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ | ✔ | ✘ | ✘ | ? |
| Software AG Universal Messaging | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ | ✔ | ✔ | ✔ | rm | ✘ |
| Solace | ✔ | ✔ | ✘ | ✔ | § | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ |
| SwiftMQ | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ | ✔ | ✔ | ✔ | ✘ | ✔ |
| Trafero Tstack | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ | ✔ | ✔ | ✘ | ✘ | ✘ |
| VerneMQ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| WebSphere MQ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ? | ? | ? |
如上所示，對應的可選產品有很多，需要根據我們實際業務特性去選擇，當然如果開源產品無法滿足，可以考慮直接繼承百度、阿里、Azure、AWS等大廠的IoT Hub形成自身能力，但爲可能無法滿足私有化部署的需求。
安全認證&權限策略
安全認證和權限策略，更多的是集成在Broker中,比如MQTT協議的服務器，對於連接的認證，對於Topic的發佈和訂閱的權限控制策略，包括黑白名單等均由此模塊負責
數據分析
數據分析模塊主要負責設備聯網後的所有數據的上傳，解析，存儲和分析。目前抽象出的幾個組件爲消息路由、協議解析、多級存儲、地圖定位；根據實際業務需要適當選擇搭配；
消息路由：主要負責將接受到的消息路由到對應的目標隊列或渠道，可以是一個或多個，便於對數據的不同業務處理
協議解析: 主要負責解析從設備端上傳過來的消息，可能上傳過來的是二進制、Json、xml或自定義字符串等，這裏主要是對消息進行解析
多級存儲: 主要提供對於解析後的消息做存儲功能，對於設備的消息可以支持多種存儲方式，比如Mysql,MongoDB,TSDB等，便於系統在整合時的適配
地圖定位: 主要負責解析或轉換設備的地理位置，因爲設備很多時候不能定位或是GPS不到導致定位數據缺失，此組件提供基於其他雲廠商地圖服務的基站定位，和地址編碼轉換功能，從而明確出設備的具體經緯度和地址描述
設備管理
設備管理模塊主要負責設備註冊、數字孿生、設備控制、OTA升級等,對設備整體做管理和控制。
設備註冊: 設備註冊負責設備連接前的添加註冊，同時提供對外接口便於業務系統根據實際進行設備登記
數字孿生: 數字孿生是一個抽象概念，意爲在雲端構建一個與實體一致的設備模型，然後同步設備狀態及動作，當需要操作設備或是查詢設備信息時直接通過數字孿生設備進行查詢或操作即可，形成與物理設備一一對應
設備控制: 設備控制主要負責下發消息給設備，與設備建立下達通道，確保通道暢通。同時記錄操作日誌，便於如其他模塊集成
OTA升級：OTA升級引擎提供安全的OTA升級服務，基於補丁分發機制的雲端智能推送策略，解決OTA升級過程中可能出現的如數據篡改，固件包僞造，鏈路劫持等安全風險。主要體現形態：自動升級、手動升級、強制升級三種模式，單臺升級、批量升級、全網升級三種模式。技術上實現可通過連接通道，後端的定時任務和隊列進行組合實現。
規則引擎
規則引擎主要在於解析設備協議，或是上傳設備數據之後對於設備數據終端狀態、時間進行過濾，提取出關鍵信息然後通過對外接口(如廣播)進行公告。此處可通過集成第三方規則引擎再結合MQ消息隊列或是http外部調用方式擴散特徵數據。
用戶端抽象
用戶端抽象主要分爲兩方面，一方面是對於蒐集到的設備數據在用戶端的個性化呈現，另一方面是對於外部系統集成所能提供的開放接口，因此主要抽象出兩個組件，自定義報表和OPEN-API
自定義報表
主要希望通過此組件能實現設備的實時展示，或是對分析過的數據進行結果呈現；此處可選實現方案可繼承第三方的BI組件，或是開源的報表組件，如果前期對於數據暫時效果要求不高，推薦用grafana，這是一個不錯的展示工具，支持多種數據源，可以多維度呈現不同的業務或設備數據。
OPEN-API
openApi模塊更多的是爲了對外暴露整個雲端能力接口，在OPEN-API中需要能夠提供接口鑑權，限流，容錯，記錄等功能，
總結：
以上是近期對於物理網整體架構抽象的思考，或許還不完美，但是已經比最初不知道如何做好了很多，知識的積累在於不斷的學習、驗證、總結再學習、驗證、總結的無限循環。
最後，希望看到此文章的朋友能爲大家帶去思路和思考，也歡迎有不同見解的朋友一起探討學習。