# General
又拍是一个不错的面向图片的云存储服务。
又拍云存储提供的服务主要是海量文件存储、存储文件在全国各地的高速访问（CDN）、图片的各种版本调用（缩略图）等基础性的服务。
# Architecture
又拍图片云计算平台是Amazon S3 + CloudFront 模式；
又拍云存储架构采用各地方缓存节点、核心缓存层、中心数据机房，3层结构部署，前端智能DNS调度用户到该用户访问最快的节点，地方缓存节点会保持连接2个核心缓存机房做负载均衡及相互备用，避免单路网络问题，核心缓存机房通过多条线路互备到数据机房读取文件。
#Technique
- Lanuage: C、PHP、Erlang、Python
- Tools: Nginx、GraphicsMagick、MySQL、Memcached、Hadoop、Redis、Squid、Heartbeat、IPVS BIND
# Security
- 文件操作接口和文件读取接口（只读，无操作权限）分离，客户网站用户只能访问读取接口，文件操作接口只对客户开放，需凭客户密钥授权操作。并且，文件读取接口可以单独设置关闭。
- 帐号系统分离，空间管理员可设多个操作员帐号给不同部门或项目组的人员，并且权限分离，空间管理员只有空间设置权限，无文件操作权限。操作员只有授权空间的文件操作权限，无空间设置权限。最大程度分离帐号的权限。
- 很多网站会允许用户浏览处理过的缩略图，但不允许或需要授权用户才能下载此图片的原图，又拍云存储有原图Secret功能，每个图片原图都可以设置Secret key。
- Token防盗链，用户可以给每个Url生成Token签名，也就是只有获得网站允许授权的用户才能访问这个图片，并且该授权还可以设置过期时间，精确到秒。
# Performance
- 不同于传统CDN服务源站在各地各个机房，又拍云存储源站分布在CDN网络核心机房，在回源这条回路上做了最大优化，保证快速读取。
- 国内网络环境非常复杂，今天通畅的网络没法保证明天还是这么通畅，为了适应复杂的网络变化，又拍云存储有专门的技术人员，结合自身及第3方的各地速度监控系统，不断更新速度表格，将用户优化到访问最快的机房。
- 每个缓存节点投入更多的资源，目前所有节点的部署的缓存容量规模均在10T以上，保障客户文件能长期缓存在各地节点。
- 缓存节点机房服务器集群做LVS4层负载，7层Nginx进行一致性Hash提高缓存命中率，冷热文件调度将热门文件调度到SSD存储。
- 开发者可采用直传API，让用户通过云存储网络直接上传到云存储，而不需要经过用户服务器，存储速度更快。
# Messaging System
- 目前又拍的消息系统规模不算太大，每天由5个节点处理大约500万条消息。
- 目前Erlang与工作进程（主要由Python开发）是通过Erlang的内置序列化方式BERT进行通信的，与PHP则是通过JSON-RPC通信 的。
除了这两种方式，打算加入更多的外部通信协议，比如msgpack，protobuf 等等。
- 之前基于RabbitMQ
在2009年选择RabbitMQ，当时网站架构在做比较大的变迁以减轻对Java体系的依赖， 而开源消息队列中比较有名的Apache ActiveMQ是基于Java的实现，显得太厚重，而被排除在考虑之外。
另外，那个时候ZMQ还没推出。没有具体了解过ZMQ，以目前地认识来 看，我认为它们之间也存在很大的差异。例如RabbitMQ比较完整的实现了AMQP协议，而ZMQ则提供了简单的接口，相比之下，前者显然比后者偏重。 如果是比较性能，ZMQ会胜出是无庸置疑。后面我们会对ZMQ作进一步了解，因为它可能能和YPTask有一个很好的结合。
目前也没有再使用 RabbitMQ。
- YPTask
YPTask和RabbitMQ没有任何关系，实际上YPTask并不是消息系统，确切地讲应该是一个基于消息的远程方法调用系统。
YPTask是基于 Erlang的OTP实现的，本身就是一个很健壮的分布式系统。它具备管理、配置外部工作进程的功能，而简化了消息队列地实现。外部工作进程不是通过网络 接口与YPTask通信的，而是通过标准输入/输出。所以理论上后端的工作进程可以用任何语言实现，只要它支持Erlang的序列化方式BERT。事实 上，BERT的其它语言实现已经非常丰富。更重要的是，YPTask作为一个中间层次的系统，把大多数的配置和管理工作统一起来，极大地减少了业务代码需 要处理的事，使得业务逻辑的开发和管理都变得很简单。
# References
http://www.infoq.com/cn/news/2012/05/upyun-techinfo
http://www.infoq.com/cn/news/2011/12/youpai-zhaozhongqiu