# 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