1. Yunfs的由来

多年前，大概是09年的时候，我老婆所在的外贸公司正在使用一种ERP系统，员工们普遍报怨ERP系统不仅没有提高工作效率反而增加了不少工作量，因为我之前从事过政务管理方面软件的开发，对管理系统的开发也有所心得体会，所以我就对老婆说，我能够开发一款简单易用的ERP系统先给她免费使用，如果使用的效果不错，再推广给她们公司使用。老婆一听，当然好了，立马就同意了，自此我便开始了这个ERP系统的设计开发。

在设计ERP的过程中，感觉这个ERP的技术实现上很简单，基本上没有挑战性，复杂的只是些业务逻辑，可以由一个web版的前端加上一个后台DB来做即可。因为我是系统工程师出身，更喜欢做些技术挑战性的工作，加上当年NoSQL也是刚刚推出的新生事物，所以便有了编写一个NoSQL数据库的念头。啊！！！你疯了吗？？，为了写一个ERP，决定自行开发一个NoSQL数据库。对，你没看错，我也没疯，我喜欢做一些挑战性的事情以此来磨练自己的技术，喜欢创造新的系统，更愿意当一个建筑师（题外话，我喜欢玩模拟城市）。

过了几个月，当我跟老婆及她们公司同事一起出去游玩时，她同事在饭桌上问我：

“听说你在为我们开发ERP系统，这个ERP开发的如何了?”

我听到后，心里苦笑回答道：

“我正在重新造一个大轮子，需要花更多时间做这个”

当然直至今日，我也没有完成这个ERP系统，老婆也没有因此责备我，虽然这个ERP系统并没有完成，但是Yunfs却由此诞生，这就是Yunfs 的起源。

2.Yunfs的发展经历

当我决定为这个ERP系统开发一款NoSQL 数据库时，我感觉NoSQL跟文件系统并没有多大区别。 相比传统意义上的文件系统，NoSQL数据库近来年在用户中更流行，很多新用户都在尝试使用NoSQL。 但是我相比于NoSQL而言，更熟悉文件系统，所以文件系统比NoSQL更加吸引我，更重要的是我开发的新文件系统也可以提供强大的数据库服务，因为这个新文件系统不是一个传统意义的文件系统，它更像是一个内存缓冲服务器。 所以我决定开发一款新概念的文件系统，这个决定在准备设计开发的ERP的第一天就确定了。

首先，YunFS 曾用名SlabFS，如果你比较熟悉Linux Kernel的话，一定会清楚Slab 是kernel 里最重要的管理内存的机制。 Solaris 发明的ZFS一出世，就给了世界一个震憾，磁盘的管理可以被当成内存池来管理，再没有了磁盘卷的概念，取而代之的是池概念。ZFS的设计者其实也是Slab机制的发明者（Jeff Bonwick）如果你知道了这个渊源，就能明白为何ZFS会被那样设计。当我在学习ZFS的源码时，我想，我可以设计一款新文件系统比ZFS设计的更加激进与纯粹，因为磁盘块的管理可以完全使用内存Slab技术。Slab机制是一件比较好的技术机制，它已经在kernel 里被证明非常适合于管理小内存。 所以全内存是Yunfs的重要特性之一，磁盘块被线性的当成内存块来管理。

当云计算，云存储流行的今天，单机的文件系统已经失去了公众的目光，所以当我的第一个SlabFS 文件系统原型诞生后，我遇到的第一个问题是，SlabFS的意义何在，现在市面上已经有了太多的单机文件系统，不多你一个，也不少你一个。所以我对SlabFS的未来陷入了深深的思考，SlabFS可以成为一个分布式文件系统，基于云端存储。为什么我们需要基于云端存储，因为云端存储就是一个对象存储文件系统，一个分布式的键值文件系统，作为一个对象存储，它并没有层级的概念，只有键值概念。所以我便改名SlabFS为YunFS, 一个基于云端对象存储的分布式文件系统。

作为一个分布式文件系统，最大的挑战就是分布式数据的一致，为了解决这个数据一致性问题，YunFS引进了RAFT协议来保障数据一致性，简单概述RAFT就是一个领导者负责制的协议，只有领导者才有权力写，其它跟随者只有读的权力，领导者是由一群跟随者选举而成，每个跟随者都可以成为候选人，都有成为领导者的可能。

为了缓解云端存储的开销压力，我们存储一至两个备份到云端存储，云端磁盘块被按需调用缓冲到本机磁盘，一个分布式的元数据表用来记录每个磁盘块的版本号及散列值，这个元数据表是即时在各个YunFS节点进行同步的，所以当一个被缓冲在本地的磁盘块发生了改变时，YunFS节点会请求远端的云存储进行本机磁盘块缓冲即时更新。

