高性能利器:CDN我建議你好好學一下!

硬核乾貨分享,歡迎關注【Java補習課】成長的路上,我們一起前行 !
《高可用系列文章》 已收錄在專欄,歡迎關注!

CDN 概述

CDN 全稱 Content Delivery Network,即內容分發網路。其基本思路是儘可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節,使內容傳輸的更快、更穩定

CDN 的工作原理 就是將源站的資源快取CDN各個節點上,當請求命中了某個節點的資源快取時,立即返回客戶端,避免每個請求的資源都通過源站獲取,避免網路擁塞、緩解源站壓力,保證用戶訪問資源的速度和體驗。

舉一個生活中的例子,我們在某東上購買商品,快遞能做到當日送達,其根本原理是通過在全國各地建設本地倉庫。當用戶購買商品時,通過智慧倉配模式,為消費者選擇就近倉庫發貨,從而縮短物流配送時間。

image.png

而商品庫存的分配,流程可以參考下圖,從 工廠(源站) -> 地域倉庫(二級快取) -> 本地倉庫 (一級快取)

image.png

內容分發網路 就像前面提到的 智慧倉配網路 一樣,解決了因分布、頻寬、伺服器性能帶來的訪問延遲問題,適用於站點加速、點播、直播等場景。使用戶可就近取得所需內容,解決 Internet網路擁擠的狀況,提高用戶訪問網站的響應速度和成功率。

image.png

CDN的誕生

image.png

CDN 誕生於二十多年前,為解決內容源伺服器和傳輸骨幹網絡壓力過大的問題,在 1995 年,麻省理工學院教授,互聯網發明者之一 Tom Leighton 帶領著研究生 Danny Lewin 和其他幾位頂級研究人員一起嘗試用數學問題解決網路擁堵問題。

他們使用數學演算法,處理內容的動態路由安排,並最終解決了困擾 Internet 使用者的難題。後來,史隆管理學院的 MBA 學生 Jonathan Seelig 加入了 Leighton 的隊伍中,從那以後他們開始實施自己的商業計劃,最終於 1998 年 8 月 20 日正式成立公司,命名為 Akamai。Akamai 公司通過智慧化的互聯網分發,結束了 「World Wide Wait」 的尷尬局面。

同年 1998 年,中國第一家 CDN 公司 ChinaCache 成立

CDN工作原理

接入CDN

在接入CDN前,當我們訪問某個域名,直接拿到第一個真實伺服器的IP地址,整個流程如下(圖有點簡陋)

image.png

當我們需要加速網站時,通過向運營商註冊自己加速域名,源站域名,然後進入到自己域名的DNS配置資訊,將 A 記錄修改成 CNAME 記錄即可。阿里雲加速申請參考如下:

image.png

CDN訪問過程

image.png

  • 1、用戶訪問圖片內容,先經過 本地DNS 解析,如果 LDNS 命中,直接返回給用戶。
  • 2、LDNS MISS,轉發 授權DNS 查詢
  • 3、返回域名 CNAME picwebws.pstatp.com.wsglb0.com. 對應IP地址(實際就是DNS調度系統的ip地址)
  • 4、域名解析請求發送至DNS調度系統,DNS調度系統為請求分配最佳節點IP地址。
  • 5、返回的解析IP地址
  • 6、用戶向快取伺服器發起請求,快取伺服器響應用戶請求,將用戶所需內容傳送到用戶終端。

圖:華為雲全站加速示意圖
image.png

CDN解決了什麼問題

骨幹網壓力過大

Tom Leighton1995 年, 帶領團隊嘗試用數學問題解決網路擁堵問題,從而解決骨幹網絡壓力過大的問題。由於上網衝浪 的少年越來越多,造成骨幹網的核心節點流量吞吐不足以支撐互聯網用戶的增長,通過CDN可以避免用戶流量流經骨幹網。

骨幹網是一個全球性的區域網,一級互聯網服務提供商(ISP)將其高速光纖網路連接在一起,形成互聯網的骨幹網,實現在不同地理區域之間高效地傳輸流量。

