推送式与拉取式CDN服务的优劣问题

Question

因为以前也做过一些站，所以用过国内外的一些cdn加速服务。我发现这些服务无非分为两种

1. 以Amazon的CloudFront为代表，内容发布者主动将需要发布的资源推送到CDN发布服务器上，然后由CDN服务商分发到其各节点。国内的提供商有UpYun。
2. 以CloudFlare为代表，与前者不同，内容不需要主动发布，而是在浏览器向CDN请求资源时，CDN服务才主动向后端的资源服务器抓取资源。国内的提供商有WebLuker。

这两种服务，一种推送，一种拉取。后者除了在DNS设置上稍显麻烦外，其它方便性均超过前者，特别是因为内容源在自己的服务器上，可以灵活的设置url，比如动态合并js之类的功能，都可以实现了。

而前者除了多一个存储备份的功能外，内容的组织形式较为死板，必须按照静态目录的方式组织，不适合较为灵活的开发。似乎后者才是大势所趋。

以上是我的看法，不知道各位有没有研究过这两者的优劣，我想后者一直存在一定有它的原因的

Answer 1

我上个月正好跟又拍云、中国擦车网、快网谈过CDN合作，8年前也用过CDN，来解答一下吧。

1. 你说的拉取式CDN，本质上是反向代理，甚至有的小CDN厂商找几个机房，搞几台低端硬件，装上squid就开始干活了。国内的代表（是反向代理类的大厂代表，不是小CDN代表啊）应该是中国擦车网（ChinaCache）、快网（FastWeb）、Weblucker
2. 拉取式和推送式的DNS设置复杂度是完全一样的。不存在谁更麻烦的问题，都是设置DNS CNAME。只不过你在用又拍云的时候根，直接使用了又拍云的子域名，图片不在sfcdn.com这样的域名下，又拍也支持DNS CNAME，绑定你自己的sfcdn.com的。而中国擦车网等均不支持你直接使用CDN厂商的子域名。
3. 这两者在逐渐融合。中国擦车网也有接口，允许你调用这个接口，主动将你指定的目录/文件同步到CDN节点上。又拍的反向代理模式也即将推出，时间我不知道。
4. 推送式（又拍）的优点在于节省源站带宽，提前将要分发的内容放到CDN节点上了，当某个流量高峰来临时，不会把你的源站带宽占满（源站还要留点带宽提供动态HTML啊）。打个比方，类似聚划算的每天10点开团，如果没有主动推送，你的源站在10点将会迎来一个流量高峰，你不得不为源站服务器购买更大的BGP带宽，以便CDN每天10点拉文件。缺点是需要针对CDN做接口开发，在被分发内容生成时主动上传给CDN
5. 抓取式（反向代理）的优点在于实在太简单，签个合同，做个DNS CNAME解析就完成了CDN的实施
6. 像贵站这样的小公司，没有历史项目的包袱，有自己的研发团队，建议将来重点使用主动推送类的CDN，之所以说是将来，是因为目前又拍自己的中心结点往全国节点同步的时候还存在分钟级的延时，又没其它的同类厂商，给创业企业多一些包容和支持，相信又拍会越做越好。
7. 动态合并JS不是问题。你完全可以合并好了之后上传到又拍上去，比如10个JS要动态合并，也就100种组合，全部合并好了传上去，HTML中引用合并好之后的js路径，这需要打包发布工具的支持，适合新公司，不适合老公司。
8. CDN行业不是大家以前想的那种傻大黑粗（跟电信关系好，搞几台机器装squid就开始赚钱了），也有很多公司在研发自己特色的东西，比如fastweb拥有自己的反向代理软件，还有动态内容（PHP，Java）加速服务（意义不是太大，且太贵，我举这个例子只是说他们有研发新东西）；比如又拍提供分布式存储和缩略图；比如ChinaCache研发了针对FLV视频网站CDN（这个投资很失败，大视频网站有几个不自己做CDN的啊？土豆跟它的合约一终止，它就开始变卖服务器回笼资金了）
9. 在中国，大网站最终都要自己做CDN的，像Instagram这样10亿美元了还全部用Amazon的奇葩公司未来5年都不会出现。最终CDN的走向嘛，我想会出现几家综合性的“fastweb+又拍”服务商