迎战视频时代就是个伪命题，客户私域里那点并发量连我当年爬虫脚本的十分之一都不到。但架不住被大厂开源出来的微服务架构洗脑了，觉得不搞这个就是落后于时代。看着那几个新来的后端菜鸟眼里闪着光，我拍板了：拆，必须拆，用 Docker 和 K8s 搞起来。
结果就是灾难。原本单体架构里一个函数调用就能搞定的事，现在变成了三个服务之间的 RPC 远程调用。用户上传一个十秒的视频，流程是这样的：上传服务接收文件，调用转码服务，转码服务再调用存储服务写库，最后通知业务服务更新状态。听着挺美，链路一长全是坑。第一个通宵就栽在超时上，转码服务那边 ffmpeg 参数没调好卡住了，上游的调用全部挂起，直接服务雪崩，用户页面转圈转到死。我们几个人对着监控面板，看着那条调用链从绿色变黄再变红，心跳跟着一起飙升。
第二个通宵在修数据一致性。订单表在 A 服务，视频元数据在 B 服务，用户权益在 C 服务。一个用户删视频的操作，需要按顺序调用三个服务的接口。网络稍微一抖，B 服务成功了，C 服务超时了，结果就是用户视频删了但权益没扣回来，数据对不上。为了补这个窟窿，又紧急写补偿脚本，脚本本身还有 bug，差点把生产数据库给清空了。那晚上我抽了快两包烟，看着那几个眼睛通红的新人，心里明白这技术债务算是彻底背上了。
第三个通宵已经有点麻木了，就是在各种缝缝补补。加熔断，加降级，加日志链路追踪。原本清晰简单的业务逻辑，现在被拆得七零八落，藏在十几个服务的配置文件里。新来的小孩问我某个字段到底在哪改，我得想半天。这哪是微服务，这是微折磨。
现在凌晨四点，服务器暂时稳住了。我盯着屏幕，满手油污——刚才机柜交换机的一个风扇异响，还得自己动手弄。极度痛心地意识到，我们这种小 SaaS 公司，离千万级 QPS 差了十万八千里，却提前享受了阿里级别的架构复杂度。过度设计的阵痛，全是自己作的。技术人的傲慢太可怕了，总觉得下一个大厂框架能解决所有问题，其实只是用更高级的麻烦覆盖了旧麻烦。工资哗哗地烧，时间嗖嗖地没，换来的是一套运行起来战战兢兢、维护成本翻了三倍的“未来架构”。
实用主义才是活下去的唯一路径。什么狗屁视频时代，先把客户的播放失败率降下来再说吧。微服务？等真被流量打趴下那天再考虑也不迟。现在，我只想把这堆 Docker 容器一个个摁回去，回到那个虽然土但是一把梭的单体应用里。可惜，代码和人一样，拆散了，就难再圆回去了。
