三年架构设计：从0到10亿的创业后端实战

　　接口背锅——又双叒是接口背锅。上礼拜灰度开关没推完，前端在群里甩了个截图，红色箭头直指 /api/v2/order/create 499，PM说“用户等不及了”，测试补了句“我录了三遍都是超时”，我当场打开日志查 trace ID，结果发现那台机器的 JVM 已经被前天发版漏掉的 -XX:MaxRAMPercentage=75 蹭到 92%，GC 次数三百七十二次调用里占了二百一十一，但监控大屏上那个紫色的 GC Pause 曲线其实压根没抖，它就是懒，连抖都懒得抖。

　　我原以为加个降级熔断能糊弄过去，结果上线五分钟后 DBA 王工直接冲进站会间，手里捏着一张纸，边走边念“你们那个 order_id 做了分库分表没？没做？那你用什么防雪崩？”，我说“我们用了 Redis 限流”，他把纸往白板上一拍——上面全是慢 SQL 的 hash 值，第十七行写着 “SELECT FROM order WHERE user_id = ? AND status IN (‘created’, ‘paid’) ORDER BY created_at DESC LIMIT 20”，我张嘴想说“这我们早改过”，话没出口，他手机震了一下，掏出来看了眼，是家里人问“晚上回不回”，他顺手关了静音，咖啡杯上印的公司 logo 那个“∞”符号裂了一道缝，我盯了三秒，后来才想起来：那是去年双十一前行政团建发的，杯子早该换。

　　三年架构设计：从0到10亿的创业后端实战？呵。优胜劣汰是真的，但不是架构优胜、业务淘汰，是人——谁先扛不住谁先滚。前年这时候我还在写单体服务，用 @Transactional 套三层，事务传播行为全靠试错，有一次线上死锁，排查到凌晨四点，发现是支付回调里调了个查询用户等级的 Feign 接口，而那个 Feign 接口自己又开了个新事务……最后没动代码，只把 @Transactional 的 rollbackFor 从 Exception 改成了 RuntimeException，问题就没了。这个我敢打包票。

　　可你要问我分库键怎么选的、中间件版本兼容性有没有测全、TCC 补偿到底覆盖了几种异常路径——这个我说不准。真不行。我们当时连 schema migration 工具都没配好，每次加字段都是手动 exec SQL，有次上线前五分钟，测试小陈非说“你确认这张表没被其他服务查吗”，我去查了下元数据，发现订单中心居然被客服后台直连查过三次，还是三个月前的某次临时导数，没人删脚本。那天上线延迟了四十三分钟，我蹲在茶水间倒了杯水，水壶底结了一圈浅黄色水垢，像某种失败的隐喻。

　　产品又来改需求了。这次是要把“预计送达时间”从“明天下午”细化成“明天14:30-15:20”，精确到二十分钟窗口。前端老李直接在评审会上翻白眼：“你们的履约系统连实时定位都没接入，凭啥算这个？”PM 不说话，低头改 Figma，指甲油是深蓝色的，涂得挺匀。我忽然想起去年 KPI 里有一条“支持毫秒级履约预估能力”，HR 给的权重是15%，但技术侧没人认领，最后扔进了“中长期技术债池”。池子到现在还没清理，上个月我手滑点开过，里面有十七条记录，最新一条是“统一地址解析引擎 V3（含高德逆地理兜底）”，创建人是已离职的搜索组阿哲，创建时间是二零二一年十一月四日。

文章配图，仅供参考

　　所以说优胜劣汰，本质是汰人——留下的不一定是最好的架构，是没被踩中那几颗雷的。你看那个灰度开关，昨天终于推完了，但开关本身逻辑是用 if (env == "prod" && version >= "2.3.0") 实现的，没抽象成配置中心里的一个 flag key；DBA 吵完那晚，王工自己偷偷写了条 MySQL 的 pt-online-schema-change 自动化脚本，跑在一台测试机上，没进 CI 流水线，也没 PR；还有一次发版，测试在验收环境跑了十八毫秒的 mock 回放，结果线上一压，发现下游某服务的 okhttp 连接池 max idle time 被设成了 0，复用失效，连接疯长……这些事没一件上过周报，但全卡在发布检查清单的“非必检项”里。

　　现在轮到我教新人了。上周带实习生搭新项目脚手架，我让他先配 Spring Cloud Gateway 的全局 filter，他问我“要不要加 tracing context 透传”，我说“加，但是先注释掉”，他一脸困惑，我就说“等哪天你值班时接到告警电话，发现链路追踪断在某个 filter 里，再回来解注释”。说完我摸了摸口袋，发现手机没带，又折回去拿，看见前台墙上挂的日历还停在六月，下面贴着张便签：“运维部提醒：内网 DNS 解析缓存 TTL 由300s 临时调整为60s”，字迹是行政小吴的，但小吴上个月调去海外了。

　　所以啊，别信那些“从零到十亿”的路线图，那是 PPT 画的。真实路径是一堆临时方案拼起来的：Redis 集群是主从哨兵凑的，MySQL 分片靠 application 层路由硬顶，消息队列消费重试策略写死在 yaml 里，连健康检查端点都曾因返回状态码 200 但 body 为空被负载均衡器踢掉过三次。我现在每天早上第一件事，是扫一眼 Grafana 里那个叫 “service_unhealthy_since_0317” 的自定义 panel——它不报警，也不告警，就挂着，绿的时候比红的时候多，但红的时候一定是我刚合完 PR 的那半小时。下个月我打算把这个 panel 删了。或者，至少换个名字。

（编辑：站长网）

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