無線時代，網絡穩定性差，應用流量敏感，APP與Server之間每次HTTP請求都需要進行DNS解析，有沒有可能直接使用IP來提速呢？
典型HTTP請求處理過程如何？
第一步，用戶端通路DNS伺服器，由域名拿到Nginx的外網IP；
第二步，用戶端使用外網IP通路Nginx；
第三步，Nginx将請求分發給實際處理HTTP請求的Web-server；
移動時代APP的通路特點如何？
（1）網絡慢，DNS解析的時間不能忽略；
（2）一旦DNS被劫持，整個APP就挂了；
APP能夠把Web-server的ip-list内置，進而跳過DNS解析，跳過Nginx中轉，直接通過IP通路後端的Web-server麼？
不行，Web-server的擴充性較差，增加IP時APP沒辦法得到通知。
畫外音：Nginx可以保證Web-server的高可用，去掉Nginx後，需要APP重試，或者Web-server做高可用。
如何進行優化呢？
不要将ip-list内置在APP裡，而是通過HTPP請求來拉取：
（1）APP第一次通路時，先拉取Web-server的ip-list儲存到APP本地；
畫外音：使用域名拉取ip-list，隻1次通路。
（2）未來通路時，用戶端直接使用ip-list中的IP來通路server，不再需要DNS；
畫外音：使用IP通路業務Web-server，所有業務請求。
跳過了Nginx，如何對Web-server怎麼做負載均衡呢？
APP随機通路ip-list中的IP。
跳過了Nginx，如何對Web-server做水準擴充呢？
直接在ip-list中增加IP即可。
新的問題又來了，在ip-list裡增加了IP，新的使用者能通路到新的IP，舊的APP已經将ip-list拉取到APP本地了，此時如何更新本地的ip-list呢？
版本号，是架構設計中，減少拉取流量的同時，又能保證資料随時更新的好辦法：
（1）ip-list增加一個版本号，每次拉取ip-list時，同時拿到版本号；
（2）如果版本号與本地ip-list版本号一緻，則直接使用本地ip-list；
畫外音：節省流量，不用每次拉取檔案。
（3）版本号變化時，重新拉取ip-list儲存到本地；
畫外音：保證資料能夠得到更新。
總結
無線時代，可使用“IP直通車”來加速APP通路：
- 不需要每次請求做DNS解析，節省時間，避免DNS劫持
- 不需要每次請求做Nginx轉發，節省時間
- 不需要每次拉取ip-list，節省流量
- 通過ip-list可以對Web-server做水準擴充
- 通過版本号可以保證ip-list的資料一緻性
思路比結論更重要。
本文轉自“架構師之路”公衆号，58沈劍提供。