面試官：你懂 CDN 嗎？

圖解學(xué)習(xí)網(wǎng)站：https://xiaolincoding.com

五一假期期間，圖解網(wǎng)站的圖片突然全部掛了，可以說(shuō)是P0事故了，很多讀者紛紛私信跟我說(shuō)，圖片掛了， 耽誤他學(xué)習(xí)了！

我還是很驚訝，節(jié)假日還挺多人在學(xué)習(xí)的呢，針不戳！

這次的事故原因也比較簡(jiǎn)單，CDN 域名的證書過(guò)期了，因?yàn)閳D片是放在了 CDN 所以受影響了。

上一次是網(wǎng)站證書過(guò)期「我的網(wǎng)站證書過(guò)期了。。。」，疏忽了，以后更新證書得兩個(gè)一起更新。

重新更新了證書，就恢復(fù)了，因?yàn)樽C書是白嫖的，可免費(fèi)用 3 個(gè)月，3 個(gè)月后也要重新更新了，希望我能提前記得。

那話說(shuō)回來(lái)，大家知道 CDN 是什么嗎？為什么要用 CDN 呢？

今天就跟大家聊聊 CDN。

聊聊 CDN

想必大伙都聽(tīng)過(guò) CDN（Content Delivery Network），幾乎市面上所有上點(diǎn)規(guī)模的公司都會(huì)用到 CDN。

我前段時(shí)間看了一本《CDN技術(shù)詳解》，然后本地簡(jiǎn)單實(shí)現(xiàn)了一個(gè) CDN 服務(wù)，這篇文章來(lái)簡(jiǎn)單總結(jié)一下 CDN 的一些關(guān)鍵點(diǎn)。

大多數(shù)人應(yīng)該都了解它的基礎(chǔ)原理。如果網(wǎng)站服務(wù)器部署在北京，香港的用戶訪問(wèn)該網(wǎng)站，由于物理距離的緣故（網(wǎng)絡(luò)的傳輸時(shí)間受距離影響），時(shí)延相對(duì)而言會(huì)比較大，導(dǎo)致體驗(yàn)上并不是很好。

并且當(dāng)用戶量比較大的時(shí)候，全國(guó)各地所有的請(qǐng)求都涌向北京的服務(wù)器，網(wǎng)絡(luò)的主干道就會(huì)被阻塞。這個(gè)應(yīng)該很好理解，就好比國(guó)慶假期的網(wǎng)紅打卡點(diǎn)，大家都想去那里打卡，那么前往這個(gè)打卡點(diǎn)的道路不就都被堵滿了嗎？

這其實(shí)就是所謂的“熱點(diǎn)”問(wèn)題，該如何解決這個(gè)問(wèn)題呢？可以采取類似分流的操作。

主服務(wù)器部署在北京不變，但是全國(guó)各地都建立一些緩存站，這些緩存站可以緩存一些主服務(wù)器上變化不頻繁的資源，比如一些 css/js/圖片等靜態(tài)資源。

當(dāng)香港的用戶想去訪問(wèn)網(wǎng)站的時(shí)候，根據(jù)就近原則，選擇一個(gè)距離它最近的緩存站，比如有個(gè)深圳站：

那么先去這個(gè)站上看看有沒(méi)有資源，如果有就直接就從緩存站要到資源了，這個(gè)流量就被深圳站攔截了，由于距離很近，響應(yīng)時(shí)延也很低，且不占用請(qǐng)求北京的主干道流量，也減輕了北京服務(wù)器的負(fù)擔(dān)，一舉多得！

如果緩存站找不到，那么就回源到源站，也就是緩存站會(huì)去北京的服務(wù)器去要數(shù)據(jù)，然后將這些數(shù)據(jù)緩存到本地且返回給用戶，用戶的感覺(jué)可能就是網(wǎng)站卡了一下，然后就好了。

這次操作后，別的香港用戶訪問(wèn)同樣的內(nèi)容由于緩存站緩存了，因此不需要再次回源，直接從深圳站就返回?cái)?shù)據(jù)了。

當(dāng)然，一些熱點(diǎn)的數(shù)據(jù)也可以讓源站主動(dòng)推送給緩存站，進(jìn)行緩存預(yù)熱，這樣減少了回源的動(dòng)作，使得高峰時(shí)期服務(wù)器更加平穩(wěn)，用戶也不會(huì)有卡一下的表現(xiàn)。

同理，源站也可以主動(dòng)刷新緩存來(lái)更新緩存站上的老數(shù)據(jù)，緩存站上的緩存也可以設(shè)置有效期，過(guò)期刪除，減輕緩存站的存儲(chǔ)壓力。

動(dòng)態(tài)數(shù)據(jù)怎么辦？

