今年秋天，我加入猛买之后，遇到的第一个挑战就是图片托管。当时，网站流量快速增长，原有服务器几次增加带宽依然无法满足需求，流量常常跑满。现在回头总结一下，像我们这样的小公司，自己维护静态资源服务器大致有这些不爽：

• 峰值带宽决定大部分成本
  如果峰值带宽在20Mb，那就得买20Mb，哪怕在凌晨只有几百Kb。
• 运维的成本不可忽视
  除了买带宽，还得时时处处留意服务器运行情况、网卡流量、安全状况等，也需要持续投入。
• 单机达不到CDN的功效
  虽然我们用的机房速度和稳定性都不错，但毕竟是单机，无法保证全国各地的访问速度。

在两个月的使用过程中，UpYun确实出现过2次不稳定的状况，但又拍同学们都很及时地解决了。正式上线后，稳定性极佳，到目前为止可用率高达100%。

这篇文章主要是从用户的角度谈谈UpYun的特点和使用技巧，让对UpYun感兴趣的朋友们更好地了解这个平台，可以加深了解，更好地使用它。UpYun目前提供的是文件存储+CDN的服务，可以认为是AWS的S3+CloudFront，但实际用起来，有些细节上的不同。

0、与众不同的Bucket

和一般云存储服务提供的Bucket不同，UpYun中的Bucket分为文件类和图片类。文件类Bucket可以存放任何文件；图片类Bucket仅能存放图片文件，妄图上传其他类型会被拒绝。每个Bucket都可以绑定多个域名。

1、文件增量同步

使用第三方服务托管静态资源，都会有文件同步的需求。那么，放在主服务器的文件，如何同步到UpYun呢？又拍官方提供了两种方式：FTP和API。API功能强大，但是需要做开发，目前还没人开发出类似s3cmd这样的工具；FTP命令功能有限，想用原生的几个命令辗转腾挪实现sync很费劲（不切实际地想，如果支持rsync就好了）。

我们在实际使用时，利用了lftp的mirror命令，通过FTP协议实现了文件增量同步。再配合crontab，就能做到定时增量同步了。这样既避免了投入精力围绕API做开发，又能达到rsync的效果。下面是一个脚本示例供参考：

#!/bin/bash

HOST=”v0.ftp.upyun.com”

USER=”username”

PASS=”password”

LCD=”localpath”

RCD=”remotepath”

lftp -c “open ftp://$HOST;

user $USER $PASS;

lcd $LCD;

cd $RCD;

mirror –reverse \

–delete \

–dereference \

–verbose \

–exclude-glob=*.php”

2、缩略图功能

肯德基说“We do chicken right”，又拍的兄弟们完全可以自豪地说“We do pictures right”。UpYun的图片类Bucket有一个高级功能，那就是自动生成指定尺寸缩略图。

在Web页面上如果出现大图小用，不仅浪费流量，也会导致用户浏览器缩小图片从而影响前端性能（小图大用的情况就不用说了吧）。这时，UpYun的缩略图功能就派上用场了。

设置完成后，只要上传一张原图，UpYun可以按需生成多张不同尺寸的缩略图（如果没有请求是不会生成的，这样可以节约空间）。

下面是3个不同尺寸的缩略图：

• 150px宽
• 200px宽
• 310px宽

要拥有这些缩略图，只需要上传一张原图：

又拍云可通过不同的URL得到不同尺寸的缩略图（感兴趣的话可以看看上面几幅图的地址）。是不是有点像淘宝的图片服务器？缩略图功能依然是按照使用的空间和产生流量收费，无额外费用。

3、数据备份

很多公司需要备份各类数据，这种需求也可以利用UpYun的文件Bucket来满足。当然，首先要将其设为私有，从而使外部无法访问。如图

设为禁止外链后，这个Bucket就可以用来安全地存放数据备份了。需注意目前对单个文件有最大100MB的限制。

除以上功能外，UpYun还提供了直观的流量统计图表，如图：

