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