緣起
我經營的一些網站和產品的訪問量越來越高，付出的cdn流量成本（主要是圖片資源）也越來越大。抱著節省成本的想法，我嘗試在網路上找下有沒有便宜的cdn商家。 像阿里雲、騰訊雲、七牛雲，這些公有云cdn的價格都大同小異，我感覺即使從這一家換到另一家，也節省不了多少成本，同時還增加了遷移的麻煩。因此我把目光投向傳統機房，預感可能越接近機器底層，能最佳化的空間越大。
經過幾天的考察，發現很多非熱門地區的機房都或多或少都有一些閒置的優惠產品，甚至其中也不乏優質頻寬機器。特別是三四線機房，線路測試其實還不錯。很明顯這些閒置資源沒有得到充分利用。一個點子在我腦海中醞釀了。
使用開源 or 自己原創？
假如我把各地的閒置機器組織起來，把它們當成一個個節點，組建起一個分散式網路，自動容災切換，豈不就是一個廉價的自建cdn方案了？ 順著這個思路，我去找一下開源的cdn軟體 ，看看有沒有現成的解決方案。
然而事情沒有我想的那麼簡單。開源cdn並沒有很好的容災切換機制，無法實時避障。 它核心原理裡，用域名cname的方式指向某個節點ip，當節點掛了的時候，由於域名cname解析變更有10分鐘以上的快取，所以必定會導致使用者有一段時間的訪問故障。
我現在探索的是把各地機房整合到一起，其中機器節點的可靠性是參差不齊的。如果想做成一套cdn，那麼就必須要假設節點是不可靠的，隨時可能故障的，然後為此設計一套完善的容災解決方案。
既然找不到現成的開源解決方案，那就自己動手寫程式碼實現吧。
基本邏輯
我邊啃著玉米，邊用筆在紙上畫著邏輯互動圖。 經過一陣子的反覆斟酌，基本邏輯已經成型。
1，這套程式主要有兩個角色，排程伺服器和節點伺服器。排程伺服器架設在阿里雲k8s上，保障高可用。而節點伺服器則是分佈在各地機房，做好可能會故障、隨時容災切換的準備。
2，排程伺服器的作用是導流和容災，將使用者流量以重定向的方式導向可用的節點，同時避開故障節點，做到實時無縫切換。
3，節點伺服器的主要作用是拉取原始檔到本地快取，從而被使用者訪問。
4，節點伺服器跟排程伺服器之間要用某tcp協議實時連線監控，監控粒度細分到每個檔案，方便排程伺服器實時避開故障節點，這樣才能保證故障時候，使用者訪問的每個連結都可以正常切換訪問。這裡實時性是非常重要的，也是容災方案的核心。
小試牛刀
於是我花了一個多月的時間去寫程式碼來實現這個邏輯。核心程式碼其實寫得很快，但是為了保障穩定性，增加了非常多的異常容災措施，要花時間不斷測試不斷重寫。 初期只放三個異地機房節點，把流量切進來看看。
為了保險起見，先從小的做起。我一開始切日均10G流量過去，讓它跑幾天。
幾天後，沒問題。
試試日均50G流量？ 50G跑了幾天，ok。日均300G ？ 依然正常執行 。
開放商用
現在，已經完美執行了一個月，每天承受超過1000G流量，暫時沒發現有故障現象。我以及一些朋友的很多產品都在用。我刻意關掉其中一個節點，排程伺服器馬上切流量到其他節點。我刻意關閉全部節點，流量也馬上轉到源站。整個過程中，只要排程伺服器正常運作，那麼，無論節點故障與否，使用者都將繼續無感知地正常訪問圖片。 而排程伺服器直接執行在阿里雲k8s上，可靠性是非常高的。因此整套架構的可靠性很高。
有了這個架構，如果需要承受更大流量，我只需要增加節點數即可。而全國範圍內的機房機器多的是 ，我可以隨時租機器來新增節點。當我意識到有規模化運作大流量的可能性後， 我決定把cdn能力包裝出去 ，商業化運作。於是註冊並備案了大風雲網， 訪問地址是 www.dfyun.com.cn
結語
大風雲 www.dfyun.com.cn 嚴格來講不是傳統cdn ，它是另一種內容分發機制，基於傳統cdn 以及傳統機房機器， 用軟體技術實現資源整合，是應用層面的一種微創新，在圖片訪問，檔案下載等這些場景下可以成倍地降低流量成本 ，成本低於0.05元/G ， 降低到公有云cdn價格的四分之一以下（只對比平時價格，不考慮搞活動的臨時特價），幾乎是全網cdn流量成本最低之一了。
本作品採用《CC 協議》，轉載必須註明作者和本文連結