Fastdfs OSS迁移COS

概述：文中包含：迁移前后的架构对比、迁移方案、迁移中遇到的问题

背景

公司打算将服务器从阿里迁移到腾讯，文件系统也从OSS改为腾讯的COS。
系统当前的文件存储方式是FastDfs + OSS 混合使用。所以顺带将FastDfs也迁移到COS。
当前系统中对FastDfs和OSS的使用架构

从实现方式上区分为两类服务：
使用FastDfs和使用OSS的
从调用方式上区分为三类服务：

middleware是我们自己的中间件，其中实现了三种方式的文件处理，其中FastDfs可以单独访问、common-fastdfs是一个单独的SDK

迁移方案

1. 运维操作，将FastDfs、OSS中存储的文件迁移到COS
   迁移后，文件路径保持不变。腾讯提供的迁移工具可以记录上次迁移位置，增量数据迁移也方便。所以不用考虑双写问题。

注意：FastDfs的访问路径：域名 + fdfsServer + 文件id

迁移之后fdfsServer + 文件id，成为了新的文件id，项目上根据自身情况处理路径问题

2. 业务架构改造

原架构有点混乱，现统一通过中间件处理文件

每个服务都新增一个文件处理工具类，有两个实现类，一个通过middleware实现，一个通过common-fastdfs实现。

middleware中提供三种方式的实现。保留common-fastdfs是因为私有化客户不进行迁移，这里主要是兼容私有化。

• 为什么不用把工具类抽出来放到中间件？

因为各个服务使用方式不一致，比较难以抽取。代码写完之后发现有不少内容可以抽取。但是写之前确实难以考虑到。写代码也没必要一定要一步到位，容易出bug，可以后续逐步优化。

回滚方案

改造后走哪个实现类都是通过配置决定的，需要回滚就直接切换配置。

遇到的问题

1. 代码复用问题

一开始难以做到高复用，所以每个服务加了接口。但实际上如果把工具类抽取到中间件，会少很多代码量，维护也方便。这个要根据项目自身情况而定。我的项目中就不是很适用。

2. 硬编码的问题

开发过程中，偶尔遇到常量，没有多考虑，直接硬编码在代码中，后面发现这个常量越用越多。所以一开始就应该维护好常量池。

3. FastDfs元数据问题，OSS、COS、BOS这些文件存储都是把元数据放在文件headers中的，而FastDfs元数据是另存了一个文件，文件路径是原文件路径加后缀”-m“ ，文件迁移后需要对历史Fastdfs文件的元数据做兼容。