loveshuyuan
V2EX  ›  职场话题

分享一个工作上无语的事情

By loveshuyuan at 2 天前 · 2802 次点击

因为项目里面遇到需要异步任务队列的需求,之前是用本地 process 实现的,现在需要支持水平扩展,调研了一番,又考虑到 asyncio 的支持,于是选中了 https://taskiq-python.github.io 这个框架。

咔咔咔一顿重构之后,公司里面的 devops ,是一个老外,非不让用 taskiq ,说什么技术栈不稳定,非要让用 k8s job 来实现,还为此写了一篇技术文档。。。

我无语了,也听其他同事说他经常对技术栈,需求啥的提出一些意见,搞得人很不爽。之前还有一件事情,一个 Dockerfile ,通过不同 cmd 来分别启动 backend 和 worker ,他非得让拆成两个 Dockerfile...

我是远程在一个国外公司,听组内其他同事说这个老外很犟,很古板,只听老板的话,其他人谁的也不听。

21 条回复    2026-03-13 10:54:02 +08:00
JoeJoeJoe
   1
JoeJoeJoe  
PRO
   2 天前
有人替你背锅, 还有技术文档这种书面材料, 是好事啊.

如果能给做一个具体的实施方案就更好了, 老外真是一个 good buddy
midsolo
   2
midsolo  
   2 天前
这老外还真不错,我们领导就是口头上一句话,搞好了是他决策能力强、资源协调的好,搞砸了是我们的问题,让我们背大锅
loveshuyuan
   3
loveshuyuan  
OP
   2 天前
@JoeJoeJoe 还真有具体的实施方案,他还搞了两种 mode ,本地用 thread ,k8s 用 k8s job 。。。
kapr1k0rn
   4
kapr1k0rn  
   2 天前
这是好事,他做的是 devops,考虑的东西比单纯技术实现多些。这个框架发布才到 0.12,是可能不稳定。我要是遇到这种同事高兴还来不及
loveshuyuan
   5
loveshuyuan  
OP
   2 天前
@kapr1k0rn 我觉得他搞的方案挺复杂的,还得调用 k8s api ,本地也不好测试
cloudzhou
   6
cloudzhou  
   2 天前
就这两个事情来说,从技术上,我支持老外,并且显然他的技术水准更高

1. 本地 process ,这简直就是短平快的产物,但是你这里需求没说清楚,k8s job vs mq 是两个不同的东西,k8s job 和 taskiq 场景也很不同,为什么能拿出来比较

2. 一个 Dockerfile ,通过不同 cmd 来分别启动 backend 和 worker ,他非得让拆成两个 Dockerfile...

这事情我更支持老外了,“明确大于其他”,使用 cmd 这玩意,很容易弄错
老外很具有云原生观念,就是一个事情,能用原生用原生,能明确就明确
mrzx
   7
mrzx  
   2 天前
@loveshuyuan 我也是支持老外,你觉得复杂的,可能后期遇到问题,处理起来就简单了....

老外明显谨慎,做技术需要的就是谨慎...

做技术别只考虑眼前的实施,开发简单...要考虑长远的维护..
loveshuyuan
   8
loveshuyuan  
OP
   2 天前 via iPhone
@cloudzhou #6 Dockerfile 这个可以理解吧,但是关于 job 这个东西,原始需求就是代码里面需要启动异步任务去执行长耗时的代码逻辑,然后记录任务状态、进度这些,并且支持 stop/resume ,还需要水平扩展,我感觉不太适合用 k8s job
cloudzhou
   9
cloudzhou  
   2 天前
@loveshuyuan 这个我从你的需求里,看不出哪个合适,如果是长时间,并且单次执行的 job ,那么 k8s job 合适;如果类似 mq 功能,可能用 taskiq 。至于你说的 “记录任务状态、进度这些,并且支持 stop/resume ,还需要水平扩展”,我觉得 k8s job 作为这么重要一个组件,应该有生态支持的
loveshuyuan
   10
loveshuyuan  
OP
   2 天前 via iPhone
@cloudzhou #9 多次执行,前端界面触发
cloudzhou
   11
cloudzhou  
   2 天前
@loveshuyuan 看代价,k8s job 因为要初始化容器,所以一般用于笨重的 job ,长久运行然后退出,比如每天统计一下报表; taskiq 比较轻量并且有结果返回,api 成熟

我感觉这两个根本不应该拿来比较
darksword21
   12
darksword21  
PRO
   2 天前
他既然文档都写好了。。
cryptovae
   13
cryptovae  
   2 天前   ❤️ 1
`通过不同 cmd 来分别启动 backend 和 worker ,他非得让拆成两个 Dockerfile`

没毛,Docker 设计哲学和推荐准则, 就是一个 Docker 容器只负责一个服务,容器生命周期=主进程生命周期
woodfizky
   14
woodfizky  
   2 天前
其实是好事,有个人在定你们的技术架构/实现方案,整个团队各个项目不会乱七八糟的,蛮好。
管理上是这样没错。

我这里也是写 Python ,几个项目在不同时期由不同人用不同的代码风格建立和维护的,当时就是缺少一个这样的角色去约束去规范各个项目,比较自由,反而导致现在有新东西要统一适配的时候十分蛋疼,比如代码风格不同、项目启动方式不同、项目 web 框架不同、等等。。。

你如果技术上有十分明确的理由和稳妥的实现方案。
你也可以写技术文档,或者跟他发邮件友好交流辩论一下。
zhybb2010
   15
zhybb2010  
   1 天前   ❤️ 1
根据 OP 描述,很明显老外更专业,更懂软件工程
DT37
   16
DT37  
   1 天前
问在哪能找到这样子的老外?
SmiteChow
   17
SmiteChow  
   1 天前
如果要支持 checkpoint/restore 那 taskiq 是做不到的
sampeng
   18
sampeng  
   1 天前 via iPhone
我也是 devops ,就 2k 的 star ,还是 python ,我也会劝用成熟方案。但不会推 k8s job 。有很多更成熟的…当然,推是推,方案是研发定。这是基本原则。我一定会说在前面:我看好这个方案,你看看,还是你懂,肯定是你定。但你要给我做好部署的方案,运维的方案给我,不是你本地跑了就没事了
zjj19950716
   19
zjj19950716  
   1 天前
dockerfile 这个不分开难道还写一起吗? 那起多个 worker 的时候还要起多个 backend 吗
neel
   20
neel  
   1 天前
这个老外还是很有工程师思维的,而且也挺负责的。
flmn
   21
flmn  
   2 小时 5 分钟前
k8s job 这个我站老外。
cmd 这个我站你。

纯从技术出发,不带感情色彩。
© 2026 V2EX · 24ms · 3.9.8.5