基于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

应该说还是比较满意的。

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