后端文檔教程【免費(fèi)下載鏈接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.項(xiàng)目地址https://gitcode.com/GitHub_Trending/sy/system-design-101點(diǎn)擊查看免費(fèi)下載CDNContent Delivery Network內(nèi)容分發(fā)網(wǎng)絡(luò)通過(guò)在全球范圍內(nèi)部署邊緣服務(wù)器把靜態(tài)與動(dòng)態(tài)內(nèi)容緩存到離用戶最近的地方從而顯著降低延遲、提升可用性并優(yōu)化帶寬成本。本篇以 System Design 101 倉(cāng)庫(kù)中的 CDN 主題文檔為骨架系統(tǒng)講解 CDN 的價(jià)值來(lái)源、一次完整的請(qǐng)求是如何被路由到最近的邊緣節(jié)點(diǎn)的以及在生產(chǎn)環(huán)境中優(yōu)化 CDN 的最佳實(shí)踐讀完即可掌握 CDN 的核心組件、GSLB / Anycast / IXP 三類路由手段的差異并能將其直接用于系統(tǒng)設(shè)計(jì)面試與線上架構(gòu)評(píng)估。為什么 CDN 如此流行市場(chǎng)信號(hào)與價(jià)值來(lái)源CDN 早已不是錦上添花的加速工具而是現(xiàn)代 Web 基礎(chǔ)設(shè)施的標(biāo)配。從市場(chǎng)角度看CDN 市場(chǎng)預(yù)計(jì)在 2028 年前后接近約 380 億美元的規(guī)模Akamai、Cloudflare、Amazon CloudFront 等主流廠商都在這一領(lǐng)域持續(xù)重金投入。高投入的背后是高需求視頻流媒體、電商大促、全球化的 SaaS 應(yīng)用都需要把內(nèi)容推到用戶身邊。CDN 帶來(lái)的核心價(jià)值可以歸結(jié)為四個(gè)方面見 what-is-cdn-content-delivery-network.md降低延遲Reducing Latency內(nèi)容不再必須跨越半個(gè)地球從源站Origin Server取回而是從地理上最近的 CDN 節(jié)點(diǎn)直接命中緩存。降低帶寬成本Reducing Bandwidth大量重復(fù)的內(nèi)容請(qǐng)求在邊緣節(jié)點(diǎn)被攔截源站出口帶寬與 CDN 回源帶寬都大幅下降。提升內(nèi)容可用性Increasing Content Availability邊緣節(jié)點(diǎn)天然形成了冗余即使某個(gè)源站或某個(gè)區(qū)域節(jié)點(diǎn)故障流量也能被路由到其他可用節(jié)點(diǎn)。增強(qiáng)網(wǎng)站安全性Improving Website Security尤其體現(xiàn)在對(duì)抗 DDoSDistributed Denial-of-Service分布式拒絕服務(wù)攻擊上——攻擊流量在到達(dá)源站之前就會(huì)被邊緣網(wǎng)絡(luò)吸收和過(guò)濾。這些收益在延遲敏感的業(yè)務(wù)上會(huì)被進(jìn)一步放大。倉(cāng)庫(kù)中的 top-5-strategies-to-reduce-latency.md 指出在降低延遲的常用策略清單里CDN 與數(shù)據(jù)庫(kù)索引、緩存、負(fù)載均衡、異步處理、數(shù)據(jù)壓縮并列是面向高規(guī)模用戶系統(tǒng)的六大手段之一可見其地位。CDN 請(qǐng)求流程從 DNS 到邊緣節(jié)點(diǎn)再到源站原文檔給出了 CDN 請(qǐng)求的核心三步流程這是理解 CDN 的鑰匙DNS 解析完成后用戶的設(shè)備把內(nèi)容請(qǐng)求發(fā)送到 CDN 邊緣服務(wù)器Edge Server。邊緣服務(wù)器先檢查自己的本地緩存緩存命中直接把內(nèi)容返回給用戶緩存未命中把請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器Origin Server。邊緣服務(wù)器從源服務(wù)器拿到內(nèi)容后在本地緩存一份副本再交付給用戶。把上述流程放到一次真實(shí)的瀏覽器訪問(wèn)里參考 how-does-cnd-work.md 中 Bob 訪問(wèn)部署在倫敦的電商網(wǎng)站www.myshop.com的例子整個(gè)鏈路會(huì)展開為更完整的 10 步用戶在瀏覽器輸入www.myshop.com瀏覽器先查本地 DNS 緩存。本地緩存未命中瀏覽器向 DNS 解析器通常位于 ISP 側(cè)發(fā)起域名解析。DNS 解析器遞歸解析該域名最終向權(quán)威域名服務(wù)器Authoritative Name Server發(fā)起查詢。不使用 CDN 時(shí)權(quán)威域名服務(wù)器直接返回www.myshop.com的源站 IP使用 CDN 時(shí)權(quán)威域名服務(wù)器返回的是一個(gè)指向 CDN 域名的別名CNAME例如www.myshop.cdn.com。DNS 解析器繼續(xù)向權(quán)威域名服務(wù)器解析www.myshop.cdn.com。權(quán)威域名服務(wù)器返回 CDN 負(fù)載均衡器的域名例如www.myshop.lb.com。DNS 解析器向 CDN 負(fù)載均衡器解析www.myshop.lb.com。負(fù)載均衡器根據(jù)用戶的 IP 地址、用戶所屬 ISP、請(qǐng)求的內(nèi)容類型以及各邊緣服務(wù)器的實(shí)時(shí)負(fù)載選出最合適的邊緣節(jié)點(diǎn)。CDN 負(fù)載均衡器返回被選中的邊緣服務(wù)器 IP 地址。DNS 解析器把該 IP 返回給瀏覽器——到這里才拿到真正的目標(biāo) IP。瀏覽器訪問(wèn) CDN 邊緣服務(wù)器加載內(nèi)容。邊緣服務(wù)器緩存的既有靜態(tài)內(nèi)容頁(yè)面、圖片、視頻也有動(dòng)態(tài)內(nèi)容例如邊緣計(jì)算的結(jié)果若邊緣節(jié)點(diǎn)未命中請(qǐng)求會(huì)逐級(jí)上溯到區(qū)域 CDN 節(jié)點(diǎn)、中心 CDN 節(jié)點(diǎn)甚至直達(dá)倫敦的源站 Web 服務(wù)器——這個(gè)逐級(jí)上溯的過(guò)程就是 CDN 的分發(fā)網(wǎng)絡(luò)distribution network。值得注意的是DNS 解析本身就是這套流程的耗時(shí)大頭。倉(cāng)庫(kù)中 how-does-the-domain-name-system-dns-lookup-work.md 給出的數(shù)據(jù)顯示一次 DNS 查詢平均耗時(shí)在 20–120 毫秒之間因此 CDN 在 DNS 層就引入的負(fù)載均衡與就近路由實(shí)際上是整個(gè)性能優(yōu)化鏈條的第一環(huán)。CDN 架構(gòu)的四大組件CDN 的架構(gòu)由四類組件構(gòu)成見 why-are-content-delivery-networks-cdn-so-popular.md組件職責(zé)源服務(wù)器Origin Server內(nèi)容的首要來(lái)源保存站點(diǎn)內(nèi)容的正本例如部署在倫敦的電商 Web 服務(wù)器。邊緣服務(wù)器Edge Servers在全球范圍內(nèi)分布式部署負(fù)責(zé)緩存并直接向用戶提供內(nèi)容是距離用戶最近的節(jié)點(diǎn)。DNS把域名解析為最近邊緣服務(wù)器的 IP 地址是請(qǐng)求路由的入口?？刂破矫鍯ontrol Plane負(fù)責(zé)配置和管理所有邊緣服務(wù)器例如下發(fā)緩存規(guī)則、更新內(nèi)容、監(jiān)控節(jié)點(diǎn)狀態(tài)。從倉(cāng)庫(kù)中 a-beginners-guide-to-cdn-content-delivery-network.md 的補(bǔ)充可以看到邊緣服務(wù)器的價(jià)值不限于緩存還延伸出兩個(gè)重要概念邊緣計(jì)算Edge Computing在靠近用戶的節(jié)點(diǎn)上完成數(shù)據(jù)處理而非全部集中到中心數(shù)據(jù)中心。這對(duì)需要實(shí)時(shí)處理的場(chǎng)景視頻流、在線游戲尤其重要。云游戲Cloud Gaming借助云計(jì)算為用戶提供高質(zhì)量、低延遲的游戲體驗(yàn)正是邊緣計(jì)算 CDN 網(wǎng)絡(luò)的典型落地場(chǎng)景。CDN 請(qǐng)求路由的三種關(guān)鍵手段路由是 CDN 的指揮系統(tǒng)決定了每個(gè)用戶請(qǐng)求最終落到哪一臺(tái)邊緣服務(wù)器。原文檔歸納了三種核心機(jī)制GSLB全局服務(wù)器負(fù)載均衡GSLBGlobal Server Load Balancer全局服務(wù)器負(fù)載均衡根據(jù)以下因素把用戶請(qǐng)求路由到合適的服務(wù)器地理鄰近度Geographic Proximity優(yōu)先選擇離用戶物理距離更近的節(jié)點(diǎn)服務(wù)器負(fù)載Server Load避開過(guò)載節(jié)點(diǎn)實(shí)現(xiàn)跨節(jié)點(diǎn)負(fù)載均衡網(wǎng)絡(luò)條件Network Conditions考慮各條鏈路的實(shí)時(shí)質(zhì)量而不是只看直線距離。這與 internet-traffic-routing-policies.md 中總結(jié)的 DNS 路由策略一脈相承。除了基礎(chǔ)的 Simple簡(jiǎn)單路由全部流量指向單一端點(diǎn)之外CDN 場(chǎng)景下最常用的是Failover故障轉(zhuǎn)移流量?jī)?yōu)先走主端點(diǎn)主端點(diǎn)不可用時(shí)自動(dòng)切換到備用端點(diǎn)Geolocation地理位置路由按請(qǐng)求方的地理位置分發(fā)流量提供本地化內(nèi)容Latency延遲路由把流量導(dǎo)向?qū)φ?qǐng)求方延遲最低的端點(diǎn)Weighted Routing加權(quán)路由按權(quán)重把流量按比例分配到多個(gè)端點(diǎn)。Anycast DNS多個(gè)服務(wù)器共享同一 IPAnycast 允許網(wǎng)絡(luò)中的多臺(tái)服務(wù)器共享同一個(gè) IP 地址通過(guò) BGP 等路由協(xié)議把入站流量引導(dǎo)到最近的數(shù)據(jù)中心。這樣做的好處是用戶始終與網(wǎng)絡(luò)距離最近的節(jié)點(diǎn)建立連接天然實(shí)現(xiàn)就近接入與高可用。倉(cāng)庫(kù)中 unicast-vs-broadcast-vs-multicast-vs-anycast.md 對(duì)四種網(wǎng)絡(luò)通信方式進(jìn)行過(guò)對(duì)比其中明確點(diǎn)出 Anycast 的典型用途就是DNS 查詢和 CDN。與單播Unicast一個(gè)發(fā)送者對(duì)一個(gè)接收者如 HTTP、FTP、SMTP、廣播Broadcast一個(gè)發(fā)送者對(duì)多個(gè)接收者如 ARP、DHCP、NTP、組播Multicast發(fā)送給特定設(shè)備組如 IPTV、視頻會(huì)議相比Anycast 是一組主機(jī)對(duì)其中一個(gè)接收者的最佳建?！粋€(gè) IP 被廣播到多個(gè)數(shù)據(jù)中心路由器把數(shù)據(jù)包送給距離最近的那個(gè)。Internet Exchange PointsIXP與 ISP 直連交換流量IXP互聯(lián)網(wǎng)交換點(diǎn)是不同網(wǎng)絡(luò)ISP、CDN 廠商、云廠商等之間直接交換流量的物理匯聚點(diǎn)。CDN 廠商在全球主要 IXP 建立接入點(diǎn)PoP其意義在于縮短路徑流量不再繞行公共互聯(lián)網(wǎng)的冗長(zhǎng)鏈路而是通過(guò) IXP 與本地 ISP 直接互聯(lián)降低成本減少對(duì)上游中轉(zhuǎn)運(yùn)營(yíng)商的依賴降低流量交換成本提升穩(wěn)定性減少中間跳數(shù)降低丟包與抖動(dòng)。這解釋了為什么主流 CDN 廠商都在全球鋪設(shè)大量 PoP節(jié)點(diǎn)密度直接決定了 IXP 互連的質(zhì)量和就近路由的效果。CDN 最佳實(shí)踐安全、緩存與內(nèi)容優(yōu)化原文檔將 CDN 最佳實(shí)踐歸納為三大方向結(jié)合倉(cāng)庫(kù)中相關(guān)文檔可進(jìn)一步細(xì)化1. 安全層面的優(yōu)化DDoS 防護(hù)邊緣網(wǎng)絡(luò)本身就是天然的流量清洗層攻擊流量在到達(dá)源站前被分散、過(guò)濾見 what-is-cdn-content-delivery-network.md。源站隱藏通過(guò) CDN 代理真實(shí)源站 IP配合 WAFWeb 應(yīng)用防火墻規(guī)則在邊緣層攔截惡意請(qǐng)求。邊緣緩存未命中攻擊防護(hù)避免惡意流量反復(fù)制造緩存未命中、拖垮源站倉(cāng)庫(kù)中 cache-miss-attack.md 專門討論了這類攻擊。2. 緩存層面的優(yōu)化合理設(shè)置緩存策略對(duì)圖片、視頻、靜態(tài)資源設(shè)置較長(zhǎng)的 TTL對(duì)動(dòng)態(tài)內(nèi)容采用邊緣計(jì)算或按需回源。多級(jí)緩存回源邊緣 → 區(qū)域 → 中心 → 源站的逐級(jí)回源設(shè)計(jì)可以顯著降低源站壓力見 how-does-cnd-work.md 的分發(fā)網(wǎng)絡(luò)部分。注意緩存失效與一致性緩存系統(tǒng)設(shè)計(jì)時(shí)需考慮替換、失效與挑戰(zhàn)倉(cāng)庫(kù) learn-cache.md 覆蓋了緩存部署、分布式緩存、替換與失效策略等完整議題。3. 內(nèi)容層面的優(yōu)化靜態(tài)內(nèi)容優(yōu)先上 CDN頁(yè)面、圖片、視頻等靜態(tài)資源是緩存命中率最高的內(nèi)容類型邊緣計(jì)算承載動(dòng)態(tài)內(nèi)容把需要實(shí)時(shí)處理但又不適合全部回源的邏輯下沉到邊緣節(jié)點(diǎn)壓縮與格式優(yōu)化在邊緣層完成數(shù)據(jù)壓縮與媒體轉(zhuǎn)碼減少回源與下行的數(shù)據(jù)量。小結(jié)CDN 為什么值得流行回到最初的問(wèn)題——CDN 之所以如此流行本質(zhì)上是它用一套分布式邊緣網(wǎng)絡(luò)同時(shí)解決了性能、成本、可用性和安全四類問(wèn)題GSLB 與 Anycast 讓每個(gè)用戶都能就近訪問(wèn)多級(jí)緩存讓源站從海量重復(fù)請(qǐng)求中解放出來(lái)IXP 直連讓流量走最短路徑而邊緣層天然成為 DDoS 的第一道防線。無(wú)論你是準(zhǔn)備系統(tǒng)設(shè)計(jì)面試還是為線上業(yè)務(wù)評(píng)估架構(gòu)都可以把本篇的請(qǐng)求流程、四大組件與三種路由機(jī)制作為理解 CDN 的最小知識(shí)框架再結(jié)合倉(cāng)庫(kù)中 a-beginners-guide-to-cdn-content-delivery-network.md、how-does-cnd-work.md 與 what-is-cdn-content-delivery-network.md 等文檔繼續(xù)深入。贊分享后端文檔教程【免費(fèi)下載鏈接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.項(xiàng)目地址https://gitcode.com/GitHub_Trending/sy/system-design-101點(diǎn)擊查看免費(fèi)下載相關(guān)推薦System Design 101CDN 內(nèi)容分發(fā)網(wǎng)絡(luò)工作原理詳解DNS 解析、邊緣緩存與回源機(jī)制System Design 101CDN 內(nèi)容分發(fā)網(wǎng)絡(luò)工作原理詳解DNS 解析、邊緣緩存與回源機(jī)制 本文以 system design 101 倉(cāng)庫(kù)中的后端文檔教程oauth2-proxy 請(qǐng)求行為全解析認(rèn)證要求、放行路由與轉(zhuǎn)發(fā)流程oauth2 proxy 請(qǐng)求行為全解析認(rèn)證要求、放行路由與轉(zhuǎn)發(fā)流程 導(dǎo)讀 本文以 oauth2 proxy 7.7.x 版本的行為文檔 behaviour.后端API網(wǎng)關(guān)認(rèn)證鑒權(quán)GitHub_Trending/sys/system-design架構(gòu)分析Hashnode如何規(guī)模化生成內(nèi)容流GitHub_Trending/sys/system design架構(gòu)分析Hashnode如何規(guī)?；蓛?nèi)容流 引言內(nèi)容分發(fā)平臺(tái)的規(guī)模化挑戰(zhàn) 在當(dāng)今數(shù)字化時(shí)文檔教程知識(shí)庫(kù)上一篇Vue.Draggable與WebSockets自動(dòng)重連庫(kù)使用示例下一篇如何讓2008-2017年老Mac電腦重新煥發(fā)新生運(yùn)行最新macOS系統(tǒng)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考