如果采用 KV 方式存儲，如何設(shè)計數(shù)據(jù)結(jié)構(gòu) ?同上，我們要怎樣去設(shè)計一種高效的 topic 分片存儲策略;
訂閱關(guān)系的管理是 MQTT 消息系統(tǒng)的核心模塊，假如這個存儲模塊失效，就必定會導(dǎo)致消息通信失敗，從而讓客戶端收不到消息，這就必須要求這個模塊一定是高可用的，也就意味著我們必須構(gòu)建一個高可用的 KV 存儲集群，該集群要能容忍一定程度的節(jié)點失效;
冷熱 topic 要有淘汰機制，要有一定策略將不活躍的 topic 定期淘汰到磁盤以節(jié)約內(nèi)存容量;
KV 存儲集群要能高效地動態(tài)擴容;
在很長一段時間的實踐中，我們采用過好幾種 KV 存儲的集群方案，踩了不少坑，最后還是決定自己造輪子來開發(fā)一個高可用的 KV 存儲模塊。不過這又是一個很大的話題，我們將在后續(xù)博客中具體闡述我們的做法。
缺陷與不足
在團隊發(fā)展初期，由于人力和時間等種種因素，我們把業(yè)務(wù)邏輯模塊開發(fā)成了一個巨大的單體架構(gòu)應(yīng)用。在團隊規(guī)模較小的情況下，單體架構(gòu)的應(yīng)用確實較好維護和開發(fā)，但隨著新人的加入，單體架構(gòu)則嚴重制約著特性開發(fā)和性能優(yōu)化。從架構(gòu)層面上來看，合理地劃分更細粒度的模塊，在性能和可維護性上采用 微服務(wù) (microservice)設(shè)計模式，成了我們未來優(yōu)化系統(tǒng)的方向之一。
總結(jié)
軟件工程上有「沒有銀彈」(No Silver Bullet)這條金科玉律，用戶選擇云服務(wù)商亦是如此，絕對沒有完美的第三方云服務(wù)商，每一家都可能存在明顯的優(yōu)點和缺陷。用戶必須從自己應(yīng)用場景和痛點出發(fā)，選擇合適的后端服務(wù)。云巴將會在自己產(chǎn)品的核心競爭力上持續(xù)發(fā)力，精打細磨，吸取行業(yè)內(nèi)的高效實踐經(jīng)驗，打造出更加優(yōu)秀的高可用實時通信系統(tǒng)。