马斯克：接口工程师最该放弃的3个技术执念

　　去年春节值班，凌晨三点被线上报警薅起来，一看监控面板——嚯，某个支付接口的QPS曲线跟坐了火箭似的，直接顶穿阈值。我原以为又是哪个前端没加限流，结果翻日志发现是下游服务突然降配，超时时间从两秒砍到五百毫秒，咱们这边的重试机制直接把流量打爆了。运维在群里喊“快关重试”，产品还在追问“用户会不会报错”，我盯着屏幕突然想起马斯克那句话——接口工程师最该放弃的三个技术执念，第一个就是“绝对不丢消息”。

　　说白了，当时我们用的消息队列是RocketMQ，理论上能保证至少一次投递，可下游服务降配那会儿，人家直接返回503了。按老思路，这时候该死磕“不丢消息”，要么加重试队列，要么上本地缓存，结果呢？我同事老张为了这个“不丢”，愣是给接口加了三层兜底逻辑，代码从三百行膨胀到八百行，测试环境跑着好好的，一到线上就卡顿——因为兜底逻辑里有个同步写DB的操作，并发一高直接锁表。后来我们咬着牙把“不丢”改成“可丢但可追溯”，在消息体里加个全局ID，下游处理失败就丢到死信队列，第二天再人工补数。你猜怎么着？QPS降了四十个百分点，报警再也没响过。

　　手机亮了一下，是测试组的消息：“你们那个新接口的兼容性测试挂了。”我瞄了眼工位上的咖啡，凉透了。窗外的天已经黑透，键盘声还是噼里啪啦响个不停——后端小王正在改另一个接口的降级策略，嘴里嘟囔着“这破熔断器怎么又误杀”。这让我想起马斯克说的第二个该放弃的执念：“必须兼容所有旧版本”。

　　去年大半年都在跟旧版本较劲。前端为了“用户体验”，要求接口必须支持三年前的API格式；测试为了“回归覆盖”，强制我们保留所有历史字段；连运维都跳出来说“别删旧表，万一要回滚”。结果呢？我们维护了五套参数校验逻辑，三个版本的响应体格式，两个不同的鉴权方式。最离谱的是有次前端传了个废弃字段“user_type”，值是“VIP”，后端没校验直接存进DB，后来数据迁移的时候发现这个字段在十万条记录里有八万种写法——“VIP”“vip”“Vip”“1”“true”……我原以为兼容是“对用户负责”，结果发现用户根本不在乎你兼容不支持，他们只在乎“为什么我的支付按钮点了没反应”。

　　第三个执念更搞笑：“必须保证接口绝对稳定”。去年双十一前，我们为了“稳定”把接口的超时时间从三秒调到五秒，结果下游服务因为超时重试，把数据库连接池打满了。运维在群里喊“快降超时”，产品跳出来说“不能降，用户会看到加载中”。最后我们折中调到四秒，结果还是爆——因为四秒刚好卡在下游服务的慢查询阈值上。后来我们学乖了，把“稳定”改成“可控的不稳定”：给每个接口打上“稳定性等级”标签，核心接口超时设两秒，非核心设五秒，灰度的时候先放百分之十的流量，观察错误率和耗时，不行就回滚。说白了，接口哪有绝对稳定的？就像马斯克说的，优胜劣汰——能扛住流量的接口留下，扛不住的就被淘汰，别瞎折腾什么“绝对稳定”。

文章配图，仅供参考

　　工单系统又弹了条消息，是前端的：“新接口的字段名能不能改成snake_case？我们后端都这么写。”我盯着屏幕看了三秒，回复：“不行，咱们现在统一用camelCase，这是团队规范。”发完突然笑了——你看，有些执念还是放不掉啊。不过至少现在我知道，哪些该坚持，哪些该放弃。至于马斯克说的那三个，我挺认同的——优胜劣汰，接口开发也一样。

　　下一步该查查那个兼容性测试为什么挂，可能是新加的字段没加索引？或者测试环境的数据量太小，没触发慢查询？算了，先喝口凉咖啡，等小王改完降级策略再说。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!