Pre

我們使用的電商、直播、社交工具、視頻網站中都含有大量的圖片、視頻、檔案等，這些資源需要分發給用戶，

對于一些體量較大的應用來說，如果把大量資源集中到單一節點進行分發，恐怕很難有某個機房可以支撐得住這么大的流量，

例如一個榷訓在 100W 的小型互聯網產品，如果每次請求需要 1M 的資料，那就剛好是近 1TB 資料，對于這樣的資料規模而言，完全由單一節點進行分發是不現實的，

因此現在互聯網應用在分發內容的時候，并不是從自己架設的服務器上直分發內容，而是走一個叫作內容分發網路（Content Dilivery Network）的互聯網底層建設，

我們就以“CDN 回源是如何作業的”為引， 一起探索 CDN 的原理和場景，

CDN 是什么?

和域名系統類似，內容分發網路（Content Dilivery Network，CDN）是一個專門用來分發內容的分布式應用，

CDN 構建在現有的互聯網之上，通過在各地部署資料中心，讓不同地域的用戶可以就近獲取內容，

這里的內容通常指的是檔案、圖片、視頻、聲音、應用程式安裝包等，它們具有一個顯著的特征——無狀態，或者說是靜態的，這些資源不像訂單資料、庫存資料等，它們一旦發布，就很少會發生變化，另一個顯著的特征，是這些資源往往會被大量的用戶需要，因此分發它們的流量成本是較高的，

為什么不能集中提供這些靜態資源呢？這和域名系統的 DNS 記錄不能集中提供是一個道理，需要考慮到流量、單點故障、延遲等因素，在離用戶更近的地理位置提供資源，可以減少延遲，按照地理位置分散地提供資源，也可以降低中心化帶來的服務壓力，

因此，CDN 的服務商會選擇在全球布點，或者在某個國家布點，具體要看 CDN 服務提供商的服務范圍，目前國內的阿里云、騰訊云等也在提供 CDN 業務，

內容的分發

CDN 是一個分布式的內容分發網路，當用戶請求一個網路資源時，用戶請求的是 CDN 提供的資源，和域名系統類似，當用戶請求一個資源時，首先會接觸到一個類似域名系統中目錄的服務，這個服務會告訴用戶究竟去哪個 IP 獲取這個資源，

事實上，很多大型的應用，會把 DNS 決議作為一種負載均衡的手段，當用戶請求一個網址的時候，會從該網站提供的智能 DNS 中獲取網站的 IP，

例如當你請求百度的時候，具體連接到哪個百度的 IP，是由百度使用的智能 DNS 服務決定的，域名系統允許網站自己為自己的產品提供 DNS 決議

所以總體靜態資源的使用路徑如下圖所示

當用戶請求一個靜態資源的時候，首先會觸發域名系統的決議，域名系統會將決議的責任交由 CDN 提供商來處理，CDN 的智能 DNS 服務會幫助用戶選擇離自己距離最近的節點，回傳這個節點的 A（或 AAAA）記錄，然后客戶端會向 CDN 的資源節點發起請求，最侄訓得資源，

在上面整個程序當中，CDN 的智能 DNS 還充當了負載均衡的作用，如果一個節點壓力過大，則可以將流量導向其他的節點，

回源

目前我們已經討論了 CDN 的主要設計和架構，但是還有一個問題沒有解決——就是資源怎么進入內容分發網路，資源的生產者，也是 CDN 的購買者，目的是向用戶提供網路服務，那么服務提供者的靜態資源如何進入 CDN 呢？ 手動上傳、用介面推送，還是通過其他別的方式呢？

你可以把 CDN 想象成一個分布式的分級快取，再加上資料庫的兩層設計，如下圖所示：

用戶的請求先到達快取層，如果快取被穿透，才到達最終的存盤層，快取的設計必須是分布式的，因為絕大多數的資源使用都會發生在快取上，只有極少數的請求才會穿透到底層的存盤，通常這種設計，我們期望快取層至少需要幫擋住 99% 的流量，既然快取層能擋住 99% 的流量，那么實際的資料存盤就可以交由源站點完成，

值得一提的是，在程式設計當中有一個核心的原則，叫作單一資料源（Single Souce of Truth， SSOT），這個原則指的是，在程式設計中，應該盡可能地減少資料的來源，最好每個資料來源只有單獨一份，這樣能夠避免大量的資料不一致以及同步資料的問題，基于這樣的設計，誰來提供資源的存盤呢？誰來提供這個單一的資料源呢？當然是服務提供者本身，如果 CDN 再提供 一份資源的存盤，不就有兩個資料源了嗎？而且，只有服務的提供者才能更好地維護這個資源倉庫，

