海柔創新是一家專注於箱式倉儲機器人系統的研發和設計的科技公司，其模擬平臺透過數字模擬技術，再現實際倉庫環境和裝置，利用匯入的地圖、訂單、庫存及策略配置等資料來驗證和最佳化倉儲解決方案，確保設計方案的效率和合理性。
最初，海柔的模擬平臺在單機環境中執行，但隨著資料量的增長，運維逐漸面臨挑戰。因此，平臺被遷移到私有云的 Kubernetes 環境中，團隊隨後開始尋找適合在 k8s 環境中運用的分散式檔案系統。
模擬平臺的資料特徵包括：大量小檔案、併發寫入、跨雲架構等。經過對比 Longhorn、Ceph 等多種系統後，海柔科技選擇了 JuiceFS。目前，平臺的總檔案數量為 1100 萬、日均寫入檔案數量 6000 多，以小檔案為主，平均檔案大小是 3.6KB；同時，Mount Point 數量超過 50個。
01 模擬平臺儲存挑戰：從商用軟體到自建
模擬平臺（simulator）是基於離散事件引擎的工具平臺。它透過底層的數字模擬，對接上層業務系統，在沒有實體裝置的情況下，達到與實體裝置等效的能力。 簡單的說 其實模擬平臺就是建立了一個虛擬倉庫，所有的模擬都是基於這個虛擬倉庫來完成的。
傳統公司通常使用商業軟體，但這些軟體無法進行大規模排程或減少計算資源消耗。為此，我們自研了一個模擬平臺，涵蓋 IaaS、PaaS 等服務。我們的模擬主要是基於離散事件進行，與使用 GPU 的商業軟體不同，透過簡化計算步驟，最佳化事件的抽象，顯著減少了計算量，甚至可以只使用 CPU 完成倍速模擬的計算任務。
我們的模擬系統主要涵蓋幾個關鍵部分：首先是模擬本體，如機器人模擬，包括其運動、旋轉和移動速度的邏輯模擬。模擬裝置與我們自研的排程系統和 WMS （Warehose Management System）系統直接對接。這也是商業軟體所不直接提供的功能。
模擬過程中還包括機械模擬、揀選作業模擬和上游系統環境的業務整合。模擬完成後，會生成大量事件資料，這些資料被記錄在小檔案中。我們透過這些小檔案在另一節點進行存算分離，從而提取和分析這些資料。透過這種方法，我們能夠有效地從模擬資料中洞察操作效率和潛在問題，進一步最佳化系統效能。
我們的模擬平臺一開始是一個純單機版系統。單機版主要包括一個啟動器（starter），核心引擎（core engine，可以類比為一個遊戲引擎），它將透過真實的通訊協議與真實業務系統 RCS （Robot Control System）連線，從而高度還原現場。
然而，單機版系統存在一些缺點，如原 Core Enging 使用 Python 編寫，不能滿足單機高併發 IO 的需要，另外當系統擴充套件至 50 臺虛擬機器時，運維變得尤為困難。考慮到我們團隊的人員數量，這種規模的運維對我們來說是一個巨大的挑戰。
02 模擬平臺上雲：從私有云到混合雲架構
單機系統大約持續了 2 年時間，隨著資料量的增長，單機系統面臨的運維問題日益複雜，於是我們遷移到了 Kubernetes 架構，採用了服務化 (SAAS) 的方式，將所有元件都部署在 K8s 環境中。由此面臨，如何在 Kuberenetes 環境中進行儲存選型。
K8s 環境儲存選型：JuiceFS vs CephFS vs Longhorn
在我們選擇分散式檔案系統時，效能並不是首要考慮因素，更關鍵的是如何有效實現跨雲網路結構。我們簡單評估了 JuiceFS、CephFS 和 Longhorn。
Longhorn 僅支援單叢集內檔案共享，需要先打通 Kubernetes 的多雲叢集網路通訊，這對我們來說運維成本繁瑣。而 CephFS 對於我們這種小規模團隊來說，存在過高的維護難度。
因此，我們選擇了 JuiceFS，主要因為它的運維特別簡單，非常適合小團隊使用。JuiceFS 的即插即用特性意味著即使是初學者也能輕鬆上手，幾乎不會遇到大問題，這降低了運營風險。此外，自從部署以來，JuiceFS 未出現過任何故障，這一點非常值得讚揚。
目前 JuiceFS 使用規模方面，過去六個月我們處理了大約 1,100 萬個檔案。我們每半年會進行一次資料清洗，刪除不再需要的資料，因此總資料量不會繼續增加。日均寫入大約是 6.4k 個檔案，平均每日總檔案數量為 6 萬個，檔案大小介於 5kB 到 100kB 之間。日均資料寫入量約為 5GB，最高可達 8GB。我們計劃將併發寫入量逐步擴充套件至 50 個。
在私有云 K8s 環境中搭建模擬平臺
2023 年中，我們開始在 K8s 環境中搭建模擬平臺。當系統擴充套件到 1000 臺機器人時，我們發現 Python的 IO 處理能力不足以支撐。因此，我們採用了 Go 語言，這一改變顯著提升了系統的 IO 效能，使得單機可以輕鬆支援超過 1 萬臺機器人的併發操作。
整個系統的檔案處理特徵為小檔案的高併發寫入，當前的併發級別為 50，能夠滿足了我們的需求。
最近，我們將系統從單體架構轉變為微服務架構。這一轉變解決了原有團隊程式碼混雜和耦合的問題，確保各個服務間程式碼的獨立性，從而提升了系統的可維護性和擴充套件性。
我們還實施了存算分離的策略，在模擬節點透過使用 JuiceFS 寫入模擬過程資料小檔案，並在寫入結束時重新命名為 *.fin 檔案；當另一個分析計算節點實時發現 *.fin 檔案並開始計算，從而實現隔離模擬與分析的存算分離，避免 CPU 搶佔造成模擬過程失真。
混合雲 SaaS 模擬服務
在私有云 K8s 環境中，我們的團隊需要管理眾多元件，如 MySQL、OSS 等，為了解決資源和精力分散的問題，我們在 2024 年 1 月開始轉向混合雲 SaaS 解決方案，並選擇將儲存服務遷移到阿里雲。對於小團隊來說，如果條件允許，我建議儘量利用公有云服務，特別是在儲存方面，因為資料安全是基本需求，不能有失誤。
我們採用了阿里雲的 OSS 和 MySQL 服務，在兩個叢集間實現資料共享。這種配置不僅提升了資料處理的效率，還帶來了成本效益和靈活性的優勢。例如，當本地資料中心的機器資源不足時，利用 JuiceFS 天然的跨雲端儲存能力，在這個架構下，我們可以輕鬆地從任意雲廠商租用機器彈性伸縮叢集以滿足需求，從而實現成本節約。
03 使用 JuiceFS 踩過的坑
在遷移到雲端之前，我們本地使用 Redis 和 Minio 執行得很好，因為我們擁有充足的記憶體和儲存空間，這樣就不會出現效能問題。然而，遷移到雲端後，遇到了一些問題。
預設的快取過大，導致 Pod 驅逐
預設的快取大小設為 100GB，而標準阿里雲伺服器通常配備的磁碟只有 20GB。這種配置不匹配會導致 Pod 被驅逐，因為快取過大超出了實際可用磁碟空間。
混合雲場景下 storageClasses 的 bucket 設定問題
在實現跨雲功能時，儘管官方文件可能推薦使用內網，實際操作表明應當使用外網地址，特別是在使用容器儲存介面（CSI）時。預設情況下，第一個執行的操作是格式化 Pod（format pod），它會將當前的配置引數寫入資料庫。如果其他節點未指定 bucket 設定並依賴於資料庫中的這一設定，使用內網地址可能導致外網訪問失敗。
物件儲存佔用空間比實際多
儘管阿里雲賬戶下我們有 6TB 的儲存空間，實際使用中發現只儲存了大約 1.27TB 資料，物件儲存佔用的空間明顯膨脹，遠超實際資料量。這可能是由於缺乏自動垃圾回收（GC）處理。因此，我們必須定期手動執行 GC 操作，以減少儲存佔用。
04 未來展望
我們計劃在雲端實現彈性伸縮，採用混合平臺策略，並推出高速版服務。目前，我們在機器學習領域的高效模擬已經取得顯著進展，成功實現了模擬倍速提升至 100 倍。
為了進一步提升效率，我們計劃完善整個系統的閉環管理。由於我們的模擬系統已經能夠生成大量資料，這些資料理應被充分利用，透過機器學習訓練來完善閉環系統，實現資料的最大化利用。這將極大地增強我們系統的智慧化和自動化水平。