Ruby老兵亲授:前端架构双轨优化实战
|
线上报警那一刻,我正把冷掉的咖啡往嘴里送,手抖洒了半滴在键盘F键上——那地方现在还黏。前端老张语音炸进来:“Ruby后端挂了?我们页面白屏率飙到六成!”我点开监控面板,QPS跌得跟坐滑梯似的,但日志里连个500都懒得打,全是200,就静静地、阴险地返回空JSON。我原以为是缓存雪崩,结果查完Redis发现它比我还清醒,数据全在,热得冒烟。
文章配图,仅供参考 运维小陈冲进工位,T恤领口还沾着早餐包子油渍,指着屏幕说:“你们那个/user/profile接口,响应头塞了二十个Set-Cookie,前端发三次请求,浏览器直接卡死重绘。”我懵了一下——谁写的?翻git blame,是我自己三年前提的PR,备注写“兼容IE8”,底下还有一行“(已测试)”。我点了下“已测试”那几个字,没反应,鼠标悬停提示是PDF预览插件冲突……算了,这事儿不重要。反正IE8早死了,但那段代码活成了祖传诅咒,连cookie名都叫“user_login_status_legacy_v2_2021_fallback”,中间下划线多得像蚯蚓产卵。窗外天黑得很快,路灯一盏接一盏亮起来,像系统里那些没人敢动的定时任务。去年一月,产品阿美拍桌子说“首页首屏要压到800ms”,我们当场拉了个双轨会:一边走新路由,用GraphQL聚合数据;一边老HTTP接口照常跑,灰度切流。听起来很美。结果上线头两天,前端老张半夜两点发微信:“你那个新接口返的user对象里,address字段是hash还是array?文档写的是array,你返的是hash,但上周五又改成array了?”我翻commit记录,发现是我改的,理由是“前端说他们想扁平化”,但再往前看,三天前又是我回滚的,备注“iOS客户端崩溃”。我至今没搞懂为啥iOS认array就不崩溃——可能它只是恰好那天没更新Podfile。 手机亮了一下,是招聘组弹消息:“Ruby高级岗已下线,转为‘全栈(偏Node)’”。我顺手关了通知。其实Ruby写Web真不慢,慢的是人。比如我们有个超时设置,写着timeout: 15.seconds,可它真正起效得看OpenSSL版本、DNS resolver缓存、还有某次部署漏掉的systemd服务RestartSec配置。有回生产事故,查到凌晨四点,发现是某台机器的/etc/resolv.conf里多了一行nameserver 127.0.0.1,而本地dnsmasq根本没跑——谁配的?Git记录显示是运维小陈,但他坚称“只改了监控探针”,后来查出是他表弟实习那周替班干的。这事最后不了了之,因为问题自愈了:DNS服务器被隔壁组重启,顺带把我们的超时也“重置”了。 工单系统又弹了条消息:“【P0】订单页价格错乱,请速查”。点开一看,是促销模块调用的/pricing/calculate接口,在计算满减时用了浮点除法,然后.to_i截断——我盯着那段代码看了五分钟,突然想起这行是前年双十一流量洪峰里加的临时兜底,原意是防BigDecimal溢出,结果它把9.99元商品算成9元,用户乐了,财务哭了。谁Review的?是我。理由写“紧急上线,后续重构”。后续?没有后续。现在它还在那儿,像块贴在核心逻辑上的创可贴,血都渗出来了,胶布还粘得挺牢。 说白了,“Ruby老兵亲授:前端架构双轨优化实战”这标题听着唬人,其实就俩字:优胜劣汰。不是技术优劣,是人扛不住的淘汰——前端扛不住改三次接口的联调节奏,产品扛不住需求变脸的速度,运维扛不住半夜三点被叫醒查一个拼写错误的header name,而我,扛不住自己写的legacy cookie命名规范。去年一月那波双轨,最后活下来的不是GraphQL,是那个被前端悄悄绕过、直接fetch原始JSON的老接口。为什么?因为它返回字段稳定,就算错,也是错得一致。一致性有时候比正确性更值钱。 谁的键盘声很响,哒哒哒,像啄木鸟在敲我们系统的蛀洞。老同事李哥去年裸辞去了云南养蜂,前天朋友圈晒蜂蜜罐子,标签是#逃离RESTful。他走的时候删掉了自己写的全部rescue块,说“Ruby的异常够诚实,不该由人来假装优雅”。我留着他删剩的半行代码:rescue StandardError => e # TODO: log or die? ——那行注释还挂着,和我们所有没merge的feature分支一样,活着,但不算活。 我最近在看Rack::Timeout的源码,想扒明白它底层怎么hook住IO阻塞的。但看到一半卡住了,因为它的timeout handler依赖于信号(SIGUSR1),而我们有台老机器在Docker里跑,signal被屏蔽了三次。查到这里,我倒了杯新咖啡,刚放桌上,手机又亮——这次是钉钉,前端老张发来截图,上面是我们新接口返回的timestamp字段:“你这个ISO8601格式里带了时区Z,但我们Android端解析崩了,能不能改成+08:00?”我看着那个Z,忽然想起三年前我坚持用Z,因为“标准就是标准”。可标准哪管Android的time zone parser是不是用正则硬拆的。我回了个“马上改”,然后打开编辑器,光标停在timezone字段旁,犹豫三秒,删了Z,打了+08:00。改完没跑测试,直接push了。反正……测不出来的问题,就不算问题。 接下来我想查查那台DNS出问题的机器,看看systemd的journal里有没有漏记的重启记录。或者干脆找个借口,重启一遍所有网关Pod——上次有效,这次说不定也灵。谁知道呢。我连自己写的Cookie名里第四个下划线该不该保留都没搞清,更别说整个双轨系统到底优在哪儿、劣在哪儿了。先喝口咖啡吧,这杯好像又凉了。 (编辑:站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |

