存储迁移记录

摘要

最近项目需要从AWS迁移到阿里云，对存储也需要从S3转移到OSS，同时并不是所有环境都会从AWS迁移到阿里云，因此对应存储逻辑需要适配两种类型的存储。

实现思路及逻辑

概述

项目为微服务架构，个人是第一次接触这个项目，对项目整体逻辑以及测试逻辑不算熟悉，此为第一个风险点；临时接受这个需求，对S3以及OSS均不熟悉，此为第二个风险点；经过统计以及对代码的熟悉，发现当前所有微服务里对存储的操作较为简单，业务限制，主要是后期的测试较为繁琐。

整体流程

熟悉业务代码，统计修改点

涉及到对应业务，不赘述；
统计步骤如下：

• 打开对应微服务pom文件，快捷键：Ctrl + Alt + Shift + U，打开当前微服务所有jar包的关系图
• 搜索关键字：s3后，当前图已选中s3对应jar包，但由于引入包过多，可能出现很难看到的情况，此时点击工具栏Show Path：Root -> Selection后，显示的即为s3对应jar包到根节点的关系简化图，很有用
• 此时有两种情况：s3为当前服务直接引入或者由第三方包间接引入
• 直接引入，很简单，直接搜索s3即可，对应使用逻辑也比较明显，可以很快就整理出来
• 间接引入，这种情况就有点麻烦，个人是通过通读配置文件的方式，筛选出有可能是存储的配置，然后对应全局搜索，整理出对应使用逻辑；
  上述统计步骤主要归功于IDEA，快捷键以及功能可以提高效率。

在统计出的表格基础上，阅读OSS操作文档，熟悉OSS API调用

其实最开始个人感觉最耗费时间的就是熟悉API，但是没想到OSS的API写得很好，通俗易懂，除了一些警告信息等挺容易错过以外，个人在阅读熟悉过程中体验很不错（不吹不黑），真的挺棒（个人是暂时写不出这样的文档：链接在此

通用业务点1：定时任务删除某个bucket下的以prefix开头的所有文件

从原本的逻辑看，这里应该是直接通过定时任务定时删除固定天数前的文件，受限于业务，公司主要存储图片等信息，虽然从整体业务理解上，个人认为图片也不应该删除，但是原本逻辑就这样，个人也没有修改以及反驳的权利；阅读代码之后，整理出问题如下：
1）采取@Schedule进行定时任务的实现，但是没有自定义对应的线程池，不可避免会影响到其他同样类型的定时任务，但是纵观整体的微服务架构，并没有发现第三方定时任务工具包（也有可能是暂时没看到；
2）日志格式不规范，这个…见仁见智，至少个人认为下述日志格式较为规范（traceId也是需要的）；

log.info("[类名.方法名] 日志内容");

通用业务点2：生成临时凭证，下发终端，使其拥有临时访问OSS的权限

这里其实一开始个人不太理解，后来在阅读代码和文档的过程中渐渐理解：OSS和S3都提供支持STS（Security Token Service）方式访问，可以被理解为一种暂时的访问凭证，生命周期可以自行配置，这里需要注意一点：文档里写着默认周期为3600s，超过该配置就会报错（个人就是配置的时候报错了去查才查到对应信息），但是个人对应业务需要这个凭证至少生效时间超过3600s，所以提出了问题，后来经由同部门另外一个大佬提醒，说是这配置运维可以直接修改，看状况确实运维可以改；整体修改过程中没啥大问题，主要是需要按照文档修改，不得不再次说，这个文档写得确实挺好的。

通用业务点3：生成预览链接，下发终端

这里就是通过STS生成的临时凭证生成图片访问链接，然后在移动端可以访问就行，这个是没啥大问题。

改代码

原本是想用策略模式修改的，毕竟两种存储访问方式都得存在，那反正写个策略模式，判断当前环境，对应生成bean即可；在实现过程中尝试使用了泛型，尝试结合spring ioc实现策略模式，整体实现过程挺顺利；后来再看另外一个jar包的时候发现，使用适配器模式也行，便匆匆又写了一份；可惜，基于历史原因，最终测试上述代码都没提交…代码之后写几个demo补充在下面：

//TODO

测试

整体测试过程没啥大问题，主要是网络、环境等其他问题导致整体个人测试进程拖了大概一周；

问题

1、遇事不决，先看文档；
2、java项目，还是得尝试多想想设计模式，多思考多实践；

总结

原本上头说是等另外一个项目切换完后直接借鉴，但个人还是不太懂如何借鉴，还是自己看了文档、读了代码、写了逻辑，其实也是想试试当前水平吧，虽然还很菜，但是确实是进步了，挺开心的。