對一次網絡請求過程的瞭解程度，一是展現你的專業知識；二是深刻的理解，讓你在大型網站架構中做出更適合、可靠的架構。而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