UPYUN：用 Erlang 开发的对象存储系统

在国内的几家云计算创业公司当中，UPYUN（又拍云）选择了一个比较独特的定位：面向开发者提供非结构化数据云存储服务。非结构化数据存储服务一个很重要的卖点是要提供快速的静态文件访问能力，这对底层的存储系统性能和上层的 CDN 系统提出了较高的要求。

黄慧攀（@oneoo）是 UPYUN 技术总监。在QCon 上海 2013 大会上，黄慧攀介绍了UPYUN 的 CDN 系统架构，包括 Nginx 的二次开发经验、防盗链服务的实现、海量小文件的性能处理等；在QCon 北京 2014 大会上，他将对 UPYUN 底层的对象存储系统的研发经验进行分享。

在本次采访中，黄慧攀介绍了 UPYUN 对象存储系统的一些历史，团队的分工，以及做测试方面的一些思路。

InfoQ：先介绍一下你自己吧。你关于计算机的知识都是自学，从底层网络、操作系统到上层的 Java、PHP 都玩，Lua 也玩。你对技术的选择有什么标准吗？如果有，是怎样的标准？

黄慧攀：我是出身于广东一个小城市“鹤山”人，最早是在 95 年接触电脑，98 年开始使用互联网，那时网易还只是做邮箱服务的，我非常感谢我的初中母校，使我能这么早期接触到互联网，影响一生 :) 也因为当年电脑、互联网才刚刚起步，学校也缺乏较好的教育能力，所以很多知识需要自学。也因为这个兴趣太浓，搞得其他学科基本都挂科了，也就没考上高中和大学。到现在还是有点小后悔，起码得把英文学好。

2001 年，18 岁的我第一份工作是市里一个集团公司的 B2B 门户网站，负责程序开发工作。那时用的语言是 PHP，边学边做的折腾了 3 年时间。

2004 年，项目因为市场、资金的原因结束了。在我们的小城市互联网就业机会基本为零，只好转到一个做弱电工程的公司任技术工程师，负责网络系统方案设计、智能灯光系统等等。

2006 年，压抑不住互联网的心，就出来创办 yo2.cn 优博网，国内第一个基于 WordPress 的博客服务平台，这个创业经历使我的技术能力提升很大，因为没人嘛，所以整个网站的事情都得自己做，开发、运维、客服，甚至设计等等。记得当时网站被人吐槽最多的就是用户体验，我想如果能把这块也做好，可以做 UED 了，哈哈。

2009 年，机缘巧合来到杭州，跟朋友做了几次创业，虽然也是失败告终，但在其中的过程使自己成长了很多，因为创业嘛，所以很多事情都必须自己做的，这就奠定了我的技术层面比较广的基础。

2011 年，收到又拍网的邀请，开始又拍云的开发工作至今。

经历这么多年和多次创业，积累到比较丰富的技术经验。知识比较全面，在看待技术选型方面的把握还是比较准的。比如：Java 的优点是适合大型项目、团队协作开发，缺点也很明显，开发周期长、人员成本相对 PHP 高一些；而 PHP 的优点则是适合中小型项目、开发周期短、人员成本低，当然弊端也很明显，不支持多线程、系统资源占用高。每个语言都有自己的优缺点，要根据项目实际情况来选择。后来一个偶然的机会接触到 Lua 语言，发现它跟 PHP 很像，但又没了 PHP 几个大缺点，非常棒。所以现在我主要使用 C 和 Lua 这两个开发语言。

InfoQ：你自己做过博客平台，也在企业网站、网游等网站做过，现在在 UPYUN，可以说是从面向消费者的.com 公司转移到了一个更加基础一些的服务。你觉得在 UPYUN 做的事情跟以前有什么不一样吗？

黄慧攀：我觉得做 UPYUN 这件事，是之前几个项目的升华吧。因为这些面向消费者的项目让我知道在开发过程中产生的痛点，从而挖掘出开发者的需求。我很高兴能为开发者服务，帮助大家更快的把项目做好。

InfoQ：能不能简单介绍一下 UPYUN 这套对象存储系统的研发历程？比如是什么时候开始做的，最初的设计者是什么背景，借鉴过哪些思路，研发的过程中有没有什么好玩的故事等等。

黄慧攀：UPYUN 的对象存储系统其实早在 08 年就开始设计的，当初用的是 MogileFS，为又拍网服务。因为早期的 MogileFS 的设计本身有一定限制，tracker 角色的元信息使用单个 MySQL 实例存储，无法满足我们日益增长的存储量，所以在 2010 年转为使用 Erlang 语言开发。设计目标是提供 PB 级别的存储服务，经历 1 年多的业务测试才正式对外开放存储服务。

选择 Erlang 语言进行开发，主要是语言本身就支持分布式，这可以节省很多开发工作。且 Erlang 语言在电信行业的应用非常广泛，稳定性有保障。

