之前做了個玩具叫做 Cumulo, 大致意思后端計算數據, 通過 Diff/Patch 發到前端,

那么前端瀏覽器的 Store 就不需要業務邏輯了, 從而減少開發.

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

其實都可以歸結為性能, 要性能, 就必須做增量, 那么整個架構就崩潰了.

這篇文章嘗試描述一下稍微正常一點的, 基于數據流來設計架構的一個構想.

由于后端開發經驗的欠缺, 我并不打算給出可行的方案.

在開始之前, 先回顧一下實時 Web 應用的架構設計.

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

這時的數據流, Model 的數據發送到 View, 而 View 的更新操作回到 Model.

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

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

這時的數據流, 數據直接發送到服務端, 前端 Model 同步服務端,

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

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

當我們考慮數據庫, 特別是數據庫比如是增量處理, 問題就來了,

首先, 數據發送到 Server 而不是 Database, 因為 Server 才有邏輯,

其次, 不能把 Database 整個數據流發給 Server, 因為太大了.

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

所以實際情況就挺糾結了, Server 回到了 Controller 的角色: 

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

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

整個數據流也多了一些線路, 變得復雜起來, 這也是當初簡聊大致的架構: 

不過這個圖并不嚴謹, 比如 Database 和 Server 的具體關系很難畫清楚,

而且請求當然是訪問到一個 web server 而不可能直接放到數據庫的,

這個圖的重點是, 相比原來的一個流, 現在存在兩個流, 架構已經變了.

而數據通過兩種途徑來獲取:

數據抓取, 訪問頁面時直接抓取的數據, 以及抓取歷史

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

問題是, 如果不能進行簡化, 從而減少業務代碼的編寫, 思考就沒有意義了,

這兩個數據流的計算方法并不一致, 無法合并成一個,

所以我考慮, 從另外的角度去思考怎樣構造出一套框架來處理數據流,

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

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

對于前面四個操作我比較在意, 因為之間存在著一個共性,

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

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

那么整個應用的頁面切換, 數據查閱, 數據更新, 能放進一個統一的框子,

也就是, 路由切換時選擇客戶端訂閱哪些流, 然后按流進行瀏覽.

當然其中還是存在一些問題, 需要繼續思考,

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

配置經常是 JSON 對象, 要變成流, 就要把不同時間的修改操作也涵蓋進來,

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

結果我們需要面對一個復雜很多的流的概念.

• 另一個是數據的關聯, 消息當中會有附件, 聊天室會有成員,

數據的關聯如何處理? API 的設計怎樣對應的界面, 而兩者又進行解耦?

如果數據之間還出現循環的關聯關系, 整個方案是否將要失效?

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

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

權限系統, 搜索系統, 兩個是獨立于流的結構之外的, 無法同時抽象.

更加遠的問題, 數據庫和服務器可能是分布式的, 還會有更復雜的數據流.

所以實際上拋出來更多問題了.