大家好,千呼万唤始出来的小文同学终于又再次上线啦,泪目了!!
1. 背景
作者在小程序上线后,收到了来自服务端同学的吐槽,线上疯狂报并发登录请求 的报错,为了一探究竟。我开始反转我们Request的设计,在没有使用请求库的前提下开启了我的改造之旅。阅读代码后,发现了以下几个问题。
tips :采用的框架是uniapp
- 在用户未登录(token不存在) 的情况下,发起了n次的业务请求 ,就会发起n次的登录请求。
- 在用户已登录(token存在) 的情况下,发起了n次的业务请求 ,但是业务请求失败,返回code为401,这时候会重新发起n次的登录请求,并在登录成功后同步请求刚刚失败的n次业务请求。
然而,目前的解决方案对我个人来说还是蛮hack的 (在所有可能的入口页面处发起业务请求时去执行await checkSession), 然而也没有解决上述的第二个问题,真是救了个大命,有精神洁癖的我实在看不下去,打算上来就干!
2. 改造计划
首先捋清楚我们所采用的登录方式和相关业务逻辑是什么,然后再根据具体情况、具体分析、具体设计。但基于我有极度追求极致洁癖的背景下,在这里还是不做得太复杂了哈哈哈哈哈哈哈哈哈哈!
- 为了不增加用户的心智负担 ,进入小程序都需要去同意授权的一些操作在我们这就不需要了,咱主打的就是一个easy,进入小程序后就给它干登录,也就是我们所知道的 "静默登录"
- 同时我们是依赖支付宝平台的 uuid 信息,但是在我们这一套代码多个小程序主体 的背景下,为了支撑相同支付宝号在不同我们小程序的多账号体系下,根据不同的appid进行区分,因此在这里我们基本上所有的业务请求都是需要携带token的,所以在本次设计中就先不讨论不需要token的业务请求
3. 流程设计
在这里就不对静默登录进行过多解释了,家门人不清楚的可以搜索一下哈~
暂时无法在飞书文档外展示此内容
如图所示,我们改造后的Request 时序流程图,重点 在于解决以下两个问题:
- 如何防止 多次执行并发登录请求
- 在业务请求返回**
code
** 为401 的情况下,重新执行失败的请求
3.1 核心代码
- Request构造器属性
- 登录功能
- 状态码为401的逻辑处理
4. 总结
- ⚠️ 当时在解决业务请求code401的逻辑时,没有正确的resolve回到正确的结果,这里可能是需要注意一下的
- 鄙人文笔有限,写的代码或许也还不够优雅,但至少有在蜕变的路上