基于hdfs的ftp服务器的设计与实现

本文主要记录hdfs-ftp-server的设计思路、实现过程,使用的话直接看github项目文档即可。
项目地址:https://github.com/linshenkx/hdfs-ftp-server

第一版

hdfs-ftp-server这个项目我在20年的时候就开源过一版了,先做一下前提介绍。

1 需求

因为我们大数据平台是容器化的,一些简单的操作也需要进入容器里面才能执行,而且传递文件也很繁琐。
所以那时候的主要需求就是实现功能,即通过ftp的方式实现对hdfs文件系统的操作,方便日常操作。

2 思路

那时候主要是参考github上一些老一点的项目进行改造升级,以适配高可用、kerberos认证连接。
然后再进行易用性改造,更适合生产环境使用。

核心思路是对外作为ftp服务器,内部使用hdfs实现接口功能即可,很简单的功能。

3 存在问题

那时候用的hadoop是官方的2.9.2,后面hadoop升级到3.3.1了,
而且有时候还得对接cdh的hadoop,这个时候这个工程就不能直接拿来用了。

这种时候常规解决办法就是修改一下依赖,重新编译。

但是我觉得太麻烦了,这样也不利于代码的管理。
所以就一直想着要把这个工程模块化,核心工程独立且不常变,其他的作为模块工程对接各个版本的hadoop客户端。

第二版

针对第一版存在的问题,第二版主要是对项目进行模块化改造

技术调研及选型

最开始我目标是很明确的,就是用蚂蚁金服的ark框架来实现类隔离,
毕竟不同大版本/发行版本的hdfs依赖多少会有类冲突,直接用是肯定不放心的。

ark我之前就一直有在留意,也跑过demo,觉得还是可以寄予厚望的。
事实上这个工程重构所用的时间一大半都花在ark上。
本来是想把各个实现模块作为ark的插件的,发现ark的插件又不支持动态插拔,其核心是类隔离而不是模块化。
那就把每个模块作为service,来实现动态引用,这也是可以的,也确实改好代码打包好了。
但最终运行的时候还是有bug,类似于:https://github.com/sofastack/sofa-ark/issues/421。

终于还是折腾不下去,放弃ark了,开源支持太差了,我水平有限,玩不动。

不用ark,osgi又太重了,没必要,那就还是老老实实用java的spi吧。
类似于jdbc的用法,添加对应jar包,指定类名进行加载。

但spi并不能实现类隔离,所以就预先打包好各个jar包,运行时再根据对接hadoop版本进行加载。

即每个模块形成一个fatjar,如cdh632.jar,official331.jar。
在对接cdh6.3.2的时候将cdh632.jar添加到类路径下即可,如果是对接官方3.3.1则添加official331.jar。

这里还有一个问题,要不要把hadoop的依赖包也一并打包呢?
这个倒没纠结太久,还是打包了。缺点是体积大很多,优点是摆脱依赖。
你只需要给我hadoop的连接配置文件就行了,而不需要整个hadoop客户端环境。
至于包大点就大点,不差那点流量、空间。

为了简化、统一子模块的开发,我又把gradle任务统一定义在父工程的build.gradle里面。
让子模块更加的简单易懂。

成果总结

https://github.com/linshenkx/hdfs-ftp-server

应该说还是比较满意的。

虽然就技术来说很简单,毕竟别人十年前就做过的东西,
但还是花了很多时间、心思在上面折腾,把这个小东西做得好用一些。
在这个过程也算有点收获吧。


基于hdfs的ftp服务器的设计与实现
https://linshenkx.github.io/hdfs-ftp-server-design-and-implementation/
作者
John Doe
发布于
2022年1月17日
许可协议