在分布式算法的选型上是参考 Dynamo 方案。而在具体的数据存储结构方面则是自主研发的一致性哈希算法，以实现多机柜、多服务器和多磁盘之间的数据备份工作。做到每文件的对应备份点在不同机柜、不同服务器上，避免某台服务器甚至某个机柜的服务器宕机而影响到文件的读写操作。

至于测试周期长达 1 年多，是因我们本身又拍网（照片社区）的数据量就非常庞大，从老的 MogileFS 集群迁移到新的云存储服务器占大部分时间，另外是因分布式存储服务的容灾测试过程比起应用测试要漫长得多，主要的测试点会有：某磁盘故障、某服务器故障、某机柜故障等好几种灾难测试，且每个故障都会产生一定量的数据迁移，文件会在集群内部自动寻找合适的备份点再建备份，所以说测试周期需要很长时间。也只有做到充分的测试，我们才放心的在集群上存储大量数据。否则等遇到无法排除的问题，要考虑新建集群的话，迁移成本和周期都会非常巨大。比如 10PB 的数据要从 A 集群迁移到 N 集群，网络传输就要 100pb，基于 10gb 网络也得耗时半年；且要保障迁移期间内不再发生新故障，这是很难做到的。所以我们选择前期测试做得非常充分，来保障日后服务的可持续性。

InfoQ：又拍云专注于做图片的存储，你们提供了一些很有特色的服务（如缩略图、防盗链），同时非常专注于服务质量。相对于文件备份类的应用场景，海量小图片存储是非常吃资源的，你们在存储系统的设计上做了哪些工作以确保在资源占用高的情况下仍然能保持图片访问的服务质量？

黄慧攀：是的，UPYUN 主要面向小于 100MB 的小文件提供服务，目前我们的存储集群已存有超过 2PB 的数据。面向海量小文件所面临的主要问题是：随机读取非常高、磁盘性能低；大家都知道缓存系统可以解决这类问题，而 CDN 其实就是个巨大的缓存系统，所以我们自建了 CDN 并对外提供服务。不仅能解决海量小文件所产生的磁盘性能问题，还能加速文件在互联网上的传输，一举两得。

InfoQ：UPYUN 系统的测试是如何做的？

黄慧攀：我们团队还比较小，目前未专门设立测试部门，所有测试工作均由项目开发者来完成，毕竟开发人员更清楚会有哪些潜在问题，并制定自动化测试的样例。下面是我们一个项目的开发、测试与发布流程：

1. 项目策划、文档和方案撰写
2. 开发（过程中会有两名以上开发人员交叉 review）
3. 本地测试（主要测试该项目的功能是否正常和程序稳定性、资源占用率等等）
4. 模拟平台测试（主要测试该项目的功能上线是否对原平台上其他子系统产生不良影响，这里会有我们自己编写的一批批量测试脚本，以验证平台每项功能逻辑是否正确）
5. 灰度测试（业务环境中抽取 1% 的服务器更新或指定某个别客户可使用该功能来进行测试）
6. 全网发布

从整个流程来看，我们的测试周期是比较长的，测试工作占整个项目周期 50% 以上，甚至个别影响范围大的项目，测试周期会长达半年以上。

InfoQ：你们的团队是怎样分工的？研发跟产品运营、系统运维的同学又是如何沟通的？

黄慧攀：大家从我们的产品介绍上会知道我们主要提供 3 块服务，

1. 云存储
2. 云分发
3. 云处理

所以我们的开发团队主要是根据这 3 个方向进行分组。现在我们团队分应用开发组和核心研发组，而在核心研发组中又分存储、分发、处理 3 个小组，分得比较细。因此我们的小组成员之间会有交叉分工，以便大家对整体系统能有充分的了解。

我们的产品服务与一般互联网服务不太一样，我们是以产品为主导而非运营主导，且我们的产品经理也是开发出身的，所以在与开发团队的协作沟通上不会存在什么问题。另外的运维部门则是更加紧密，因我们正在开始整个平台的自动化运维系统开发，我们的开发人员已走到一线，跟运维人员一起探讨运维自动化系统的功能性问题，开发人员能亲身了解运维工作和痛点，并以此来驱动运维自动化系统的开发工作。

InfoQ：这次 QCon 北京，你希望面向哪些人群进行分享？他们能从你的分享中获得什么？

黄慧攀：很感谢 QCon 能让我们来继续跟大家做些云计算方面的分享。在上一次的 QCon 上海大会我跟大家分享了又拍云的 CDN 技术，按我们公司的服务层次划分，这次的分享主题是我们在云存储系统的研发和构建过程中遇到的一些问题和经验。希望大家能通过我们这次的分享，对云存储能有更深入的了解，比如分布式算法、存储结构和日常维护等等。