引言
作為公司 cdn 小組的一名小碼仔，我為寫一篇 cdn 的科普文章準備了好一段時間（大概有一個多月沒有更新我的社交賬號了）。
在我剛進入公司，培訓完，進入小組，瞭解到我們做的是 cdn 相關的工作後，我第一時間就是上網搜關於 CDN 的入門知識。不知道大家有沒有做過和我相類似的事情，但是，我想結果都是差不多的：不太能找到一篇符合自己預期的 cdn 入門介紹文章。
作為 IT 行業的從業者，偶希望這文章雖然講的是入門，但最好又不那麼入門，最好能把我們學過的計算機知識串聯起來。就是那種，請把我的頭髮染成黑色，但又不要那麼的黑，需要那種五彩斑斕的黑.....
首先我盡力為這篇文章奠定一個大的基調，不知道大家贊不贊同：快取和遞迴，是計算機領域最有意思的兩個詞之二。
大家想一想，計算機自頂向下，是不是多級快取構建起來的？
計算機最底層的執行命令就那麼幾條，我們上層應用所有花裡胡哨的行為，終究要回歸到這幾條指令。而這個花裡胡哨到簡單明瞭的轉化，靠的就是遞迴呀！
假設您能認同這個觀點（解釋的角度可以切換，但這篇這麼講比較合適），我們進一步思考：那貌似我們計算機系統設計就離不開快取和遞迴思想。
既然計算機離不開快取與遞迴，那麼，基於計算機，在此之上構建的網路通訊自然也離不開快取與遞迴。計算機找 IP，各種定址，但凡你要是細想，你會發現：龜龜，全是快取與遞迴......
扯遠了，我們回到工作當中。可以這麼說，網際網路產品，幾乎沒有不使用 CDN 網路的，小公司為了加速使用者訪問產品，不得不上 cdn；成規模的公司基本都有 cdn 小組負責公司的 cdn 解決方案；大公司基本都會構建自己的 cdn 網路，進而對外兜售 cdn 服務。
有了以上鋪墊後，各位看官請醞釀一下快取與遞迴的思想，聽我站在使用者的角度講個故事：
開胃小故事
很久很久以前，我家住在村頭，雜貨店在村尾，村頭和村尾相隔十萬八千里，我每次買東西都要跨過山河大海，我非常不爽，因為這非常耗時間。
這個時候村裡來了一箇中間商，他在村頭和村尾之間擺了一個小攤，當我想去買東西的時候就會在村中間遇見他，我問他：你有沒有 AD 鈣奶。
他說：等我一下。
然後他一個跟斗雲翻到了村尾，取了 AD 鈣奶，然後又一個跟斗返回他的小攤，他告訴我：AD 鈣奶，我給你取回來了。
我很高興，這次不用走那麼遠了。
第二天，我又想喝 AD 鈣奶，我往村尾的方向走，到了村中間的小攤又遇到了老闆。
老闆聽說我要 AD 鈣奶，往下一掏，直接就拿了出來。
我說龜龜，這次怎麼這麼快？
老闆說，你上次來買過一次，我已經記住了，而且我還把 AD 鈣奶存到我的小攤裡。
我很高興，這次連等老闆取貨的時間都省了。
第三天，我想喝 82 年的拉菲了，我又往村尾的雜貨店走去，中間又遇到了老闆。
老闆往下一掏，直接就拿出了一瓶 82 年的拉菲，叫我微信掃碼。
我很好奇：我之前沒來買過 82 年的拉菲呀！怎麼事先就存放在這了呢？
老闆說：哦，村尾雜貨店知道你們村頭人喜歡喝 82 年的拉菲，所以提前把拉菲提前下放到了我的小攤裡。
我想：哎喲，這還挺貼心。
第四天，我又想喝 AD 鈣奶，而且我在電視廣告得知，AD 鈣奶出了新品種，我想喝最新的。
於是我再次來到了老闆的小攤。
老闆又往下一掏。
我說：停停。
AD 鈣奶已經更新了，你這不是最新的版本！
老闆說：哦？是麼？
然後他又一個跟斗雲翻回村尾雜貨店，取了最新的 AD 鈣奶，再一個跟斗雲回到小攤。
於是，我喝到了最新的 AD 鈣奶。
老司機肯定知道，我上面這小說，已經把 CDN 的基本使用講完了，接下來，我從內容提供者的角度，用專業術語，重現一次這個過程。
技術名詞講解
我們以訪問一張圖片為例子，假設我直接基於手邊笨重的機器搭建靜態檔案伺服器，把圖片寄存到這臺機器上，假設我的工作地點在廣州，那麼這個時候如果有一名北京的使用者想訪問我的圖片資源，就要走很長一段網路鏈路。
使用者載入圖片的速度慢，就會不爽，不爽就不會用我們的服務，使用者流失嚴重，我就會被炒掉，所以我要想辦法解決這個問題。
於是我聯絡上海的同事，問他能不能用他們機房的機器做一個快取節點，把我這機器當作源站，使用者取檔案的時候先到你那裡取，發現沒有就到我這取，取完後把圖片資源快取在你們的機器上，這樣使用者再次訪問這張圖片的時候，就能從你們那取到了，不用走這麼遠。
同事說沒問題。
但他接著問：哎阿菌，既然你知道使用者要訪問這張圖片，為啥不提前把這張圖片預熱到我們的快取節點上呢？你提前把圖片傳送到我們節點，我們就不需要回源去取了呀！
我恍然大悟：你說的有道理。
同事說，哈哈哈，不過咧取圖片倒也不用特別久，因為圖片頂多就幾個 MB，我們回源取也沒問題。但是如果你們以後有一些大檔案，比如說十幾 GB 的遊戲安裝包，那提前預熱放到我們那，使用者的體驗是會提高很多的。
我簡直不能再同意。
兩個星期後，我們產品對那張圖片提出了整改要求，要求把圖片的背景色改成黑色，但又不要那麼黑，改完之後要求我們立刻把圖片更新給客戶。
我一想，完了，由於加了快取機制，快取節點上放的是以前的圖片，使用者不會直接到我們這兒取最新的圖片。
於是我再次打電話給上海的同事，我說，大佬，我們那張圖片更新了，你那邊可以讓快取在你們節點上的圖片失效麼，重新來我們這取一張最新的圖片。
同事哈哈一笑：當然可以，這種重新整理操作我們必然支援。或許我們以後還可以商量加一個功能，新增一個快取的失效時間。
我說那簡直太好了。
一段時間後，我們機房出了一個事故，一隻老鼠旋轉跳躍的時候扯斷了我們機房的一根電線，我們存放圖片的機器受到了牽連，機器掛了。
恰好那個時候同事的快取節點有許多回源請求來我們源站取資源，這些請求全都受到了牽連，使用者立馬就來投訴，為啥資源遲遲未能載入？
同事說：哎阿菌，要不你們以後多整幾個源站吧，這樣當我們請求一個源站遲遲未能有響應的時候，就立馬切換到下一個源站節點。
我覺得他說得很有道理，便在不同的地方搭建了好幾個源站。
這回系統就有意思了。
作為內容提供者，我需要保證的是：我的每一份資源，都要能確保傳送到每一個源站站點，要確保每個源站上的資源都是一樣的。這裡涉及到了分散式系統的一致性問題。
而我的同事，快取節點的維護者，他們要考慮的是：如何通過合理的負載均衡演算法，確保回源請求能正確訪問源站節點。
講到這裡，不知道朋友們是否就能將 CDN 和我們所學的各種計算機知識聯絡起來了呢？
我個人覺得，CDN 的設計和 Web 後端設計是相通的，和我們使用 nginx 在自己的伺服器前加一層代理是同型別操作。
感覺這 CDN 服務想要賣錢，首先需要依靠團隊紮實的技術基礎，另一個更重要的則是公司的基礎建設。所以可以大膽預言，CDN 服務最後的勝者不會是這條賽道的先驅，而是基礎建設牢固的那些公司們。
但是這世界上終究沒有永遠的勝者，蛋糕這麼大，有人吃肉，有人喝湯嘛。
對於我們這種 CDN 服務的使用者而言，我們只要知道他的原理，並且能好好設計使用方案使用就好了。
授之以漁
假設我是一名讀者，讀到這裡，我肯定會覺得意猶未盡。
所以非常推薦大家動手實際操作，申請一個域名，體驗一下整個 cdn 的使用流程。在這個過程中如果遇到了感興趣的知識點就能深入往下學習啦。
由於工作原因我體驗過很多主流廠商的域名申請，但由於沒有一家給廣告費，我也不知道該用哪家舉例子比較好 T_T。
推薦從域名申請開始的原因是：域名申請往往需要和域名配置一起進行，當你進行域名配置的時候，你能從配置中反推很多 cdn 的知識。
比如說：
- 源站配置。當我們配置源站的時候，你需要考慮配多少個源站？快取節點訪問源站用什麼協議？訪問源站多久算超時？回源的時候要不要帶上一些特定的 HTTP 頭以達成某種目的？回源的時候要不要進行一些前置配置？
- 快取配置。我們要快取哪些請求？GET 請求是要的，其他請求要不要考慮捏？允許哪些協議？請求源站返回錯誤怎麼辦，要不要配個預設錯誤頁面？
- 其他配置。被攻擊了怎麼辦，IP白名單可以考慮用起來。cdn 的請求日誌要不要開啟，獲取更多的使用者資訊就能做更多的定製服務等等......
你可從中看出，其實 cdn 知識和伺服器開發知識是緊密關聯的。我本人是個初學者，所以放出這些問題和大家一起討論了。要學的還有很多，共勉～