物联网项目杂论
目前從事于物聯(lián)網(wǎng)行業(yè)。 共享充電寶。 負責(zé)通訊相關(guān)。 當(dāng)前設(shè)備在線量約50W 臺。記錄一下走得彎路。 方便大家借鑒。
文筆不太好，希望大家輕噴。
本文主要是從以下幾個方面探討：
1. 物聯(lián)網(wǎng)方案選型
2. 通訊協(xié)議設(shè)計
3. 后臺架構(gòu)設(shè)計
4. 統(tǒng)計和監(jiān)控
1.物聯(lián)網(wǎng)方案選型
方案選型這一塊其實蠻多的。 需要大家根據(jù)自己得業(yè)務(wù)類型來做出選擇。 是直接走TCP長連接？ 還是使用MQTT， HTTP這些已經(jīng)封裝好得協(xié)議。
mqtt 協(xié)議開箱即用，方便快捷。 而且相關(guān)的開源項目也不少。方便借鑒和資料查找。 目前各大云平臺也有IOT相關(guān)服務(wù)。 直接鏈入快速開發(fā)即可。 但卻不在本文討論之中。本文只討論TCP協(xié)議。
如果使用TCP協(xié)議， 對于業(yè)務(wù)的話則需要重傳， 確認機制。 對于業(yè)務(wù)性強的領(lǐng)域。 可以考慮增加 短信，和UDP 進行通訊。
我方目前采用 TCP + 短信進行通訊， 目前95% 的流量再TCP就進行處理了。（只有部分剩余機器所處網(wǎng)絡(luò)狀況不佳） 剩余 約 5 % 使用的短信進行通訊。
2. 通訊協(xié)議設(shè)計
這里推薦大家自定義私有協(xié)議。 安全性高。 報文體積小。 在這里有幾點需要注意：
對于報文設(shè)計來說， 最好的是盡可能的將所有設(shè)備信息上報。 方便業(yè)務(wù)進行處理。 而不要在硬件上進行消息屏蔽。 應(yīng)在后臺業(yè)務(wù)中做出處理。
3. 后臺架構(gòu)設(shè)計
當(dāng)前的云服務(wù)器 ECS? 4C/8G/10MB , 這種配置一臺可以扛住1W 以上鏈接。 但是在做鏈入設(shè)計時。 最好使用2臺以上服務(wù)器來進行輪詢分配。 避免單點故障。 這一點在任何系統(tǒng)中都應(yīng)該做備災(zāi)設(shè)計。 至于開發(fā)語言。 其實用什么都可以的。 目前無論時 java/ php/ nodejs 。性能基本都足夠使用。? 反正我現(xiàn)在覺得 性能什么的都是扯淡。 業(yè)務(wù)才是最重要的。? ? ? ?只要業(yè)務(wù)能賺錢， 完全可以重構(gòu)做2.0, 3.0； 性能時迭代上去的。
4. 統(tǒng)計和監(jiān)控
在這里也需要注意一點， 對于物聯(lián)網(wǎng)來說， 統(tǒng)計監(jiān)控必須要做好。
推薦使用列式存儲， 可壓縮。而且方便分析處理。 我們使用的是 clickhouse.?
主要需要統(tǒng)計以下指標(biāo)：
- 鏈入次數(shù)
- 接口請求走勢
- 數(shù)據(jù)上報走勢
- 異常發(fā)生走勢
- 當(dāng)前在線設(shè)備
對于設(shè)備來說， 日志可以多存一點方便跟蹤和排查問題。 以上指標(biāo)最好做聚合分析。 使用釘釘什么做一個推送。一有異常， 馬上排查。 對于物聯(lián)網(wǎng)設(shè)備來說， 量小一般不會有什么問題。 設(shè)備量大問題馬上就暴露了。 而且由于重試等機制， 容易出現(xiàn)洪水攻擊導(dǎo)致后臺雪崩。 所以監(jiān)控最好早點做。 防微杜漸。
總結(jié)
