分布式存储系统-Curve
2020-08-11 10:20:03 
阿炯
Curve是网易开源的高性能、高可用、高可靠分布式存储系统，具有非常良好的扩展性。基于该存储底座可以打造适用于不同应用场景的存储系统，如块存储、对象存储、云原生数据库等。其设计开发始终围绕三个理念：一是顺应当前存储硬件设施发展趋势，做到软硬件结合打造顶级的存储产品；二是秉持 “Simple Can be harder than complex”，了解问题本质情况下选择最简单的方案解决问题；三是拥抱开源，在充分调研的前提下使用优秀的开源项目组件，避免造轮子。
当前网易基于Curve已经实现了高性能块存储系统，支持快照克隆和恢复，支持 QEMU 虚拟机和物理机 NBD 设备两种挂载方式，在网易内部作为高性能云盘使用。其编码规范严格按照Google C++开源项目编码指南来进行代码编写采用Apache v2.0的协议授权。
Curve总体架构图：
Curve支持部署在私有云和公有云环境，也可以以混合云方式使用，私有云环境下的部署架构如下：
其中CurveFS共享文件存储系统可以弹性伸缩到公有云存储，可以为用户提供更大的容量弹性、更低的成本、更好的性能体验。
公有云环境下，用户可以部署CurveFS集群，用来替换云厂商提供的共享文件存储系统，并利用云盘进行加速，可极大的降低业务成本，其部署架构如下：
特性
1. 高性能
高性能是 Curve的一大特点，也是项目团队创建 Curve项目的初衷。RPC 层面 Curve采用了高性能和低延迟并且已开源的 brpc；在一致性层面选择了基于 quorum 机制并且开源的 braft，从协议层面来说 quorum 机制在延迟方面天生优于多副本强一致的方式。实现上 Curve对 braft 快照的实现进行了优化，在状态机的实现上采用 chunkfilepool 的方式 ( 初始化集群的时候格式化出指定比例的空间用作 chunk ) 使得底层的写入放大为 0；此外Curve还在 chunk 上进行更细力度的地址空间 hash 以达到读写分离、减小 IO 碰撞等的效果，从而进一步提升 IO 性能。
2. 高可用
高可用是 Curve的另一大特点。MDS、ChunkServer 以及 SnapShotCloneServer 都支持多实例部署，部分实例异常不影响整个集群的可用性。
MDS
MDS 是无状态的，推荐至少部署两个实例，通过 Etcd 进行选主。多个 MDS 实例通过 Etcd 进行选主，当单个实例失效时，可以秒级切换到另外一个实例。失效实例上正在处理的请求，Client 和 SnapShotCloneServer 都会对其进行重试，以达到不影响集群可用性的效果。
SnapShotCloneServer
它与 MDS 类似, 也是通过 Etcd 进行选主，不同的是，它通过负载均衡对外提供服务。失效期间的请求失败重试都是幂等的，不影响任务的正确性以及集群的可用性。
ChunkServer
它是一个集群，通过 Raft 协议保持数据一致性，并通过 MDS 做负载均衡。单个节点失效时，会影响到这个节点上存储的所有 Copyset。对于 Copyset 上的 Leader 节点，会中断服务，等待重新选举；对于Copyset 上的 follower 节点，服务不会受影响。当某个 Chunkserver 节点失效且在一段时间内无法恢复，MDS 会将其上的数据迁移到其他节点上。
Curve是网易数帆自主设计研发并开源的高性能、易运维、全场景支持的云原生软件定义存储系统。Curve于2020年7月正式开源，当前由CurveBS和CurveFS两个子项目构成，分别提供块存储和文件存储两种能力。Curve开源项目曾获评中国信通院 OSCAR 尖峰开源项目及开源社区，通过可信开源项目评估，并且Curve社区也是中国信通院牵头创立的可信开源共同体（TWOS）的首批正式成员。它是一款高性能、易运维、云原生的开源分布式存储系统 (CNCF Sandbox)。可应用于主流的云原生基础设施平台：对接 OpenStack 平台为云主机提供高性能块存储服务；对接 Kubernetes 为其提供 RWO、RWX 等类型的持久化存储卷；对接 PolarFS 作为云原生数据库的高性能存储底座，完美支持云原生数据库的存算分离架构。它亦可作为云存储中间件使用 S3 兼容的对象存储作为数据存储引擎，为公有云用户提供高性价比的共享文件存储。本节将介绍 Curve 块存储相关的部分，并分享 Curve 在一些场景的应用。
1、分布式存储介绍
1. 分布式存储的分类
首先简单介绍一下分布式存储的分类。分布式存储可以分为三类：对象存储、文件存储和块存储。对象存储在互联网中应用的比较多，比如一个对象、一个图片、一个音频，这种可以通过 PUT GET 接口来进行存储。文件存储与传统意义的文件系统的区别是，它是分布式的，传统的项目对应的是 Ext4，或者是 NTFS。块存储，就是所谓的云盘。
2. 分布式存储的要素
下面介绍一下分布式存储在设计时的一些要素。首先需要大容量的硬盘空间，并且可以随机写，还有最重要的是要保证服务的质量，数据不能丢失，还要保证它的可用性。
要素可以拆解为以下三方面：
①第一是高性能。在分布存储里面，存储节点会非常多，所以要知道数据存在什么位置以及如何去取。
②第二是可用性。要保证数据的可靠性，避免数据丢失，并且保证在机器故障时数据的读写是能够正常运行的。
③第三是可扩展性。如果容量用完了，可以新增机器扩展容量。
数据分布，主要有两种，一个是无中心节点，另一个是有中心节点。
另外一个比较重要的点是一致性协议。首先是 Ceph 的强一致性。在分布式系统中，一致性是指在多个副本之间保持数据一致。在 RADOS 中，数据被分割成多个对象，每个对象都有多个副本，这些副本分布在集群的不同节点上。当一个对象被修改时，Ceph 会确保所有的副本都被同时更新，从而保证了强一致性。第二是 Raft 算法，他只需要大多数副本保证更新完成就可以认为成功了。
2、Curve 架构及介绍
1. 项目介绍
关于 Curve，我们的愿景是希望打造一款性能比较好，适用多种场景的，并且是围绕开源的云原生分布式存储系统。目前 Curve 已经捐赠给 CNCF 基金会，并成为其生态系统中的一个项目。其提供块存储和文件存储两种方式，以满足不同应用的需求。对于 Curve 块存储，它具有快照克隆恢复功能，主要应用场景包括 OpenStack 云主机和 Kubernetes 持久存储卷。对于共享需求，Curve 提供文件存储；对于性能要求较高且无共享需求的场景，建议使用 Curve 块存储。Curve 还与阿里巴巴的 PolarDB 进行了联合，作为其底层存储运行。此外它也在 AI 训练领域得到了广泛应用。Curve 在过去几年中通过了信创认证，并获得了工信部组织的中国开源创新大赛二等奖。
2. Curve 的架构介绍
Curve 的整体架构是以硬盘为单位进行空间分配，每个硬盘被划分为多个 segment，而每个 segment 又包含多个 chunk。引入 segment 的概念是为了减少原数据的量。类似于 Ceph 中的一个硬盘对应一个节点，Curve 中的一个硬盘对应一个服务组件，由一个磁盘进程进行管理。
Curve 采用了 Raft 协议作为其一致性协议的选择。这是因为 Curve 项目的背景与我们在网易的实际业务需求有关。在网易的业务中，之前大部分业务使用的是 Ceph。然而，在使用 Ceph 过程中，一旦用户更换硬盘或某个机器发生故障，会导致业务出现卡顿，这是业务方无法接受的。因此，这促使我们进行 Curve 的研发。基于这个背景，我们选择了 Raft 协议。选择该协议的原因有两个方面：一是 Raft 协议具有较高的可用性，相对于 Ceph 的强一致性模型，在集群中出现一些问题时，可用性不会受到太大影响。另一个原因是 Raft 协议相对较容易理解。
在 Curve 的开发过程中，我们希望能够快速迭代，并避免重复开发组件。为了实现这一目标，选择了百度的 Braft 和 brpc 这两个被广泛认可为优秀的组件作为底层基础。并在这两个组件的基础上也进行了一系列的开发工作。
3、Curve 的主要亮点
Curve 的主要亮点是以下四个方面：
下面将逐一展开介绍。
1. 高性能
Curve 在随机读写方面表现优于 Ceph。然而也要承认目前存在一个问题：在大块顺序读写方面，Curve 的性能差于于 Ceph。我们正在进行后续的优化工作，以改进这方面的性能表现。
在性能方面，我们的目标是支持云原生数据库，因为云原生数据库对性能要求较高。除了支持阿里巴巴的 PolarDB 数据库，我们还支持网易内部的其他数据库。我们致力于提供高性能的存储解决方案，以满足不同数据库的需求。
在数据库方面引入了 SPDK（Storage Performance Development Kit）和 RDMA（Remote Direct Memory Access）技术。这两种技术已经在 2023 年上半年上线。然而，在实施过程中，我们也面临了一些问题和挑战。以下是一些典型的例子：
RDMA 对网络质量要求较高。当用户的网络质量较差时，可能会出现丢包或拥塞现象，而这对性能的影响明显高于 TCP。为了解决这个问题，我们实现了网络链路的自动切换机制。当用户的网络质量较差时，系统会自动切换到 TCP 来应对这个问题。
在将 NVMe 绑定到 SPDK 后，它将没有盘符。然而，缺少盘符会导致线上监控失效。对于一个存储系统来说，缺乏监控是不可接受的。为了解决这个问题，我们利用 SPDK 提供的一系列脚本进行了内部适配，以确保监控的正常运行。这些问题和挑战是我们在引入 SPDK 和 RDMA 技术时所面临的，我们正在努力解决它们，以提供更稳定和可靠的存储解决方案。
第三个挑战是关于 Brpc 的 RDMA 支持。在当时，Brpc 的 RDMA 功能并不完善。因此，我们对 Brpc 的 RDMA 进行了支持。由于 RDMA 支持是一个较为常见的技术，我们对 Brpc 的 RDMA 进行了文档介绍和代码方面的比较。如果您对此感兴趣，欢迎加入我们的微信群进行学习和交流。
第四个挑战是关于零拷贝技术。在引入 SPDK 后，我们希望引入零拷贝技术。然而，零拷贝技术在实施过程中有很多要求。因此，我们对这项技术进行了一些探索和研究。最终，我们成功实现了零拷贝技术，并且我们的技术和性能得到了显著提升。
在混合存储方面，我们利用了 bcache 来实现。为什么要采用混合存储呢？因为使用 NVMe 或者 SSD 可能会在性能和成本方面遇到一些瓶颈。因此，我们希望能够利用 HDD 作为数据盘，类似于 Ceph 中的 HDD，而利用高性能存储设备来提升低速磁盘的 IO 性能。为了实现这一目标，我们采用了 bcache 技术。
bcache 技术在我们的架构中起到了重要作用。在最初的设计中，我们使用了一个 NVMe 硬盘和几块数据盘。然而，如果 NVMe 硬盘发生故障，那么整个数据盘的数据都会丢失。为了解决这个问题，我们采用了 raid 技术，以提供冗余备份。此外，我们还对 bcache 进行了优化。在优化过程中，我们遇到了一些问题，例如发现 bcache 的 writeback 机制会失效，即使写入的数据量未达到阈值。最终，我们发现这是一个 bug，并进行了修复。有关这个 bug 的详细记录可以在上面图片的链接中找到。
在处理 bcache Gc 的影响方面，我们也进行了一些工作。例如，我们采取了分离的策略，将 WAL 单独放置在 NVMe 设备中，而不放在 bcache Gc 的范围内。通过这样的方式，我们能够减少 bcache Gc 对系统性能的影响。
第三个问题也是非常重要的，尽管在最初的测试中可能不容易发现，但我们花了相当长的时间来定位它。我们发现在测试集群性能时，重复测试可能导致性能下降。最终的定位结果表明，这实际上是由于 NVMe 硬盘本身存在的问题。在持续写入的情况下，NVMe 硬盘的性能可能会下降。这与硬盘的 SAD 和 OP 空间有关。通过适当设置 OP 空间，可以提升硬盘的性能。
此外还了解到三星的企业级硬盘可能存在一些问题，例如固件支持方面。有关这方面的详细记录可以在下面图片的参考链接中找到。如果您对此感兴趣，欢迎参考相关文档。
在高性能方面，我们仍然有许多工作要做。正如之前提到的，我们的随机读写性能要比 Ceph 好得多，但在顺序读写方面则差于 Ceph。因此，我们将重点优化顺序读写性能，这将是后续工作的重点之一。另一个重要工作是本地快照的支持。目前，我们的快照功能将快照上传到 S3 存储。然而，对于一些用户来说，他们对数据的安全性要求更高，可能没有使用 S3 存储。因此，我们非常关注本地快照的支持，以满足这些用户的需求 (本地快照功能已经开发完成，预计 Q4 可 release)。
还有其它一些计划，可以查看相关的 road map 以获取更多信息。
2. 易运维
Curve 是一个易运维的存储系统。即使对于不熟悉 Curve 的人来说，根据我们的文档，只需要花费十几分钟的时间就能够将 Curve 部署起来。除了部署易用性方面，还支持在 Kubernetes 云原生环境中进行部署。我们提供了类似于 Operator 的解决方案，使得 Curve 的部署和运维更加简单。目前已经支持了基本的部署易用性，例如 Operator，但还有一些高级功能，如自动升级，尚未完全实现，我们将在后续继续努力。
3. 更稳定
Curve 在稳定性方面具有显著优势。正如之前提到的，我们选择开发它的原因之一就是为了提高系统的稳定性，这也是我们从 Ceph 中获得的经验。此外，热升级也是 Curve 的一个亮点。关于热升级的详细信息，您可以在我们的文档中找到相关介绍。
在 Curve 的开发过程中，我们对质量要求非常高。进行了单元测试、集成测试以及各种其他类型的测试，以确保系统的稳定性和可靠性。注重测试的全面性和多样性，以确保 Curve 在各种异常场景下都能表现出色。
4. 高质量
对于 Curve 项目，当开发者提交一个 PR 时，会自动触发 CI 流程。CI 流程包括单元测试、集成测试和系统测试等多个测试环节。只有当 CI 流程通过并且测试通过后，PR 才会被合并入代码库。这样的流程确保了代码的质量和稳定性。
在技术架构的先进性方面，简要介绍两个关键点。首先是中心化节点，它充当集群的中心，可以感知集群的负载容量和异常情况，并进行资源调度和数据均衡。其次是文件池的 chunkfilepool，它通过降低文件原数据的开销来提高性能，同时也支持快照功能。目前，我们使用的是快照 S3，这使得用户可以方便地与 S3 或其他对象存储进行对接。
4、RoadMap
最后来分享一下后续的计划。
除了 CurveBS，我们还有 Curve FS 作为另一个重点方向。Curve BS 已经在网易进行了两三年的大规模线上运行，运行非常稳定，目前主要是在进行支持一些高级特性方面的工作。而 Curve FS 在 2022 年 6 月份完成了第一个 release 版本并上线。截至目前，Curve FS 的开发时间只有大约一年左右，还有很多工作要做。特别是在 AI 时代，我们希望 Curve 能够在支持 AI 方面做得更好，这也是我们的一个亮点。当然，除了支持 AI，还在开发其他场景的支持，例如 ES 和传统的接口，如 HDFS。
5、问答环节
Q：Curve 写入代码性能比 Ceph 低吗？
A：在性能方面，Curve 在随机写方面表现比 Ceph 要好很多，但在顺序写方面则差于 Ceph。这主要是因为 Ceph 在过去使用了双写的机制，导致日志和数据都需要写入两次。为了解决这个问题，Ceph 后来采用了 BlueStore 引擎，使得大块写入时只需写入数据一次，从而减少了原数据的写入量。然而，Curve 目前仍然存在日志和数据写入两份的问题，因为它使用了 Raft 机制。这导致了带宽的利用率不高，性能相对于 Ceph 较差。因此，我们的重点之一是优化 Curve 的顺序写性能，特别是在 KBS（Kernel Block Service）方面。我们目前正在进行这方面的工作。
Q：我了解 Curve，请提供 CurveFS 和 CurveBS 他们之间的区别和联系？
A：Curve FS 是一个文件系统，而 Curve BS 是一个块存储系统。与 Ceph 相比，Curve 有一个有趣的特点是 Curve FS 和 Curve BS 可以进行联动。这意味着 Curve FS 的数据既可以存储在 S3 中，也可以存储在 Curve BS 中。这是与 Ceph 相比的一个亮点。通过这种联动，我们可以根据性能需求直接对接 Curve BS，或者根据成本需求直接对接 S3。这是我们的一个亮点，为用户提供了更大的灵活性和选择性。
Q：SPD 跟 RDMA 什么时候开源？
A：关于 SPDK 和 RDMA，我们在 GitHub 上已经有一个版本可用。在上半年，我们在这方面进行了大量的工作，并且在不久前进行了上线。目前，我们正在整理相关的源代码和其他资料。预计在第四季度我们将完成整理工作并达到一个稳定的状态。
Q：Curve 如何对接 K8S? 在这一方面做了一些什么事情？
A：Curve 有一个重要亮点是易运维，我们开发了 CurveAdm 工具。CurveAdm 工具通过容器化技术实现了部署和易运维的功能，这只是其中的一小部分。此外，我们还支持与云原生环境结合，我们已经通过 Operator 实现了这一功能。
开源中国对网易分布式存储项目 Curve专访：凭什么比 Ceph 提升 84%
大数据时代，分布式存储凭借其较低的拥有成本、灵活的扩展能力、线性增长的性能、统一的资源池管理等诸多先天优势，逐步替代了传统的网络存储，成为越来越多的互联网企业用于有效处理海量业务数据的利器。
在开源领域，目前比较主流的开源分布式存储系统无疑是 Linux 基金会旗下的 Ceph。2020年7月下旬，网易宣布开源一款名为 Curve的分布式存储系统，从官方公布的性能测试结果来看，Curve的性能相比 Ceph 提升了 84% ，引起了国内外开源爱好者的关注。为深入了解 Curve项目的具体情况，包括其与主流开源分布式存储系统(特别是 Ceph) 的差异，开源中国第一时间邀请到了 Curve项目负责人、网易数帆轻舟业务部总经理陈谔，与我们分享了 Curve项目的诞生历程以及项目团队对于开源模式的看法。
2020年7月16日，网易基础软件团队网易数帆宣布开源分布式存储系统 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 个月的节奏。今年Curve的主要规划是继续性能优化，以及在安装部署、维护的便利性、文档的完善程度方面进行优化。” 未来网易的团队会更多关注对云原生数据库、容器有状态服务、存储 cache 层(配合后端 EC 存储综合获得较好的单位成本性能收益)等方面的支持和演进。关于Curve项目的运营规划，陈谔还透露了一个重磅信息：“我们希望后续能够有机会把项目捐赠给相关开源基金会来进行管理。”
Github For OpenCurve CN
网易数帆下的Curve通过信息技术应用创新（信创）认证
2022年7月中旬消息，Curve 是一款高性能、易运维、云原生的分布式存储系统，由网易数帆存储团队发起开源，现为 CNCF 沙箱项目。国家工业信息安全发展研究中心测试结果显示，Curve 在文件存储与块存储的功能性、性能效率、可靠性、维护性等方面 49 个测试用例全部通过。当前我国正处在数字经济高速发展期，建设国产自主可控体系、大力发展信创产业已成为 “数字基建” 的目标，此次获得权威机构认可，验证了 Curve 与信创供应链中其他产品的高度兼容适配，既意味着其作为存储软件担当推动目标完成的硬实力，也是其抓住重大历史机遇提速发展的表现。
信创存储三驾马车：创新架构、软件定义与开源
功能性、性能效率、可靠性和维护性是信息系统的基本要素，对于底层存储系统而言尤为重要，事实上，Curve 正是因着国外开源存储 Ceph 在性能效率、维护性等方面的痛点而生。Curve 采用 chunkfilepool、条带化设计、Raft 等创新架构设计护住基本盘，并实现了一套简化运维的工具降低使用门槛。同时，Curve 也拥抱数字化基础设施变革的浪潮，针对云原生场景进行设计和优化。与其他信创存储不同，Curve 作为一款存储软件，在研发之初即基于 “软件定义存储” 的理念设计，拒绝对特殊硬件的依赖，同时支持 ARM、x86 和 MIPS 架构，并且系统完全开源，走 “众人拾柴火焰高” 的研发路线，吸引所有志同道合的从业者参与项目创新，快速经受更多业务场景的考验，这些都为 Curve 成为信创产品奠定了基础。
20 多万行自研代码，高度适配国产化架构
Curve 系统核心模块和数据结构以及数据通讯协议均为自主设计与开发，据统计自主研发代码已超过 20 万行，测试代码的覆盖率也达到了 80%。在参与信创测试之前，网易数帆存储团队已反复完成 Curve 在鲲鹏 CPU + 麒麟操作系统下的兼容适配和相关测试，以确保软件架构能够充分利用并发挥国产硬件以及操作系统的性能和功能。国家工业信息安全发展研究中心的测试结果，正是古语 “功不唐捐” 的注脚。此外，在数据库领域，Curve 已经成为 PolarDB for PostgreSQL 的官方生态合作伙伴，为后者提供分布式共享存储。目前，Curve 已经应用于网易严选、云音乐、游戏、有道、云信以及创云融达、超聚变数字技术有限公司等落地应用。
项目主页：
https://github.com/opencurve/curve
https://gitee.com/mirrors/curve
当前网易基于Curve已经实现了高性能块存储系统，支持快照克隆和恢复，支持 QEMU 虚拟机和物理机 NBD 设备两种挂载方式，在网易内部作为高性能云盘使用。其编码规范严格按照Google C++开源项目编码指南来进行代码编写采用Apache v2.0的协议授权。
Curve总体架构图：
Curve支持部署在私有云和公有云环境，也可以以混合云方式使用，私有云环境下的部署架构如下：
其中CurveFS共享文件存储系统可以弹性伸缩到公有云存储，可以为用户提供更大的容量弹性、更低的成本、更好的性能体验。
公有云环境下，用户可以部署CurveFS集群，用来替换云厂商提供的共享文件存储系统，并利用云盘进行加速，可极大的降低业务成本，其部署架构如下：
特性
1. 高性能
高性能是 Curve的一大特点，也是项目团队创建 Curve项目的初衷。RPC 层面 Curve采用了高性能和低延迟并且已开源的 brpc；在一致性层面选择了基于 quorum 机制并且开源的 braft，从协议层面来说 quorum 机制在延迟方面天生优于多副本强一致的方式。实现上 Curve对 braft 快照的实现进行了优化，在状态机的实现上采用 chunkfilepool 的方式 ( 初始化集群的时候格式化出指定比例的空间用作 chunk ) 使得底层的写入放大为 0；此外Curve还在 chunk 上进行更细力度的地址空间 hash 以达到读写分离、减小 IO 碰撞等的效果，从而进一步提升 IO 性能。
2. 高可用
高可用是 Curve的另一大特点。MDS、ChunkServer 以及 SnapShotCloneServer 都支持多实例部署，部分实例异常不影响整个集群的可用性。
MDS
MDS 是无状态的，推荐至少部署两个实例，通过 Etcd 进行选主。多个 MDS 实例通过 Etcd 进行选主，当单个实例失效时，可以秒级切换到另外一个实例。失效实例上正在处理的请求，Client 和 SnapShotCloneServer 都会对其进行重试，以达到不影响集群可用性的效果。
SnapShotCloneServer
它与 MDS 类似, 也是通过 Etcd 进行选主，不同的是，它通过负载均衡对外提供服务。失效期间的请求失败重试都是幂等的，不影响任务的正确性以及集群的可用性。
ChunkServer
它是一个集群，通过 Raft 协议保持数据一致性，并通过 MDS 做负载均衡。单个节点失效时，会影响到这个节点上存储的所有 Copyset。对于 Copyset 上的 Leader 节点，会中断服务，等待重新选举；对于Copyset 上的 follower 节点，服务不会受影响。当某个 Chunkserver 节点失效且在一段时间内无法恢复，MDS 会将其上的数据迁移到其他节点上。
Curve是网易数帆自主设计研发并开源的高性能、易运维、全场景支持的云原生软件定义存储系统。Curve于2020年7月正式开源，当前由CurveBS和CurveFS两个子项目构成，分别提供块存储和文件存储两种能力。Curve开源项目曾获评中国信通院 OSCAR 尖峰开源项目及开源社区，通过可信开源项目评估，并且Curve社区也是中国信通院牵头创立的可信开源共同体（TWOS）的首批正式成员。它是一款高性能、易运维、云原生的开源分布式存储系统 (CNCF Sandbox)。可应用于主流的云原生基础设施平台：对接 OpenStack 平台为云主机提供高性能块存储服务；对接 Kubernetes 为其提供 RWO、RWX 等类型的持久化存储卷；对接 PolarFS 作为云原生数据库的高性能存储底座，完美支持云原生数据库的存算分离架构。它亦可作为云存储中间件使用 S3 兼容的对象存储作为数据存储引擎，为公有云用户提供高性价比的共享文件存储。本节将介绍 Curve 块存储相关的部分，并分享 Curve 在一些场景的应用。
1、分布式存储介绍
1. 分布式存储的分类
首先简单介绍一下分布式存储的分类。分布式存储可以分为三类：对象存储、文件存储和块存储。对象存储在互联网中应用的比较多，比如一个对象、一个图片、一个音频，这种可以通过 PUT GET 接口来进行存储。文件存储与传统意义的文件系统的区别是，它是分布式的，传统的项目对应的是 Ext4，或者是 NTFS。块存储，就是所谓的云盘。
2. 分布式存储的要素
下面介绍一下分布式存储在设计时的一些要素。首先需要大容量的硬盘空间，并且可以随机写，还有最重要的是要保证服务的质量，数据不能丢失，还要保证它的可用性。
要素可以拆解为以下三方面：
①第一是高性能。在分布存储里面，存储节点会非常多，所以要知道数据存在什么位置以及如何去取。
②第二是可用性。要保证数据的可靠性，避免数据丢失，并且保证在机器故障时数据的读写是能够正常运行的。
③第三是可扩展性。如果容量用完了，可以新增机器扩展容量。
数据分布，主要有两种，一个是无中心节点，另一个是有中心节点。
另外一个比较重要的点是一致性协议。首先是 Ceph 的强一致性。在分布式系统中，一致性是指在多个副本之间保持数据一致。在 RADOS 中，数据被分割成多个对象，每个对象都有多个副本，这些副本分布在集群的不同节点上。当一个对象被修改时，Ceph 会确保所有的副本都被同时更新，从而保证了强一致性。第二是 Raft 算法，他只需要大多数副本保证更新完成就可以认为成功了。
2、Curve 架构及介绍
1. 项目介绍
关于 Curve，我们的愿景是希望打造一款性能比较好，适用多种场景的，并且是围绕开源的云原生分布式存储系统。目前 Curve 已经捐赠给 CNCF 基金会，并成为其生态系统中的一个项目。其提供块存储和文件存储两种方式，以满足不同应用的需求。对于 Curve 块存储，它具有快照克隆恢复功能，主要应用场景包括 OpenStack 云主机和 Kubernetes 持久存储卷。对于共享需求，Curve 提供文件存储；对于性能要求较高且无共享需求的场景，建议使用 Curve 块存储。Curve 还与阿里巴巴的 PolarDB 进行了联合，作为其底层存储运行。此外它也在 AI 训练领域得到了广泛应用。Curve 在过去几年中通过了信创认证，并获得了工信部组织的中国开源创新大赛二等奖。
2. Curve 的架构介绍
Curve 的整体架构是以硬盘为单位进行空间分配，每个硬盘被划分为多个 segment，而每个 segment 又包含多个 chunk。引入 segment 的概念是为了减少原数据的量。类似于 Ceph 中的一个硬盘对应一个节点，Curve 中的一个硬盘对应一个服务组件，由一个磁盘进程进行管理。
Curve 采用了 Raft 协议作为其一致性协议的选择。这是因为 Curve 项目的背景与我们在网易的实际业务需求有关。在网易的业务中，之前大部分业务使用的是 Ceph。然而，在使用 Ceph 过程中，一旦用户更换硬盘或某个机器发生故障，会导致业务出现卡顿，这是业务方无法接受的。因此，这促使我们进行 Curve 的研发。基于这个背景，我们选择了 Raft 协议。选择该协议的原因有两个方面：一是 Raft 协议具有较高的可用性，相对于 Ceph 的强一致性模型，在集群中出现一些问题时，可用性不会受到太大影响。另一个原因是 Raft 协议相对较容易理解。
在 Curve 的开发过程中，我们希望能够快速迭代，并避免重复开发组件。为了实现这一目标，选择了百度的 Braft 和 brpc 这两个被广泛认可为优秀的组件作为底层基础。并在这两个组件的基础上也进行了一系列的开发工作。
3、Curve 的主要亮点
Curve 的主要亮点是以下四个方面：
下面将逐一展开介绍。
1. 高性能
Curve 在随机读写方面表现优于 Ceph。然而也要承认目前存在一个问题：在大块顺序读写方面，Curve 的性能差于于 Ceph。我们正在进行后续的优化工作，以改进这方面的性能表现。
在性能方面，我们的目标是支持云原生数据库，因为云原生数据库对性能要求较高。除了支持阿里巴巴的 PolarDB 数据库，我们还支持网易内部的其他数据库。我们致力于提供高性能的存储解决方案，以满足不同数据库的需求。
在数据库方面引入了 SPDK（Storage Performance Development Kit）和 RDMA（Remote Direct Memory Access）技术。这两种技术已经在 2023 年上半年上线。然而，在实施过程中，我们也面临了一些问题和挑战。以下是一些典型的例子：
RDMA 对网络质量要求较高。当用户的网络质量较差时，可能会出现丢包或拥塞现象，而这对性能的影响明显高于 TCP。为了解决这个问题，我们实现了网络链路的自动切换机制。当用户的网络质量较差时，系统会自动切换到 TCP 来应对这个问题。
在将 NVMe 绑定到 SPDK 后，它将没有盘符。然而，缺少盘符会导致线上监控失效。对于一个存储系统来说，缺乏监控是不可接受的。为了解决这个问题，我们利用 SPDK 提供的一系列脚本进行了内部适配，以确保监控的正常运行。这些问题和挑战是我们在引入 SPDK 和 RDMA 技术时所面临的，我们正在努力解决它们，以提供更稳定和可靠的存储解决方案。
第三个挑战是关于 Brpc 的 RDMA 支持。在当时，Brpc 的 RDMA 功能并不完善。因此，我们对 Brpc 的 RDMA 进行了支持。由于 RDMA 支持是一个较为常见的技术，我们对 Brpc 的 RDMA 进行了文档介绍和代码方面的比较。如果您对此感兴趣，欢迎加入我们的微信群进行学习和交流。
第四个挑战是关于零拷贝技术。在引入 SPDK 后，我们希望引入零拷贝技术。然而，零拷贝技术在实施过程中有很多要求。因此，我们对这项技术进行了一些探索和研究。最终，我们成功实现了零拷贝技术，并且我们的技术和性能得到了显著提升。
在混合存储方面，我们利用了 bcache 来实现。为什么要采用混合存储呢？因为使用 NVMe 或者 SSD 可能会在性能和成本方面遇到一些瓶颈。因此，我们希望能够利用 HDD 作为数据盘，类似于 Ceph 中的 HDD，而利用高性能存储设备来提升低速磁盘的 IO 性能。为了实现这一目标，我们采用了 bcache 技术。
bcache 技术在我们的架构中起到了重要作用。在最初的设计中，我们使用了一个 NVMe 硬盘和几块数据盘。然而，如果 NVMe 硬盘发生故障，那么整个数据盘的数据都会丢失。为了解决这个问题，我们采用了 raid 技术，以提供冗余备份。此外，我们还对 bcache 进行了优化。在优化过程中，我们遇到了一些问题，例如发现 bcache 的 writeback 机制会失效，即使写入的数据量未达到阈值。最终，我们发现这是一个 bug，并进行了修复。有关这个 bug 的详细记录可以在上面图片的链接中找到。
在处理 bcache Gc 的影响方面，我们也进行了一些工作。例如，我们采取了分离的策略，将 WAL 单独放置在 NVMe 设备中，而不放在 bcache Gc 的范围内。通过这样的方式，我们能够减少 bcache Gc 对系统性能的影响。
第三个问题也是非常重要的，尽管在最初的测试中可能不容易发现，但我们花了相当长的时间来定位它。我们发现在测试集群性能时，重复测试可能导致性能下降。最终的定位结果表明，这实际上是由于 NVMe 硬盘本身存在的问题。在持续写入的情况下，NVMe 硬盘的性能可能会下降。这与硬盘的 SAD 和 OP 空间有关。通过适当设置 OP 空间，可以提升硬盘的性能。
此外还了解到三星的企业级硬盘可能存在一些问题，例如固件支持方面。有关这方面的详细记录可以在下面图片的参考链接中找到。如果您对此感兴趣，欢迎参考相关文档。
在高性能方面，我们仍然有许多工作要做。正如之前提到的，我们的随机读写性能要比 Ceph 好得多，但在顺序读写方面则差于 Ceph。因此，我们将重点优化顺序读写性能，这将是后续工作的重点之一。另一个重要工作是本地快照的支持。目前，我们的快照功能将快照上传到 S3 存储。然而，对于一些用户来说，他们对数据的安全性要求更高，可能没有使用 S3 存储。因此，我们非常关注本地快照的支持，以满足这些用户的需求 (本地快照功能已经开发完成，预计 Q4 可 release)。
还有其它一些计划，可以查看相关的 road map 以获取更多信息。
2. 易运维
Curve 是一个易运维的存储系统。即使对于不熟悉 Curve 的人来说，根据我们的文档，只需要花费十几分钟的时间就能够将 Curve 部署起来。除了部署易用性方面，还支持在 Kubernetes 云原生环境中进行部署。我们提供了类似于 Operator 的解决方案，使得 Curve 的部署和运维更加简单。目前已经支持了基本的部署易用性，例如 Operator，但还有一些高级功能，如自动升级，尚未完全实现，我们将在后续继续努力。
3. 更稳定
Curve 在稳定性方面具有显著优势。正如之前提到的，我们选择开发它的原因之一就是为了提高系统的稳定性，这也是我们从 Ceph 中获得的经验。此外，热升级也是 Curve 的一个亮点。关于热升级的详细信息，您可以在我们的文档中找到相关介绍。
在 Curve 的开发过程中，我们对质量要求非常高。进行了单元测试、集成测试以及各种其他类型的测试，以确保系统的稳定性和可靠性。注重测试的全面性和多样性，以确保 Curve 在各种异常场景下都能表现出色。
4. 高质量
对于 Curve 项目，当开发者提交一个 PR 时，会自动触发 CI 流程。CI 流程包括单元测试、集成测试和系统测试等多个测试环节。只有当 CI 流程通过并且测试通过后，PR 才会被合并入代码库。这样的流程确保了代码的质量和稳定性。
在技术架构的先进性方面，简要介绍两个关键点。首先是中心化节点，它充当集群的中心，可以感知集群的负载容量和异常情况，并进行资源调度和数据均衡。其次是文件池的 chunkfilepool，它通过降低文件原数据的开销来提高性能，同时也支持快照功能。目前，我们使用的是快照 S3，这使得用户可以方便地与 S3 或其他对象存储进行对接。
4、RoadMap
最后来分享一下后续的计划。
除了 CurveBS，我们还有 Curve FS 作为另一个重点方向。Curve BS 已经在网易进行了两三年的大规模线上运行，运行非常稳定，目前主要是在进行支持一些高级特性方面的工作。而 Curve FS 在 2022 年 6 月份完成了第一个 release 版本并上线。截至目前，Curve FS 的开发时间只有大约一年左右，还有很多工作要做。特别是在 AI 时代，我们希望 Curve 能够在支持 AI 方面做得更好，这也是我们的一个亮点。当然，除了支持 AI，还在开发其他场景的支持，例如 ES 和传统的接口，如 HDFS。
5、问答环节
Q：Curve 写入代码性能比 Ceph 低吗？
A：在性能方面，Curve 在随机写方面表现比 Ceph 要好很多，但在顺序写方面则差于 Ceph。这主要是因为 Ceph 在过去使用了双写的机制，导致日志和数据都需要写入两次。为了解决这个问题，Ceph 后来采用了 BlueStore 引擎，使得大块写入时只需写入数据一次，从而减少了原数据的写入量。然而，Curve 目前仍然存在日志和数据写入两份的问题，因为它使用了 Raft 机制。这导致了带宽的利用率不高，性能相对于 Ceph 较差。因此，我们的重点之一是优化 Curve 的顺序写性能，特别是在 KBS（Kernel Block Service）方面。我们目前正在进行这方面的工作。
Q：我了解 Curve，请提供 CurveFS 和 CurveBS 他们之间的区别和联系？
A：Curve FS 是一个文件系统，而 Curve BS 是一个块存储系统。与 Ceph 相比，Curve 有一个有趣的特点是 Curve FS 和 Curve BS 可以进行联动。这意味着 Curve FS 的数据既可以存储在 S3 中，也可以存储在 Curve BS 中。这是与 Ceph 相比的一个亮点。通过这种联动，我们可以根据性能需求直接对接 Curve BS，或者根据成本需求直接对接 S3。这是我们的一个亮点，为用户提供了更大的灵活性和选择性。
Q：SPD 跟 RDMA 什么时候开源？
A：关于 SPDK 和 RDMA，我们在 GitHub 上已经有一个版本可用。在上半年，我们在这方面进行了大量的工作，并且在不久前进行了上线。目前，我们正在整理相关的源代码和其他资料。预计在第四季度我们将完成整理工作并达到一个稳定的状态。
Q：Curve 如何对接 K8S? 在这一方面做了一些什么事情？
A：Curve 有一个重要亮点是易运维，我们开发了 CurveAdm 工具。CurveAdm 工具通过容器化技术实现了部署和易运维的功能，这只是其中的一小部分。此外，我们还支持与云原生环境结合，我们已经通过 Operator 实现了这一功能。
开源中国对网易分布式存储项目 Curve专访：凭什么比 Ceph 提升 84%
大数据时代，分布式存储凭借其较低的拥有成本、灵活的扩展能力、线性增长的性能、统一的资源池管理等诸多先天优势，逐步替代了传统的网络存储，成为越来越多的互联网企业用于有效处理海量业务数据的利器。
在开源领域，目前比较主流的开源分布式存储系统无疑是 Linux 基金会旗下的 Ceph。2020年7月下旬，网易宣布开源一款名为 Curve的分布式存储系统，从官方公布的性能测试结果来看，Curve的性能相比 Ceph 提升了 84% ，引起了国内外开源爱好者的关注。为深入了解 Curve项目的具体情况，包括其与主流开源分布式存储系统(特别是 Ceph) 的差异，开源中国第一时间邀请到了 Curve项目负责人、网易数帆轻舟业务部总经理陈谔，与我们分享了 Curve项目的诞生历程以及项目团队对于开源模式的看法。
2020年7月16日，网易基础软件团队网易数帆宣布开源分布式存储系统 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 个月的节奏。今年Curve的主要规划是继续性能优化，以及在安装部署、维护的便利性、文档的完善程度方面进行优化。” 未来网易的团队会更多关注对云原生数据库、容器有状态服务、存储 cache 层(配合后端 EC 存储综合获得较好的单位成本性能收益)等方面的支持和演进。关于Curve项目的运营规划，陈谔还透露了一个重磅信息：“我们希望后续能够有机会把项目捐赠给相关开源基金会来进行管理。”
Github For OpenCurve CN
网易数帆下的Curve通过信息技术应用创新（信创）认证
2022年7月中旬消息，Curve 是一款高性能、易运维、云原生的分布式存储系统，由网易数帆存储团队发起开源，现为 CNCF 沙箱项目。国家工业信息安全发展研究中心测试结果显示，Curve 在文件存储与块存储的功能性、性能效率、可靠性、维护性等方面 49 个测试用例全部通过。当前我国正处在数字经济高速发展期，建设国产自主可控体系、大力发展信创产业已成为 “数字基建” 的目标，此次获得权威机构认可，验证了 Curve 与信创供应链中其他产品的高度兼容适配，既意味着其作为存储软件担当推动目标完成的硬实力，也是其抓住重大历史机遇提速发展的表现。
信创存储三驾马车：创新架构、软件定义与开源
功能性、性能效率、可靠性和维护性是信息系统的基本要素，对于底层存储系统而言尤为重要，事实上，Curve 正是因着国外开源存储 Ceph 在性能效率、维护性等方面的痛点而生。Curve 采用 chunkfilepool、条带化设计、Raft 等创新架构设计护住基本盘，并实现了一套简化运维的工具降低使用门槛。同时，Curve 也拥抱数字化基础设施变革的浪潮，针对云原生场景进行设计和优化。与其他信创存储不同，Curve 作为一款存储软件，在研发之初即基于 “软件定义存储” 的理念设计，拒绝对特殊硬件的依赖，同时支持 ARM、x86 和 MIPS 架构，并且系统完全开源，走 “众人拾柴火焰高” 的研发路线，吸引所有志同道合的从业者参与项目创新，快速经受更多业务场景的考验，这些都为 Curve 成为信创产品奠定了基础。
20 多万行自研代码，高度适配国产化架构
Curve 系统核心模块和数据结构以及数据通讯协议均为自主设计与开发，据统计自主研发代码已超过 20 万行，测试代码的覆盖率也达到了 80%。在参与信创测试之前，网易数帆存储团队已反复完成 Curve 在鲲鹏 CPU + 麒麟操作系统下的兼容适配和相关测试，以确保软件架构能够充分利用并发挥国产硬件以及操作系统的性能和功能。国家工业信息安全发展研究中心的测试结果，正是古语 “功不唐捐” 的注脚。此外，在数据库领域，Curve 已经成为 PolarDB for PostgreSQL 的官方生态合作伙伴，为后者提供分布式共享存储。目前，Curve 已经应用于网易严选、云音乐、游戏、有道、云信以及创云融达、超聚变数字技术有限公司等落地应用。
项目主页：
https://github.com/opencurve/curve
https://gitee.com/mirrors/curve