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技术，按我们公司的服务层次划分，这次的分享主题是我们在云存储系统的研发和构建过程中遇到的一些问题和经验。希望大家能通过我们这次的分享，对云存储能有更深入的了解，比如分布式算法、存储结构和日常维护等等。