一次日常需求处理带给我的思考

一杯JAVA浓 做棵大树 3个月前 (09-02) 56次浏览 0个评论
文章目录[隐藏]

在大淘宝技术公众号看了很多文章,感觉都蛮有深度的,读起来像是付费水平的那种;这篇相比之下水准就低了很多,所以各位如果有什么建议欢迎评论区指教,谢谢啦!

需求背景

团队项目原来使用的云存储中间件已经下线了,由于历史原因未能及时将其全部迁移到新的云存储平台,进而导致部分功能在使用时出现问题。
比如在某些需要上传并存放文件的场景下,会导致上传失败,影响正常的业务逻辑;在某些需要下载文件的场景下无法找到正确的路径,从而无法下载相关业务数据。
这个问题之所以被发觉是因为前台客诉反馈过来啦:某个菜单里的导出按钮在点击后没有反应

排查思路

收到反馈后我的思路大概是这样子的。
首先是先评估下这个问题的影响面,我的思路也比较简单:

这个问题持续了多久了?影响到了多少用户/操作的触发呢?处于业务中的那一步?

还好这个系统是面向内部的,因此待导出的数据并不多;并且因为它是独立于业务主流程的,是需要单独手动触发的一个非必然操作,因此并未阻碍主流程的执行,影响范围较小。

在确定了大致的影响范围之后,就要进入排查环节啦。
排查环节可以从日志执行流程业务逻辑以及第三方依赖这几个方面入手(受个人的思维局限性影响,大家有建议可以指正哈),套上这次具体的场景,大概就是以下几个问题。

  1. 服务器日志中有无错误信息?
  2. 提交后的表单是否通过了验证逻辑并进入下载处理流程?
  3. 下载处理流程是怎么样的?
  4. 中间是否有第三方依赖?以及第三方依赖状态是否正常?

我们把这些问题解了,大概率也就找到了这个 Bug 藏在了哪里。

工作过程

于是我先去看了后台被触发的方法,以及方法内打印的日志内容:save to *** failed, service not found,然后顺藤摸瓜也就找到了问题的原因:调用了某个已经下线的云存储中间件。导出操作的时序图简化版如下:

一次日常需求处理带给我的思考

在查看项目代码的时候,自己发现之前有前辈做过相关工作的迁移,并且封装了几个上传到新的云存储平台的方法,大概是这个按钮不常被点击,历史迁移的时候也就给他漏了。于是结合老的文件导出的处理流程,我就在已有方法的基础上新增了可以接收 File 类型的方法,文件存放的位置则沿用了之前前辈所使用的 bucket 和父目录。(bucket: 存放文件的某个桶,可以将不同的 bucket 理解为不同的存储空间)
新增完方法之后,为了简化该方法在使用时的成本,就在方法体内部根据 用户 ID 和 UUID 自动生成了父目录下的文件子路径,从而将其封装为了仅需要一个 File 类型参数即可上传文件的方法。
相比于其他上传方法在调用前需要定义好几个方法参数来说,这里只需要一行代码直接 save 就行了。
这样乍一看感觉没什么问题,讲道理,我在提交 CR 的时候都觉得这个方法很不错,用起来可以说说是干净又卫生。 既然这样,我为啥还要写这篇文章呢?

问题就在于,它可能有点“干净”但并不“卫生”!
“干净”在于之前说的调用的时候只需要传入 File对象即可,对已有代码块只需要改动一行就成。那为什么说它不“卫生”呢?

思考总结

在代码上线前的 CR 环节,师兄从代码的安全性、通用性、维护性等几个角度进行了评估,发现存在很多问题。
安全性 角度来讲:不安全。本文之前有提到 “沿用了之前前辈的 bucket”,这点就是个容易被忽略的点,自己在使用这个 bucket 的时候并未去查看这个 bucket 中文件的访问权限问题,而是直接默认了:这个项目中用到 oss 存储的地方都是这个 bucket,应该只申请了这一个 bucket,那我直接用也是 ok 的。
这个其实是十分危险的想法,只把目光放到了项目上,而并未下沉到业务角度。在 CR 的过程中我们发现,之前使用这个 bucket 存放内容,是因为对应的业务方法和存放的数据都是可以对外的。而本次需求对应的业务方法,则并不对外,而是针对公司小二的。那再用这个就不合适了。

通用性 角度来讲:不通用。设计初衷是这个方法可以直接传入对象就能存储,不需要再写几行代码来定义对应的 bucket 和文件子路径;但是其实在我们舍弃掉参数入口的时候,也关掉了灵活性和通用性的大门。这样的设计意味着如果用户使用这个方法,那么文件的存储配置就必须得用你这个方法里的了,那万一人家想改改配置呢?这种情况下就造成了使用者很大的不便。

整体维护性 角度来讲:目录不易维护。前边有提到,子目录的路径是在方法体内部由登录用户的 ID 和 UUID 生成的。这样的目录划分方式其实并不合理,因为我们存放的是文件,而在维护存储的时候,我们可能会时不时整理/清理目录与文件。
而这个整理/清理的维度通常是从业务角度出发的,而并非用户角度,比方说,我们要清理某月以前的历史退款信息。一看目录,看到的都是一堆用户的 id,这个时候负责处理的同学估计就一脸懵了。相比较而言,文件目录首级以业务进行分类,下一级以用户信息或者日期信息再分类就会稍好点。那要怎么实现呢?答案就在 “通用性” 那一条:增加方法入参,把路径定义的权限给具体的业务方法,虽然业务方法可能要多写两行代码,但是最终的效果是好的。
一次日常需求处理带给我的思考

以上就是这次需求处理的整个流程了,综上,给自己最大的收获就是:

  1. 当某个需求中使用到了自己之前没用过的依赖/中间件的时候,要先去了解这个中间件的特性,以及在这个中间件中自己团队已有的配置信息及其所代表的含义,不要盲目根据看到的代码去 YY;
  2. 对于一个方法的设计,不要去盲目的追求简洁或者通用,要以实际业务出发去思考如何设计,否则可能会适得其反;
  3. 任何时候安全性一定要纳入需求处理时的考虑范畴,千万不要觉得一个功能很隐蔽就不用着重考虑它的安全性,没有人能确定迟发性的影响会“送”我们一个多大的故障。

自己作为新入行的新人,经验和思考肯定有很大的局限性,欢迎各位前辈指正文中内容的不足或给出建议,不胜感激。
扶缨(公众号:做棵大树)


做棵大树 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明一次日常需求处理带给我的思考
喜欢 (0)
[欢迎投币]
分享 (0)
关于作者:
一个整天无所事事的,有时候忽然热血的孩子
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址