今天聽 sofish 分享了好多保屯。感覺還是回來寫一下這個(gè)比較好。
我不知道在場(chǎng)多少人了解這個(gè)事情涤垫，至少我?guī)サ男』锇槎际撬贫嵌?br> 正好好久不寫技術(shù)東西姑尺，來了心情，那就不能浪費(fèi)蝠猬。
為什么我沒有現(xiàn)場(chǎng)講呢切蟋？
因?yàn)闆]圖我只能說個(gè)杰寶啊。
[合并請(qǐng)求] 這個(gè)需求來源點(diǎn)是：我們有太多的請(qǐng)求榆芦，影響性能柄粹，不如合并一起發(fā)送，減少 HTTP 請(qǐng)求數(shù)量匆绣。
這里驻右，請(qǐng)求分兩類
- 靜態(tài)資源
- 展現(xiàn)數(shù)據(jù)
靜態(tài)數(shù)據(jù)
這個(gè)比較好處理，簡(jiǎn)單粗暴的方式就是
- 編譯的時(shí)候把多個(gè) CSS 合并了
- 編譯的時(shí)候把多個(gè) JS 合并了
- 把以上兩個(gè)放到 CDN 上
- 文檔加載合并后的文件后的文件
展現(xiàn)數(shù)據(jù)
異步請(qǐng)求一般用的是相對(duì)復(fù)雜的過程崎淳，這個(gè)過程中堪夭，需要前后端的配合。
肯定不能是兩個(gè)接口拣凹，分開的時(shí)候請(qǐng)求/aaa 和 /bbb森爽，合并的時(shí)候請(qǐng)求/ccc，這也太2了嚣镜。
大致就是這樣一個(gè)過程：
br.png
其實(shí)就做了四件事情
- B 端的 Interceptor 攔截請(qǐng)求爬迟，分發(fā)結(jié)果。
- S 端的 Filter 分發(fā)請(qǐng)求菊匿，拼裝返回付呕。
約定數(shù)據(jù)結(jié)構(gòu)
請(qǐng)求大致會(huì)是這個(gè)樣子
"requests": [
{
"seq":"0",
"api":"aaa",
"data":"111"
},{
"seq":"1",
"api":"bbb",
"data":"222"
}
]
返回大致會(huì)是這個(gè)樣子
"responses": [
{
"seq":"0",
"data":"oo"
},{
"seq":"1",
"data":"xx"
}
]
攔截
- 攔截所有請(qǐng)求，Hold 住
- 第一個(gè)進(jìn)來開始計(jì)時(shí)
- 大致 20ms 內(nèi)所有請(qǐng)求組成一個(gè) Batch Request 發(fā)出去
分發(fā)
- 解析出哪些 api
- 解析出對(duì)應(yīng) data
- 扔給 Controller 去執(zhí)行
- Hold 住 Controller 結(jié)果
拼裝
- Controller 都搞定以后跌捆，就是把結(jié)果拼裝成要的樣子……
分發(fā)
- 解析結(jié)果
- 對(duì)應(yīng)結(jié)果塞到對(duì)應(yīng) callback 里去凡涩，順手轉(zhuǎn)一下 scope
整個(gè)過程對(duì)于前端和后端開發(fā)都是透明的。
前端來看我發(fā)出去是一個(gè)一個(gè)的疹蛉。
后端來看我接收到的也是一個(gè)一個(gè)的。
不足是力麸，所有交互都會(huì)有差不多 20ms 的延遲可款。
5年前我們就是這樣做的育韩。
反正我是一個(gè)渣渣，哪里寫錯(cuò)了闺鲸，有本事你來咬我呀筋讨！
