网易分布式存储项目 Curve 专访：凭什么比 Ceph 提升 84%？

来自：开源中国 原链接：https://www.oschina.net/question/4487475_2317932

大数据时代，分布式存储凭借其较低的拥有成本、灵活的扩展能力、线性增长的性能、统一的资源池管理等诸多先天优势，逐步替代了传统的网络存储，成为越来越多的互联网企业用于有效处理海量业务数据的利器。 

在开源领域，目前比较主流的开源分布式存储系统无疑是 Linux 基金会旗下的 Ceph。而近日，网易宣布开源一款名为 Curve 的分布式存储系统，从官方公布的性能测试结果来看，Curve 的性能相比 Ceph 提升了 84% ，引起了国内外开源爱好者的关注。

为深入了解 Curve 项目的具体情况，包括其与主流开源分布式存储系统（特别是 Ceph） 的差异，开源中国第一时间邀请到了 Curve 项目负责人、网易数帆轻舟业务部总经理陈谔，与我们分享了 Curve 项目的诞生历程以及项目团队对于开源模式的看法。

Curve 的诞生

7 月 16 日，网易基础软件团队网易数帆宣布开源分布式存储系统 Curve。据介绍，Curve 的定位是一个面向块存储、对象存储、云原生数据库等不同应用场景的分布式存储系统，这与 Ceph 的定位非常相似。既然市面上已经有像 Ceph 这样较为成熟的开源项目，为什么网易的技术团队还要选择自己造一个新项目呢？面对我们的疑问，陈谔向我们介绍了 Curve 的诞生契机。

其实网易也是多年的 Ceph 重度使用者，但在使用和维护 Ceph 的过程中，网易的技术团队发现了一些 Ceph 也难以解决的问题。“ 首先在一些性能、延迟敏感的应用场景下，Ceph 的 tail latency 起伏较大，经常受到业务开发人员的抱怨。更严重的是因为 Ceph 需要完成所有副本的写入才能返回，这样在出现慢盘等不是快速失败的情况下，就造成大量请求的延迟大幅增加，从而对上层业务的稳定性带来明显的影响。” 陈谔说，“其次在运维方面，Ceph 也比较复杂，比如运行一段时间后容易产生数据分布不均匀的问题，就需要人工介入调整。” 

陈谔认为，造成以上问题的原因是由 Ceph 的一些基本设计（如元数据管理、一致性协议等）决定的，要解决这些问题就必须在 Ceph 原本的基础上去改进，这样做的代价会非常大，所以网易内部决定通过自研来解决这些问题，于是就诞生了现在的 Curve 。

Curve VS Ceph

此前，网易曾公布了 Curve 和 Ceph L 版本的测试数据对比：在单卷的场景下，核心的 4K 随机读/写的 IOPS 性能方面，Curve 分别是 Ceph 的 1.84 倍和 1.58 倍，同时延迟相比 Ceph 分别降低 48.39% 和 37.50% 。这样的提升效果确实非常可观，那么 Curve 具体在哪些方面做了改进或优化，才使得其性能超过 Ceph 呢 ？

 

陈谔介绍，首先 Curve 采用 Raft 作为一致性协议，多数副本 commit 就能返回，因此延迟特性就比 Ceph 更好。其次，Curve 的 IO 处理路径相对 Ceph 有所优化，实现的较为轻量。与此同时，Curve 开始研发时已经有了类似 brpc、braft 这样高质量的开源基础组件，起点相对 10 年前的 Ceph 来说自然也就更高了。 

此前网易曾透露，Curve 目前还有一些创新的性能优化工作尚未完成，如细粒度哈希、io_uring 落盘方案等，预计接下来性能还能提升 30% 。陈谔说：“ 主要的性能优化的工作在今年内基本都会完成。Curve 在实现过程中迭代较快，不仅是要考虑一些比较明确的优化点，更多的是要能够跟踪工程实现过程中引入的性能回归或一些细节实现的合理性问题。我们目前的计划是会先进行一轮全链路的性能分析，来发现 IO 路径上需要进一步优化或修正的点。我们希望除了承诺的 30% 提升之外还能带来更多的惊喜。” 

除了性能优于 Ceph 以外，陈谔还介绍了 Curve 与 Ceph 其他方面的对比优势，“ 与 Ceph 相比，Curve 代码可读性更好，更易维护、复杂性更低（一定程度来来自于设计方面的选择，例如选择有中心 Master 的设计）。此外，Curve 的运维代价更低，例如 Curve 支持自动化的在线rebalance，能做到基本不影响业务。后续我们会在 Curve 的设计、代码层面作出更多的解读，来说明 Curve 在可维护性、易运维性方面的考虑。” 以下是 Curve 与包括 Ceph 在内的市面上其他开源分布式存储系统的对比：

