CDN:靜態資源如何加速？

• 靜態資源加速的考慮點
• CDN 的關鍵技術
• 總結

現在，我們應該對包括本地 緩存、分布式緩存等緩存組件的適用場景和使用技巧有了一定了解了。結合我們前面學過的客戶端高可用方案，我們會將單個緩存節點擴展為高可用的緩存集群，現在，我們的系統架構演變成了下面這樣：

在這個架構中我們使用分布式緩存對動態請求數據的讀取做了加速，但是在我們的系統中存在著大量的靜態資源請求：

• 對于移動 APP 來說，這些靜態資源主要是圖片、視頻和流媒體信息。
• 對于 Web 網站來說，則包括了 JavaScript 文件，CSS 文件，靜態 HTML 文件等等。

具體到電商系統來說，商品的圖片，介紹商品使用方法的視頻等等靜態資源，現在都放在了 Nginx 等 Web 服務器上，它們的讀請求量極大，并且對訪問速度的要求很高，并且占據了很高的帶寬，這時會出現訪問速度慢，帶寬被占滿影響動態請求的問題，那么我們就需要考慮如何針對這些靜態資源進行讀加速了。

靜態資源加速的考慮點

我可能會有疑問：“是否也可以使用分布式緩存來解決這個問題呢？”答案是否定的。一般來說，圖片和視頻的大小會在幾兆到幾百兆之間不等，如果我們的應用服務器和分布式緩存都部署在北京的機房里，這時一個杭州的用戶要訪問緩存中的一個視頻，那這個視頻文件就需要從北京傳輸到杭州，期間會經過多個公網骨干網絡，延遲很高，會讓用戶感覺視頻打開很慢，嚴重影響到用戶的使用體驗。

所以，靜態資源訪問的關鍵點是就近訪問，即北京用戶訪問北京的數據，杭州用戶訪問杭州 的數據，這樣才可以達到性能的最優。

當然我們不可能在各個地方都部署服務器，這樣成本太高了，而且當靜態資源發生變化，需要更新所有的靜態資源服務器，這顯然是不現實的。而且，單個視頻和圖片等靜態資源很大，并且訪問量又極高，如果使用業務服務器和分布式緩存來承擔這些流量，無論是對于內網還是外網的帶寬都會是很大的考驗。

所以我們考慮在業務服務器的上層，增加一層特殊的緩存，用來承擔絕大部分對于靜態資源 的訪問，這一層特殊緩存的節點需要遍布在全國各地，這樣可以讓用戶選擇最近的節點訪問。緩存的命中率也需要一定的保證，盡量減少訪問資源存儲源站的請求數量(回源請 求)。這一層緩存就是我們這節課的重點：CDN。

CDN 的關鍵技術

CDN(Content Delivery Network/Content Distribution Network，內容分發網絡)。 簡單來說，CDN 就是將靜態的資源分發到，位于多個地理位置機房中的服務器上，因此它 能很好地解決數據就近訪問的問題，也就加快了靜態資源的訪問速度。

在大中型公司里面，CDN 的應用非常的普遍，大公司為了提供更穩定的 CDN 服務會選擇 自建 CDN，而大部分公司基于成本的考慮還是會選擇專業的 CDN 廠商，網宿、阿里云、 騰訊云、藍汛等等，其中網宿和藍汛是老牌的 CDN 廠商，阿里云和騰訊云是云廠商提供的 服務，如果服務部署在云上可以選擇相應云廠商的 CDN 服務，這些 CDN 廠商都是現今行業內比較主流的。

對于 CDN 來說，我們可能已經從運維的口中聽說過，并且也了解了它的作用。但是當讓我們來配置 CDN 或者是排查 CDN 方面的問題時，就有可能因為不了解它的原理而束手無策 了。

所以，我們來了解一下，要搭建一個 CDN 系統需要考慮哪兩點：

• 如何將用戶的請求映射到 CDN 節點上；
• 如何根據用戶的地理位置信息選擇到比較近的節點；

下面我們就具體了解一下 CDN 系統是如何實現加速用戶對于靜態資源的請求的。

如何讓用戶的請求到達 CDN 節點
首先，我們考慮一下如何讓用戶的請求到達 CDN 節點，你可能會覺得，這很簡單啊，只需要告訴用戶 CDN 節點的 IP 地址，然后請求這個 IP 地址上面部署的 CDN 服務就可以了 啊。但是這樣會有一個問題:就是我們使用的是第三方廠商的 CDN 服務，CDN 廠商會給 我們一個 CDN 的節點 IP，比如說這個 IP 地址是“111.202.34.130”，那么我們的電商系 統中的圖片的地址很可能是這樣的:“http://111.202.34.130/1.jpg”, 這個地址是要存儲在數據庫中的。

那么如果這個節點 IP 發生了變更怎么辦?或者我們如果更改了 CDN 廠商怎么辦？是不是 要修改所有的商品的 url 域名呢?這就是一個比較大的工作量了。所以，我們要做的事情是 將第三方廠商提供的 IP 隱藏起來，給到用戶的最好是一個本公司域名的子域名。

