導語
2018年又過的非常快.16年開始工作以來.沒有怎麼做過總結,感覺很遺憾(怪自己懶唄).有過想法,但沒實踐. 今年做個一個saas專案.在這也做做總結.技術棧 spring cloud + redis + rabbitmq + postgres + netty 等
工作總結
產品定位為saas專案,必然後多租戶,資料隔離等,此專案原為物聯網專案,但後期在其領域上擴充套件了其他業務(垂直行業),但是需要此專案的資料
多租戶
- 多租戶使用多個schema來解決資料隔離問題如
iot_tenant01,iot_tenant02,crm_tenant_03,crm_tenant_04 - 使用多資料來源切換來達到資料隔離
https://github.com/baomidou/dynamic-datasource-spring-boot-starter - 使用spring cloud 構建一個租戶管理微服務,來管理租戶的生命週期,開通,關閉.續費等
- 構建一個統一的認證,鑑權微服務,使用rbac許可權模型
物聯網
這一塊就包含了很多東西了.一些是設計要點,一些編碼也需要注意
通訊協議
- 如果通訊協議是自定義二進位制通訊協議,那麼使用netty解析很方便,多種編解碼器.使用netty可以構建高效能資料接收閘道器如
connector-tcp , connector-coap ,connector-mqtt(轉發,負載) - 通訊協議的可擴充套件性很重要.需要有必要的版本欄位
v1 ,v2等 - 可以考慮自解釋形的訊息協議
TLV訊息模型
資料解析
- 資料解析的靈活性由為重要,如果想做成通用的解析,可以使用模板的方式,針對每種訊息協議,有不同的訊息模板.根據index來順序解析.這要求你的資料每次都是全量上傳的
- 如果你的訊息是增量上傳(只上傳變化的資料).那麼這種解析方式就不行了.可以基於
TLV訊息協議協議的變種來實現. - 對於感測器訊息來說訊息分類是必須的,控制類,感測器資料類等,不要再感測器資料解析中加業務(很重要).
資料儲存
- 一定不能用結構化資料結構,協議變更,增刪欄位會讓你痛苦不堪,使用非格式化資料 pg 的jsonb可以試試.
- 租戶模型結合,各自租戶從訊息佇列上訂閱自己所關注的裝置資料,統一的解析端解析完後傳送到對應租戶的訊息佇列中,租戶的表中只存裝置最新的資料,如果獲取歷史資料,由提供一微服務提供
-
資料儲存對歷史資料劃分不同等級: 熱,溫,冷
- 熱: 雲上的庫只保留一週的資料,使用mongodb
- 溫: 本地庫儲存兩個月使用mongodb,或hbase
- 冷: 自建分散式資料庫: Hbase
-
關於rowkey設計很關鍵,結合自己的業務設計,參考
https://mp.weixin.qq.com/s/kmiA5Lw0ZV01h9kzUbjz0Qhttps://mp.weixin.qq.com/s/7SulKTNNrkYkcNRJE4IyUw
資料分析
- 流計算推薦flink
- 機器學習不熟悉
技術總結
spring cloud
會用但沒有深入,準備下一年深入下
Redis
這個專案剛開始採用.整體很強,最重要還是要選擇和資料結構,和key設計.針對物聯網裝置最新資料可以試試hash資料結構.同時推薦redisson
Netty
物聯網專案java技術棧首選.基於nio,效能很不錯
- netty只做訊息中轉,接到訊息往訊息中介軟體中發,再由後端系統解析
- netty中耗時業務,建議開個單獨的執行緒池去解決
- 最重要的ByteBuf不要誤用,注意記憶體洩漏(這個是個坑)
展望
- 堅持寫部落格,對比了下sg還可以.專注技術
- 深入探索spring cloud / boot,docker,redis,Hbase
- 加強java演算法,jvm,執行緒方面
- 擴充套件一種語言go
零零散散
- 很大可能會在年中換工作, 因為從畢業一直在這個行業做,做了兩年多感覺自己的視野會有一定的侷限.
- 還有感覺公司………
- 看到一句話
不空談理想，暢想未來，或者團隊文化，太假大空的東西會讓人覺得不靠譜