1、區域網

區域網(Local Area Network,LAN)是指在某一區域內由多台電腦互聯成的電腦組,比如:在大學時期,晚上12點後斷網了,我們仍然能夠通過路由器開黑打CS魔獸。那就是基於區域網互聯,實現資料共享與資訊之間的通訊。

image.png

2、骨幹網

這裡引用一下中國電信全網架構,骨幹網可以理解成是一個全國性的區域網,通過核心節點的流量互通,實現全網網路的互通。這也是為什麼我們稱為互聯網 的原因。

image.png

北京、上海、廣州,是ChinaNet的超級核心。除了超級核心之外,ChinaNet還有天津、西安、南京、杭州、武漢、成都等普通核心。

image.png

三公里之 middlemile

通常網路訪問中會有”三公里”路程

  • 第一公里為:源站到ISP接入點
  • 第二公里為:源站ISP接入點到訪問用戶的ISP接入點
  • 第三公里(最後一公里)為:用戶ISP接入點到用戶客戶端

CDN網路層主要用來加速第二公里(middlemile),

在 CDN 的基礎架構中,通常使用兩級 server 做加速:

  • L1(下層):距離用戶(或俗稱網民)越近越好,通常用於快取那些可快取的靜態數據,稱之為 lastmile(最後一公里)。
  • L2(上層):距離源站越近越好,稱之為 firstmile(第一公里),當 L1 無法命中快取,或內容不可快取時,請求會通過 L1 透傳給 L2,若 L2 仍然沒有命中快取或內容不可快取,則會繼續透傳給 L2 的 upstream(有可能是源站,也有可能是 L3),同時 L2 還可以做流量、請求數的量級收斂,減少回源量(如果可快取),降低源站壓力。
  • L1 和 L2 之間的部分,是 CDN 的 」內部網路「,稱之為 middlemile(中間一公里)。

image.png

CDN的組成

全局負載均衡系統 GLB(Global Load Balance)

image.png

  • 當用戶訪問加入CDN服務的網站時,域名解析請求將最終由 「智慧調度DNS」負責處理。
  • 它通過一組預先定義好的策略,將當時最接近用戶的節點地址提供給用戶,使用戶可以得到快速的服務。
  • 同時它需要與分布在各地的CDN節點保持通訊,跟蹤各節點的健康狀態、容量等資訊,確保將用戶的請求分配到就近可用的節點上.

快取伺服器

快取伺服器主要的功能就是快取熱點數據,數據類型包括:靜態資源(html,js,css等),多媒體資源(img,mp3,mp4等),以及動態數據(邊緣渲染)等。

眾所周知耳熟能詳的與 CDN 有關的開源軟體有:

  • Squid
  • Varnish
  • Nginx
  • OpenResty
  • ATS
  • HAProxy

具體對比可參考://blog.csdn.net/joeyon1985/article/details/46573281

CDN的分層架構

image.png

源站

源站指發布內容的原始站點。添加、刪除和更改網站的文件,都是在源站上進行的;另外快取伺服器所抓取的對象也全部來自於源站。

CDN 調度策略

DNS 調度

基於請求端 local DNS 的出口 IP 歸屬地以及運營商的 DNS 調度。

DNS 調度的問題:

  • DNS 快取時間在 TTL 過期前是不會刷新的, 這樣會導致節點異常的時候自動調度延時很大,會直接影響線上業務訪問。
  • 大量的 local DNS 不支援 EDNS 協議,拿不到客戶的真實IP,CDN 絕大多數時候只能通過local DNS IP來做決策,經常會出現跨區域調度的情況。

HTTP DNS 調度

客戶端請求固定的 HTTP DNS 地址,根據返回獲取解析結果。可以提高解析的準確性(不像DNS調度,只能通過local DNS IP來做決策),能很好的避免劫持等問題。

當然這種模式也有一些問題,例如客戶端每次載入URL都可能產生一次HTTP DNS查詢,這就對性能和網路接入要求很高。

302調度

基於客戶端 IP 和 302 調度集群進行實時的流量調度。

