對一次網路請求過程的瞭解程度，一是展現你的專業知識；二是深刻的理解，讓你在大型網站架構中做出更適合、可靠的架構。而DNS是這一切的出發點，本文結合一張常用架構圖，來描述一下這個過程。
部署架構
大型的web服務，我們的部署架構一般如下圖。先上圖再解釋。
這裡來解釋下，為什麼要這樣架構。
首先客戶端的請求會通過 DNS 獲取到對應的伺服器IP（實際上是LB的ip地址），這一層會有 DNS的負載均衡，並且如果是靜態站資源會進入到CDN，這裡DNS與CDN如何完成接棒的過程，後面會詳細解釋。
當請求到達LB層的時候（應用層協議是HTTP協議），這一層又會做一次負載均衡（可能用LVS或者Nginx做）。這裡我們有兩種不同的處理方式，一條路徑會進入到代理叢集，一條路徑直接進入到應用叢集。這是為什麼？
LB到代理叢集
通過最頂層的LB負責均衡後到達代理機器，這裡不直接進入到應用叢集，還要搞一層代理的目的主要是方便我們在代理叢集進行各種高階（騷）操作。
比如：請求日誌收集，自定義快取，自定義的負載均衡，自定義的路由規則制定（跨機房，路由分組）
LB到應用叢集
上面到代理層有那麼多好處，為什麼還有繞過代理層這條路徑存在呢？這主要是針對大流量服務。因為代理層因為有很多額外的操作，導致響應會變長，路徑增加，到下一個叢集多了一次網路傳輸往返。
所以，一般針對大流量服務，為了防止代理被打滿，響應更快，會直接在外網LB上進行負載到應用叢集。
通過上面的分割後，最終都會到達應用叢集，每一臺機器上我們會部署一臺 Nginx 來按照域名轉到對應服務，當然這裡完全也可以不是 Nginx ，比如微服務，這裡可能是一個 SideCard 代理。這裡主要是為了便於說明我們後面全部都是當成Nginx。服務呼叫 DB Cache 等，都是通過域名，這是為了負載均衡，請求時，會通過內網DNS服務，完成域名解析，然後拿到內網的 LB 的IP。然後再這裡進行內網的負載均衡，會根據域名的埠來檢查你是寫操作、還是讀操作返回IP。常規一點會保證是單點寫入，多點讀取。來完成資料一致性的保障。
整個大體過程如此，接下來我們詳細說一下 DNS 與 CDN 相關的工作原理。
DNS如何實現IP查詢
為了後面說清楚CDN，這裡先介紹DNS的解析過程。當然此類文章網路上已經極多。但是我還是想按照我的理解來說一下DNS是如何工作的。
在整個DNS過程中有四個重要概念，下面解釋下。
DNS Resolver - 遞迴解析器，主要是接收客戶端發出的域名解析請求，併傳送 DNS query 查詢請求。對於客戶端來說它不需要任何操勞，等待 DNS Resolver 告訴自己域名轉IP的結果就好。
Root Server - 這是轉換IP執行的第一步查詢，根伺服器並不會儲存具體的域名IP對映資訊。它就像一個索引伺服器，會告訴你下一步該去那臺 TLD Server 查詢。
TLD Server - 這是頂級域名伺服器，是執行IP查詢的第二步，這裡會告訴 DNS Resolver 權威域名伺服器的地址。
Authoriative Server - 權威域名伺服器就是包含了完整的機器名的域名，例如：www.example.com ，在這臺機器上儲存了這個具體域名對應的IP地址。
下面根據圖中的十個步驟說一下每一步都在幹嘛。
- 一個使用者在瀏覽器輸入了：example.com，這時會產生一個 DNS 查詢，從而進入到 DNS Resolver中；
- Resolver 會進入到 root server 進行查詢；
- root server 返回了 TLD server 的地址，查詢請求轉向頂級域名服務，這裡是 .com 伺服器。
- 遞迴解析器向 .com 伺服器傳送一個請求；
- TLD server 收到請求後會返回 example.com 權威伺服器的地址；
- 遞迴解析器又發了一個向權威伺服器查詢的請求，至此權威伺服器查詢自己的對映表拿到IP；
- 返回查詢到的IP給了 DNS Resolver；
- DNS Resolver返回IP給瀏覽器，瀏覽器將會用這個IP來建立連線，發起請求;
- 客戶端通過這個IP地址，發起一個 HTTP 請求；
- 伺服器解析請求，並返回資料到瀏覽器。
這裡需要補充一點是，上面每一步其實都有DNS快取的設計。比如：
- 瀏覽器會快取DNS的結果，（chrome://net-internals/#dns）
- 作業系統的DNS模組會快取
- 後面的每一層級也都有快取
所以很多時候，我們的解析過程並不是要順序執行完這8個步驟。這就跟我們自己開發的應用服務一樣，層層快取，有快取就讀取快取結果，快取實現就執行完整流程。
DNS的解析分類
DNS有多種解析記錄可以設定，我這裡介紹三個很常用的設計。
A記錄 - 被稱為IP指向，使用者設定自域名指到對應的IP主機上。如果想要利用A記錄實現 負載均衡 需要主機商的支援。
CNAME記錄 - 它相當於為一個主機名設定一個別名，而且該記錄不能直接使用IP，只能是另一個主機的別名。CDN主要就是利用該記錄來完成的。如果有A記錄與CNAME記錄同時存在，A記錄會被優先使用，換句話說CNAME記錄不會生效。
NS記錄 - 用來設定一個域名的權威伺服器路徑，該記錄只會對子域名生效。這個地方可以設定IP也可以設定另外一個權威伺服器的域名。需要重點指出的是它的優先順序高於A記錄，並且它在DNS解析過程中，會跳過2，3，4，5步。
瞭解完了DNS的步驟，接下來就進入到CDN部分的分析。
CDN訪問加速度
什麼是CDN呢？中文翻譯過來就是內容分發網路。看張圖。
沒有CDN的時候，不管哪裡的使用者訪問我們的站點，都需要到我們資料中心來獲取資料(單純的DNS過程)。而有了CDN之後，使用者根據自己的地理位置會選擇距離自己最近的快取資料中心來獲取資料。不會每次都到源站（應用伺服器）來獲取資料。為了理解這個過程，我們是如果在完整的DNS過程中，實現CDN的呢？
接下來我們需要回答兩個問題。
- CDN帶來了什麼好處。
- 如何解析到CDN。
CDN帶來的好處
瞭解一個東西之前最好知道它能幹什麼，帶來的好處是什麼。然後我們再去看它的執行原理。對於CDN有以下幾個方面的好處。
提高頁面載入速度
這是最顯而易見的一個優勢，通過上面的圖，大家也可以直觀感受下，使用者訪問距離自己最近的機器，速度肯定是最快的。並且網站的載入速度越快那麼使用者體驗越優秀，你的網站更會受到對應使用者的喜愛。至於如何實現就近訪問的，後面原理部分介紹。
增加內容的冗餘
CDN是一個典型的分散式架構，它通過增加資料的冗餘，一方面保障在大流量面前有多臺伺服器能夠提供相同的資料；另一方面當部分機器出現故障時，可以進行自動轉移。
節省頻寬
如果大家自己買過雲服務就知道，頻寬每增加一點價格就飆升。使用CDN後，由於流量被分流了，那麼原機器頻寬要求自然就降低了。當然頻寬費用降低了，你還需要為CDN付費。
保障服務安全
CDN可防止的攻擊：DDOS攻擊，該攻擊就是通過巨大流量打滿你的頻寬，讓你喪失服務能力。那麼由於CDN的存在，它將巨大的流量進行了分流。那麼源站壓力自然小了。這其實也是高併發需要考慮的。
CDN目前不僅僅是隻能快取靜態的HTML、CSS、JS、VIDEO，現在還有能夠快取動態介面內容的CDN，這為我們在架構高併發的服務時，提供了更多的手段進行選擇。
CDN工作原理
在介紹DNS的時候，介紹了客戶端是如何獲取到IP地址的。那麼有了CDN之後，這個過程該怎麼處理呢？
CDN其實更像是放在應用伺服器與使用者之間的一層快取。所以如果DNS的時候，返回給客戶端的是CDN機器的IP而不是應用的IP，那麼自然就走到了CDN機器上。
為了實現上述目的，我們會為該域名配置一個 CNAME（大家注意上面提到的CNAME與A記錄的優先順序），那麼這個CNAME是最終如何解析到對應的CDN機器呢？其實流程與DNS解析是一樣的。當發現一個域名設定了CNAME時，DNS解析器會繼續解析這個CNAME別名（其實就是另一個域名）。對這個CNAME解析的時候會用到全域性負載DNS解析，它會根據訪問者的地理位置資訊返回對應的IP（CDN機器的IP）。因此客戶端實際上得到的是距離它最近的CDN機器的IP地址。
如果說使用者訪問CDN，但是CDN上沒有對應內容會怎麼辦？此時CDN機器其實會根據自身專用的DNS解析服務，根據域名得到源站的IP，然後向源站傳送請求獲取資料，並把這些資料快取到本地，方便後續使用；同時返回本次結果，完成本次請求的訪問。
需要說一下的是，CDN其實也是分層的。距離使用者最近的稱之為邊緣節點。而CDN的中心伺服器叢集被稱為二級快取。在上面就是應用部署的源站。一般邊緣節點沒資料就去找二級快取，二級快取沒資料就去找源站（被稱為回源）。
小結
關於 DNS 的過程，文中是以流程介紹為主，至於更細節的依賴協議、傳輸過程都忽略了。 關於CDN也是我們經常用到的效能提升手段，後續要寫的秒殺相關文章，就會用到它來提升效能。特別是CDN的分散式設計、解析過程在我們平常設計應用架構時非常有參考意義。
公眾號：dayuTalk