后台还有很多其他功能，就不一一截图了。

CDN也很赞，在国内不同位置获得的IP也不同，而且速度都不错。如图：

看完这些是不是心动了？产品给力，服务更没的说。快到UpYun申请试用吧。

–

最后，打个广告。

猛买的技术团队期待靠谱研发工程师加盟；

公司里全是年轻人，气氛活泼，更兼业务稳健，从成立之初就一直盈利；

技术团队氛围宽松，不打卡+弹性工作制那是必须的；

钱和期权都管够，但我们不拿创业忽悠人，更希望每个人都能茁壮成长。

如果正在看这篇文章的你，热爱技术，喜欢研究新鲜玩意儿，正在找工作或是打算换工作，请联系我：zhanglei909#gmail.com。

P.S. 也欢迎实习；用Gmail和Twitter都有加分滴。

以前用GAE的时候，写过一篇《用Google App Engine做山寨CDN》。但GAE服务器远在国外，不时被封；并且本身有不少限制（如文件数量不超过1K，单个文件不超过1M等），所以拿来做CDN并不那么爽。注册了SAE账号以后，第一时间就想把GAE上的静态文件们，挪到SAE上来。

搭建的过程非常顺利，只花了不到10分钟就完成。SAE的SDK特别规定了文件的目录结构，需要放在apps/app_name/app_version/code 下面，所以我在Linux上直接用软连接的方式搞定了。用Windows的话，可能真的得cp文件了。

很多人说我只放静态文件会比较浪费。没错，SAE提供了PHP的运行环境，MySQL和Memcached也一并提供，只是还没来得及都试试。对Sina做这样的东西，我还是很佩服的。

说几个不足：

1. 缺少Rewrite支持。SAE使用了nginx做web服务器。用nginx的话所有rewrite规则必须写到配置文件并重启才会生效。没有Rewrite的话，URL就太不好看了。
2. SDK规定的目录结构太复杂。
3. “应用日志”没有任何内容，不知是不是还没实现。

几张截图：

值得一提的是这配额信息，不管怎么刷，使用率都不变。也许是还没达到1%。

UPDATE:现在再看时，使用率已经有变化了。

BTW，我还没有可用的邀请，后台也看不到什么可以发邀请的地方。不过大家可以在Twitter上关注 @sina_app_engine ，没准哪天就大量发邀请了。

CDN多数时候被用来分发一些静态文件（虽然也支持动态文件），比如js, css以及网页里使用的图片，都可以放在CDN上。把静态文件托管在别处好处很多，不仅可以避开浏览器的连接数限制，而且不会发送没用的cookie。更多这方面的心得请看Fenng的旧文。

现在有了Google Appengine，就可以用Google的服务器来存放静态文件，起到CDN的效果。也是我写这篇文章的初衷。在Appengine上托管静态文件极其简单：

第一步，在Appengine上新建一个应用。

第二步，在本地新建项目文件夹，并创建几个用于存放静态文件的目录，如img, javascripts之类的。

第三步，在项目文件夹中创建一个app.yaml文件，内容如下：

application: YOUR_APP_ID
version: 1
runtime: python
api_version: 1

handlers:

- url: /img
static_dir: img

- url: /javascripts
static_dir: javascripts

- url: /stylesheets
static_dir: stylesheets

最后，把要Appengine托管的静态文件放到相应的文件夹，使用appcfg.py 把文件上传到服务器，大功告成。所有加入的静态文件应该已经都能访问了。

我托管了的prototype.js：http://niupucdn.appspot.com/javascripts/prototype.js

需要注意的是，Appengine对文件大小和文件数量都有限制。如果小文件过多（超过了1000），可以考虑采用zip压缩，但也要避免压缩之后文件体积超过1M。

经过我观察，用Appengine托管静态文件也有不足：没有ETag，也无法返回304。只是会在响应头信息里设置10分钟后过期。在这方面可控性太低。

看看后台的图表，感觉很漂亮：