因为以前也做过一些站，所以用过国内外的一些cdn加速服务。我发现这些服务无非分为两种
- 以Amazon的CloudFront为代表，内容发布者主动将需要发布的资源推送到CDN发布服务器上，然后由CDN服务商分发到其各节点。国内的提供商有UpYun。
- 以CloudFlare为代表，与前者不同，内容不需要主动发布，而是在浏览器向CDN请求资源时，CDN服务才主动向后端的资源服务器抓取资源。国内的提供商有WebLuker。
这两种服务，一种推送，一种拉取。后者除了在DNS设置上稍显麻烦外，其它方便性均超过前者，特别是因为内容源在自己的服务器上，可以灵活的设置url，比如动态合并js之类的功能，都可以实现了。
而前者除了多一个存储备份的功能外，内容的组织形式较为死板，必须按照静态目录的方式组织，不适合较为灵活的开发。似乎后者才是大势所趋。
以上是我的看法，不知道各位有没有研究过这两者的优劣，我想后者一直存在一定有它的原因的
网页的话，其实用代理模式就可以了。大文件还是建议你做CDN的预推，这样的话 源压力就非常的小了。不过又些CDN是需要会源的 例如：网宿 CC。
我想首先明白CDN的原理和需要解决的问题就可以很容易取舍了。
CDN无非就是解决静态文件就近访问，达到加速的目的，并且都是反向代理，唯一的区别的就是两者的源不一样。CDN的难点其实不在技术而是在网络和点的分布，还有对ip分布的判断上面。
拉取式，相对简单，但灵活性很大，因为源是由自己控制的，而且还可以配合header头的信息对不同的静态文件进行相应的控制，这个只要跟CDN合作商谈好就行，国内是可以这样的。缺点就是跟推送式的优点。
推送式，灵活性就没有那么大了，源是需要通过一定的方式推送到CDN指定的位置，而且需要配合代码更新和业务需求进行及时的推送，推送式会有一点的延时，主要看CDN商的实现方式和推送API的效率，有些CDN商的推送上去之后还会将数据分发到他们自己不同的服务器存储多份，更有恶心的CDN商，分发是通过计划任务每隔多久进行一次分发，那么延时性就更大。再加上如果一旦内部出现问题排查时间会比较久。但推送式的优点是可以减少源站的网络带宽流量，对于访问量大和延时性不高的业务有非常好的作用，并且多地备份也起到安全性的作用。
取舍就跟你的具体业务有关系了。
另外有提到amazon亚马逊的CDN，就是一个很明显的推送式，一方面是方便他自己的结构，这种方式对于亚马逊也可以很方便和简单的流程控制，另一方面也可以减少流量费用，所以他只采用了这一种方式。
我要提醒一点的是，有缓存就需要有更新，CDN的缓存更新是基本都要涉及的问题，像亚马逊就不支持带参数的方式更新，因为他认为 http://1.t.com/1.jpg和 http://1.t.com/1.jpg?version=2 是同一个url不管?后面的内容，所以你的缓存更新就要想办法啰。
推送式的CDN排查问题的话比抓取式的要困难点
我上个月正好跟又拍云、中国擦车网、快网谈过CDN合作，8年前也用过CDN，来解答一下吧。
- 你说的拉取式CDN，本质上是反向代理，甚至有的小CDN厂商找几个机房，搞几台低端硬件，装上squid就开始干活了。国内的代表（是反向代理类的大厂代表，不是小CDN代表啊）应该是中国擦车网（ChinaCache）、快网（FastWeb）、Weblucker
- 拉取式和推送式的DNS设置复杂度是完全一样的。不存在谁更麻烦的问题，都是设置DNS CNAME。只不过你在用又拍云的时候根，直接使用了又拍云的子域名，图片不在sfcdn.com这样的域名下，又拍也支持DNS CNAME，绑定你自己的sfcdn.com的。而中国擦车网等均不支持你直接使用CDN厂商的子域名。
- 这两者在逐渐融合。中国擦车网也有接口，允许你调用这个接口，主动将你指定的目录/文件同步到CDN节点上。又拍的反向代理模式也即将推出，时间我不知道。
- 推送式（又拍）的优点在于节省源站带宽，提前将要分发的内容放到CDN节点上了，当某个流量高峰来临时，不会把你的源站带宽占满（源站还要留点带宽提供动态HTML啊）。打个比方，类似聚划算的每天10点开团，如果没有主动推送，你的源站在10点将会迎来一个流量高峰，你不得不为源站服务器购买更大的BGP带宽，以便CDN每天10点拉文件。缺点是需要针对CDN做接口开发，在被分发内容生成时主动上传给CDN
- 抓取式（反向代理）的优点在于实在太简单，签个合同，做个DNS CNAME解析就完成了CDN的实施
- 像贵站这样的小公司，没有历史项目的包袱，有自己的研发团队，建议将来重点使用主动推送类的CDN，之所以说是将来，是因为目前又拍自己的中心结点往全国节点同步的时候还存在分钟级的延时，又没其它的同类厂商，给创业企业多一些包容和支持，相信又拍会越做越好。
- 动态合并JS不是问题。你完全可以合并好了之后上传到又拍上去，比如10个JS要动态合并，也就100种组合，全部合并好了传上去，HTML中引用合并好之后的js路径，这需要打包发布工具的支持，适合新公司，不适合老公司。
- CDN行业不是大家以前想的那种傻大黑粗（跟电信关系好，搞几台机器装squid就开始赚钱了），也有很多公司在研发自己特色的东西，比如fastweb拥有自己的反向代理软件，还有动态内容（PHP，Java）加速服务（意义不是太大，且太贵，我举这个例子只是说他们有研发新东西）；比如又拍提供分布式存储和缩略图；比如ChinaCache研发了针对FLV视频网站CDN（这个投资很失败，大视频网站有几个不自己做CDN的啊？土豆跟它的合约一终止，它就开始变卖服务器回笼资金了）
- 在中国，大网站最终都要自己做CDN的，像Instagram这样10亿美元了还全部用Amazon的奇葩公司未来5年都不会出现。最终CDN的走向嘛，我想会出现几家综合性的“fastweb+又拍”服务商
(注意：我没有使用过UpYun，有使用Amazon EC2、S3和CloudFront经验。)
首先纠正一下，Amazon S3需要push，CloudFront是可以设定源进行pull的。
我觉得这里所讨论的似乎并不是CDN的push与pull的问题，而是细分的两种服务，
- CloudFront 属于CDN加速服务，主要是对公开资源进行加速作用；
- S3属于存储服务，不一定是公开资源，包括各种私有的备份都可以存放；
我个人倾向：
- 网站固有的资源文件使用CloudFront进行加速；
- S3等主要存放一些UGC文件[1]，根据cache命中率（譬如多数用户上传的照片可能只有他的朋友能看到，命中机率小）的不同可以选择是否使用CDN加速(而UpYun看起来正是这样的一个CDN与存储的结合体)。
当然CDN也确实有push与pull的区别，如果不是比较大的文件，多数时候pull比较方便。
------
1 - UGC是指用户生成内容，这里主要是用户上传的头像、照片、文件等资源。