今天聽 sofish 分享了好多。感覺還是回來寫一下這個比較好。
我不知道在場多少人了解這個事情，至少我?guī)サ男』锇槎际撬贫嵌?br> 正好好久不寫技術(shù)東西，來了心情，那就不能浪費(fèi)。
為什么我沒有現(xiàn)場講呢？
因?yàn)闆]圖我只能說個杰寶啊。

[合并請求] 這個需求來源點(diǎn)是：我們有太多的請求，影響性能，不如合并一起發(fā)送，減少 HTTP 請求數(shù)量。

這里，請求分兩類

• 靜態(tài)資源
• 展現(xiàn)數(shù)據(jù)

靜態(tài)數(shù)據(jù)

這個比較好處理，簡單粗暴的方式就是

• 編譯的時候把多個 CSS 合并了
• 編譯的時候把多個 JS 合并了
• 把以上兩個放到 CDN 上
• 文檔加載合并后的文件后的文件

展現(xiàn)數(shù)據(jù)

異步請求一般用的是相對復(fù)雜的過程，這個過程中，需要前后端的配合。

肯定不能是兩個接口，分開的時候請求/aaa 和 /bbb，合并的時候請求/ccc，這也太2了。

大致就是這樣一個過程：

br.png

其實(shí)就做了四件事情

• B 端的 Interceptor 攔截請求，分發(fā)結(jié)果。
• S 端的 Filter 分發(fā)請求，拼裝返回。

約定數(shù)據(jù)結(jié)構(gòu)

請求大致會是這個樣子

"requests": [
  {
    "seq":"0",
    "api":"aaa",
    "data":"111"
  },{
    "seq":"1",
    "api":"bbb",
    "data":"222"
  }
]

返回大致會是這個樣子

"responses": [
  {
    "seq":"0",
    "data":"oo"
  },{
    "seq":"1",
    "data":"xx"
  }
]

攔截

• 攔截所有請求，Hold 住
• 第一個進(jìn)來開始計(jì)時
• 大致 20ms 內(nèi)所有請求組成一個 Batch Request 發(fā)出去

分發(fā)

• 解析出哪些 api
• 解析出對應(yīng) data
• 扔給 Controller 去執(zhí)行
• Hold 住 Controller 結(jié)果

拼裝

• Controller 都搞定以后，就是把結(jié)果拼裝成要的樣子……

分發(fā)

• 解析結(jié)果
• 對應(yīng)結(jié)果塞到對應(yīng) callback 里去，順手轉(zhuǎn)一下 scope

整個過程對于前端和后端開發(fā)都是透明的。
前端來看我發(fā)出去是一個一個的。
后端來看我接收到的也是一個一個的。
不足是，所有交互都會有差不多 20ms 的延遲。

5年前我們就是這樣做的。

反正我是一個渣渣，哪里寫錯了，有本事你來咬我呀！