[討論] 平臺建設，我們從架構中去掉kafka？
目 錄
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釋出，整合裝置容器、檢視建模、機器學習三大模組 》
《iNeuOS雲作業系統，.NET Core全系打造 》
物聯網&大資料技術 QQ群：54256083
物聯網&大資料合作 QQ群：727664080
網站：http://www.ineuos.net
聯絡QQ：504547114
合作微信：wxzz0151