作者注：JuiceFS 的服務端和客戶端完全使用 Golang 編寫，同時爲了更精細化的管理內存，我們沒有使用 Golang 的內存模型，手工控制，避免 GC。後續會寫專門的文章來分享我們在 Golang 多個角度的技術實踐。
我們很激動地宣佈，將經過 4 年持續迭代和累計幾千萬小時線上考驗的 JuiceFS 開源了！
JuiceFS 是什麼
JuiceFS 是爲海量數據設計的分佈式文件系統，使用對象存儲來做數據持久化，避免重複造輪子，還能大大降低工程複雜度，讓我們專注解決元數據和訪問協議部分的難題。
JuiceFS 的創新架構更符合雲原生的發展趨勢，我們一開始就以 SaaS 的形式將它提供給公有云的客戶，讓客戶分鐘級就可以獲得 PB 級企業文件存儲服務。同時，我們也和行業領先的對象存儲廠商一起服務私有云客戶。
爲什麼開源
在創業之初，我們認爲 SaaS 可以爲用戶提供最佳的體驗，同時讓我們更快地迭代產品，決定優先把 SaaS 做好。經過 4 年的持續迭代和積累，JuiceFS 已經在幾十家科技企業的大數據、AI、容器平臺、歸檔、備份等場景中形成最佳實踐， SaaS 使用量也持續快速增長，並且在過去的 2020 年首次實現了盈虧平衡。我們相信找到了可持續發展的模式，有信心保障 JuiceFS 的長期運營。
我們也發現閉源的基礎軟件會限制使用者對它的深度理解，不利於它服務更多的人，依靠 SaaS 產品的收入支撐和開源社區的力量，我們可以讓 JuiceFS 幫助更多的人。
架構再升級
藉助對象存儲的幫助，JuiceFS 已經大大降低了分佈式文件系統的複雜度，元數據管理是它最核心的問題。JuiceFS 的 SaaS 使用的元數據引擎，是專爲文件系統打造的數據庫，我們已經積累了豐富的運維經驗，仍然如履薄冰。如果開源的話，讓社區用戶自己運維仍然會是一個大的挑戰和負擔，一旦運維失誤導致數據丟失，後果非常嚴重。
帶着這個問題，我們將元數據服務改造爲支持多引擎的插件式架構，可以利用已有的開源數據庫實現元數據存儲。這樣可以更靈活地適應不同場景，根據場景的規模、性能和成本需求，選用不同的元數據實現。這是 JuiceFS 的架構再升級，爲未來的發展翻開新的篇章。
我們選用 Redis 作爲第一個開源存儲引擎，是因爲它：
是全內存的，可以滿足元數據的低延時和高 IOPS 要求；
支持樂觀事務，能夠滿足文件系統元數據操作的原子性要求；
有豐富的數據結構，易於實現文件系統的諸多 API；
有着非常廣泛的社區和成熟的生態，運維 Redis 不會是一個問題；
在各個雲上都有託管的服務，在雲上使用會更簡單；
未來，我們還會增加 SQL 數據庫、TiKV 等支持事務的 KV 數據庫支持。
未來發展
最近幾年，數據庫領域發生了一件有趣的事情：當 NoSQL 數據庫在滿足了數據的快速增長後，它在一致性、訪問便捷性和管理能力方面的不足逐漸顯露，把這些複雜性轉嫁到了業務系統和運維上，開始被人詬病。同時， SQL 數據庫也有了長足的進展，已經能夠滿足現在的數據規模需求，經過全面的對比分析後，大家又在迴歸 SQL 數據庫，曾經的 NoSQL 運動也逐漸顯出頹勢。
估計類似的事情也會發生在非結構數據領域。對象存儲在媒體文件等場景取得了巨大的成功，但當人們以爲它就是未來的存儲形態，開始推廣到更大範圍時，它犧牲掉的樹形目錄結構、可修改性、元數據性能、一致性等等，變成了一隻只攔路虎，影響它在其他場景的使用效果。
我們堅信文件系統是最好的管理非結構化數據的方式，對象存儲只適用於某些簡單場景。分佈式文件系統一直是基礎軟件中難啃的骨頭，JuiceFS 通過對文件系統中元數據和數據的獨立抽象，大大減低了系統複雜度，使得文件系統能夠藉助這些年來對象存儲和分佈式數據庫的進展，管理超大規模的數據。同時，複雜度的降低可以讓更多的開發者參與進來，未來更多的應用也會建立在文件系統接口之上。
我們將通過開源社區的相互協作，一方面爲各個應用提供更好的存儲支持，也會在底層存儲引擎和對象存儲上加深協作，一起推動文件存儲的快速發展，打造未來數據生態的堅實底座。
我們 GitHub 見！
https://github.com/juicedata/juicefs
閱讀原文給我們star