分布式对象存储Ambry - 官方博客翻译与摘录（1）背景介绍

原文地址 在当今互联网时代，多媒体内容越来越普遍。资料照片，邮件附件，微博博客等是常见的多媒体文件（例如图片，视频，PDF等等）的展示形式。用户上传这些文件至服务器，服务器保存这些文件至后台存储系统并且通过CDN（Content Delivery Network）来分发这些文件并展示在网站上。 随着Linkin业务量的增长，传统的后台存储系统暴露了很多在扩展性，可用性和易操作性上的问题。两年前，我们回顾了我们之前用的技术，并着手于优化改造，Ambry就是之后的成果。从我们在2014年开始分享关于Ambry这个内部项目的数据开始，Ambry在网络延迟和传输效率上有了长足的进步。并且， 在我们给一些公司做了相关的展示后，他们对Ambry展示了极大的兴趣，并想将Ambry最为他们的后台存储系统。 今天，我们宣布Ambry开源（Apache 2.0 协议）。Ambry适用于存储多媒体对象并且提供多媒体服务。多媒体内容对于任何一个网站在提高用户交互品质，提升用户体验上都是至关重要的。未来会有更多的公司投入到多媒体渠道中，尤其是随着视频技术和VR的发展。在这种趋势下，Ambry将扮演一个至关重要的角色。 Ambry是一个分布式不可变高可用对象存储系统，并且可容易扩展。 Ambry适用于存储从几KB到几GB的多媒体对象，并能保证高吞吐量以及低延迟。他也能实现从客户端到存储层端到端的直接通信，反之亦可。系统可以跨机房多活热部署，并且能提供非常廉价的存储。 我们发现没有现成的开源解决方案能满足我们对于水平扩展性，可用性和多活数据中心配置的需求。我们找到的分布式文件系统对于小对象的处理并不是很好，并且为了一致性牺牲了可用性，没有关注于实时应用并且难以操作维护。有一些对象存储解决方案，但是大部分不成熟，不适用于不同大小的对象存储，而且在性能上没有达到我们对于实时传输的要求。我们相信Ambry达到了我们各方面的需求并且在未来可以成为建设多媒体通道的核心。 在本文中，我们将回顾我们之前的设计和局限，深入探讨我们如何设计，构造和部署Linkin的多媒体生态系统Ambry，并会提到未来的规划。

在2013年的多媒体存储

LinkIn之前用的系统叫做“多媒体服务器”（没有起名字。。。）。，包括多媒体对象存储的文件系统和一个Oracle数据库（用来保存元信息）。系统前台是一些无状态运行着SOLARIS 系统的机器，将客户端的请求转发到对应的后台文件系统或者数据库。文件系统是挂载在这些无状态机器上的NFS（Network File System），通过远程的Java File API访问。系统前台还设置有缓存，为了确保低延迟和防止性能问题和下游系统问题（文件系统/数据库）造成的服务运行中断。

随着在LinkIn需求量的增长，这个系统对于我们有比较严重的限制。我们因为如下的原因决定替换掉它：

• 频繁的可用性问题：原有系统在每次面对对于元数据操作增长时会出现延迟波峰。这种增长一般是因为有很多的小文件被访问了。每次的文件操作都会涉及几层之间的传输（Java, NFS, Filers等）并且是Debug极为困难。我们由于经常性的运行中断所以不得不加一层缓存来减轻影响。
• 扩容困难：底层系统是单一性的存储，水平扩容基本是不可能的，而且每次扩容，都需要手工移动很多数据。
• 低效率的小对象-大对象支持：在我们当时的数据集中包含大约数万亿的小对象（50KB-1MB）还有数十亿的大对象（1MB-1GB），对于数万亿小对象元数据的操作的耗费是非常惊人的。同时，原有系统没有提供任何针对大对象端到端流的通信，对于提出与设计新应用是个局限。
• 很差的MTTR（Mean time to repair）：原有系统大部分是黑盒，这需要我们必须随时在线定位解决线上问题。这很影响我们的MTTR，有时候我们需要几天时间来解决一个问题。如果没有对于系统很深的理解，Debug很难。获取衡量指标同样很困难，因为我们被限制在黑盒提供的指标中。
• 成本昂贵：随着系统规模的增大，成本越来越高，我们如果想要继续扩容的话，必须放弃原有系统来控制成本。

这些原因使我们坚信，我们必须寻找一个更好的方法。我们将它当做一个比较不同端到端解决方案的机会。我们比较了分布式文件系统解决方案，存储设备解决方案，云方案还有内部解决方案。我们比较了每种方案的优缺点，结合我们的需求，确定要做一个内部方案来更好地使用与我们的需求。