[討論] 平台建設，我們從架構中去掉kafka？
- 2020 年 3 月 5 日
- 筆記
目 錄
1. 概述… 2
2. 原有結構（帶kafka）… 2
3. 改造後的結構（去掉kafka）… 3
4. 對比… 4
1. 概述
我們主要面向鋼鐵行業工業互聯網公有雲和私有去建設，偏向PAAS層和SAAS層應用，框架是支撐這個體系建設。現在我們的公有雲的IAAS資源層使用的是第三方雲平台，現在有50個左右的站點，1個站點就是一個生產單位，1個站點每天傳輸到公有雲平台的數據大概為300-500MB，1個站點的數據包括：一級PLC及感測器的數據、原燃料的化驗數據、模型計算結果數據、產量數據及人工填報的數據，我們大致把這些數據分為兩大類：設備數據和業務數據，暫時不包括：經營數據、物流數據、資產數據等。數據的實時性，基本上是現場產生了數據，會秒級檢測，立即上傳。數據的完整性，設備數據一般用於監測，可以有丟失的情況，業務數據一般用於報表、統計和分析，要求完整性和一致性，不能多數據也不能少數據。
上述就是我們的公有雲平台的大致情況，下面把我們的原來的結構和改造完成的結構和大家分享一下，大家可以充分討論。
2. 原有結構（帶kafka）
接收到全國站點的數據後：
（1） 把本次傳輸的數據寫入到redis快取中。
（2） 把本次傳輸的數據編號存儲到mysql資料庫，形成待處理的任務。
（3） 把本次傳輸的數據編號發送給kafka消息列隊，負載平衡通知處理端處理本次傳輸的數據。
（4） 處理端接收到kafka的本次傳輸的數據編號，從redis取出來數據，進行入庫操作，關係數據、文件數據、影片數據、圖片數據等。
（5） 本次傳輸的數據處理完成。
以上描述是接收數據後的整體流程，結構示意，如下圖：
3. 改造後的結構（去掉kafka）
接收到全國站點的數據後：
（1）把本次傳輸的數據寫入到redis快取中。
（2）把本次傳輸的數據編號存儲到mysql資料庫，同時指定哪個處理端負責處理數據，形成待處理的任務。
（3）處理端定周期從mysql取得自己負責處理的任務，再從redis取出來數據，進行入庫操作，關係數據、文件數據、影片數據、圖片數據等。
（4）如果處理端服務異常掛掉，那麼接收數據端會重新分配該處理端無法處理的數據處理任務。
（5）本次傳輸的數據處理完成
以上描述是改造後，接收數據後的整體流程，結構示意，如下圖：
4. 對比
（1） 原有結構，實時的效率更高，kafka直接負載分配給處理端。
改造後結構，處理端需要定周期從mysql取得自己的處理任務，有周期耗時時間。
（2） 原有結構，如果一個處理端處理數據事務超時，kafka重新分配分區，會影響所有處理端，造成待處理任務堆積。
改造後結構，如果一個處理端掛掉了，重新分配的時間比較快，並且不影響其他處理端。
（3） 原有結構，處理環節比較多。
改造後結構，少了kafka的環節。
（4）其他網友補充……。
文章：
《.NET Core開發的iNeuOS工業互聯網平台，發布 iNeuDA 數據分析展示組件，快捷開發圖形報表和數據大屏》
《[影片演示].NET Core開發的iNeuOS物聯網平台，實現從設備&PLC、雲平台、移動APP數據鏈路閉環 》
《.NET Core開發的iNeuOS物聯網平台部署樹霉派（raspbian），從網關到雲端整體解決方案》
《.NET Core開發的iNeuOS物聯網平台部署在Ubuntu作業系統，無縫跨平台》
《iNeuOS 物聯網雲作業系統2.0發布，集成設備容器、視圖建模、機器學習三大模組 》
物聯網&大數據技術 QQ群：54256083
物聯網&大數據合作 QQ群：727664080
聯繫QQ：504547114
合作微信：wxzz0151