上面我說(shuō)的是靜態(tài)資源，如果是提交訂單這樣的操作怎么緩存呢？不還是得請(qǐng)求北京的服務(wù)器嗎？

確實(shí)如此，很多業(yè)務(wù)場(chǎng)景涉及到存儲(chǔ)層面是有狀態(tài)的，如果我們讓緩存站也能處理這些業(yè)務(wù)場(chǎng)景，就得將一些業(yè)務(wù)數(shù)據(jù)存儲(chǔ)下來(lái)，那么就又會(huì)涉及數(shù)據(jù)同步問(wèn)題。

這種數(shù)據(jù)同步機(jī)制又會(huì)帶來(lái)另一個(gè)高復(fù)雜度的挑戰(zhàn)，也就是數(shù)據(jù)一致性問(wèn)題，很復(fù)雜。

所以現(xiàn)在很多云廠商提供的全站 CDN， 一般指的是 CDN 廠商會(huì)自動(dòng)識(shí)別你網(wǎng)站資源哪些是靜態(tài)的，哪些是動(dòng)態(tài)的。

靜態(tài)的按照我們上面說(shuō)的路子走，動(dòng)態(tài)的則是根據(jù)內(nèi)部的一些調(diào)度算法，智能地選擇最優(yōu)回源路徑去請(qǐng)求源站，節(jié)省請(qǐng)求的時(shí)間。

這就好比我們自駕從香港開(kāi)到北京，路線有很多，然后有個(gè)導(dǎo)航很智能，它可以實(shí)時(shí)監(jiān)控計(jì)算當(dāng)前道路信息，給我們提供一條路徑最短、最不堵的路。

CDN 基礎(chǔ)架構(gòu)

接下來(lái)我們就來(lái)分析下 CDN 究竟是如何工作的，一圖勝千言，我們先來(lái)看看下圖：

所謂的 CDN 緩存節(jié)點(diǎn)就是我上面說(shuō)的緩存站，然后還是一個(gè)很重要的 GSLB （全局負(fù)載均衡器）。

這個(gè) GSLB 的主要功能就是實(shí)現(xiàn)我上面說(shuō)的 ：當(dāng)香港的用戶想去訪問(wèn)網(wǎng)站的時(shí)候，根據(jù)就近原則，選擇一個(gè)距離它最近的緩存站。

沒(méi)錯(cuò)，它最主要的功能就是用戶訪問(wèn)網(wǎng)站的時(shí)候，根據(jù)用戶請(qǐng)求的 ip、url 選擇最近的節(jié)點(diǎn)，讓用戶直接請(qǐng)求最近的節(jié)點(diǎn)即可。

簡(jiǎn)單來(lái)說(shuō)就是請(qǐng)求轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)到最近（或許是最空閑）的站。

GSLB 轉(zhuǎn)發(fā)機(jī)制有三種實(shí)現(xiàn)：

• 基于 DNS 解析
• 基于 HTTP 重定向（主流應(yīng)用層協(xié)議為 HTTP）
• 基于 IP 路由。

業(yè)界實(shí)現(xiàn)轉(zhuǎn)發(fā)的主流技術(shù)是 DNS 解析，這里大家可以花 10 秒鐘思考一下，為什么主流是 DNS 解析？

答案是 DNS 有緩存功能和負(fù)載均衡能力，能天然減輕 GSLB 的壓力。

設(shè)想一下，如果采用 HTTP 重定向去實(shí)現(xiàn)轉(zhuǎn)發(fā)，從功能角度來(lái)看有問(wèn)題嗎？

沒(méi)問(wèn)題，301 永久重定向和 302 臨時(shí)重定向都可以實(shí)現(xiàn)轉(zhuǎn)發(fā)功能。

那么 301 合適嗎？永久重定向好像不合適，比如重定向的緩存站掛了咋辦，遷移了咋辦？GSLB 叫全局負(fù)載均衡，就均衡一次完事兒啦？

所以只能 302 ，而 302 的流程每次還得訪問(wèn) GSLB，那不就等于所有請(qǐng)求每次都得經(jīng)過(guò) GSLB 操作？因此 GSLB 可能會(huì)成為性能瓶頸。

而 DNS 解析不會(huì)這樣，用戶通過(guò)域名解析定位到 GSLB ，通過(guò)負(fù)載均衡返回用戶最近的一個(gè)緩存站 ip，后續(xù)瀏覽器、本地 DNS 服務(wù)器等都會(huì)將本次域名解析得到的 ip 結(jié)果緩存一段時(shí)間。

那么這個(gè)時(shí)間段內(nèi)用戶再次請(qǐng)求這個(gè)域名，壓根不會(huì)打到 GSLB 而是直接訪問(wèn)對(duì)應(yīng)的緩存站，這不就解決瓶頸問(wèn)題了嗎？

