# 设计思路

# 背景

作者Orca (opens new window)，从2011年开始接触存储，部分工作经历与存储有关。从最早的单机对象存储到后来的分布式对象存储。有的是基于存储的应用（备份一体机、企业云盘、IM后端存储、feed流收发件箱等），也有单纯的公、私有云存储服务。有的是从0到1设计实现，有的是从1到100优化迭代。技术栈从基于文件系统的自研对象文件系统，到基于MySQL+OpenStack Swift（后文简称Swift）、到MongoDB+自研存储，到PhxPaxos+LevelDB的各种实现方案。老司机如果看到有说得不对的地方，还请不吝指教、私我修改，欢迎新同学随时私我交流、一起共建OrcaS。🎉🎉🎉

# 需求

我目前期望实现一个低成本的单机NAS用于存储私有数据，从几K的小文件到几G的大文件，能够提供一定的扩展性，在此基础上扩展成分布式版本，它应该能够运行在配置较低（CPU、内存、网络）的设备上，比如树莓派或者ARM上，存储可能也是廉价的低擦写次数的，比如TLC闪存的SD存储卡。

# 我希望它该有的样子

尽可能快
支持按需扩容
支持大、小文件
支持按需加密和压缩
传输层透明（端到端）
能够保障数据可用性
支持随机读部分数据
支持存储对象的多个版本

如果有这些功能，那就更好了：

秒传：服务端已经存在的文件，不再需要上传
权限控制（桶/对象）：可以扩展外链分享功能
多版本支持快照和闪回（flashback）
差分同步：同一个对象的多版本能减少传输和存储量
纠删码（EC）或者重复数据删除（CDC/FSP）：节省归档类存储的占用空间
能够识别对象类型：支持自定义插件，做对应的操作
在线预览：图片、视频、Office文档、PDF、CAD文档等
能够通过自定义存储适配器，引用、适配其他存储的数据
...

# 现状

近10多年来，开源基础设施大量涌现，动手实现一个简单的单机NAS越来越容易。比如：LevelDB/RocksDB、etcd/consul、各种Paxos/Raft的实现。这里我们先从单机NAS开始说起，通过提供相同的适配器，让实现多节点多副本等组合方案变成简单的事情。通过系列文章，我希望能够手把手带你实现一个NAS，借鉴同类设计的好的经验，一起交付一个好(sì)东(bù)西(xiàng)，并且这应该是不限制语言的，文中使用Go语言作为示例。

# 反思不好的设计

这么多年收获了不少经验，也有过不少过度设计、走弯路的经历，总结发现基于当下的场景去设计和实现才更有意义。

比如断电一致性中关于保障数据完整的部分，以前的方案是实时刷盘，在部分场景下，可改进为几秒刷一次盘，产生偶发故障后，能识别出需要重传的对象即可。
比如因为数据依赖元数据而存在，导致写入流程复杂、步骤多、性能差：先要创建不完整对象，再写入数据，再设置属性为完整。
比如提前设计了一些未来可能用的功能，维护了很多年直到被删除都没有被实际需求化到。
比如所有操作都是单对象的，改为批量很复杂，OrcaS默认操作是批量的。
比如数据部分还保留了上下级关系，增加了很多额外的维护成本。

# 路线图

☑️ 单机单副本 (opens new window)

支持上传下载的基础功能
以及额外的比如秒传、压缩、加密、打包等

☑️ 支持网络协议

中间增加网络传输层 (opens new window)，补充鉴权逻辑 (opens new window)
支持多种常见网络协议
支持cli工具 (opens new window)、前端管理页面 (opens new window)
支持前端界面 (opens new window)

⏳ 支持docker

支持开箱即用（借鉴MinIO）

⏳ 支持虚拟盘

支持smb协议
支持FUSE，能挂载成虚拟磁盘

⏳ 支持多副本、多节点、多集群

支持多节点分布式部署，默认3节点3副本配12块磁盘
支持负载均衡、高可用、故障切换方案
支持换盘、数据修复和迁移等
支持按集群扩容，规避集群内扩容的数据迁移问题
参考Ceph的PG，TiKV的PD等

⏳ 支持S3兼容

提供Amazon S3、Swift兼容的RESTful API

⏳ 支持纠删码

减少多副本的存储空间浪费

# 参考文档

设计方案 →