那么如何做到這一點呢？這就需要依靠 DNS 來幫我們解決域名映射的問題了。

DNS(Domain Name System，域名系統)實際上就是一個存儲域名和 IP 地址對應關系 的分布式數據庫。而域名解析的結果一般有兩種，一種叫做“A 記錄”，返回的是域名對應 的 IP 地址;另一種是“CNAME 記錄”，返回的是另一個域名，也就是說當前域名的解析 要跳轉到另一個域名的解析上，實際上 www.baidu.com 域名的解析結果就是一個 CNAME 記錄，域名的解析被跳轉到 www.a.shifen.com 上了，我們正是利用 CNAME 記 錄來解決域名映射問題的，具體是怎么解決的呢？我們舉個例子。

比如我們公司的一級域名叫做 example.com，那么你可以給你的圖片服務的域名定義 為“img.example.com”，然后將這個域名的解析結果的 CNAME 配置到 CDN 提供的域 名上，比如 uclound 可能會提供一個域名是“80f21f91.cdn.ucloud.com.cn”這個域名。 這樣你的電商系統使用的圖片地址可以是“http://img.example.com/1.jpg”。

用戶在請求這個地址時，DNS 服務器會將域名解析到 80f21f91.cdn.ucloud.com.cn 域名 上，然后再將這個域名解析為 CDN 的節點 IP，這樣就可以得到 CDN 上面的資源數據了。

不過，這里面有一個問題：因為域名解析過程是分級的，每一級有專門的域名服務器承擔解 析的職責，所以，域名的解析過程有可能需要跨越公網做多次 DNS 查詢，在性能上是比較差的。

從“ 域名分級解析示意圖”中你可以看出 DNS 分為很多種，有根 DNS，頂級 DNS 等等。除此之外還有兩種 DNS 需要特別留意:一種是 Local DNS，它是由你的運營商提供的 DNS，一般域名解析的第一站會到這里;另一種是權威 DNS，它的含義是自身數據庫中存 儲了這個域名對應關系的 DNS。

如何找到離用戶最近的 CDN 節點

GSLB（Global Server Load Balance，全局負載均衡），它的含義是對于部署在不同地域的服務器之間做負載均衡，下面可能管理了很多的本地負載均衡組件。它有兩方面的作用：

一方面，它是一種負載均衡服務器，負載均衡，顧名思義嘛，指的是讓流量平均分配使得下面管理的服務器的負載更平均；

另一方面，它還需要保證流量流經的服務器與流量源頭在地緣上是比較接近的。

GSLB 可以通過多種策略，來保證返回的 CDN 節點和用戶盡量保證在同一地緣區域，比如說可以將用戶的 IP 地址按照地理位置劃分為若干的區域，然后將 CDN 節點對應到一個區 域上，然后根據用戶所在區域來返回合適的節點；也可以通過發送數據包測量 RTT 的方式來決定返回哪一個節點。

有了 GSLB 之后，節點的解析過程變成了下圖中的樣子：

當然，是否能夠從 CDN 節點上獲取到資源還取決于 CDN 的同步延時。一般，我們會通過 CDN 廠商的接口將靜態的資源寫入到某一個 CDN 節點上，再由 CDN 內部的同步機制將 資源分散同步到每個 CDN 節點，即使 CDN 內部網絡經過了優化，這個同步的過程是有延時的，一旦我們無法從選定的 CDN 節點上獲取到數據，我們就不得不從源站獲取數據，而 用戶網絡到源站的網絡可能會跨越多個主干網，這樣不僅性能上有損耗，也會消耗源站的帶寬，帶來更高的研發成本。所以，我們在使用 CDN 的時候需要關注 CDN 的命中率和源站 的帶寬情況。

總結

我們了解了 CDN 對靜態資源進行加速的原理和使用的核心技術，這里你需 要了解的重點有以下幾點：

• DNS 技術是 CDN 實現中使用的核心技術，可以將用戶的請求映射到 CDN 節點上；
• DNS 解析結果需要做本地緩存，降低 DNS 解析過程的響應時間；
• GSLB 可以給用戶返回一個離著他更近的節點，加快靜態資源的訪問速度。

作為一個服務端開發人員，我們可能會忽略 CDN 的重要性，對于偶爾出現的 CDN 問題嗤之以鼻，覺得這個不是我們應該關心的內容，這種想法是錯的。

CDN 是我們系統的門面，其緩存的靜態數據，如圖片和視頻數據的請求量很可能是接口請 求數據的幾倍甚至更高，一旦發生故障，對于整體系統的影響是巨大的。另外 CDN 的帶寬 歷來是我們研發成本的大頭，尤其是目前處于小視頻和直播風口上，大量的小視頻和直播研發團隊都在絞盡腦汁地減少 CDN 的成本。由此看出，CDN 是我們整體系統至關重要的組 成部分，而它作為一種特殊的緩存，其命中率和可用性也是我們服務端開發人員需要重點關注的指標。

總結

以上是生活随笔為你收集整理的CDN:静态资源如何加速？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。