之前做了個玩具叫做 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 的設計怎樣對應的界面, 而兩者又進行解耦?
如果資料之間還出現循環的關聯關系, 整個方案是否将要失效?
這是一個相當麻煩的事情, 最開始可能還是要盡量避免掉.
此外, 即便解決了上邊兩個問題, 前面清單當中剩下的選項依然要處理,
權限系統, 搜尋系統, 兩個是獨立于流的結構之外的, 無法同時抽象.
更加遠的問題, 資料庫和伺服器可能是分布式的, 還會有更複雜的資料流.
是以實際上抛出來更多問題了.
作者：佚名
來源：51cto