我是如何把网站图片cdn流量成本压到全网最低(之一)的

缘起

我经营的一些网站和产品的访问量越来越高，付出的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 协议》，转载必须注明作者和本文链接