日前，LinkedIn 在Github 上基于 Apache 2 许可证协议开源了其分布式对象存储系统Ambry。Ambry 是一个是不可变对象的存储系统，非常易于扩展，它能够存储KB 到GB 大小的不可变对象，并且能够实现高吞吐和低延迟，该系统支持跨数据中心的双活部署，并且存储成本低廉。它特别适于存储各种媒体内容。
据Linkedin 的前工程主管Sriram Subramanian介绍，媒体内容在 Web 中已经无处不在，Linkedin 中的每项新特性基本上都会与某种类型的媒体内容进行交互。这些媒体内容会存储在后端，并且主要会由内容分发网络（Content Delivery Networks，CDN）来提供服务，后台存储系统会作为 CDN 的原始服务器（origin server）。
随着 Linkedin 流量的不断增长，原来所使用的媒体内容存储方案在可扩展性、可用性以及运维方面所遇到的问题越来越多。两年前，他们着手解决这些问题，而 Ambry 正是该项工作的结果。
2013 年时的媒体存储是什么样的？
LinkedIn 之前的系统被称为媒体服务器（因为没有一个像样的名字），这个系统由两部分组成，分别是用于媒体文件存储的 Filer 以及存储元数据的大型 Oracle 数据库。这些系统的前端是一些运行在 SOLARIS 上的无状态机器，它们会将请求路由到对应的 Filer 或数据库上。Filer 是通过 NFS 的方式 mount 到无状态机器上的，并使用 Java 的 File API 进行远程访问。前端会与数据中心（DC）里面的一组缓存进行交互，从而保证如果下游系统（Filer/Oracle）出现性能问题或不可用时，前端不会受其影响。
随着 LinkedIn 对媒体内容的需求不断增加，原有的系统在面临这些需求时，遇到了如下严重的问题：
在这个过程中，Linkedin 探索过多种替代方案，最终还是决定自行实现更匹配其需求的解决方案。
Ambry 是如何运行呢？
设计目标
在了解 Ambry 的设计和内部运行原理之前，明确其设计目标是很有帮助的，这决定了它的实现方式。
概览
总体上来讲，Ambry 由三部分组成，分别是用来存储和检索数据的一组数据节点，路由请求的前端机器（请求会在一些预处理之后路由到数据节点上）以及协调和维护集群的集群管理器。数据节点会在不同节点之间复制数据，同时支持数据中心内部和数据中间之间的复制。前端提供了支持对象 PUT、GET 和 DELETE 操作的 HTTP API。另外，前端所使用的路由库也可以直接用在客户端中，从而实现更好的性能。在 LinkedIn，这些前端节点会作为 CDN 的原始服务器。
Ambry 提供了 REST API，它们适用于大多数的场景。在有些场景下，需要更好的性能，如果是这样的话，Ambry 也支持在客户端使用路由库，直接针对数据节点的流字节进行读取和写入。目前，路由库是阻塞的（同步），不过 Ambry 目前正在致力于实现非阻塞（异步）版本，同时也会提供对路由库的多语言支持。
Clustermap
Clustermap 控制拓扑结构、维护状态并帮助协调集群的操作。Clustermap 有两部分组成：
数据节点和前端服务器都能够访问 clustermap，并且会始终使用它们当前的视图来做出决策，这些决策涉及到选择可用的机器、过滤副本以及识别对象的位置等。
存储
存储节点会用来存放不同分区的副本。每个存储节点会有 N 块磁盘，副本会跨磁盘分布存储。这些副本的结构和管理都是相同的。
在存储方面，Ambry 涵盖的功能包括如下几个方面：
路由 / 前端
前端服务器提供了 HTTP 接口，供客户端与之通信。除此之外，它们还会负责为 CDN 设置正确的头信息、进行安全校验，并将对象以流的形式返回给路由库和客户端。
路由所负责的功能如下所示：
在路由中，典型的 PUT 和 GET 操作的流程分别如下所示，系统的实际运行过程会比下述的描述会更复杂一些：
解决运维的难题
分布式系统最困难的在于它的运维，在这个过程中，需要工具、度量并且要进行广泛地测试，从而保证所有的事情都能符合预期。在这个过程中，Ambry 积累了很多的工具和实践。
除此之外，Ambry 还实现了指标和告警工具，用来帮助识别系统中的异常行为以及维护集群的管理工具。
迁移工作是如何进行的？
团队需要将所有的媒体内容从遗留系统迁移至 Ambry，在这个过程中还要服务于所有的流量，不能出现任何的宕机时间。除此之外，团队还面临着多项 deadline，了解 Ambry 是如何组织研发和部署的，对我们会有一定的指导意义：
Ambry 团队采用了一种特殊的方式来达到这些里程碑节点。首先，构建前端并使用它来代理所有对旧系统的请求，然后再将所有的客户端迁移到新的前端上。这虽然费了很大的功夫，但是确保了第一个 deadline 目标的达成。
第二步是让 Ambry 能够以端到端的方式运行，并且只将其部署到新的数据中心上，然后将所有的数据从旧系统迁移至 Ambry。在代码中，添加了一定的逻辑，确保如果新数据中心发生故障的话，将会使用旧的系统。这可能会产生更多的延迟，但是团队决定承担这个风险。
在新数据中心搭建完成之后，在接下来的几个月里，团队不断运行并稳定 Ambry。基于测试和审计结果，当对新系统完全自信的时候，团队决定停掉遗留的系统。这样就在一年的 deadline 之内完成了目标。
Ambry 是如何适应 Linkedin 的生态系统的？
媒体基础设施是针对媒体内容的端到端管道，涉及到上传、存储、处理、元数据管理以及内容下载。在基础设施中，Ambry 是很重要的一个环节，基础的稳固是非常重要的。在 Ambry 就绪之后，就可以围绕着它进行扩展并关注生态系统中的其他组成部分。
下一步的研发计划
目前，Ambry 主要进行中的任务包括在前端和路由层实现非阻塞、存储节点实现机架感知等功能。团队希望不断地为 Ambry 添加新的特性，并且构建活跃的开源社区。完整的未来工作计划列表可以参见Github 上的相关页面，如下列出了当前正在进行的或者可能会开展的项目：
对于社区来讲，这个系统会有很大的用处，有助于支持媒体内容的实时上传和媒体服务的构建，详细的文档可以参见Github 上的相关页面。如果读者有反馈意见或有志于为该项目做出贡献的话，可以参考其开发指南。Ambry 团队希望该项目的开发能够保持开放的状态，并帮助社区使用它来构建应用程序。另外值得一提的是，2016 年度的SIGMOD（Special Interest Group on Management Of target="_blank">其网站了解更多信息。
查看英文原文 ：Introducing and Open Sourcing Ambry
感谢李建盛对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（，@丁晓昀），微信（微信号：InfoQChina）关注我们。
