合并批量请求

　　前一段时间，碰到一个问题，后端提供的API是批量接口，容许在一个HTTP请求中放上N个业务上的请求，一块儿处理，完成后一块儿返回，可是咱们的前端又是以单个请求为主，这样势必致使不少http请求仅仅包含单个业务请求，大量的把带宽浪费在http head，以及把cpu浪费在http协议的解析上，而改写现有代码让请求尽可能合并在起来是一件既费力又会遭遇多线程间没法合并等问题的麻烦事情。。。那么，这里就须要找到一个不须要大幅修改现有的代码，而且能完成请求合并的方法。

　　软件上的问题，大部分能够经过添加一个层来搞定，此次的这个问题也不例外。

　　首先，来肯定一下范围，为了简化问题，咱们作了下面几个限制：

• 只支持该请求有一个相似TRequest[]的参数，而且其返回值为相似TResponse[]，乍一看，好像不少请求不能知足这个要求，不过，咱们能够将其余参数放在Tuple之类的对象中，把请求假装成一个类型的数组
• 只支持一个请求有且必须有一个返回，也就是说，不能一个请求返回多个结果，也不能够不返回结果
• 只支持请求的顺序与返回的顺序一致，换句话说，请求一、二、3，必须返回一、二、3，顺序必须一致。不少api不会这么设计，不过，咱们能够加一些预处理，使这个条件知足

　　而后，须要分析一下合并策略：

• 不是全部请求都能合并在一块儿的，这取决于后端API的实现，例如：不一样权限角色可能不能合并，部分参数可能必须是一致的
• 批量请求一般会有数量上限，不太可能有后端代码会支持无限数量的批量
• 合并请求每每是以增长延迟为代价的，如何在二者之间平衡是一门艺术，也就是说没法说哪一种方式是最好的，只能凭感受

　　这里，咱们作了这样的一个选择：

• 合并须要一些规则作约束，这些规则能够添加不少，可是必须是轻量级的，不然会影响合并的效率（这里咱们只能假设，万一真的有人在里面写个Thread.Sleep，咱们也只能呵呵了）
• 延迟和合并之间的平衡，咱们决定让连接数来决定，也就是保持总连接数不大于某个值，若是连接很空闲，就直接出去，不作任何合并，反之，若是连接已经被占满，就尝试与排队中的请求合并，没法合并，就新建请求
• 不支持排队中的请求再排序，这里假定全部请求都是相同优先级的

　　到这里，咱们的目标已经明确，剩下的就是写代码实现了。

----------------------------此处省去过程5000字------------------------------

　　最后，分享一下这段代码。