1.前言
距離上一次寫物聯網系列已經半年多過去了。一直沒有更新該系列。主要是平台完成的七七八八了。但是由於我遠離硬件需求端，對於一些特定的需求，不理解，避免閉門造車。加上之前斷斷續續跟一個公司合作開發。最近半年安裝他們公司進行深入定制化，現在樣品也陸續開始發出去了。預計進入商用階段，同時平台完善后，基於平台還將陸續有一些應用被開發。
還有他們公司也找了個前端，對我那個基於layui的框架界面進行優化，采用vue-element進行重構開發。基於此，還將有配套硬件開發包出售。兩年了。一切都朝着越來越好的方向發展。
最近在公司也開始帶新人了。物聯網平台的事情，公司繼續沒有讓我做和得到重視。正職，我還是繼續我的企業信息化，爭取明年底把運營分析系統搭建起來。平時周末就繼續搞自己的物聯網平台。加油喲~~~
2. 物聯網新架構圖
這個是年初二月份畫的。最近半年是主要是寫一些API和日志分析，還有應用。這部分還沒有形成完整的文檔和流程，所以還不發出來。
如上圖所示，各個功能點詳述
A: 作為物聯網設備端的一環，我們的手機也可以理解為一個功能較多的智能設備，跟那種資源受限，功能單一的普通設備是一樣的。只是一般的手機性能較為強大，推薦使用MQTT+JSON的通信方式及協議
B: 普通的智能設備一般也分為高性能硬件和低性能硬件，一般是推薦能使用MQTTs+JSON通信方式的設備盡量使用MQTT+JSON。一些類似NB模塊的也可以使用CoAP+JSON通信方式
C: 對於低功耗需求或者低性能設備，又或者是以前舊的設備，而無法使用的。可以使用TCP自定義協議。但是此時需要一個網關服務器。用來實現協議轉換。這個協議轉換，如果放到偏服務器測，那么稱之為協議網關。如果放到偏設備測，那么稱之為邊緣節點。如果還帶有管理界面或者編程實現邏輯的，也稱之為邊緣計算。最后轉換成平台規定的協議格式進行通信。
D: 以上A、B、C三類設備，最后都是作為數據生產者，把采集到的數據發送到平台。設備通信需要設備認證，我們平台采用“一機一密”，“一型一密”兩種方式進行設備認證。然后設備攜帶設備的DeviceSN、DeviceKey、DeviceUUID等信息登錄到EMQ服務器。按照協議進行通信。
E: 這部分作為設備接入，采用EMQX這個中間件。是MQTT的Broker。開源，免費。開源版本也有自帶集群功能。該中間件只是作為數據傳輸，轉發的功能，不進行過多的邏輯操作與運輸。設備認證是，EMQ通過WebHook方式，HTTP API讀取P功能，進行判斷是否合法設備已經通信是否符合平台規定Topic權限策略。D方向是數據的生產者，平台采用編寫一個轉發程序，一般采用訂閱根節點。然后根據不同的Topic構造不同的Topic，這個Topic與MQTT的Topic不一樣，是屬於Kafka的Topic。由於MQTT與Kafka兩者都是消息隊列，但是底層數據結構不一樣。Kafka的Topic不能太多。因此要進行歸類。
F: 從EMQ經過F到I，可以直接在EMQX里面寫插件，簡單的進行轉發，這個插件也不是很難，我自己也寫過。網上實現的也有，這種方式實現性能會比較好。但是由於還要重新學習Erlang，要實現過多的業務邏輯會有點麻煩。
G: 通過插件方式實現是一種方式，也可以通過定義MQTT的根Topic，按照Topic進行不同類別的轉發。前期優先使用這種方式。比如根據MQTT的Topic的后綴是event、alarm、property等功能進行轉發到Kafka。因為payload里面已經有客戶ID，產品ID、設備ID
H: 作為Kafka的生產者，因為可能會出現數據高峰，已經消費者的處理時間問題。引入Kafka消息隊列，解決生產者與消費者問題。H這里會做出動態化，插件化。比如要增加一個支付服務，那么H部分就是對Kafka的pay這個Topic寫數據。然后J消費者如果剛好有個支付服務，剛好訂閱pay這個Topic，就可以消費這些數據。
I: Kafka是第二版引入的一個中間件。也是一個開源、免費的中間件。主要實現架構層級分離。生產者與消費者的分離。配置規則與策略還要詳細了解。
J: 消費者，這里就是插件化。比如有個客戶有特殊需求，那么通過一個customer的Topic，經過H。那么這里只需要編寫一個訂閱I的customer的Topic。就可以實現自定義邏輯。標准平台會實現一些標准的插件。比如K的持久化插件，比如L的報警服務。以后這里會做成一個生態。一個插件市場。讓平台生態化。
K: 持久化服務，作為一個標准插件。如果設備生產者遵循標准化通信方式，那么可以直接使用這個插件，插件會收集所有的數據，並通過簡單的邏輯處理，將數據持久化到時序數據庫，如InfluxDB。然后使用開源的Grafana圖表進行展示。有特殊需求的，還可以獲取Grafana或者自己封裝成HTTP API給第三方調用，使用這些數據。做數據分析與利用。
L: 報警服務，這個也是物聯網比較常見的一個服務。比如設備消費端通過event這個Topic發到J，這個L就剛好是訂閱這個event的Topic的。就分析傳輸過來的數據。邏輯判斷是否需要報警。需要告警的，會通過釘釘的開發API，通知到釘釘群。有能的，可以實現到短信、微信公眾號等方式。都是可以插件化實現。
M: 這里的M已經是客戶人員。就是所謂平台的租戶了。平台會提供一個Web界面或者OAuth開放文檔，讓客戶自定義皮膚。平台遵循前后端分離的微服務架構。
N: 平台需要交互，同時也需要與第三方公司的客戶系統進行對接。這里有兩種方式，一種是客戶直接利用平台的OAuth或者HTTP APIKey進行遠程調用。還有一種是通過CallBack，讓平台調用第三方系統。
O: 標准平台會提供給M客戶一個賬號密碼，功能客戶登錄到設備管理Web后台。登陸后可以查看產品、設備配置一些基礎信息。
P: E是標准化產品的中間件。EMQX，一般不需要進行二次開發。EMQ提供了豐富的API和配置項。平台適用里面的auth_http方式，通過HTTP調用來實現設備的“Topic權限策略”，“設備帳號密碼認證”，“設備狀態獲取”等功能。
Q: 這里有三個基礎功能“Topic權限策略”，“設備帳號密碼認證”，“設備狀態獲取”。采用微服務，每個服務都對應一個功能。
R: 這里是一些基礎微服務，包含后台管理界面、設備管理界面增刪改查登錄功能。還有OTA固件升級管理。設備物理模型管理。
S: 一些基礎存儲服務，包含關系型數據庫Postgres，非關系型數據庫Redis，還有對象存儲的MinIO等。
T: 這里也是一些微服務基礎組件，包含配置中心，日志中心，運維中心等。
U: 后台運維Web管理界面，超級管理員登錄界面。負責平台的日常管理、監控、運維等工作。
本文地址：https://www.cnblogs.com/wunaozai/p/13860572.html
本系列目錄： https://www.cnblogs.com/wunaozai/p/8067577.html
個人主頁：https://www.wunaozai.com/
