团队邀请又拍云团队CTO（黄慧攀）& COO（沈志华） 来公司进行一次交流。主要涉及到CDN、云存储、以及未来的工作方向相关的讨论，以下简单纪录一些point。

1 存储

  • 1.1 数据

又拍云的数据量大概在5个P的样子，跟我们网易云存储差不多在一个规模，我们大概逻辑存储量在1.5P左右的样子，物理存储量在3.5P的样子。ps:CDN是其核心业务，存储并不是。

  • 1.2 技术

    • 存储引擎

      又拍云从2010开始到现在底层存储系统经过几次的技术选型，刚开始是mongofs,到ceph，以及当前自己的分布式文件系统。当前mongofs基本已经淘汰，而ceph和其自研的存储系统都可能还都在使用，当前是主要启用自研的文件系统，ceph中不再新增加新数据。

* EC

又拍当前没有用EC，基本采用三备份方式，在启用灾备份情况下就是6倍分，这主要跟他们自己产品的卖点跟成本上考虑有关。因为存储成本相对于流量成本相对比较小，而且本身接业务的时候会主要偏向于接流量型的业务(😄，主要还是靠CDN赚钱)，而并不是大量冷数据，访问很少的业务。

* 存储架构

一般对象存储会选择将对象元信息和对象数据分别保存到不同的系统里面，对象元信息可以选择存放在关系型数据库，而对象数据存储于底层其他kv存储引擎。而##又拍##选择了将对象元信息和对象一起存放(meta文件)，都存放在存储引擎的方式，距离如下图所示。

storagearch.jpg

这两种方式各有各的优缺点
统一存储：统一设计考虑数据和元数据高可用，高可靠，分布式策略,相比数据元数据大的小往往是比较小的，所以相比而言元数据会得到非常好的分布特性，元数据不易成为瓶颈。但是在应用灵活性方面相对会比较差。

分离存储：需要分别考虑设计元数据系统和数据系统，（ps：统一使用同一套存储引擎，元数据数据还是还是分离的方法还是另说）,并且一般来说元数据是比较集中的，所以机遇元数据的操作和方案设计相对会比较简单，比如统计、标记删除过期清理等等。

  • 1.3 其他

    对##机房存储容量## 的问题进行了一次讨论，我们云存储团队在2014年由于机房容量的问题做过一次存储机器的整体搬迁（ps：需要做同城物理运输），存储系统架构对副本数据的设计是比较集中的，所以搬迁过程还算比较简单，以副本为单位进行搬迁。但是对运维来说还是存在不少的挑战，因为设计的时候并没有考虑到机房搬迁等运维事务。而跟又拍云交流过程中，我们也找到了另外一种思路。

    一般来说，就云存储而言，应该会基于当前的存储容量和增长趋势做容量规划，比如机房够用1～2年，那么在机房资源紧张的情况下，启用新的机房，针对几个量比较大的产品，要求使换一个桶，使用另外一个新机房的存储空间（bucket）。

2 CDN

CDN当前是又拍业务的核心、计算图片处理，视频处理非核心；应该说与七牛云存储是不同的发展方向，七牛是围绕数据做计算，但是，CDN是外包的，其核心是存储＋数据计算。

  • 2.1 points

以下为一些关键技术点。

  1. 130多个边缘区域，10多个二级区域，3级就是又拍的存储机房，服务器大概几千台。
  2. 二级节点主要选择的是一些多线(BGP)的资源，因为会牵涉到不同线的用户源站。
  3. 评估选点三级区域节点选择相对比较简单，利用听云等服务商测量服务器ping值等信息，进而选择相对优秀的节点。
  4. IP库选择，目前使用的是IPIP的付费IP库。
  5. 可用带宽大概子1T。
  6. 三级节点到二级节点的路由是自动选择的。
  7. 上传加速依赖于同一套系统，通过边缘节点进行流式代理。
  8. 在CDN当前这种日趋白热化的竞争状态下，又拍表示还是有一定利润空间的。
  9. CDN的防攻击，针对CDN的攻击，攻击几个点是比较容易的，但是攻击整个CDN事比较困难的，(ps:CloudFlare CDN技术支持AnyCast协议可以使得CDN攻击流量分散到所有节点而大大提升抗攻击能力）
  10. 又拍CDN团队大概是10多号人，存储团队5个人，阿里云CDN团队30多号人.

-

  • 2.2 整体架构

其实又拍云的架构跟Facebook的图片系统还是比较类似的，中心机房之前其实有一套ATS通用缓存，一来是作为缩略图的缓存，另外由于支持多机房策略，Origin会从别的storage机房获取数据，缓存有利于较少跨机房的数据复制(Ps:由于前两层CDN缓存，一般到请求到origin的请求量相对较少，命中率相对比较低了，20%左右)

storagearch.jpg

  • 2.3 其他

CDN技术应该算现在都已经算是比较完善的技术了。所以又拍的技术团队也在思考能不能基于CDN做更多的差异化和创新。正在酝酿基于CDN做分布式区域服务，比如抢红包业务，可以将红包服务分散到各个区域的边缘节点。当然这个服务需要一定的技术支持，当前就这种服务形态也在做技术选型。一种是当前比较火的docker技术，另一种是希望构建语言级别的虚拟机（类似于SAE？）。个人认为docker容器技术对于人家的应用场景相对还是比较重，所以选择后者可能更佳合适。

This article used CC-BY-SA-4.0 license, please follow it.