過多的介面請求是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