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

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

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

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

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

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

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

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

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

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

接著, 把 Server 重新放回來, 大致就到了 Cumulo 的情況,

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

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

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

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

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

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

Cumulo 中用的是 Diff/Patch 方案, 而這對于 Database 來說并不可行,

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

***為了性能, 更新邏輯還需要從 Database 拿開, 而讓 Model 回來,

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

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

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

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

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

而數(shù)據(jù)通過兩種途徑來獲取:

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

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

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

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

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

所以我整理了一下聊天室需要的常見操作:

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

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

比如一個消息流, 就會有, 切換, 抓取, 歷史, 更新, 這些個操作,

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

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

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

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

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

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

但是這還是會涉及到新的問題, 每一條消息都可能修改, 那么也是流,

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

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

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

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

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

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

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

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

所以實(shí)際上拋出來更多問題了.