随着越来越多的人开始在现实生活中使用比特币，这个分布式的区块链吸引了我的目光，并带来了一些新的想法。YunFS采用了比特币块链的技术设计，把一个大的磁盘块分成无数个固定长度的小块（8M每块）， 这些小块被存储在Amazon S3，或者其它的云存储上，通过定制YunFS Disk Module, 它可以存储在任何第三方的云存储之上，YunFS可以管理的最大磁盘块是2⁶⁴ byte， 基本上够用了，虽然云端存储公司都声明它们可管理的存储是无限的。但是YunFS的设计哲理是够用就好，我不会说它是无限的，虽然我们只用了非常小的部分。

3. YunFS特性简述

作为一个基于云端存储的分布式文件系统，YunFS有一些特性是区别于传统的文件系统的。YunFS的磁盘块是被直接保存在云端的，它没有卷的概念，使用了一个被分割为小块的线性大磁盘。 大多数的云存储公司都声明它们的稳定性及有效性都高达99.999%，YunFS可以直接享受到这些云存储公司提供的好处，不再担心数据丢失或损坏。我们可以存储相同的磁盘备份到不同的云存储公司，这样就可以享受到双重数据安全保障了。

  * 基于一个分布式框架平台，提供了基本的RPC服务，所以任何跟随者节点可以直接通过RPC远程调用领导者节点提供的特权函数进行特权访问，如CREATE、DELETE，ADD，REMOVE。

  * 分布式框架平台是完全是动态模块化设计，可以方便INSTALL，UNINSTALL，START，STOP 模块通过一个CLI接口，你可以随时查看当前模块的运行状态，是运行中还是被停止，可以随时安装卸载模块，即插即用。

  * 分布式框架平台提供了自动代码生成器，通过一个IDL文件，1秒内自动生成了所有模块代码，简单换句话说，当你完成了IDL文件的定义，一秒后，就你可以看到模块的运行结果。它同时提供了模板测试代码自动生成，通过定义一个测试策略文件，所有的测试代码自动生成。测试策略逻辑还需要用户自定义，目前我们还做不到全自动生成测试代码，那个是AI自动编程，目前还只是半自动生成。

  * 提供目录层次结构的文件系统，提供实时读写流，实际上Amazon的S3对象存储并不能做到这两点，S3只是对象存储，不能提供真正的目录层次结构（对象存储只有一级结构，平级），及实时流读写，它只能完整的读取一整块，写一整块（对象存储的键值特性）

  *作为一个全内存文件系统，磁盘块的管理被当成内存块来管理，所有的磁盘块被访问后，会同时在内存中存在相同大小的内存缓冲，所有操作是首先在内存中被完成后，然后再随后同步到磁盘上来。

  * 采纳了比特币的块链设计，一个线性的大磁盘块2⁶⁴, 被分割成为无数的小磁盘块，这些小的磁盘块是存在云端存储上的。 没必要我们存储一个非常大的磁盘块在S3上，然而我们却只想要其中的一小块，记住，云存储的流量费也是一笔不少的费用开销，S3的对象存储决定了，你要么拿一个完整的块，要么不拿，只想拿一个大块中的其中一小部分，可以直接告诉你No Way.

  * 提供HTTP REST服务，任何第三方平台或者软件通过REST来访问YunFS，Create、Remove, Read, Write. YunFS并不提供任何Posix接口，它的定位是只为Web应用而生，不是传统意义上的单机磁盘文件系统。

   * 分布式数据一致性，YunFS是单一领导者，多个跟随者设计，分布式一致性算法采用的是RAFT 一致性算法，本来只有领导者才能进行特权操作，经过优化的分布式自治系统，每个节点都有比较大的自治特权，可以在本节点专属的池内创建，删除，读写文件，因为采用的是Share Nothing 设计，所以在节点专属池内的任何特权操作都是完全自治，并不需要领导者的确认才能进行，只需要事后通报给领导者即可，所以可以达到线性的性能扩展能力。无论是读，或写，或创建，或删除，都是线性的性能扩展。在地点敏感的最近地点应用中，这种可线性扩展的能力会有着极大的吸引力。

哈哈，下面就是YunFS的 体系框架图

下面是yunfs的运行图

如果你对YunFS有更多兴趣，可以访问

https://www.amazon.com/Distributed-Cloud-YunFS-Concepts-Design/dp/1517334349