需求背景团队项目原来使用的云存储中间件已经下线了。由于历史原因，未能及时全部迁移到新的云存储平台，导致部分功能丢失。使用时出现问题。比如在一些需要上传和存储文件的场景下，会上传失败，影响正常的业务逻辑；在某些需要下载文件的场景下，找不到正确的路径，导致无法下载相关业务数据。之所以发现这个问题是因为前台客户投诉某菜单中的导出按钮点击后没有反应。排查思路收到反馈后，我的思路大致是这样的：首先我先评估这个问题的影响，思路比较简单：这个问题持续了多长时间？有多少用户/操作触发器受到影响？业务的那一步？好在云存储中间件系统是面向内部的，所以导出的数据不多。并且由于独立于主业务流程，属于可选操作，需要单独手动触发，所以不妨碍主流程的执行，影响范围小。在确定了大概的影响范围之后，就要进入调查流程了。排查过程可以从日志、执行流程、业务逻辑和第三方依赖等方面入手（受个人思维局限影响，有建议请指正），把这个具体场景，大概有以下几个问题。服务器日志中是否有任何错误消息？提交的表单是否通过验证逻辑，进入下载流程？下载过程是怎样的？中间有没有第三方依赖？第三方依赖状态是否正常？这些问题我们都解决了，大概率会找出BUG隐藏的地方。我在工作过程中找到问题出在哪里后，首先查看了后台触发的方法，方法中打印的日志内容：Saveto***failed,servicenotfound，然后顺藤摸瓜找到问题原因：调用了一个已经下线的云存储中间件。导出操作时序图的简化版如下：导出操作时序图查看项目代码时，发现之前有前辈做过相关工作的迁移，封装了几个上传到的方法新的云存储平台，大概这个按钮不常点，历史迁移的时候会漏掉。所以结合老的文件导出处理流程，我在已有方法的基础上增加了一个方法可以接收File类型，文件的存放位置沿用前人使用的bucket和父目录。（bucket：存储文件的桶，不同的bucket可以理解为不同的存储空间）添加方法后，为了简化方法的使用成本，在方法体中根据用户ID和UUID自动生成父目录下文件的子路径被封装为上传文件的方法，只需要一个File类型参数。相比其他上传方法调用前需要定义多个方法参数，这里只需要一行代码就可以直接保存。乍一看，我觉得没有问题。连提交CR的时候，我都觉得这个方法很好。可以说干净卫生。既然如此，我为什么要写这篇文章？问题是，它可能有点“干净”但不“卫生”！“干净”就是调用时只需要传入File对象，只需要改动现有代码块的一行即可。那为什么说它不“卫生”呢？思考与总结在代码上线前的CR链接中，师兄们从安全性、通用性、可维护性等几个角度对代码进行了评估，发现存在很多问题。从安全的角度来看：不安全。这篇文章之前提到过“用的是前辈的桶”，这是一个容易被忽略的点。我在使用这个bucket的时候，并没有检查这个bucket里面文件的访问权限，而是直接默认了“这个bucket在项目中用于oss存储，所以我应该只申请这个bucket”。那我直接用就ok了，这个其实是一个很危险的想法，只关注项目，没有下沉到业务角度，在CR的过程中，发现我们用这个bucket来存储内容之前因为可以对外暴露对应的业务方法和存储的数据，这个需求对应的业务方法不是对外的，而是对公司的小辈来说的，所以不适合再用这个。从通用性的角度：不通用，设计的初衷是这个方法可以直接传入要存储的对象，不需要写几行代码定义对应的bucket和文件子路径；但实际上，我们在放弃参数入口的同时，也关闭了灵活性和通用性之门，这样的设计意味着如果用户使用这种方法，那么文件的存储配置就必须使用你的方法，那万一有人要改怎么办配置？在这种情况下，给用户带来极大的不便。从整体可维护性来看：目录不易维护。如前所述，子目录的路径是根据方法体内登录用户的ID和UUID生成的。这种目录划分其实是不合理的，因为我们存储的是文件，在维护存储的时候，我们可能会时不时的整理/清理目录和文件。而这个排序/清洗维度通常是从业务角度出发，而不是从用户角度出发。比如我们要清理某个月之前的历史退款信息。查看目录，我看到的是一堆用户ID。这时候负责处理的同学估计傻眼了。相比较而言，最??好在第一层按业务分类文件目录，然后再在下一层按用户信息或日期信息分类。如何实现？答案就在“通用性”部分：添加方法参数，将路径定义的权限赋给具体的业务方法。虽然业务方法可能需要多写两行代码，但最终效果还是不错的。比如上面就是这个需求处理的全过程。综上所述，对自己最大的收获就是：当某个需求使用到一个自己没有用过的依赖/中间件时，首先要了解这个中间件。软件的特点，以及你团队在这个中间件中已有的配置信息和代表的含义，不要盲目按照看到的代码去YY；对于一个方法的设计，不要一味追求简单或者通用，而是要结合实际业务去思考如何设计，否则可能会适得其反；在任何时候，处理要求时都必须考虑安全性。不要认为一个功能很隐蔽，不需要关注它的安全性。没有人能确定。随机效应可以“送”我们一个大失败。作为这个行业的新人，我的经验和思考都非常有限。欢迎各位前辈指出文中不足的内容或提出建议。我会很感激。
