Hyperledger Fabric節點服務器對存儲空間的消耗還是比較大的，在我實際生產體驗的過程中，每一條請求數據大概僅2K左右，但實際占用空間遠不止這點，每個節點都會對Block及鏈進行保存維護，也會將數據解析存儲在本地，基本上1000萬條數據會占用500G左右的空間。當然，這個僅供參考，不同的業務可能會略有差距。
我所負責的業務需要在聯盟鏈搭建初期就導入巨量的數據，這個需求本就有些違背區塊鏈的設計原則，已經把它當成一個數據庫來使用了，這樣龐大的業務量在實際處理過程中也遇到很多的麻煩，最明顯的就是服務器性能的各種瓶頸，還要控制請求的次數和頻率。
一般情況下，不會出現大批量導數的時候，節點服務器采用8C8G1T的配置足夠用很久了，我這邊因為業務原因，服務器采用16C16G3T，內存是綽綽有余，8G甚至4G也能滿足沒問題，但CPU就明顯不足，這個官方也沒有給出一個建議配置，只能自己摸索。
在一些網絡博文中可以找到一些官方資料的線索，比如Hyperledger Fabric 1.0的目標是支持1000TPS，且實驗室數據已經達到300~400TPS了。這些文章沒有明確到底是節點服務器還是排序服務器廣播的值，在實際操作中一台16C16G的服務器完全沒有達到文檔中所說的那樣，節點服務器大約在50~70之間，排序服務器廣播的在60~80之間，這可能是自己沒完全摸清楚Hyperledger Fabric性能優化這一塊。
日常使用最低配置建議：
| 服務器類型 | 建議配置 | 備注 |
| zookeeper | 4C+4G+500G | 磁盤有擴容需求 |
| kafka | 4C+4G+500G | 磁盤有擴容需求 |
| orderer | 8C+4G+500G | 磁盤有擴容需求 |
| peer | 4C+4G+3T | 磁盤有擴容需求，如大批量數據導入，則cpu提前做好擴容 |
如果存在大批量數據導入的情況，orderer和peer的配置建議均高於16C+16G，以免數據導入過程中容器down掉從而導致數據丟失的情況發生。
接着說下Fabric容器的問題，因為區塊鏈的項目才開始接觸容器的概念，在使用的時候對目錄存儲這塊有所了解。
在將HyperLedger Fabric項目部署到生產之前，需要先將其存儲根目錄做下調整，以免日后遇到存儲目錄磁盤充滿的情況。
HyperLedger Fabric使用的是Docker容器，默認的掛載路徑是/var/lib/docker，這個是掛載在磁盤第一目錄下，即如果不做修改，今后備份、搬遷及擴容等都是大問題。
這里有兩個比較簡潔的解決方案：
一：服務器配置之初安裝docker時就指定其在額外掛載磁盤中。
這個意思很簡單，即新掛載磁盤到linux的data目錄下，docker容器就安裝到該目錄下，docker的卷宗文件也會在安裝時指定位置，如/data/docker/docker，通過docker info命令即可查看，即下圖所示：
二：通過修改docker配置文件來指定其卷宗文件存儲目錄。
這一步需要修改一個名為daemon.json的文件內容，該文件位於/etc/docker/目錄下
具體步驟如下：
編輯或新建daemon文件
sudo vim /etc/docker/daemon.json
在該文件中指定docker的存儲根目錄
1 { 2 "graph": "/data/docker/docker" 3 }
執行docker重新加載當前配置信息
sudo systemctl daemon-reload
重啟docker服務
sudo systemctl restart docker.service
至此，我們再次執行
docker info
來查看docker的存儲目錄位置，此時結果應該已經如第一種方法中的圖示一樣。
當然，該方法需要在部署生產之前就做好，切勿臨時變更。