随着京东业务的发展，数据规模越来越大。开源平台如Hadoop可以满足离线大数据的存储与处理。然而，对内基础平台与对外云服务需要更加多样的存储抽象和不同的存储产品。当前面临的需求场景可以概括为几类：

1.公司内部的在线小文件存储。例如商品图片、交易订单、库房订单等数据。这些文件大小通常为几KB或几十KB，每天新增几千万条。这些数据对公司非常重要，语义上要求非常强的可靠性与一致性。

2.面向公有云的对象存储服务。我们面向京东的合作伙伴、第三方开发者等客户提供类似Amazon S3与Google Cloud Storage的对象存储服务。

3.针对虚拟机的持久块设备存储服务。无论私有云还是公有云的虚拟机实例，均需持久磁盘的存储抽象。同行的相关工作包括AWS的Elastic Block Store与Google Cloud的Persistent Disks.

面对多样的存储需求，京东云平台的愿景是：“One team, one storage infrastructure.”于是京东组建了一支团队，正致力于自主研发统一的数据中心存储基础架构，提供多种存储抽象，有效满足上述三类实际业务需求。

分别对应第一节所述三类业务需求，京东云存储平台向上实现了三类使用抽象：Private Client Libraries, Public RESTful API, Block Storage Abstraction. 后两类的功能定义与业界相关产品非常类似，因此本文仅介绍第一种。

针对公司线上服务，京东提供了私有云客户端开发库，其抽象方式为Container/Key/File。其中Container为命名空间的单位，通常对应用于一个使用实例或者业务单元，整个集群支持上亿个Container。在一个Container内部，由Key映射至File，Key数目没有上限，File大小也没有限制 – 可以从几个Byte到1TB。另外，Key可以由用户给定或者由存储系统自己生成;File除了支持创建、删除、读取、替换等操作外，还支持Append即追加操作，这对大文件上传是非常方便的。

京东云存储平台采用的技术策略是：统一的系统架构，不同的复制协议与存储引擎。

具体而言，对于系统元数据管理、小文件存储、大文件存储、定长块设备文件存储，京东有针对性地利用访问模式并实现不同的底层存储引擎与复制协议，以做到系统性能、可靠性、一致性、易维护性等多方面因素之间的最优权衡。

以公司内部在线小文件存储为例。无论商品图片、交易订单、库房订单，这些电商数据需要非常强的可靠性，可用性，与一致性。常见开源分布式系统所采用的最终一致性(Eventual Consistency)是无法被公司内部服务所接受的。因此京东在CAP定理中选择C+A，即通过非常强的复制协议来实现存储一致性与可用性，牺牲了对网络划分(Network Partition)的容忍。一方面，Network Partition在单个数据中心里面并不常发生;即使发生，前台的在线服务已经受到影响，可以接受此时存储系统出现“写操作不可用”。

京东采用了小团队作战，各个子系统并行开发并快速迭代的工程方式。整个系统主要采用Go与C编程语言来开发，其中C负责底层存储引擎开发，Go负责整体的系统框架实现。

大规模存储系统的思考：拿来主义还是自主研发？很多公司，尤其是到了一定规模之后的互联网公司都会面临一个问题：是使用开源软件还是自主研发分布式存储?我们建议视情况而定。如果数据规模很大且重要性极高，需求强烈且明确，那么自主研发的成本是完全可以接受的。另外一方面，要尽可能让一个团队开发统一存储平台来满足多样性需求，而非多个团队并行研发多个产品，这从技术团队打造与系统长期优化的角度都是性价比最高的选择。