Batch Requests

今天听 sofish 分享了好多。感觉还是回来写一下这个比较好。
我不知道在场多少人了解这个事情，至少我带去的小伙伴都是似懂非懂。
正好好久不写技术东西，来了心情，那就不能浪费。
为什么我没有现场讲呢？
因为没图我只能说个杰宝啊。

---

[合并请求] 这个需求来源点是：我们有太多的请求，影响性能，不如合并一起发送，减少 HTTP 请求数量。

这里，请求分两类

• 静态资源
• 展现数据

静态数据

这个比较好处理，简单粗暴的方式就是

• 编译的时候把多个 CSS 合并了
• 编译的时候把多个 JS 合并了
• 把以上两个放到 CDN 上
• 文档加载合并后的文件后的文件

展现数据

异步请求一般用的是相对复杂的过程，这个过程中，需要前后端的配合。

肯定不能是两个接口，分开的时候请求/aaa 和 /bbb，合并的时候请求/ccc，这也太2了。

大致就是这样一个过程：

br.png

其实就做了四件事情

• B 端的 Interceptor 拦截请求，分发结果。
• S 端的 Filter 分发请求，拼装返回。

约定数据结构

请求大致会是这个样子

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

返回大致会是这个样子

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

拦截

• 拦截所有请求，Hold 住
• 第一个进来开始计时
• 大致 20ms 内所有请求组成一个 Batch Request 发出去

分发

• 解析出哪些 api
• 解析出对应 data
• 扔给 Controller 去执行
• Hold 住 Controller 结果

拼装

• Controller 都搞定以后，就是把结果拼装成要的样子……

分发

• 解析结果
• 对应结果塞到对应 callback 里去，顺手转一下 scope

---

整个过程对于前端和后端开发都是透明的。
前端来看我发出去是一个一个的。
后端来看我接收到的也是一个一个的。
不足是，所有交互都会有差不多 20ms 的延迟。

5年前我们就是这样做的。

反正我是一个渣渣，哪里写错了，有本事你来咬我呀！