網易分散式儲存專案 Curve 專訪：憑什麼比 Ceph 提升 84%？

大資料時代，分散式儲存憑藉其較低的擁有成本、靈活的擴充套件能力、線性增長的效能、統一的資源池管理等諸多先天優勢，逐步替代了傳統的網路儲存，成為越來越多的網際網路企業用於有效處理海量業務資料的利器。 

在開源領域，目前比較主流的開源分散式儲存系統無疑是 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 專案的運營規劃，陳諤還透露了一個重磅資訊：“我們希望後續能夠有機會把專案捐贈給相關開源基金會來進行管理。”

嘉賓介紹

陳諤，網易數帆輕舟業務部總經理，網易杭州研究院的元老之一、網易雲計算基礎服務的領軍人。