组件架构
文件组件在蚂蚁财富域内发展了有三四年了，早期文件处理比较粗暴简单一个Reader一个Writer基本搞定， 但是
随着文件类型越来越多，多套Reader/Writer，多套模板定义，上层任务实现也必须多套， 统一接口统一模板定义就显得十分的重要了；
随着集团层面去NAS接入OSS，对存储操作统一接口也是组件的基本要求；
随着业务的发展，对文件读写过程中不再是简单的读写，伴随一系列的额外的业务逻辑如：文件是否加密了， 是否计算读写的字节数，是否计算MD5值,oss的存储写完本地后是否触发上传到oss，是否将数据定义模板写入到文件头中等，这些额外逻辑使得代码不在干净，组件升级维护风险增加；
随着组件的扩散，对平台性也有了要求，如：模板文件不仅跟着项目，也要求存储到oss或者db等外部存储。
所以rdf-file组件的架构设计希望能够达到如下几点：
- 接口统一，模板统一
- 文件读写过程中主流与额外业务逻辑分离，且用户在读写过程中可以扩展自定义业务逻辑
- 多存储操作，且用户可以通过扩展实现其他存储操作
- 用户可以自定义文件协议（格式）
- 组件具备平台性能力，加载外部资源
- 组件对第三方包低依赖（事实上rdf-file-core核心包无任何第三方依赖，当然如果你需要oss存储操作，oss依赖的第三方包还是要依赖的）
为了达到如上的目标，rdf-file组件整体采用的微内核+插件思想去实现，微内核+插件并不是一个新概念如:eclipse的插件扩展，dubbo的架构设计。微内核即组件提供几个基本服务如文件读写，分片，合并，校验，排序，目录服务；插件即扩展服务如文件协议（格式）、 字段类型、格式化方式、存储、读写流程中自定义处理器等扩展， 组件通过开放SPI实现插件机制
- intefaces模块：主要包含用户使用接口API
- tools模块：包含组件内核实现的文件操作工具
- codec模块：对文件结构，行数据，字段数据进行编码解码
- meta模块： 元数据配置以及加载
- loader/extension模块: 对配置、插件等资源进行加载
- resource模块：对资源层抽象，组件内部实现classpath, file, oss加载,用户可以自定义插件实现其他存储加载
- spi模块：开放给用户的插件扩展入口
- config模块：配置相关的资源信息