当然，作为一个成长中的开源项目，Curve 的成熟度暂时还不及 Ceph，陈谔坦言，“ Curve 目前并不是一个大而全的统一存储产品，当前仅支持块存储场景。” 

网易的存储技术栈

如陈谔所说，目前网易已经基于 Curve 实现了高性能块存储系统，并且在实际生产环境中已经上线 400 多天，尚未出现数据不一致或丢数据的情况，也没有发生过重大故障，证明了 Curve 在块存储领域已经具备了相当的可靠性和成熟度。那么网易除了块存储以外的其他存储系统采用的是什么技术呢？这些技术又是否会在将来被 Curve 取代？ 

陈谔向我们透露了目前网易在存储方面的技术栈构成，“ 除了块存储场景，网易主要还在对象存储场景使用 NOS 系统，在具有统一存储需求且对性能延迟不敏感的场景使用 Ceph 存储系统，在大数据场景使用 HDFS 系统。其中 NOS 是网易杭州研究院从 2006 年就开始自主研发的对象存储系统，Curve 的研发团队正是来自于 NOS 的长期沉淀。” 

谈到 Curve 未来是否会应用到网易的对象存储和大数据存储场景中时，陈谔表示，“ 对象存储和大数据这两类场景对延迟的要求不高，因此把这些功能在 Curve 上重新开发一遍回报不高。但业界很多企业有大量的文件存储，这里可能也有 Curve 的适用场景。Curve 本身并未限定应用的场景，它是一个很好的基础的分布式文件系统，有比较完善的接口能支持上层开发。”

网易眼中的开源

如今，开源模式已经成为席卷全球软件开发行业的浪潮，越来越多的国内外互联网巨头开始拥抱开源。作为一家国内知名的互联网公司，网易对开源社区的贡献也不在少数。我们请陈谔谈了谈他的团队对于开源模式的看法。

陈谔表示，团队之所以选择把项目开源，首先是希望 Curve 在迭代演进的道路上能够经历更多场景的应用、测试并获得反馈，他们认为开源就是一个非常好的方式。像 Ceph 这样复杂的系统能在长期演进的道路上保持稳定性，开源带来的大量应用反馈是不可或缺的。 

其次 Curve 核心是一个通用的分布式文件系统，开源社区能够基于这个底座开发出更多的上层存储服务，覆盖更多的场景。“单在网易自身我们可能今天看不到一些场景，明天需求来了也来不及反应，满足不了需求软件的生命力也就不会很长久。” 陈谔说道。 

最后，在网易数帆 2B 业务发展道路上，推进云原生技术栈的落地应用是网易重要的战略，“我们要为客户提供基于云原生技术栈的云 OS，而其中很重要的一个基础是推进 IT 架构的存算分离，开源 Curve 也可看成是我们推动云原生 OS 所做的一个努力。” 

尽管这是 Curve 团队第一次主导大型开源项目的维护，陈谔仍然表达了自己对于维护好 Curve 项目的信心：“Curve 团队主导开源项目的经验不多，这也是我们目前在尽力去学习要补课的地方，我们一定会尽力维护好这个项目，对得起‘网易出品，必属精品’ 的招牌。”

从 Curve 社区目前的建设情况来看，项目维护团队也收获了不少开发者提交的非常有意义的反馈。

“ Curve 的用户群内讨论比较热烈，线上用户群已有三百多人，目前在编译、安装部署环节获得了较多的反馈，使 Curve 能适配更多的 OS，编译器、软件库的环境。另外我们计划尽快发布一份如何参与代码贡献的指南，并给出对贡献者的支持方案。”

关于未来

最后，陈谔向我们介绍了 Curve 项目以及网易技术团队接下来的工作规划。

“Curve 接下来的版本周期大约是大版本 6 个月，小版本 1-2 个月的节奏，9 月会发布第一个社区稳定版本。今年 Curve 的主要规划是继续性能优化，以及在安装部署、维护的便利性、文档的完善程度方面进行优化。” 

未来网易的团队会更多关注对云原生数据库、容器有状态服务、存储 cache 层（配合后端 EC 存储综合获得较好的单位成本性能收益）等方面的支持和演进。

关于 Curve 项目的运营规划，陈谔还透露了一个重磅信息：“我们希望后续能够有机会把项目捐赠给相关开源基金会来进行管理。”

嘉宾介绍

 

陈谔，网易数帆轻舟业务部总经理，网易杭州研究院的元老之一、网易云计算基础服务的领军人。