之前做了個(gè)玩具叫做 Cumulo, 大致意思后端計(jì)算數(shù)據(jù), 通過(guò) Diff/Patch 發(fā)到前端,

那么前端瀏覽器的 Store 就不需要業(yè)務(wù)邏輯了, 從而減少開(kāi)發(fā).

然而這種做法存在天然的缺陷, 首先, 性能問(wèn)題, 其次, 持久化問(wèn)題.

其實(shí)都可以歸結(jié)為性能, 要性能, 就必須做增量, 那么整個(gè)架構(gòu)就崩潰了.

這篇文章嘗試描述一下稍微正常一點(diǎn)的, 基于數(shù)據(jù)流來(lái)設(shè)計(jì)架構(gòu)的一個(gè)構(gòu)想.

由于后端開(kāi)發(fā)經(jīng)驗(yàn)的欠缺, 我并不打算給出可行的方案.

在開(kāi)始之前, 先回顧一下實(shí)時(shí) Web 應(yīng)用的架構(gòu)設(shè)計(jì).

首先在前端 Model-View 分離是***步, 以便解放 View 的開(kāi)發(fā)效率.

這時(shí)的數(shù)據(jù)流, Model 的數(shù)據(jù)發(fā)送到 View, 而 View 的更新操作回到 Model.

(這里的 Model 接近 Store, 并不是單純數(shù)據(jù), 而是包含更新邏輯): 

接著, 把 Server 重新放回來(lái), 大致就到了 Cumulo 的情況,

這時(shí)的數(shù)據(jù)流, 數(shù)據(jù)直接發(fā)送到服務(wù)端, 前端 Model 同步服務(wù)端,

***再回到 View, 這時(shí) Model 就成為一個(gè)中間過(guò)程了: 

那么結(jié)合上邊兩張圖, 把這部分簡(jiǎn)化, 基本就回到***張圖的情形,區(qū)別是, 這時(shí) Model 換成了服務(wù)器, 而數(shù)據(jù)流從服務(wù)器流行瀏覽器: 

當(dāng)我們考慮數(shù)據(jù)庫(kù), 特別是數(shù)據(jù)庫(kù)比如是增量處理, 問(wèn)題就來(lái)了,

首先, 數(shù)據(jù)發(fā)送到 Server 而不是 Database, 因?yàn)?Server 才有邏輯,

其次, 不能把 Database 整個(gè)數(shù)據(jù)流發(fā)給 Server, 因?yàn)樘罅?

Cumulo 中用的是 Diff/Patch 方案, 而這對(duì)于 Database 來(lái)說(shuō)并不可行,

所以實(shí)際情況就挺糾結(jié)了, Server 回到了 Controller 的角色: 

***為了性能, 更新邏輯還需要從 Database 拿開(kāi), 而讓 Model 回來(lái),

那么 Model 一方面要處理數(shù)據(jù)請(qǐng)求, 一方面要處理推送, 只能增加,

整個(gè)數(shù)據(jù)流也多了一些線路, 變得復(fù)雜起來(lái), 這也是當(dāng)初簡(jiǎn)聊大致的架構(gòu): 

不過(guò)這個(gè)圖并不嚴(yán)謹(jǐn), 比如 Database 和 Server 的具體關(guān)系很難畫(huà)清楚,

而且請(qǐng)求當(dāng)然是訪問(wèn)到一個(gè) web server 而不可能直接放到數(shù)據(jù)庫(kù)的,

這個(gè)圖的重點(diǎn)是, 相比原來(lái)的一個(gè)流, 現(xiàn)在存在兩個(gè)流, 架構(gòu)已經(jīng)變了.

而數(shù)據(jù)通過(guò)兩種途徑來(lái)獲取:

數(shù)據(jù)抓取, 訪問(wèn)頁(yè)面時(shí)直接抓取的數(shù)據(jù), 以及抓取歷史

推送, 用戶使用過(guò)程中, 從其他客戶端獲取的更新

問(wèn)題是, 如果不能進(jìn)行簡(jiǎn)化, 從而減少業(yè)務(wù)代碼的編寫(xiě), 思考就沒(méi)有意義了,

這兩個(gè)數(shù)據(jù)流的計(jì)算方法并不一致, 無(wú)法合并成一個(gè),

所以我考慮, 從另外的角度去思考怎樣構(gòu)造出一套框架來(lái)處理數(shù)據(jù)流,

所以我整理了一下聊天室需要的常見(jiàn)操作:

• 切換聊天室
• 抓取首屏消息
• 抓取消息
• 接收消息更新
• 查詢(xún)歷史消息
• 用戶登錄
• 用戶權(quán)限驗(yàn)證

對(duì)于前面四個(gè)操作我比較在意, 因?yàn)橹g存在著一個(gè)共性,

比如一個(gè)消息流, 就會(huì)有, 切換, 抓取, 歷史, 更新, 這些個(gè)操作,

而整體看來(lái), 其他的能夠抽象到流的數(shù)據(jù)也可以復(fù)用這個(gè)套路,

那么整個(gè)應(yīng)用的頁(yè)面切換, 數(shù)據(jù)查閱, 數(shù)據(jù)更新, 能放進(jìn)一個(gè)統(tǒng)一的框子,

也就是, 路由切換時(shí)選擇客戶端訂閱哪些流, 然后按流進(jìn)行瀏覽.

當(dāng)然其中還是存在一些問(wèn)題, 需要繼續(xù)思考,

• 消息列表是流, 那么用戶配置是流嗎?

配置經(jīng)常是 JSON 對(duì)象, 要變成流, 就要把不同時(shí)間的修改操作也涵蓋進(jìn)來(lái),

但是這還是會(huì)涉及到新的問(wèn)題, 每一條消息都可能修改, 那么也是流,

結(jié)果我們需要面對(duì)一個(gè)復(fù)雜很多的流的概念.

• 另一個(gè)是數(shù)據(jù)的關(guān)聯(lián), 消息當(dāng)中會(huì)有附件, 聊天室會(huì)有成員,

數(shù)據(jù)的關(guān)聯(lián)如何處理? API 的設(shè)計(jì)怎樣對(duì)應(yīng)的界面, 而兩者又進(jìn)行解耦?

如果數(shù)據(jù)之間還出現(xiàn)循環(huán)的關(guān)聯(lián)關(guān)系, 整個(gè)方案是否將要失效?

這是一個(gè)相當(dāng)麻煩的事情, 最開(kāi)始可能還是要盡量避免掉.

此外, 即便解決了上邊兩個(gè)問(wèn)題, 前面列表當(dāng)中剩下的選項(xiàng)依然要處理,

權(quán)限系統(tǒng), 搜索系統(tǒng), 兩個(gè)是獨(dú)立于流的結(jié)構(gòu)之外的, 無(wú)法同時(shí)抽象.

更加遠(yuǎn)的問(wèn)題, 數(shù)據(jù)庫(kù)和服務(wù)器可能是分布式的, 還會(huì)有更復(fù)雜的數(shù)據(jù)流.

所以實(shí)際上拋出來(lái)更多問(wèn)題了.