本文中會提到部分廠商，不過均為舉例需要或客觀推薦的解決方案，并無任何利益關系

有用戶反應產品偶然會出現(xiàn)『未能找到使用指定主機的服務器』問題，應該是 DNS 沒有正確解析。從監(jiān)控記錄中并沒有發(fā)現(xiàn)什么問題，各地的監(jiān)測點的結果都很正常，那就應該是用戶所處網絡環(huán)境出了問題。

為了盡量提高產品可用性，進行了 HTTP DNS 的改造。

什么是 HTTP DNS

普通的網絡請求，系統(tǒng)自動通過 DNS Server 將目標域名解析成 IP 地址，然后向這個 IP 地址發(fā)送請求完成數(shù)據(jù)交互。這個解析的過程對于 APP 來說是不可見的。

HTTP DNS 則是 APP 主動向 HTTP DNS Server 發(fā)送解析請求，Server 返回目標域名對應的 IP 地址，然后 APP 直接向目標地址發(fā)送請求，繞開了系統(tǒng)解析的這個環(huán)節(jié)，避免了用戶所處環(huán)境帶來的干擾。

當然 HTTP DNS Server 也是通過 IP 地址直接訪問的，比如 DNSPod 免費版的 119.29.29.29，還有其他廠商可以自己尋找。

如何進行改造

根據(jù)改動范圍是否設計后端（包括運維）有兩種方法

A. 前后端配合版

這種改造方案非常簡單，后端 Web Server 將 IP 地址直接綁定到目標站點，APP 在發(fā)起請求前，直接將所有 URL 中自己域名的部分換為通過 HTTP DNS 獲得目標 IP 即可。

當然如果后端有針對域名的邏輯也需要處理下，比如防盜鏈用的 Referer 校驗等。

另外有的第三方庫（比如支付寶）需要 APP 傳入 Server 回調地址。這種是沒必要改的，畢竟請求來自 IDC 機房等網絡環(huán)境很好的場合。不過一定要改的話，這種地址可能在第三方平臺上有綁定審核，實際動手前請?zhí)崆皽蕚鋵徍恕?/p>

B. APP 單獨版

不同公司合作開發(fā)或者一臺 Server 托管了若干站點的情況，只能 APP 自己想辦法了。這種稍微麻煩點，針對不同用途的 URL 需要做不同的處理。

1. 普通請求，類似于 REFTful API，每次請求完成一個動作，比如獲得數(shù)據(jù)之類
   這種可以直接用 IP 替換域名，然后在 HTTP request header 中將 Host 指定為域名即可。

2. Webview 中加載 Web page
   如果只是加載用戶協(xié)議、關于我們這種單頁純文本的東西，和普通請求相同改法即可。不過很多網頁內都會有相對地址的超鏈接，Webview 內的超鏈接跳轉時無法指定 Host 字段，后端 Server 可能無法正確處理這種請求。另外 cookie 等和域有關對的東西也容易出問題，所以這種類型最好還是維持域名訪問的原狀。

3. 傳給第三方庫使用的回調地址
   同樣，這種本來就沒問題，強行改的話反而會出問題，所以不要更改。

4. 第三方地址，比如 Apple Store 的評分頁面，或者點擊廣告后跳轉的營銷頁
   這種可改可不改，視具體情況而定，總體建議維持原狀比較好。

一些有用的實踐經驗

• APP 啟動時異步 HTTP DNS 查詢 IP 地址
  畢竟大部分用戶網絡狀況都是正常的，沒必要影響所有人的啟動速度

• 查到后將 IP 地址緩存
  除了內存外最好也能持久化緩存，這樣下次啟動時即使萬一 HTTP DNS 查詢比較慢也能確保有可用的 IP。

• HTTP DNS 查詢后觸發(fā)進行一次系統(tǒng)的 DNS 解析
  仍有使用域名請求的場景（比如APP單獨改造時用到 Webview）下使用。
  如果域名不是被刻意劫持或干擾，一般無法找到主機的問題只是解析過慢，提前觸發(fā)查詢后，等用戶操作到相關邏輯時正常的概率就會更高。

• 發(fā)送請求前若有 IP 則使用 IP，否則使用域名
  這是當然的 XD

• 網絡狀況發(fā)生變化時，重新異步 HTTP DNS 查詢 IP 地址
  如果產品在不同線路部署有不同 Server 的話，重新查詢一遍可以確?？偸鞘褂米詈线m的那臺。

第三方庫

iOS/Android 都有現(xiàn)成的第三方庫可供使用，GitHub 上有新浪和七牛的項目

另外七牛項目的分別發(fā)布到了 CocoaPods 和 maven 上更易使用，所以推薦七牛。