过多的接口请求是web前端的主要性能瓶颈之一，接口合并是刚需。后台的接口设计有其既有粒度，对每个功能场景额外的增加合并的接口，工作量巨大，且场景难以覆盖。增加一台离接口服务器很近的代理服务器，定义一套接口合并的规则，代理服务器解析前端发来的规则，对接口服务器发起近距离请求，合并后返回。

一、Web 开发的困境

在web开发中，前端为了一个实现一个功能，连续的请求多个接口的场景并不少见。图一示例中，后一个接口依赖于前一个接口的请求结果，于是你经常要这样去组织你的接口请求step1.then(step2).then(step3)（promise语法），图二中，step1,step2,step3虽然没有依赖关系，但是同样需要跟api-server交互三次，web应用中，没多一秒等待都意味着多一份失去。

你可能会抱怨后端的同事，为何不把这几个接口合并，然而后端的同事就会反驳你：“你这个场景需要step1->step2->step3，那个页面只需要step1 -> step2，甚至有些页面只需要step1，我如何给你合并？”你可以继续说，可以提供三个这样的接口嘛，那么后台的同事可能直接会崩溃，这样的场景何其多，新增一个场景新增一个接口，后台就得发一次版本。

二、代理服务的接口合并方案

代理服务（proxy-server.png）和接口服务器（api-server）的网络链路应该尽量的“近”。部署在同一机房同一网段的服务器上，甚至是同一服务器上；增加服务器硬件性能；负载均衡集群等；这些都是“简短“网络链路的有效手段
前后端约定好一套接口合并的规则，代理服务只需要做好解析规则请求合并的工作，一旦部署将保持稳定，接口合并的主动权将掌握在前端，前端可以根据场景的变化自由的组合合并规则
代理服务与接口服务走的同样是http/https协议，对接口服务器没有依赖嵌入，前端直接请求接口服务器也是没有问题的，换句话说：老的访问方式完全不受影响。

这种合并方案为什么能极大的提升接口访问速度

对于需要访问三个有依赖关系的接口的场景（上图一）：传统的前端直接请求接口服务器的方式，前端跟服务器的交互相当于需要走三次”远路“（为什么说前端直接连接口服务器认为是”远路“，因为前端的网络状态无法保证，对于移动端设备常常只能在3g/4g的网络环境下，况且移动端硬件性能并不占优），并且需要串行等待；然而使用代理服务器的方式，前端只需要走一次”远路“把规则告诉代理服务器，代理服务器再跟它老表接口服务器要三次数据（代理服务器跟接口服务器的访问速度往往远高于前端与服务器的直接交互的访问速度，根本不是一个量级的）

没有数据支撑的理论臆测都是在耍流氓，我在同一台服务器上分别部署了接口服务（api-server），和使用了上述代理方案的node实现（freedom-api，后文会详细说明），接口服务器提供了两个有依赖关系的串行接口，使用手机在不同的网络下分别使用传统的直连方式和走代理服务合并接口的方式进行测试，得到如下测试结果：

由图可见，在三种网络环境下，代理合并的方式的访问速度都明显高于传统直连的方式，并且网络状况越差，体现得越明显

三、规则定义

请移步 freedom-api

四、基于 freedom-api 实现的在线接口流程测试工具

请移步 Facemagic