设计理念与对比

本章节介绍 WANOS 与常见对象存储 / 工具（如 MinIO、SeaweedFS、rclone 等）的定位差异，以及为何选择当前的系统形态与架构设计。

核心定位：存储管理与编排，而非单一存储引擎

WANOS 的本质是一个构建在现有存储系统之上的 “存储控制面” (Storage Control Plane)。它采用 元数据与数据分离 的架构，更加关注 “存储管理与编排”，而非重新实现一套底层的对象存储引擎。

其核心目标包括：

碎片空间整合（Unified Namespace）：
- 面向已有的多种异构存储资源（云存储、本地盘、NAS、WebDAV、OneDrive 等），将分散、零碎的空间统一纳入一个逻辑层中进行管理。
- 透明分片 (Sharding)：利用元数据层将大对象切分为多个分片（Parts）分布到不同后端，既利用了碎片空间，也大幅提升了并发读写性能。
跨存储快速迁移：
- 支持在不同存储后端之间对对象进行迁移与回迁，例如从本地盘阵迁到公有云、从冷存储回迁到热存储等。
- 元数据驱动：由于元数据（SQL）与数据（Backend）独立，迁移过程只需移动数据块并更新索引，对上层业务透明。
边缘存储能力：
- 面向“边缘-中心”部署场景，Center 节点管理全局元数据，Edge 节点（DataNode）负责数据缓存和就近读写，降低跨区域流量与延迟。

在上述目标下，WANOS 选择构建的是以 S3 接口为统一入口的编排网关（基于 versitygw），而非一个单纯的对象存储服务实例。

MinIO 是一套优秀的对象存储实现，但它更偏向于提供高性能的存储引擎。WANOS 与其关注点不同：

关注点不同：Engine vs Orchestrator：
- MinIO：致力于构建一套高可用、强一致性的高性能存储集群（通常要求同构硬件、数据与元数据紧耦合）。
- WANOS：致力于 “纳管” 和 “编排” 已有的多种存储后端。你可以把 MinIO 作为一个高性能后端接入 WANOS。
碎片空间与资源整合：
- WANOS 不要求硬件同构，甚至允许混合使用本地磁盘和公有云接口。
- 通过策略，将对象映射到不同后端，而不是把所有数据都收敛到一个单一的物理集群里。
跨后端迁移与编排能力：
- WANOS 内置了精细的任务调度（如一致性校验、副本修复），可以在后端之间透明地移动数据，适合混合云与分层存储场景。

因此，WANOS 更像是运行在 MinIO、S3、各类云存储之上的 “统一入口与调度层”，而不是与 MinIO 直接竞争的单体对象存储实现。

很多分布式文件系统（例如 SeaweedFS 等）专注于提供完整的 POSIX 文件系统能力。WANOS 没有选择这条路线，而是做了以下取舍：

后端模型尽量简单：
- STorage 后端仅要求具备基本的 Key -> Value（Put/Get/Delete/Range）能力即可。
- 这使得 WANOS 可以轻松适配 WebDAV、OneDrive 甚至公有云 API，而无需处理复杂的块设备逻辑。
文件系统交由现有成熟方案处理：
- 文件系统层由现成工具负责，例如 s3fs、rclone 等，它们已经对接了 S3 接口。
- WANOS 服务端专注于 S3 协议，不直接承担 POSIX（锁、目录树权限）在广域网下的实现复杂度。
S3 接口优先，而非 POSIX：
- S3 的对象语义（不可变、分片上传、最终一致性）天然适合跨云与边缘环境。
- WANOS 将在 S3 接口层增加策略、迁移、生命周期等能力，作为对象管理与编排的统一入口。

在区域与边缘能力方面，WANOS 采用了比传统云厂商（Region 强隔离）更灵活的设计：

不强依赖“区域 = 桶”的绑定关系（逻辑桶）：
- 传统云存储通常将 Bucket 绑定到特定 Region。
- WANOS 中，Bucket 是逻辑概念。一个 Bucket 内的对象可以根据策略物理分布在“us-east”和“cn-north”的不同后端上，对用户透明。
就近访问与按需拉取（全局透明访问）：
- 当在某个区域访问对象时，DataNode 会优先从本地或其他近端节点获取；
- 若本区域尚无副本，从原始存储区域 回源拉取，并根据策略决定是否在本区域落地副本，实现“一次拉取，多次读取”。
边缘节点形成网状结构：
- 多个边缘节点（DataNode）之间可以形成网状拓扑，而非严格的树形主从结构；
- 对象在不同边缘节点之间的迁移与复制由 WANOS 的任务与策略框架负责，充当了一个智能的 “对象路由器”。

通过上述设计，WANOS 更像是一个面向多区域、多后端的 “对象流转与编排中枢”。