我們來看一個例子:

  1. 訪問 URL 鏈接後,此時請求到了調度群集上,我們能拿到的客戶端資訊有 客戶端的出口IP(絕大多情況下是相同的),接下來演算法和基於 DNS 的調度可以是一樣的,只是判斷依據由 local DNS 出口 ip 變成了客戶端的出口IP。
  2. 瀏覽器收到302回應,跟隨 Location 中的 URL,繼續發起 http 請求,這次請求的目標 IP 是CDN 邊緣節點,CDN節點會響應實際的文件內容。

302 調度的優勢:

  • 實時調度,因為沒有 local DNS 快取的,適合 CDN 的削峰處理,對於成本控制意義重大;
  • 準確性高,直接獲取客戶端出口 IP 進行調度。

302 調度的劣勢:

  • 每次都要跳轉,對於延時敏感的業務不友好。一般只適用於大文件。

AnyCast BGP路由調度

基於 BGP AnyCast 路由策略,只提供極少的對外 IP,路由策略可以很快的調整。

目前 AWS CloudFront、CloudFlare 都使用了這種方式,在路由層面進行調度。

這種方式可以很好地抵禦 DDOS 攻擊,降低網路擁塞。

當然這種方式的成本和方案設計都比較複雜,所以中國的 CDN 目前還都是用 UniCast 的方式。

一些概念

CDN運作原理

本地快取的數據,通過key-value 的形式,將url 和本地快取進行映射,存儲結構與 Map相似,採用 hash+鏈表形式進行快取。

image.png

CDN命中率

衡量我們CDN服務品質的一個核心標準,當用戶訪問的資源恰好在快取系統里,可以直接返回給用戶,說明CDN命中;如果CDN快取中,沒有命中資源,那麼會觸發回源動作。

CDN回源

當CDN本地快取沒有命中時,觸發回源動作,

  • 一級快取 訪問二級快取是否有相關數據,如果有,返回一級快取。
  • 二級快取 Miss,觸發 二級快取 回源請求,請求源站對應數據。獲取結果後,快取到本地快取,返回數據到一級快取。
  • 一級快取 獲取數據,快取本地後,返回給用戶。

CDN預熱數據

上面說的訪問模式,都是基於Pull模式,由用戶決策哪部分熱點數據會最終存留在CDN快取中;對於大促場景,我們往往需要預先將活動相關資源預熱邊緣節點(L1),避免大促開啟後,大量用戶訪問,造成源站壓力過大。這時候採用的是 Push模式

CDN的特點總結

1、資源訪問加速: 本地Cache加速,提高了企業站點(尤其含有大量圖片和靜態頁面站點)的訪問速度,並大大提高以上性質站點的穩定性

2、消除運營商間網路互聯的瓶頸問題: 鏡像服務消除了不同運營商之間互聯的瓶頸造成的影響,實現了跨運營商的網路加速,保證不同網路中的用戶都能得到良好的訪問品質。

3、遠程加速: 遠程訪問用戶根據DNS負載均衡技術 智慧自動選擇Cache伺服器,選擇最快的Cache伺服器,加快遠程訪問的速度

4、頻寬優化: 自動生成伺服器的遠程Mirror(鏡像)cache伺服器,遠程用戶訪問時從cache伺服器上讀取數據,減少遠程訪問的頻寬、分擔網路流量、減輕原站點WEB伺服器負載等功能。

5、集群抗攻擊: 廣泛分布的CDN節點加上節點之間的智慧冗餘機制,可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網站的影響,同時保證較好的服務品質 。

點關注,不迷路

好了各位,以上就是這篇文章的全部內容了,我後面會每周都更新幾篇高品質的大廠面試和常用技術棧相關的文章。感謝大夥能看到這裡,如果這個文章寫得還不錯, 求三連!!! 感謝各位的支援和認可,我們下篇文章見!

我是 九靈 ,有需要交流的童鞋可以關注公眾號:Java 補習課! 如果本篇部落格有任何錯誤,請批評指教,不勝感激 !