|
|
导读：JuiceFS 是一个为云环境而设计的散布式文件零碎，在 2021 年终开源后，过来一年在开源社区里开展很快，也遭到了得多关注。本次分享但愿让大家理解 JuiceFS 的设计配景、设计理念，以及它可以为开发者带来的帮忙和价值。
明天的引见会环抱上面四点展开：
文件存储的开展云时期的痛点与应战JuiceFS 的设计哲学JuiceFS 的使用场景分享佳宾｜苏锐 Juicedata 合伙人
编纂整顿｜王羽凡 大疆
出品社区｜DataFun
01
文件存储的开展
rvi031qfghq.jpg
首先咱们回顾一下文件存储的开展历程。
1. 局域网时期
2005 年以前仍是一个以局域网为主的阶段，互联网才刚刚开始。这个时代的散布式文件零碎或者说文件存储大部份是软硬一体的产品，咱们能在市场上看到 NetApp、EMC 还有华为的一些存储柜子。这些产品给得多用户留下了一个印象，那就是存储实际上就是买硬件，买一个存储的柜子就搞定了。
2. 互联网时期
2005 年之后，宽带互联网在寰球规模内遍及，互联网时期到来了。Web2.0的开展速度十分快，由第一代互联网那种简略呈现动静的门户网站转变为了一个一切用户均可以在网络上互动的产品状态，泛起了像社交网络这样的产品。全部互联网发生的数据发作式增长，这样的趋向也就致使像局域网时期同样去买硬件的存储柜曾经跟不上网络时期数据增长的开展了。由于买硬件的柜子会波及到选型、推销、到货、上架这样一个很长的流程，需求做很谨严的容量布局。
就在这个时间点上 Google 提出了他们的 Google File System 的论文，同时在技术社区外面泛起了第一代纯软件定义存储的散布式文件零碎产品。大家熟知的像大数据畛域的 HDFS，曾经被红帽收购的 CephFS、GlusterFS，还有过后面向 HPC 场景的 Lustre、BeeGFS 这些产品都是在 2005 年到 2009 年这样一个很短的时间窗口内降生的。这也就象征着这些产品都有一个独特的时期配景以及面向过后硬件环境的设计，好比说过后尚无云的存在，一切的这些散布式文件零碎都是面向机房里的物理机设计的。而过后的机房环境和明天最大的区分就是网络环境，过后机房外面是以百兆网卡为主的，如今机房外面根本都是万兆网卡了，这些给咱们的软件设计和 IT 根底架构的设计带来了得多的改动。
第一代软件定义存储的产品像 HDFS 和 CephFS，以及 AI 盛行当前的 Lustre 依然在被得多公司在不同规模内使用。这些产品在开展过程当中面对的新的应战就是挪动互联网的泛起。
3. 挪动互联网时期
2010 年之后的十年时间，挪动互联网比拟 Web2.0 最大的变动就是之前人们只能坐在电脑前使用网络发生数据，而到了挪动互联网时期，每集体天天醒着的时分均可以使用手机来发生数据，这就象征着全部互联网上数据的增长速度又快了一两个数量级。
第一代面向机房，用软件搭建散布式存储和散布式零碎的计划在挪动互联网时期也遇到了应战，这也就让私有云应运而生。最先的像 AWS 就是在 2006 年公布了第一个产品 S3，在过后都尚无全部私有云的体系，没有 EC2 这样的计算环境，只要一个存储办事 S3。S3 就是想简化以前人们本人搭建机房，推销硬件而后经过软件去搭建散布式零碎这个繁杂的进程。对象存储在挪动互联网时期有了一个十分疾速的开展，它的降生是为理解决以前散布式文件零碎的一些问题，但也致使就义了一些才能，这个咱们前面会再展开讲。
4. 云原生时期
在挪动互联网蓬勃开展之后，当初又迎来了物联网的开展，这对存储的范围、易办理性和扩展才能等各方面都有了一个全新的要求。当咱们回顾私有云时会发现短少一个十分合适云环境的散布式文件零碎，间接将上一时期的 HDFS、CephFS、Lustre 这样的产品放到私有云上又不克不及体现出云的劣势。
02
云时期的痛点与应战
1. 各代文件存储的特性
h1ik4tvyu5s.jpg
下图展现了这四个时期对应的存储产品的特征，以明天的视角回看，其中红字是每代产品中存在的问题，绿字是其好的特性。
2. 软硬件一体 NAS
第一代硬件产品在过后都是采取专有的硬件，扩容其实不便利，由于兼容问题无奈将不同厂商的硬件对接到一同使用。而且过后这一代软硬一体 NAS 也短少高可用，大部份采用主从互备的形式。关于明天更大负载，更大范围的零碎主从互备的可用性是不敷的。另外，还存在总体本钱较高的问题，由于需求专门的硬件，网络环境和相婚配的保护才能。
过后这一套软硬一体 NAS 有一个最大的劣势就是它是 POSIX 兼容的，学习本钱很低，对用户而言就和使用 Linux 当地盘的体验是同样的。这就象征着开发下层运用的时分是十分简略的，无论间接经过零碎调用仍是经过各种言语的框架去开发都是 POSIX 兼容的，会很便利。
3. 第一代软件定义散布式文件零碎
到了互联网时期，第一代软件定义散布式文件零碎包罗 HDFS、CephFS 再也不依赖于专有硬件，都是用规范的 X86 机器就能搞定了。比拟第一代软硬一体的扩展性有所进步，然而和起初的云存储比拟仍是不容易扩展，能看到像 CephFS、HDFS 也都有一些单集群的下限，这是在过后的容量范围下进行设计培养的局限。
另外依然短少高可用的设计，大部份仍旧采取主从互备，这样一来依然要为机房独立的推销硬件，钻研、保护大范围的散布式零碎，因此总体的 TCO 仍是相对于较高的。同时比拟上个时期关于运维的应战更高了，由于不存在厂商的办事了，需求本人构建一套运维团队，具有足够的运维才能，深化掌握这套开源的文件零碎。
好在像 CephFS、Lustre 这些依然是 POSIX 兼容的，而 HDFS 为了知足大数据 Hadoop 生态架构提出了一套新的存储接口 HDFS API。假如具体的去剖析这套 API 能发现它实际上是 POSIX 的一个子集，假定说 POSIX 有 200 个接口，到 HDFS 大略就剩下一半。从文件零碎的功用下去看，它是对一个残缺的文件零碎做了一些裁剪，好比 HDFS 是 Append Only 的文件零碎，也就是只能写新数据、追加文件，而不克不及对已有的文件做掩盖写。这是过后 HDFS 为了完成更大范围数据的存储而就义掉的一部份文件零碎语义上的才能。
4. 对象存储
对象存储比拟以前的文件零碎提出了三个中心的才能：易扩展、高可用和低本钱。在这三个中心才能的根底上提出要完成办事化，即用户再也不需求投入任何本钱在搭建、运维、扩容这些事件上了；另外还提出作为一个云办事要能装下足够海量的数据。
然而与此同时也就义了得多文件零碎原生反对的才能。
第一是接口少了。对象存储提供的 API 往往是 HDFS 的一个子集，比拟 POSIX 能提供的才能就更少了。后面举例说如果 POSIX 有 200 个 API，那到 HDFS 可能只要 100 个了，到 S3 的时分大略只剩 20-30 个了。
第二是元数据操作机能降落了。对象存储自身并非为那些需求操作繁杂元数据的运用设计的，最开始设计对象存储只是想完成数据上传再经过 CDN 进行散发这样一个简略的业务模型。最后S3里的接口其实只要 PUT、GET 和 DELETE，起初又衍生出了 LIST、HEAD，但能看到像 RENAME、MV 这些在文件零碎里很常见的操作至今对象存储都是不反对的。
5. 对象存储与文件零碎的区分
接上去咱们再展开看一下对象存储和文件零碎的几个区分。
1npk4eo51r1.jpg
6. 拜候接口的数量
POSIXPOSIX 协定曾经内置到 Linux 操作零碎的内核里了，能够经过零碎调用间接拜候一个 POSIX 兼容的存储零碎，Open、Write、Read 这些规范的接口也曾经内置到各个编程言语外面了。在 POSIX 之上构建出来的运用生态从 Linux 开始盛行到当初最少有三十年的时间了，再基于 POSIX 规范去做全新的文件零碎下层运用不需求做任何的适配修正，也不需求提供任何特殊的 SDK，各个言语都是能够间接拜候的。
HDFSHDFS 是一个只能追加的文件零碎。它提供了一套本人的 SDK，好比说有大家熟知的用在 Hadoop 外面的 Java SDK。但这给下层的运用开发带来了一些新的应战，即原来的顺序是没方法间接使用 HDFS 的，必需在跟文件零碎打交道这一层去做交换。交换的过程当中就要去斟酌接口之间是否一一对应的，不合错误应的时分用甚么形式能构建平滑的映照瓜葛。
HDFS 通过十几年的开展曾经成为 Hadoop 畛域的一个默许规范，但其真实其余畛域并无失掉普遍的运用，就是由于 HDFS 有着一套本人的 API 规范。HDFS 明天最成熟的仍是用在 Hadoop 体系外面的 Java SDK。而其余的像 C、C++、Python、Golang 这些言语的 SDK 成熟度都还不敷，包罗经过 FUSE、WebDAV、NFS 这些拜候 HDFS 的形式也不是很成熟，所以致今 HDFS 次要还只停留在 Hadoop 体系内去使用。
S3S3 最开始是基于 HTTP 协定提供了一套 RESTful API，益处是更为的规范和凋谢，然而同时也象征着它和现有的运用顺序是彻底不克不及兼容的，每一个个运用都需求面向它做对接适配或者针对性的开发。S3 自身提供了得多言语的 SDK 便利开发者使用，也降生了一些第三方名目，其中最著名的是 S3FS 和 Goofys。这两个名目都是反对将 S3 的 Bucket 挂载到零碎里，像拜候当地盘同样读写数据，当初各个私有云上也有提供针对本人对象存储的一些相似计划。
虽然这些可以完成把 Bucket 挂载到操作零碎里，然而无奈提供的是数据强统一性的包管，而后是高机能的 Listing，之前在当地盘里列目录是一个很轻量的举措，然而在对象存储的 Bucket 里去列目录机能代价是很高的。另外，对象存储也尚无反对原子的 Rename 和对文件进行随机写。POSIX 兼容的文件零碎里是有 API 反对对文件的随机写的，关上一个文件而后 Seek 指定的偏移量去更新它的内容。然而在对象存储下面要想完成对数据或者说对文件的局部进行更新，独一能做的就是先将文件残缺的下载到当地，更新其中需求修正的那一部份数据，再把这个文件残缺的上传回对象存储外面。全部随机写的操作代价是十分大的，无奈反对需求随机写的运用。
7. Rename 的行动差别
nt0dccpziw0.jpg
当初 S3 原生的 API 里依然没有 Rename，民间 SDK 和得多第三方工具确实提供了这个功用，好比经过 Goofys 或者 S3FS 把 Bucket 挂载到机器上再履行 Rename。但这里的 Rename 和文件零碎原生的 Rename 是有差异的，这里举一个例子。
yuktys2bun5.jpg
左侧摹拟文件零碎，这是一个树形构造的目录树。而对象存储是不存在原生的树形构造的，它会经过设置对象的 Key 值（对象名）来摹拟出一个门路，实际上对象存储外面的数据构造是扁平的，即右侧这样的构造。
假如此时要履行一个 Rename 操作，把 /foo 这个目录名改为 /bar，由于文件零碎是树形的数据构造，所以它就可以找到这个目录名对应的 Inode 去履行一个原子的更新，把 foo 交换成 Bar。
由于对象存储的数据构造是扁平的，所以需求在对象存储里对这个 Key 的索引去做一次搜寻，找到一切以 foo 为前缀的对象，多是 1 个也多是 100 万个。搜寻出来当前要将这些对象进行一次 lO 拷贝，用新的名字作为 Key 值复制一遍，复制之后再更新相干的索引信息同时删掉旧的对象。
能看到这是一个对比长的操作进程，要先搜寻对象，而后拷贝，再更新索引，全部进程实际上是没有事务去包管的，有可能会泛起统一性问题。目前大部份的对象存储会包管终究统一性，只要多数的对象存储会在本人原生的 API 外面包管强统一性，然而在第三方工具做的像 Rename 这样的衍生 API 里依然只是包管终究统一性。
8. 终究统一性
raasds10erw.jpg
这里再经过一个例子来解释终究统一性以及它可能对运用酿成的影响。
这里画了一副漫画，讲了老奶奶的一只猫跑到了树上，她想请这个小敌人帮她救猫，小敌人说没问题，我帮你把猫拿回来。大家能够看到他竟然从此外一个画面里把猫给取了出来，老奶奶很纳闷，为何树上和小敌人手里各有一只猫？小敌人说这只是一个 SYNC 的问题，你再去 Check 一下就行-了，老奶奶再往树上看的时分树上的猫曾经不见了。这里其实就体现了后面讲的 Rename 的进程，即在一个很长的流程里数据没有放弃残缺的统一性形态。
对应的命令在左侧，首先列了一下这个 Bucket 的目录，发现有一个文件 cat.txt，将它 MV 到新的目录，换完目录之后看到原来的这个目录外面还有这个cat.txt，而新的目录里也有了一个 cat.txt，此时看到了两只猫，这看起来就不比是 MV 的操作了。但其实这是一个 SYNC 形态的问题，可能过了一会再去原来的旧目录里查看文件就会发现 cat.txt 不见了，在操作过程当中去视察时数据形态尚无统一，然而零碎会包管终究是统一的形态。而假如下层的运用在数据形态纷歧致的时分就曾经去依赖它来进行下一步操作的话，那运用可能就会犯错了。
这里举了几个例子来讲明虽然明天对象存储是可以给咱们提供优秀的扩展性、昂贵的本钱和便捷的使用形式，然而当咱们需求对数据进行更繁杂的剖析、计算操作时对象存储依然会给咱们带来一些不便利之处，好比说接口很少、需求针对性的开发、元数据的机能差。之前在文件零碎里很轻量的操作，在对象存储里可能会变得很繁杂；另外还可能会引入一些统一性的问题，对数据准确性要求很高的场景就不合适了。
03
JuiceFS 的设计哲学
从软硬一体到第一代软件定义文件零碎再到 S3 各有各的优缺陷，所以明天当咱们在云的环境外面去看的时分会觉察短少一个十分完美，十分合适云环境又能很好的反对大数据、AI 还有一些新兴的海量数据处置或者密集计算这些场景的文件零碎产品，既能够闪开发者十分容易的使用又有足够的才能去应答这些业务上的应战，这就是咱们设计 JuiceFS 的初衷。
qw3ut2inpmy.jpg
1. JuiceFS 的设计指标
（1）多场景，多维度
后面剖析了以后市面上的场景，当咱们想去为云环境设计 JuiceFS 这个产品的时分，咱们开始斟酌本人的设计指标，要对比后面这些产品的一些优优势和它们的设计思绪，同时也要更多的关注用户业务场景的需要。文件零碎是在全部 IT 根底架构中十分底层的产品，使用它的场景会十分的丰硕，在不同的场景里对文件零碎自身的范围、扩展性、可用性、机能、同享的拜候才能以及本钱乃至还有得多维度的要求都是纷歧样的，咱们要做的是云环境通用型产品，就需求在这个矩阵下来做取舍。
2. 架构的设计选择
在多场景、多维度的条件下做架构设计时有几个微观的标的目的是咱们十分坚持的：
彻底为云环境设计元数据与数据别离这类设计会为咱们在多场景多维度下来做取舍的时分带来更多的灵敏性。像 HDFS 是元数据和数据别离的计划，而 CephFS 就更像是元数据和数据一体的计划。
插件式引擎咱们提出把 JuiceFS 设计成一种插件式的引擎，让数据办理、元数据办理包罗客户端都能提供一种插件式的才能，让用户结合本人的场景去做不同维度上插件的选择，来拼插出一个最合适本身业务场景需要的产品。
Simple is better咱们始终坚持 Linux 的一个最根本的设计哲学“Simple is better”，要尽量的放弃简略，一个根底设施产品只要足够简略能力做的足够硬朗，能力给用户提供一个易保护的使用体验。
3. 症结才能
再细化一层到 JuiceFS 产品设计的症结才能上，咱们提出在运维上做办事化，像 S3 同样使用，不需求用户本人保护；能反对多云，而非针对某一个云或者某一种环境设计，要在私有云、公有云、混合云的环境里都能用；反对弹性伸缩，不需求手动扩容缩容；尽量做到高可用、高吞吐和低时延。
后面提到 POSIX 协定以及 HDFS 和 S3 各自的规范，虽然 POSIX 是一个拜候接口上的最大集，但通过这些年的开展后，如今 Hadoop 生态中面向 HDFS 开发的组件十分之多，S3 通过十几年的开展面向它 API 开发的运用也十分多。这三个是明天市面上最盛行的拜候规范，因此最现实的状况是在一个文件零碎上可以对外输入三种不同规范的 API 的拜候才能，这样已有的这些顺序就均可以间接对接进来，新的运用也能够选择更合适的拜候协定进行开发。
强统一性是文件零碎必备的才能，终究统一性是不克不及被承受的；还有海量小文件的办理，这是上一代文件零碎广泛都没有解决的问题，由于在上一代的时间点上基本不存在海量小文件的场景，而明天咱们看到在 AI 的畛域外面，办理海量小文件逐步变成根底需要。好比说在自动驾驶、人脸辨认、声文剖析这些场景外面大家都在面对着十几亿，数十亿乃至上百亿的文件，而又没有一个文件零碎可以应答这样的范围，咱们设计 JuiceFS 就要解决这个中心问题。前面还包罗用通明的缓存做减速，尽可能放弃低本钱这些也都在咱们的设计指标里。
4. JuiceFS 的架构设计
5bmc1llyyvk.jpg
当初让咱们来看一下终究的设计，左侧是 High Level 的架构图，右侧是数据存取的构造图。
5. 总体架构
架构图能体现出咱们插件式的设计，这里有三个大的虚线框分别表现散布式文件零碎里的三大组件：左下角的元数据引擎，右下角的数据引擎以及上方的拜候客户端。元数据引擎，数据引擎和客户端三个组件都是插件式的设计，开发者能够结合详细运用和本人相熟的技术栈去做选择。
在元数据引擎上用户能够选择市面上最盛行的开源数据库包罗 Redis、MySQL、PostgreSQL、TiKV，比来还反对了单机的 SQLite、BadgerDB 和 Kubernetes 上大家对比相熟的 ETCD，还包罗咱们目前正在自研的一个内存引擎，总共曾经反对了 9-10 款不同的存储引擎可以去办理 JuiceFS 的元数据。这样设计一是为了升高学习本钱和使用门坎，二是能够便利用户结合详细场景对数据范围、机能、耐久性、平安性的要求去做取舍。
数据引擎是用来存取数据文件的，咱们兼容了市场上一切的对象存储办事。回顾上一代的散布式文件零碎，HDFS 里有 Datanode，CephFS 里有 RADOS，简直每一个个文件零碎都做了一件独特的事件就是把少量的裸机节点里的磁盘经过一个办事办理好，包罗数据内容和数据正本。当咱们斟酌为云环境设计的时分就发现私有云上的对象存储曾经能把数据办理做的十分完善了，它有足够强的扩展性，足够低的本钱，足够平安的才能。所以咱们在设计 JuiceFS 的时分就再也不本人去做数据办理而是彻底交给对象存储来做。无论是私有云公有云仍是一些开源名目提供的，咱们以为它们都是高可用，平安和低本钱的。
上方的虚线框代表了 JuiceFS 的客户端，其中最底层这个是 JuiceFS 客户端外面的一个 Core Lib，担任与元数据引擎和数据引擎通讯，并面向运用输入四种不同的拜候形式：
FUSE：百分之百兼容 POSIX，经过 LTP 和 pjd-fstest 测试Java SDK：办事于 Hadoop 生态，彻底兼容 HDFS APICSI Driver：在 Kubernetes 的环境外面能够用 CSI 的形式拜候S3 Gateway：输入一个 S3 的 End point 去对接 S3 的 API6. 数据存储
右边的图阐明了咱们是如何利用对象存储做数据耐久化的。相似 HDFS，一个文件经过 JuiceFS 写到对象存储里时会被切割，默许是每 4M 为一个数据块存到对象存储里。这样切割的益处是能够进步读写的并发度，晋升机能，这是在原来的对象存储里很难做到的。数据切割也有助于咱们完成一个机制，即写到对象存储中的一切数据块只新增不修正。当需求对数据做掩盖写的时分，会把掩盖写的内容作为一个新的数据块写到对象存储里并同步更新元数据引擎，这样的话就能读到新数据然而又不必修正旧数据块。这样的设计既能够反对随机写又能够规避掉对象存储的终究统一性问题，同时利用这个机制还能够为客户端提供细粒度的当地缓存的才能。
fxnbzgpbz3t.jpg
7. JuiceFS 的可观测性
咱们设计 JuiceFS 的时分还有一个很首要的指标就是晋升用户体验。这里指的用户既包罗使用文件零碎的开发者又包罗保护文件零碎的运维和 SRE 同窗。要做到好用好保护，咱们就斟酌提供在云原生设计中常常提及的可观测性。以往咱们使用文件零碎时以为零碎是快是慢更倾向于理性的判别，很难看到十分具体的数据。
而 JuiceFS 提供了可观测性的才能，能够在客户端里关上一个具体的 accesslog，外面会输入下层运用拜候文件零碎时一切操作的细节，包罗一切对元数据的申请，一切数据拜候申请的细节以及损耗的时间。再经过一个工具将这些信息进行汇总，就能看到下层运用运转过程当中与文件零碎这一层是如何交互的。当再遇到文件零碎慢时，就能很容易的剖析出这个慢是甚么缘故酿成的，是由于有太多的随机写，仍是由于多线程并发之间存在梗阻。这里咱们提供了 CLI 工具，在咱们私有云的云办事上还提供了一些基于 GUI 的可视化工具去做观测，置信这样的观测才能关于下层运用的开发以及关于文件零碎自身的运维都是颇有帮忙的。
04
JuiceFS 的使用场景
mco5b3qb3aa.jpg
最初来分享一下 JuiceFS 社区顶用户最常运用的一些场景。
1. Kubernetes
在 Kubernetes 里一些有形态的运用需求一个耐久卷，这个 PV 的选择始终是 Kubernetes 社区外面用户常常探讨的问题。之前大家可能会选择 CephFS，然而带来的应战就是运维相对于繁杂，JuiceFS 但愿给大家提供一个更容易运维的选项。
2. AI
由于 JuiceFS 提供了多拜候协定的反对，所以在 AI 场景中很长的 Pipeline 上的各个环节均可以很便利的使用。JuiceFS 还提供了通明的缓存减速才能，能够很好的反对数据荡涤、训练、推理这些环节，也反对了像 Fluid 这样的 Kubernetes 外面 AI 调度的框架。
3. Big Data
JuiceFS 有一个很首要的才能就是海量文件的办理才能，JuiceFS 就是为办理数十亿文件的场景去做设计和优化的。在大数据场景下，由于它彻底兼容 HDFS API，所以老的零碎无论是甚么发行版均可以很平滑的迁徙进来。另外，在 Hadoop 体系外的得多MPP数据库像 ClickHouse、Elasticsearch、TDengine 和 MatrixDB 作为新的数据查问引擎，默许设计是为了寻求更高机能的写入，需求配备 SSD 这样的存储磁盘。然而通过长期的使用后，在大数据量下就可以发现这些数据是有热数据也有温、冷数据的，咱们但愿能用更低本钱的去存储温、冷数据。JuiceFS 就反对简略通明的存储温、冷数据，下层的数据库引擎根本不需求做任何修正，能够间接经过配置文件对接进来。
4. NAS Migration to Cloud
后面更多提到的是在互联网行业中运用较多的场景，而得多其余畛域以往的行业运用都是基于 NAS 构建的，咱们看到以后的趋向是这些行业都在向云环境迁徙，借助云弹性的才能，利用更大范围的散布式环境去实现他们需求的诸如数据处置、仿真、计算这些场景。这里存在一个应战就是如何把原先机房里的 NAS 迁徙到云上。无论是社区仍是商业的客户，JuiceFS 这边都反对了从传统的机房环境上云这样一个迁徙 NAS 的进程，咱们曾经接触过的有基因测序、药物钻研、遥感卫星，乃至像 EDA 仿真、超算这些畛域，他们都曾经借助 JuiceFS 完成了将机房中的 NAS 很平滑的上云。
明天的分享就到这里，谢谢大家。
｜分享佳宾｜
sjbxdcczsd4.jpg
苏锐｜Juicedata 合伙人
Juicedata 合伙人苏锐，作为 1 号成员参预创立云原生散布式文件零碎 JuiceFS，先经过寰球私有云上的 SaaS 产品获取国际外几十家商业客户。之后于 2021 年 1 月 JuiceFS 开源，通过一年的社区开展，在 GitHub 上获取近 5000 Star，天天有上千在线活泼集群，有 50 多位奉献者参预，曾经成为一个在寰球规模备受关注的开源散布式文件零碎。苏锐在参加 Juicedata 前，历任互联网 O2O 汽车办事品牌工夫洗车开创人 & CEO，豆瓣电影 PM & Tech Lead。 |
|
注册会员