思考 Web 應用的數據流

以前作了個玩具叫作 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 的設計怎樣對應的界面, 而二者又進行解耦?
若是數據之間還出現循環的關聯關係, 整個方案是否將要失效?
這是一個至關麻煩的事情, 最開始可能仍是要儘可能避免掉.

此外, 即使解決了上邊兩個問題, 前面列表當中剩下的選項依然要處理,
權限系統, 搜索系統, 兩個是獨立於流的結構以外的, 沒法同時抽象.
更加遠的問題, 數據庫和服務器多是分佈式的, 還會有更復雜的數據流.

因此實際上拋出來更多問題了.