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