高併發架構的CDN知識介紹

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

下面根據圖中的十個步驟說一下每一步都在幹嗎。

1. 一個用戶在瀏覽器輸入了：example.com，這時會產生一個 DNS 查詢，從而進入到 DNS Resolver中；
2. Resolver 會進入到 root server 進行查詢；
3. root server 返回了 TLD server 的地址，查詢請求轉向頂級域名服務，這裏是 .com 服務器。
4. 遞歸解析器向 .com 服務器發送一個請求；
5. TLD server 收到請求後會返回 example.com 權威服務器的地址；
6. 遞歸解析器又發了一個向權威服務器查詢的請求，至此權威服務器查詢本身的映射表拿到IP；
7. 返回查詢到的IP給了 DNS Resolver；
8. DNS Resolver返回IP給瀏覽器，瀏覽器將會用這個IP來創建鏈接，發起請求;
9. 客戶端經過這個IP地址，發起一個 HTTP 請求；
10. 服務器解析請求，並返回數據到瀏覽器。

這裏須要補充一點是，上面每一步其實都有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的呢？

接下來咱們須要回答兩個問題。

1. CDN帶來了什麼好處。
2. 如何解析到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