我开发了个「自动换头像」机器人

我开发了个「自动换头像」机器人

开发者广场内容精选NaN-NaN-NaN
解决方案
作者:郝昱
推荐理由
「自动换头像」机器人是 2021 年十一期间搞出的一个小创意。上线之后也没咋维护。目前用的人越来越多,就写篇博客记录一下。
起因
某同学在 Twitter 上说,组里有同事每天上班时候将头像换成彩色的,下班时候将头像换成黑白的。我觉得这个创意很有意思,于是就想着能不能写个啥东西自动来搞。
选型
首先是 Lark 的接口支持。看到「通讯录-用户-修改用户部分信息」里面有「avatar_key」,觉得这事儿能成。申请了权限,竟然给批下来了。
然后是基础组件。那段时间刚刚学 Go 不久,本来想用 Go 来写,但找了一圈,没发现啥比较好用的 crontab 库(都是更高大上的定时任务平台。一牵扯「平台」就太重了)。但是 Python 里面发现了 APScheduler 这个库,看上去还比较好用。
开始写
整个项目不大,分成几个部分:
1.用户要能设置自己的头像。那么头像怎么来?第一想法是哪只个头像库,然后一想,哎,搞自定义上传多好呀。正好在「消息-图片信息-上传图片」那里可以设置成「avatar」,就是专门用来设置头像的。
2.上传好的头像,和用户关联起来,存数据库里面。
3.APScheduler 可以自行设置 crontab,那么就用上这个能力,让用户自己写 crontab。写好后,将「用户-crontab-头像」作为一个任务,存到数据库里。
4.剩下的东西,交给 APScheduler 来完成就好了:它自己从数据库里面读取每个任务,调用对应的 API 来换头像。
5.可管理。有时候需要删除一些任务,有时候需要删除旧头像。头像还好说,直接把 Lark 返回的 key 暴露给用户即可;任务的话,可以自己搞个 UUID,和用户 ID 一起当作主键。管理接口用最经典的「命令」方式来实现,就是说,如果一条消息是「/」开头,那么认为是个命令。
于是整体流程就和设想的差不多:
1.用户给机器人发图片,图片直接送 Lark 的图片上传接口,拿到图片 Key。
2.图片 key 和用户 ID 一起存数据库(偷懒,直接用了 mongo)
3.用户可以用指令,查询自己 ID 所关联的所有图片 key
4.用户可以设置换头像任务,格式是”/set <crontab> <avatar_key>”,然后是一些检查,例如这个头像 key 在不在库里、有没有和自己关联。如果检查通过,那么调用 APScheduler 创建一个任务,并把任务 ID 记录到数据库内
5.用户可以查询自己关联的所有任务
6.APScheduler 会在后台自动管理一切,包括定时触发、执行、设置任务下次运行时间。如果由于一些原因任务没执行(例如实例挂了),还能自动重新执行那些被错过的任务。
好了,完美。
问题
第一个大问题是审核……我哪知道还能碰到这问题啊……当时,有些人上传了一些能触发审核的图片,然后就触发审核了,然后头像就被自动删了,就 404 了。于是你在群里发言,全群人看到的都是「头像无法显示」的 404,于是 Lark 后台开始报警「头像下载 404 增多」。于是 Lark 的人就找到我这儿来了……emmmmm
第二个问题是各种延迟/不同步。换头像之后,自己这边是立刻就更新了,别人大概率需要手动点击你的资料卡,才能看到你换头像了。这还不算,由于公司里系统众多,每个系统拉用户资料的时间都不太一致,所以公司里云平台的头像、Git 的头像、模型训练平台的头像、sso 的头像……同一时间全 tm 不一样。就很诡异。
后续本来想加上根据排班表来换头像,研究了一下 API,似乎「不通用」。也想做自动跳过法定假日,但没找到合适的 API,加上「能让用户输入进去」这事儿没想通,就也搁置了。
成就
我也没统计到底多少人用了这个东西、也没统计有多少换头像任务,反正没超 QPS 上限,说明文档三天两头被传播一圈儿。记得去年大概看了下,好像有 400~500 个任务在跑着。
功能比较单一,所以也不用咋维护,一个数据库,一个实例,跑了两年多了没宕机。得益于强大的APScheduler,甚至可以多搞几个实例做分布式。不过用户量不大,似乎没啥必要。
先进生产力和业务协同平台
联系我们立即试用
更多人气推荐
查看更多

先进团队,先用飞书

欢迎联系我们,飞书效能顾问将为您提供全力支持
分享先进工作方式
输送行业最佳实践
全面协助组织提效
反馈给飞书 CEO:ceo@feishu.cn