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