在 CDN 的設計當中，CDN 實際上提供的是資料的快取，而原始資料，則由服務的提供者提供，

用戶請求靜態資源通常用自己的域名（防止跨域和一些安全問題），為了讓用戶請求的是自己的網站，而使用的是 CDN 的服務，這里會使用 CNAME 讓自己的域名作為 CDN 域名的一個別名，當請求到 CDN 服務的時候，會首先由 CDN 的 DNS 服務幫助用戶選擇一個最優的節點，這個 DNS 服務還充當了負載均衡的作用，接下來，用戶開始向 CDN 節點請求資源，如果這個時候資源已經過期或者還沒有在 CDN 節點上，就會從源站讀取資料，這個步驟稱為CDN 的回源，

另一方面，CDN 上快取的資源通常也會伴隨失效時間的設定，當失效之后同樣會觸發回源，另一種情況是可以通過開放的 API 或者 CDN 管理后臺直接洗掉快取（讓資源失效），這個操作結束后，同樣會觸發回源，

小結

總結一下，CDN 是一種網路應用，作用是分發互聯網上的資源，CDN 服務的提供商，會在世界（或國家）范圍內設立資料中心，幫助分發資源，用戶請求的資源會被 CDN 分發到最臨近的節點獲取，

CDN 作為一門生意，CDN 的服務商會大批量的從運營商處獲取流量，然后再以較高但是可以接受的價格賣給服務提供方，

對于中小型互聯網公司來說，購買一定的 CDN 流量成本可控，比如 1G 流量在 1 元以內，對于大型的互聯網公司，特別是對 CDN 依賴嚴重的公司，可能還需要自己建設，比如 2021 年抖音每天分發的資料量在 50PB 左右（1PB=1024TB），如此龐大的資料量如果換算成錢是非常高的，按照阿里云的報價，50PB 的價格是 480W 人民幣，按照這種體量計算，抖音每天要花 480W 人民幣，一年是 17 億，

所以當你設計一個內容分發的方案時，除了要考慮到其中的技術細節，也要從成本上進行思考，看看能不能從資料壓縮、資源格式角度做一些文章，

QA

請簡述 CDN 回源是如何作業的？

【決議】CDN 回源就是 CDN 節點到源站請求資源，重新設定快取，通常服務提供方在使用 CDN 的時候，會在自己的某個域名發布靜態資源，然后將這個域名交給 CDN，

比如源站在 s.example.com 中發布靜態資源，然后在 CDN 管理后臺配置了這個源站，在使用 CDN 時，服務提供方會使用另一個域名，比如說 b.example.com，然后配置將 b.example.com 用 CNAME 記錄指向 CDN 的智能 DNS，

這個時候，如果用戶下載b.example.com/a.jpg，CDN 的智能 DNS 會幫用戶選擇一個最優的 IP 地址（最優的 CDN 節點）回應這次資源的請求，如果這個 CDN 節點沒有 a.jpg，CDN 就會到 s.example.com 源站去下載，快取到 CDN 節點，然后再回傳給用戶，

CDN 回源有 3 種情況，

• 一種是 CDN 節點沒有對應資源時主動到源站獲取資源；
• 另一種是快取失效后，CDN 節點到源站獲取資源；
• 還有一種情況是在 CDN 管理后臺或者使用開放介面主動重繪觸發回源，

如果你的應用需要智能 DNS 服務，你將如何實作？

【決議】首先你可以在你的域名決議系統中增加兩條（或以上）ns 記錄，比如說你的域名是 example.com，那么你可以增加 ns1.exmaple.com, ns2.example.com，當然，指定這兩個域名的 IP 還需要配置兩個 A 記錄，

然后你需要兩臺機器（也可以是容器或者虛擬機），對應 ns1 和 ns2，最好用不在同一個物理機上的兩個容器，這樣可以避免一臺物理機故障導致服務癱瘓，然后在每個容器（虛擬機）上安裝一個 Named 服務，

Named 是一個專門用來提供 DNS 服務的工具，在虛擬機上安裝完成 Named 后，這個虛擬機就變成了一個權威服務器節點，

配置好 Named 后，你需要寫幾個腳本檔案，給要提供 DNS 的域名配置資訊，Named 配套使用的有個叫作 GeoDNS 的插件，可以提供基于地理位置的智能 DNS 服務，

更具體的操作，可以參考這篇檔案：https://bind9.readthedocs.io/en/latest/configuration.html，