tips：以下內(nèi)容需要提前你了解 DNS 基本解析流程，篇幅有限，這里不多介紹 DNS 相關(guān)知識(shí)

基于 DNS 解析具體有三種實(shí)現(xiàn)方式：

• 利用 CNAME 實(shí)現(xiàn)負(fù)載均衡
• 將 GSLB 作為權(quán)威 DNS 服務(wù)器
• 將 GSLB 作為權(quán)威 DNS 服務(wù)器的代理服務(wù)器

業(yè)界最多是使用 CNAME 方式來(lái)實(shí)現(xiàn)負(fù)載均衡，實(shí)現(xiàn)簡(jiǎn)單且不需要修改公共 DNS 系統(tǒng)配置。

利用 CNAME 如果實(shí)現(xiàn) CDN？

簡(jiǎn)單舉個(gè)例子，比如之前網(wǎng)站網(wǎng)址是 www.netitv.com.cn，此時(shí)進(jìn)行要 cdn 改造，那么將之前的網(wǎng)站網(wǎng)址作為 GSLB  服務(wù)域名的 CNAME，用戶訪問(wèn) www.netitv.com.cn，經(jīng)過(guò) CNAME 解析會(huì)映射到 GSLB 地址 www.netitv.cdn.com.cn 上，然后 GSLB 基于 DNS 協(xié)議可以進(jìn)行后續(xù)的負(fù)載均衡操作，選擇合適的 IP 返回給用戶。

具體如下圖所示，圖來(lái)自《CDN技術(shù)詳解》：

第二種實(shí)現(xiàn)方式其實(shí)很好理解，就是將 GSLB 作為一個(gè)域的權(quán)威 DNS 服務(wù)器，取而代之，那么對(duì)于這個(gè)域來(lái)說(shuō)，正常域名解析的過(guò)程不就可以為所欲為了？負(fù)載均衡就都由 GSLB 來(lái)把控了，至于如何才能成為一個(gè)域的權(quán)威 DNS 服務(wù)器？這個(gè)我不清楚，聽(tīng)起來(lái)好像有點(diǎn)難度。

至于第三種實(shí)現(xiàn)方式其實(shí)就是在權(quán)威 DNS 服務(wù)器前面做一個(gè)代理，差別就是不需要實(shí)現(xiàn)一個(gè)功能完整的權(quán)威 DNS 服務(wù)器，僅需對(duì)個(gè)別需要 GSLB 操作的請(qǐng)求進(jìn)行修改轉(zhuǎn)發(fā)即可，不過(guò)這其實(shí)也得將對(duì)外公布的權(quán)威 DNS 服務(wù)器的地址變成代理服務(wù)器地址，這個(gè)難度和第二點(diǎn)一致。

好了，最后還有一個(gè) IP 路由沒(méi)介紹，其實(shí)本質(zhì)的原理是基于路由器原有的路由算法和數(shù)據(jù)包轉(zhuǎn)發(fā)能力來(lái)實(shí)現(xiàn)轉(zhuǎn)發(fā)。

簡(jiǎn)單來(lái)說(shuō)就是域名解析得到一個(gè) VIP（虛擬 IP），用戶向 VIP 請(qǐng)求的時(shí)候，經(jīng)過(guò)路由器 A， 路由器 A 查看路由表來(lái)進(jìn)行轉(zhuǎn)發(fā)數(shù)據(jù)包，然后發(fā)現(xiàn)有多個(gè)路由，因此就可以不同路徑的轉(zhuǎn)發(fā)了，一般這種只能實(shí)現(xiàn)在某個(gè)內(nèi)部網(wǎng)絡(luò)，全國(guó)性基本不可能實(shí)現(xiàn)，所以簡(jiǎn)單了解下就行。

其他還有一些我最上面圖畫的健康檢測(cè)、異常轉(zhuǎn)移等等，這個(gè)其實(shí)和正常的微服務(wù)操作都是一樣的，這里就不多介紹了。

最后

我大概花了 7 小時(shí)讀完了 《CDN技術(shù)詳解》，上面就是我整理的對(duì)開(kāi)發(fā)同學(xué)而言關(guān)鍵的一些點(diǎn)，有興趣的同學(xué)也可以自行去閱讀這本書。

關(guān)于自建 CDN 可以利用 Netty 實(shí)現(xiàn) DNS 的解析，然后內(nèi)部做一些負(fù)載均衡的操作，將電腦 DNS 服務(wù)器設(shè)為 127.0.0.1 即可調(diào)試，這里就不多做展開(kāi)了。

推薦閱讀：

真香！想沖得物去了！

淚崩，中廠一面也要輸了。。。

騰訊一二面，強(qiáng)度拉滿！

字節(jié)都到三面了，結(jié)果還是涼了。。。