DNS與HTTPDNS

DNS服務器

• 根DNS服務器：返回頂級域DNS服務器的IP地址

• 頂級域DNS服務器：返回權威DNS服務器的IP地址

• 權威DNS服務器：返回相應主機的IP地址

  流程圖：

#### 負載均衡

• 內部負載均衡：能夠配置域名，每次返回不一樣的ip
• 全局負載均衡：高可用，若是某個服務器掛了，在DNS裏直接刪除對應ip，埃博徵訪問。

#### 示例：DNS訪問數據中心中對象存儲上的靜態資源。

假設全國有多個數據中心，託管在多個運營商，每一個數據中心三個可用區。對象存儲經過跨可用區部署，實現高可用性。在每一個數據中心中，都至少部署兩個內部負載均衡器，內部負載均衡器後面對接多個對象存儲的前置服務器。

1. 當一個客戶端要訪問object.yourcompany.com時，須要將域名轉爲ip，因此請求本地DNS解析器。
2. 本地DNS解析器查看是否有本地緩存這個記錄，若是有則直接使用
3. 若是沒有，請求本地的DNS服務器。
4. 本地的DNS服務器通常部署在你的數據中心或所在運營商的網絡中，本地DNS服務器須要查看本地是否有緩存，若是有則返回。
5. 若無，本地DNS須要遞歸的從根DNS服務器，查到頂級域名服務器，最終查到權威DNS服務器，返回給本地DNS服務器。

對於不須要作全局負載均衡的簡單應用來說，權威DNS服務器能夠直接將object.yourcompany.com域名解析爲一個或多個ip地址，服務端能夠經過多個ip地址，進行簡單的輪詢，實現簡單的負載均衡。

• 全局負載均衡器（GSLB, Global Server Load Balance），在DNS服務器中，通常經過配置cname的方式，給object.yourcompany.com起一個別名，而後告訴本地DNS服務器，讓他請求GSLB解析這個域名，在解析這個過程當中，經過本身的策略實現負載均衡。

• GSLB能夠分運營商和地域，第一層GSLB，經過查看請求他的本地DNS服務器所在的運營商，就知道用戶的運營商，經過起別名，告訴本地DNS服務器去請求第二層的GSLB。

  第二層GSLB查看請求他的本地DNS服務器的地址，知道了用戶的地理位置，將距離用戶位置比較近的region裏，六個內部負載均衡的地址，返回給DNS服務器。

  本地DNS服務器將結果返回給本地DNS解析器，而後解析器返回給客戶端

  客戶端獲得了6個ip地址，能夠經過負載均衡的方式，隨機或者輪詢選擇一個可用區進行訪問。

DNS存在的問題

1. 域名緩存問題

   本地作一個緩存，直接返回緩存數據。可能會致使全局負載均衡失敗，由於上次進行的緩存，不必定是此次離客戶最近的地方，可能會繞遠路。

2. 域名轉發問題

   若是是A運營商將解析的請求轉發給B運營商，B去權威DNS服務器查詢的話，權威服務器會認爲你是B運營商的，就返回了B運營商的網站地址，結果每次都會誇運營商。

3. 出口NAT問題

   作了網絡地址轉化後，權威的DNS服務器，無法經過地址來判斷客戶究竟是哪一個運營商，極有可能誤判運營商，致使跨運營商訪問。

4. 域名更新問題

   本地DNS服務器是由不一樣地區，不一樣運營商獨立部署的，對域名解析緩存的處理上，有區別，有的會偷懶忽略解析結果TTL的時間限制，致使服務器沒有更新新的ip而是指向舊的ip。

5. 解析延遲

   DNS的查詢過程須要遞歸遍歷多個DNS服務器，才能得到最終結果。可能會帶來必定的延時。

HTTPDNS工做模式

定義：不走傳統的DNS解析，而是本身搭建基於HTTP協議的DNS服務器集羣，分佈在多個地點和多個運營商，當客戶端須要DNS解析的時候，直接經過HTTP協議進行請求這個服務器集羣，得到就近的地址。

1. 在客戶端的SDK裏動態請求服務端，獲取HTTPDNS服務器的ip列表，緩存到本地。SDK也會在本地緩存DNS域名解析的結果。這個緩存和本地DNS的緩存不同，不是整個運營商統一作的，而是手機應用來作的，如何更新，什麼時候更新。

2. 若是本地無，就須要請求HTTPDNS的服務器，在本地的ip列表中，選擇一個發出HTTP請求，返回一個要訪問的網站的ip列表。手機客戶端知道手機坐在的運營商，能夠精確作到全局負載均衡。

• HTTPDNS的緩存設計

  解析的過程不須要本地DNS服務遞歸調用一大圈，一個HTTP請求直接搞定，本地也有緩存，過時時間，更新時間均可以本身控制。

  緩存設計模式三層：客戶端，緩存，數據源

  • 對於應用架構，就是應用，緩存，數據庫。tomcat，redis，mysql
  • 對於HTTPDNS來講，就是手機客戶端，dns緩存，httpdns服務器

  例如dns緩存在內存中，也能夠持久化到存儲上，app重啓後，就能夠儘快的從存儲中加載上次積累的解析結果。

  sdk中的緩存會嚴格按照緩存過時時間，若是沒有命中，或已通過期，則不容許使用過時記錄，會發起一次解析，保障記錄是新的。

  解析能夠是同步或異步的。

  同步更新的優勢是實時性好，缺點是若是有多個請求都發現過時的時候，會同時請求HTTPDNS，浪費資源。對應到應用架構中緩存的Cache-Aside機制，先讀緩存，不命中讀數據庫，同時寫入到緩存。

  異步的優勢是多個請求都過時的狀況能夠合併爲一個，同時能夠在即將過時的時候，建立一個任務進行預加載，防止過時以後再刷新成爲預加載。缺點是當請求拿到過時數據，若是能夠請求就沒問題，若是不能請求，則失敗，等下次緩存更新後，再請求方能成功。

  對應於應用架構中緩存的Refresh-Ahead機制，即業務僅僅訪問緩存，當過時就按期刷新。

• HTTPDNS調度設計

  客戶端嵌入了SDK，在客戶端HTTPDNS服務端能夠根據手機的國家，省市地點，運營商，選擇最佳的服務節點。

小結：

• 傳統的DNS有解析慢，更新不及時，轉發跨運營商，nat跨運營商等問題，影響了流量的調度。
• HTTPDNS經過客戶端sdk和服務端，直接解析dns，繞過了傳統dns缺點，實現智能調度。