建站
咨詢
售后
建站咨詢
新聞中心
之前做了個玩具叫做 Cumulo, 大致意思后端計算數(shù)據(jù), 通過 Diff/Patch 發(fā)到前端,
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),江陽企業(yè)網(wǎng)站建設(shè),江陽品牌網(wǎng)站建設(shè),網(wǎng)站定制,江陽網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,江陽網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
那么前端瀏覽器的 Store 就不需要業(yè)務(wù)邏輯了, 從而減少開發(fā).
然而這種做法存在天然的缺陷, 首先, 性能問題, 其次, 持久化問題.
其實都可以歸結(jié)為性能, 要性能, 就必須做增量, 那么整個架構(gòu)就崩潰了.
這篇文章嘗試描述一下稍微正常一點的, 基于數(shù)據(jù)流來設(shè)計架構(gòu)的一個構(gòu)想.
由于后端開發(fā)經(jīng)驗的欠缺, 我并不打算給出可行的方案.
在開始之前, 先回顧一下實時 Web 應(yīng)用的架構(gòu)設(shè)計.
首先在前端 Model-View 分離是***步, 以便解放 View 的開發(fā)效率.
這時的數(shù)據(jù)流, Model 的數(shù)據(jù)發(fā)送到 View, 而 View 的更新操作回到 Model.
(這里的 Model 接近 Store, 并不是單純數(shù)據(jù), 而是包含更新邏輯):
接著, 把 Server 重新放回來, 大致就到了 Cumulo 的情況,
這時的數(shù)據(jù)流, 數(shù)據(jù)直接發(fā)送到服務(wù)端, 前端 Model 同步服務(wù)端,
***再回到 View, 這時 Model 就成為一個中間過程了:
那么結(jié)合上邊兩張圖, 把這部分簡化, 基本就回到***張圖的情形,區(qū)別是, 這時 Model 換成了服務(wù)器, 而數(shù)據(jù)流從服務(wù)器流行瀏覽器:
當(dāng)我們考慮數(shù)據(jù)庫, 特別是數(shù)據(jù)庫比如是增量處理, 問題就來了,
首先, 數(shù)據(jù)發(fā)送到 Server 而不是 Database, 因為 Server 才有邏輯,
其次, 不能把 Database 整個數(shù)據(jù)流發(fā)給 Server, 因為太大了.
Cumulo 中用的是 Diff/Patch 方案, 而這對于 Database 來說并不可行,
所以實際情況就挺糾結(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ù)庫的,
這個圖的重點是, 相比原來的一個流, 現(xiàn)在存在兩個流, 架構(gòu)已經(jīng)變了.
而數(shù)據(jù)通過兩種途徑來獲取:
數(shù)據(jù)抓取, 訪問頁面時直接抓取的數(shù)據(jù), 以及抓取歷史
推送, 用戶使用過程中, 從其他客戶端獲取的更新
問題是, 如果不能進(jìn)行簡化, 從而減少業(yè)務(wù)代碼的編寫, 思考就沒有意義了,
這兩個數(shù)據(jù)流的計算方法并不一致, 無法合并成一個,
所以我考慮, 從另外的角度去思考怎樣構(gòu)造出一套框架來處理數(shù)據(jù)流,
所以我整理了一下聊天室需要的常見操作:
- 切換聊天室
- 抓取首屏消息
- 抓取消息
- 接收消息更新
- 查詢歷史消息
- 用戶登錄
- 用戶權(quán)限驗證
對于前面四個操作我比較在意, 因為之間存在著一個共性,
比如一個消息流, 就會有, 切換, 抓取, 歷史, 更新, 這些個操作,
而整體看來, 其他的能夠抽象到流的數(shù)據(jù)也可以復(fù)用這個套路,
那么整個應(yīng)用的頁面切換, 數(shù)據(jù)查閱, 數(shù)據(jù)更新, 能放進(jìn)一個統(tǒng)一的框子,
也就是, 路由切換時選擇客戶端訂閱哪些流, 然后按流進(jìn)行瀏覽.
當(dāng)然其中還是存在一些問題, 需要繼續(xù)思考,
- 消息列表是流, 那么用戶配置是流嗎?
配置經(jīng)常是 JSON 對象, 要變成流, 就要把不同時間的修改操作也涵蓋進(jìn)來,
但是這還是會涉及到新的問題, 每一條消息都可能修改, 那么也是流,
結(jié)果我們需要面對一個復(fù)雜很多的流的概念.
- 另一個是數(shù)據(jù)的關(guān)聯(lián), 消息當(dāng)中會有附件, 聊天室會有成員,
數(shù)據(jù)的關(guān)聯(lián)如何處理? API 的設(shè)計怎樣對應(yīng)的界面, 而兩者又進(jìn)行解耦?
如果數(shù)據(jù)之間還出現(xiàn)循環(huán)的關(guān)聯(lián)關(guān)系, 整個方案是否將要失效?
這是一個相當(dāng)麻煩的事情, 最開始可能還是要盡量避免掉.
此外, 即便解決了上邊兩個問題, 前面列表當(dāng)中剩下的選項依然要處理,
權(quán)限系統(tǒng), 搜索系統(tǒng), 兩個是獨立于流的結(jié)構(gòu)之外的, 無法同時抽象.
更加遠(yuǎn)的問題, 數(shù)據(jù)庫和服務(wù)器可能是分布式的, 還會有更復(fù)雜的數(shù)據(jù)流.
所以實際上拋出來更多問題了.
文章名稱：思考Web應(yīng)用的數(shù)據(jù)流
文章URL：http://www.5511xx.com/article/cdocshh.html
