缘起

我经营的一些网站和产品的访问量越来越高，付出的 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.05G/元 ， 降低到公有云 cdn 价格的四分之一以下（只对比平时价格，不考虑搞活动的临时特价），几乎是全网 cdn 流量成本最低之一了。