前面幾節(jié)課旗闽，我?guī)懔私饬司彺娴亩x以及常用緩存的使用姿勢，你應(yīng)該對包括本地緩存蜜另、分布式緩存等緩存組件的適用場景和使用技巧有了一定了解了适室。結(jié)合在14 講中我提到的客戶端高可用方案，你會將單個緩存節(jié)點擴(kuò)展為高可用的緩存集群举瑰，現(xiàn)在捣辆，你的電商系統(tǒng)架構(gòu)演變成了下面這樣：
在這個架構(gòu)中我們使用分布式緩存對動態(tài)請求數(shù)據(jù)的讀取做了加速，但是在我們的系統(tǒng)中存在著大量的靜態(tài)資源請求：
1此迅、對于移動 APP 來說汽畴，這些靜態(tài)資源主要是圖片、視頻和流媒體信息耸序；對于 Web 2忍些、網(wǎng)站來說，則包括了 JavaScript 文件坎怪、CSS 文件罢坝、靜態(tài) HTML 文件等等。
具體到你的電商系統(tǒng)來說搅窿，商品的圖片嘁酿、介紹商品使用方法的視頻等等靜態(tài)資源都放在了 Nginx 等 Web 服務(wù)器上隙券，它們的讀請求量極大并且對訪問速度的要求很高還占據(jù)了很高的帶寬，這時會出現(xiàn)訪問速度慢帶寬被占滿影響動態(tài)請求的問題闹司，那么你就需要考慮如何針對這些靜態(tài)資源進(jìn)行讀加速了娱仔。
靜態(tài)資源加速的考慮點
你可能會問：“我們是否也可以使用分布式緩存來解決這個問題呢？”答案是否定的游桩。一般來說牲迫，圖片和視頻的大小會在幾兆到幾百兆之間不等，如果我們的應(yīng)用服務(wù)器和分布式緩存都部署在北京的機(jī)房里借卧，這時一個杭州的用戶要訪問緩存中的一個視頻盹憎，那這個視頻文件就需要從北京傳輸?shù)胶贾荩陂g會經(jīng)過多個公網(wǎng)骨干網(wǎng)絡(luò)谓娃，延遲很高，會讓用戶感覺視頻打開很慢蜒滩，嚴(yán)重影響到用戶的使用體驗滨达。
所以，靜態(tài)資源訪問的關(guān)鍵點是就近訪問俯艰，即北京用戶訪問北京的數(shù)據(jù)捡遍，杭州用戶訪問杭州的數(shù)據(jù)，這樣才可以達(dá)到性能的最優(yōu)竹握。
你可能會說：“那我們在杭州也自建一個機(jī)房画株，讓用戶訪問杭州機(jī)房的數(shù)據(jù)就好了呀±卜”可用戶遍布在全國各地谓传，有些應(yīng)用可能還有國外的用戶，我們不可能在每個地域都自建機(jī)房芹关，這樣成本太高了续挟。
另外，單個視頻和圖片等靜態(tài)資源很大侥衬，并且訪問量又極高诗祸，如果使用業(yè)務(wù)服務(wù)器和分布式緩存來承擔(dān)這些流量，無論是對于內(nèi)網(wǎng)還是外網(wǎng)的帶寬都會是很大的考驗轴总。
所以我們考慮在業(yè)務(wù)服務(wù)器的上層增加一層特殊的緩存直颅，用來承擔(dān)絕大部分對于靜態(tài)資源的訪問，這一層特殊緩存的節(jié)點需要遍布在全國各地怀樟，這樣可以讓用戶選擇最近的節(jié)點訪問功偿。緩存的命中率也需要一定的保證，盡量減少訪問資源存儲源站的請求數(shù)量（回源請求）往堡。這一層緩存就是我們這節(jié)課的重點：CDN脖含。
CDN 的關(guān)鍵技術(shù)
CDN（Content Delivery Network/Content Distribution Network罪塔，內(nèi)容分發(fā)網(wǎng)絡(luò)）。簡單來說养葵，CDN 就是將靜態(tài)的資源分發(fā)到位于多個地理位置機(jī)房中的服務(wù)器上征堪，因此它能很好地解決數(shù)據(jù)就近訪問的問題，也就加快了靜態(tài)資源的訪問速度关拒。
在大中型公司里面佃蚜，CDN 的應(yīng)用非常普遍，大公司為了提供更穩(wěn)定的 CDN 服務(wù)會選擇自建 CDN着绊，而大部分公司基于成本的考慮還是會選擇專業(yè)的 CDN 廠商谐算，網(wǎng)宿、阿里云归露、騰訊云洲脂、藍(lán)汛等等，其中網(wǎng)宿和藍(lán)汛是老牌的 CDN 廠商剧包，阿里云和騰訊云是云廠商提供的服務(wù)恐锦，如果你的服務(wù)部署在云上可以選擇相應(yīng)云廠商的 CDN 服務(wù)，這些 CDN 廠商都是現(xiàn)今行業(yè)內(nèi)比較主流的疆液。
對于 CDN 來說一铅，你可能已經(jīng)從運(yùn)維的口中聽說過，并且也了解了它的作用堕油。但是當(dāng)讓你來配置 CDN 或者是排查 CDN 方面的問題時潘飘，你就有可能因為不了解它的原理而束手無策了。
所以我先來帶你了解一下搭建一個 CDN 系統(tǒng)需要考慮哪兩點：
- 如何將用戶的請求映射到 CDN 節(jié)點上掉缺；
- 如何根據(jù)用戶的地理位置信息選擇到比較近的節(jié)點卜录。
如何讓用戶的請求到達(dá) CDN 節(jié)點
首先，我們考慮一下如何讓用戶的請求到達(dá) CDN 節(jié)點眶明，你可能會覺得這很簡單啊暴凑，只需要告訴用戶 CDN 節(jié)點的 IP 地址，然后請求這個 IP 地址上面部署的 CDN 服務(wù)就可以了啊赘来。但是這樣會有一個問題：就是我們使用的是第三方廠商的 CDN 服務(wù)现喳，CDN 廠商會給我們一個 CDN 的節(jié)點 IP，比如說這個 IP 地址是“111.202.34.130”犬辰，那么我們的電商系統(tǒng)中的圖片的地址很可能是這樣的：“http://111.202.34.130/1.jpg”, 這個地址是要存儲在數(shù)據(jù)庫中的嗦篱。
那么如果這個節(jié)點 IP 發(fā)生了變更怎么辦？或者我們?nèi)绻牧?CDN 廠商怎么辦幌缝？是不是要修改所有的商品的 url 域名呢灸促？這就是一個比較大的工作量了。所以，我們要做的事情是將第三方廠商提供的 IP 隱藏起來浴栽，給到用戶的最好是一個本公司域名的子域名荒叼。
那么如何做到這一點呢？這就需要依靠 DNS 來幫我們解決域名映射的問題了典鸡。
DNS（Domain Name System被廓，域名系統(tǒng)）實際上就是一個存儲域名和 IP 地址對應(yīng)關(guān)系的分布式數(shù)據(jù)庫。而域名解析的結(jié)果一般有兩種萝玷，一種叫做“A 記錄”嫁乘，返回的是域名對應(yīng)的 IP 地址；另一種是“CNAME 記錄”球碉，返回的是另一個域名蜓斧，也就是說當(dāng)前域名的解析要跳轉(zhuǎn)到另一個域名的解析上。實際上 www.baidu.com 域名的解析結(jié)果就是一個 CNAME 記錄睁冬，域名的解析被跳轉(zhuǎn)到 www.a.shifen.com 上了挎春，我們正是利用 CNAME 記錄來解決域名映射問題的，具體是怎么解決的呢豆拨？我給你舉個例子直奋。
比如你的公司的一級域名叫做 example.com，那么你可以把你的圖片服務(wù)的域名定義為“img.example.com”辽装，然后將這個域名的解析結(jié)果的 CNAME 配置到 CDN 提供的域名上帮碰，比如 uclound 可能會提供一個域名是“80f21f91.cdn.ucloud.com.cn”這個域名相味。這樣你的電商系統(tǒng)使用的圖片地址可以是“http://img.example.com/1.jpg”拾积。
用戶在請求這個地址時，DNS 服務(wù)器會將域名解析到 80f21f91.cdn.ucloud.com.cn 域名上丰涉，然后再將這個域名解析為 CDN 的節(jié)點 IP拓巧，這樣就可以得到 CDN 上面的資源數(shù)據(jù)了。
不過這里面有一個問題：因為域名解析過程是分級的一死，每一級有專門的域名服務(wù)器承擔(dān)解析的職責(zé)肛度，所以域名的解析過程有可能需要跨越公網(wǎng)做多次 DNS 查詢，在性能上是比較差的投慈。
從“ 域名分級解析示意圖”中你可以看出 DNS 分為很多種承耿，有根 DNS，頂級 DNS 等等伪煤。除此之外還有兩種 DNS 需要特別留意：一種是 Local DNS加袋，它是由你的運(yùn)營商提供的 DNS，一般域名解析的第一站會到這里抱既；另一種是權(quán)威 DNS职烧，它的含義是自身數(shù)據(jù)庫中存儲了這個域名對應(yīng)關(guān)系的 DNS。
下面我以 www.baidu.com 這個域名為例給你簡單介紹一下域名解析的過程：
- 一開始，域名解析請求先會檢查本機(jī)的 hosts 文件蚀之，查看是否有 www.baidu.com 對應(yīng)的 IP蝗敢；
- 如果沒有的話，就請求 Local DNS 是否有域名解析結(jié)果的緩存足删，如果有就返回標(biāo)識是從非權(quán)威 DNS 返回的結(jié)果寿谴；
- 如果沒有就開始 DNS 的迭代查詢。先請求根 DNS壹堰，根 DNS 返回頂級 DNS（.com）的地址拭卿；再請求.com 頂級 DNS 得到 baidu.com 的域名服務(wù)器地址；再從 baidu.com 的域名服務(wù)器中查詢到 www.baidu.com 對應(yīng)的 IP 地址贱纠，返回這個 IP 地址的同時標(biāo)記這個結(jié)果是來自于權(quán)威 DNS 的結(jié)果峻厚，同時寫入 Local DNS 的解析結(jié)果緩存，這樣下一次的解析同一個域名就不需要做 DNS 的迭代查詢了谆焊。
- 經(jīng)過了向多個 DNS 服務(wù)器做查詢之后惠桃，整個 DNS 的解析的時間有可能會到秒級別，那么我們?nèi)绾蝸斫鉀Q這個性能問題呢辖试？
一個解決的思路是：在 APP 啟動時對需要解析的域名做預(yù)先解析辜王，然后把解析的結(jié)果緩存到本地的一個 LRU 緩存里面。這樣當(dāng)我們要使用這個域名的時候罐孝，只需要從緩存中直接拿到所需要的 IP 地址就好了呐馆，如果緩存中不存在才會走整個 DNS 查詢的過程。同時為了避免 DNS 解析結(jié)果的變更造成緩存內(nèi)數(shù)據(jù)失效莲兢，我們可以啟動一個定時器定期地更新緩存中的數(shù)據(jù)汹来。
我曾經(jīng)測試過這種方式，對于 HTTP 請求的響應(yīng)時間的提升是很明顯的改艇，原先 DNS 解析時間經(jīng)常會超過 1s收班，使用這種方式后，DNS 解析時間可以控制在 200ms 之內(nèi)谒兄，整個 HTTP 請求的過程也可以減少大概 80ms～100ms摔桦。
這里總結(jié)一下，將用戶的請求映射到 CDN 服務(wù)器上是使用 CDN 時需要解決的一個核心的問題承疲，而 CNAME 記錄在 DNS 解析過程中可以充當(dāng)一個中間代理層的角色邻耕，可以把用戶最初使用的域名代理到正確的 IP 地址上。
現(xiàn)在燕鸽，剩下的一個問題就是如何找到更近的 CDN 節(jié)點了兄世，而 GSLB 承擔(dān)了這個職責(zé)。
如何找到離用戶最近的 CDN 節(jié)點
GSLB（Global Server Load Balance绵咱，全局負(fù)載均衡）的含義是對于部署在不同地域的服務(wù)器之間做負(fù)載均衡碘饼，下面可能管理了很多的本地負(fù)載均衡組件熙兔。它有兩方面的作用：
一方面，它是一種負(fù)載均衡服務(wù)器艾恼，負(fù)載均衡住涉，顧名思義嘛，指的是讓流量平均分配使得下面管理的服務(wù)器的負(fù)載更平均钠绍；
另一方面舆声，它還需要保證流量流經(jīng)的服務(wù)器與流量源頭在地緣上是比較接近的。
GSLB 可以通過多種策略來保證返回的 CDN 節(jié)點和用戶盡量保證在同一地緣區(qū)域柳爽，比如說可以將用戶的 IP 地址按照地理位置劃分為若干個區(qū)域媳握，然后將 CDN 節(jié)點對應(yīng)到一個區(qū)域上，根據(jù)用戶所在區(qū)域來返回合適的節(jié)點磷脯；也可以通過發(fā)送數(shù)據(jù)包測量 RTT 的方式來決定返回哪一個節(jié)點蛾找。不過這些原理不是本節(jié)課重點內(nèi)容，你了解一下就可以了赵誓，我不做詳細(xì)的介紹打毛。
有了 GSLB 之后，節(jié)點的解析過程變成了下圖中的樣子：
當(dāng)然俩功，是否能夠從 CDN 節(jié)點上獲取到資源還取決于 CDN 的同步延時幻枉。一般我們會通過 CDN 廠商的接口將靜態(tài)的資源寫入到某一個 CDN 節(jié)點上，再由 CDN 內(nèi)部的同步機(jī)制將資源分散同步到每個 CDN 節(jié)點诡蜓，即使 CDN 內(nèi)部網(wǎng)絡(luò)經(jīng)過了優(yōu)化熬甫，這個同步的過程是有延時的，一旦我們無法從選定的 CDN 節(jié)點上獲取到數(shù)據(jù)蔓罚，我們就不得不從源站獲取數(shù)據(jù)椿肩，而用戶網(wǎng)絡(luò)到源站的網(wǎng)絡(luò)可能會跨越多個主干網(wǎng)，這樣不僅性能上有損耗也會消耗源站的帶寬脚粟，帶來更高的研發(fā)成本覆旱。所以我們在使用 CDN 的時候需要關(guān)注 CDN 的命中率和源站的帶寬情況蘸朋。
總結(jié)
1.DNS 技術(shù)是 CDN 實現(xiàn)中使用的核心技術(shù)核无，可以將用戶的請求映射到 CDN 節(jié)點上；
2.DNS 解析結(jié)果需要做本地緩存藕坯，降低 DNS 解析過程的響應(yīng)時間团南；
3.GSLB 可以給用戶返回一個離著他更近的節(jié)點，加快靜態(tài)資源的訪問速度炼彪。
作為一個服務(wù)端開發(fā)人員吐根，你可能會忽略 CDN 的重要性，對于偶爾出現(xiàn)的 CDN 問題嗤之以鼻辐马，覺得這個不是我們應(yīng)該關(guān)心的內(nèi)容拷橘，這種想法是錯的。
CDN 是我們系統(tǒng)的門面，其緩存的靜態(tài)數(shù)據(jù)冗疮，如圖片和視頻數(shù)據(jù)的請求量很可能是接口請求數(shù)據(jù)的幾倍甚至更高萄唇，一旦發(fā)生故障，對于整體系統(tǒng)的影響是巨大的术幔。另外 CDN 的帶寬歷來是我們研發(fā)成本的大頭另萤，尤其是目前處于小視頻和直播風(fēng)口上，大量的小視頻和直播研發(fā)團(tuán)隊都在絞盡腦汁地減少 CDN 的成本诅挑。由此看出四敞，CDN 是我們整體系統(tǒng)至關(guān)重要的組成部分，而它作為一種特殊的緩存拔妥，其命中率和可用性也是我們服務(wù)端開發(fā)人員需要重點關(guān)注的指標(biāo)忿危。
