作为一名系统设计从业者，我们经常面临的一个核心问题是：如何为我们的应用程序选择最合适的存储方式？ 在构建现代云原生应用，尤其是迎接 2026 年复杂的 AI 原生场景时，存储不仅仅是“把数据存起来”那么简单。它直接关系到系统的性能、成本，甚至决定了我们能否处理海量的非结构化数据以喂养大模型。
在这篇文章中，我们将深入探讨云计算和系统设计中最重要的三种存储架构：块存储、对象存储和文件存储。我们会结合 2026 年的技术趋势，如 NVMe-over-Fabric、AI 数据湖以及智能分层存储，通过生动的类比、实际的应用场景以及代码示例，来彻底弄懂它们之间的区别，以及如何在实际工作中做出明智的技术选型。
目录
1. 块存储：高性能的“原始”基石与 2026 演进
首先，让我们来聊聊块存储。在系统设计的世界里，块存储就像是地基，它提供了最底层、最灵活的数据存储方式。但随着 2026 年的来临，这块基石正在经历一场性能革命。
什么是块存储？
块存储是一种将数据拆分成固定大小的“块”来进行管理的技术。每一个块都有自己独立的地址，它们就像是一堆散落的积木。对于传统的块存储系统来说，它只负责存储原始的字节，这种“无知”赋予了它极高的灵活性。
2026 趋势：从 EBS 到 闪电存储
在现代架构中，我们看到了NVMe（非易失性内存主机控制器接口规范） 的全面普及。传统的 SATA/SAS 协议已经无法满足当今数据库和 AI 训练作业对吞吐量的需求。在 2026 年，NVMe-over-Fabric (NVMe-oF) 成为了高性能块存储的标准。
这意味着，我们不再只是把本地硬盘挂载到服务器，而是通过网络（如 RoCE v2）以近乎本地内存的速度访问远程存储。这对于像 PostgreSQL 这样的 OLTP 数据库，或者是需要高频 checkpoint 的分布式 KV 存储来说，是至关重要的。
为什么选择块存储？（核心特性）
- 极低延迟： 现在的顶级云块存储（如 AWS io2 Block Express 或 Azure Ultra Disk）可以提供个位数微秒级的延迟。
- 事务性保障： 数据库需要强一致性，块存储提供了最底层的写入控制。
- 虚拟机与容器持久化： 这是 Kubernetes StatefulSet 的首选存储后端。
实际应用场景与代码示例
让我们来看一个在现代云环境中如何利用 Terraform 和脚本自动化管理高性能块存储的例子。
场景： 你正在部署一个高可用的 PostgreSQL 集群。为了保证 IOPS，你需要挂载一个支持多挂载（Multi-Attach）的块存储卷。
代码示例：自动化块存储挂载与优化（生产级脚本）
#!/bin/bash
# 这个脚本展示了我们在生产环境中如何初始化一个高性能的 NVMe 块存储卷
# 注意：我们在 2026 年的实践中，通常会使用 XFS 作为文件系统以支持大容量和高并发
DEVICE="/dev/nvme1n1" # 现代云实例通常通过 NVMe 总线暴露块设备
MOUNT_POINT="/data/pg_data"
# 1. 检查设备是否存在
if [ ! -b "$DEVICE" ]; then
echo "错误: 块设备 $DEVICE 不存在！"
exit 1
fi
# 2. 性能优化：在格式化前，我们可能需要根据云厂商的建议调整 I/O 调度器
# 对于 NVMe，通常不需要调整，但对于非 NVMe 块存储，设置为 ‘deadline‘ 或 ‘noop‘
# echo noop > /sys/block/${DEVICE##*/}/queue/scheduler
# 3. 创建文件系统
# 使用 -f 强制覆盖，-K 保留日志大小以优化性能
if ! blkid $DEVICE; then
echo "正在格式化设备 $DEVICE 为 XFS..."
sudo mkfs -t xfs -f -K $DEVICE
else
echo "设备 $DEVICE 已包含文件系统。"
fi
# 4. 创建挂载点并挂载
sudo mkdir -p $MOUNT_POINT
# 检查 /etc/fstab 避免重复条目
if ! grep -q "$MOUNT_POINT" /etc/fstab; then
# 挂载选项解释:
# noatime: 禁止更新访问时间，大幅减少元数据 I/O 开销
# nobarrier: 在有电池备份缓存的情况下禁用写入屏障，提升性能 (请谨慎使用)
# defaults: 标准选项
echo "$DEVICE $MOUNT_POINT xfs defaults,noatime 0 2" | sudo tee -a /etc/fstab
fi
# 5. 立即挂载
sudo mount -a
# 6. 设置正确的权限（例如 PostgreSQL 用户）
sudo chown -R postgres:postgres $MOUNT_POINT
echo "块存储 $DEVICE 已成功挂载到 $MOUNT_POINT"
深入解读：
在这段代码中，我们使用了 noatime 挂载选项。这是我们在生产环境中的一个最佳实践：告诉系统不要在每次读取文件时都去更新文件的“最后访问时间”元数据。对于数据库这种随机读写的场景，这个小改动可以带来显著的性能提升。
2. 对象存储：云原生的数据海洋与 AI 粮仓
当我们需要存储海量的非结构化数据时，对象存储是绝对的王者。到了 2026 年，对象存储不再只是存图片的仓库，它已经演变成了大数据和 AI 的核心。
什么是对象存储？
对象存储将数据作为“对象”管理。每个对象包含数据本身、元数据和唯一标识符。它放弃了文件层级结构，采用了扁平化的命名空间，使其能够轻松扩展到 EB 级别。
2026 趋势：AI 数据湖与 S3 Select
我们正处于一个 AI 爆发的时代。现在的对象存储（如 AWS S3 或 MinIO）直接集成了 Spark 和 Trino 等大数据引擎，以及 PyTorch 等训练框架。
此外，智能分层 策略变得非常成熟。数据在创建时是热的，存放在高频层；30 天没动，自动转入标准层；一年没动，自动转入归档层。这对于存储 TB 级的模型训练数据集至关重要，因为成本可以降低 90% 以上。
实际应用场景与代码示例
场景： 构建一个 AI 代理应用，用户上传的文档需要被存储，并被 LLM（大语言模型）检索。
代码示例：使用 Python 构建智能对象上传工具
import boto3
import os
from botocore.exceptions import ClientError
# 我们封装了一个类，用于处理生产环境中的对象存储逻辑
class AIStorageManager:
def __init__(self, bucket_name):
self.s3_client = boto3.client(‘s3‘)
self.bucket_name = bucket_name
def upload_training_data(self, file_path, category, doc_id, tags=None):
"""
上传文件并附加丰富的元数据，方便后续通过 AI 检索
"""
object_key = f"datasets/{category}/{doc_id}/{os.path.basename(file_path)}"
# 构建 Metadata：这是对象存储区别于简单文件系统的关键
# 我们在这里存储标签，这样检索时不需要下载文件即可判断内容
metadata = {‘category‘: category, ‘doc-id‘: doc_id}
if tags:
metadata[‘tags‘] = ",".join(tags)
try:
# upload_fileput 会自动处理多线程上传，大文件也不怕
self.s3_client.upload_file(
file_path,
self.bucket_name,
object_key,
ExtraArgs={
‘Metadata‘: metadata,
‘StorageClass‘: ‘STANDARD‘ # 新数据默认标准层
}
)
print(f"[SUCCESS] 文件已上传: {object_key}")
return object_key
except ClientError as e:
print(f"[ERROR] 上传失败: {e}")
return None
def set_intelligent_tiering(self, object_key):
"""
演示如何动态切换对象的存储层级
"""
try:
self.s3_client.copy_object(
CopySource={‘Bucket‘: self.bucket_name, ‘Key‘: object_key},
Bucket=self.bucket_name,
Key=object_key,
StorageClass=‘GLACIER_IR‘ # 即时检索归档层，成本极低
)
print(f"[INFO] 对象 {object_key} 已移至归档层")
except Exception as e:
print(e)
# 模拟使用
manager = AIStorageManager("my-ai-app-bucket")
# manager.upload_training_data("./training_docs.pdf", "finance", "doc_001", tags=["audit", "2026"])
深入解读：
请注意代码中的 Metadata 部分。在 2026 年的系统设计中，对象存储的元数据管理是构建“可观测性”和“AI 就绪”数据湖的关键。我们在上传时就把结构化信息打好标签，后续处理数据的 Agent 就可以直接读取这些元数据，而无需下载整个文件，这将极大地节省带宽和成本。
3. 文件存储：传统共享的新生 (NFS vs. 性能)
文件存储是最符合我们日常直觉的一种存储方式。在容器化时代，它依然扮演着重要的角色，虽然边界正在缩小。
什么是文件存储？
文件存储采用了层级结构。数据被保存为“文件”，文件被组织在“文件夹”中。在网络环境中，通常通过 NFS 或 SMB 协议实现。
为什么我们依然需要它？
虽然对象存储很强大，但很多遗留应用（如 legacy CMS）或者需要强 POSIX 兼容性的科学计算应用，无法通过简单的 HTTP API 读写数据。它们需要 INLINECODE16e1af3a、INLINECODE2791138f 等高级文件锁功能。这时，高性能的 NAS（网络附加存储）就是必不可少的。
2026 年的陷阱： 千万不要把高并发的日志文件写入 NFS，也不要在 NFS 上运行数据库。网络延迟和协议开销会拖垮整个系统。
4. 混合策略：AI 原生时代的存储矩阵
在 2026 年，我们不会问“哪个更好”，而是问“如何组合它们”。让我们来看一个极具现代感的应用场景：AI 辅助编程平台的后端架构。
场景设计：
- 代码库：
* 存储方式： 对象存储。
* 理由： 代码仓库本质上是有版本控制的文本文件。虽然 Git 操作频繁，但现代 Git 托管平台通常将大文件或归档包存储在对象存储中，利用其极高的持久性和低成本。
n2. 协作编辑状态：
* 存储方式： 内存数据库 + 块存储 (RDBMS backed by NVMe Block Storage)。
* 理由： 当你和你的结对编程伙伴同时编辑一行代码时，需要极低延迟的事务锁。对象存储做不到这一点。我们需要 NVMe 块存储支持的 PostgreSQL 或 Redis 来处理实时的 OT（Operational Transformation）算法。
- 用户生成的截图/录像：
* 存储方式： 对象存储。
* 理由： 非结构化数据，且需要通过 CDN 直接分发给用户。
- AI 模型文件（Weights）：
* 存储方式： 对象存储 (冷) + 内存文件系统 (热)。
* 理由： 模型文件（如 70B 参数的 LLM）非常大（几百 GB）。启动时，我们会从对象存储（S3）通过高带宽网络拉取模型，挂载到计算节点的临时内存文件系统（如 Linux 的 tmpfs 或 GPU 显存直接映射）中运行。这是结合块存储理念（高速访问）和对象存储（持久化备份）的极致表现。
代码示例：Python 中的智能存储路由器
作为架构师，我们经常封装一个“存储路由”，让业务代码无感知地选择存储后端。
import os
from abc import ABC, abstractmethod
class StorageBackend(ABC):
@abstractmethod
def save(self, data, identifier):
pass
class BlockStorageSimulator(StorageBackend):
"""模拟用于高频事务的块存储写入"""
def save(self, data, identifier):
# 实际生产中，这里会写入 /mnt/nvme-vol/data.db
print(f"[Block Store] 写入高速块存储: {identifier} ({len(data)} bytes)")
# 模拟写入数据库的 I/O 操作
with open(f"/tmp/{identifier}.db", "wb") as f:
f.write(data)
class ObjectStorageSimulator(StorageBackend):
"""模拟用于海量归档的对象存储写入"""
def save(self, data, identifier):
# 实际生产中，这里会调用 S3 SDK
print(f"[Object Store] 上传至对象存储桶: identifier} ({len(data)} bytes)")
# 模拟网络传输开销（略）
class StorageRouter:
def __init__(self):
self.nvme_backend = BlockStorageSimulator()
self.s3_backend = ObjectStorageSimulator()
def persist_data(self, data, category, identifier):
"""
根据数据类型自动路由到最合适的存储
"""
if category == "real_time_session":
# 需要低延迟事务支持 -> 块存储
return self.nvme_backend.save(data, identifier)
elif category == "user_avatar" or category == "model_checkpoint":
# 大文件，持久化 -> 对象存储
return self.s3_backend.save(data, identifier)
else:
raise ValueError("Unknown data category")
# 实际业务调用
router = StorageRouter()
session_data = b"x01x00..." # 模拟二进制会话数据
user_avatar = open("avatar.jpg", "rb").read()
router.persist_data(session_data, "real_time_session", "session_123")
router.persist_data(user_avatar, "user_avatar", "user_alice")
总结与 2026 前瞻
当我们审视系统设计中的存储方案时，本质上是在做性能、成本与复杂度之间的权衡。站在 2026 年的视角，这一趋势更加明显：
- 边界模糊化： 随着缓存层和文件系统的进步，对象存储正在通过缓存技术模拟文件接口，而块存储也在利用快照技术实现对象级的灵活性。
- Serverless 下的存储： 我们越来越少地去“挂载”硬盘，而是通过 API 访问存储。未来的开发者可能根本不需要知道
lsblk是什么，因为他们面对的都是纯粹的云存储抽象。
希望这篇文章能帮助你不仅理解这些概念的定义，更能在实际面试或架构设计中，自信地说出：“在这个场景下，我选择混合方案，利用 NVMe 块存储承载热数据，利用对象存储归档冷数据，并通过智能缓存层连接二者。”
接下来，我建议你可以尝试在自己的环境中，利用 Local Persistent Volumes (Kubernetes 中的块存储概念) 来优化你的有状态应用性能，或者搭建一个 MinIO 来体验私有云对象存储的威力。