WEB应用系统案例分析X

杭州某电商公司的应用系后台订单系统在去年双十一崩了四十分钟。技术总监后来复盘时说，统案问题出在商品详情页的例分库存接口被营销活动页直接调用，活动页流量一冲，应用系数据库连接池就满了，统案订单服务反而等不到连接。例分这案子不算新鲜，应用系但很典型——WEB系统的统案故障，十有八九不是例分单点技术不够硬，而是应用系模块之间的调用关系没捋清楚。

我翻过他们的统案代码，营销页和详情页居然共用同一张库存表，例分还都开着长事务。应用系活动页每次刷新都要查一次库存，统案双十一那会儿每秒几千次查询，例分数据库CPU直接飙到99%。订单服务倒是独立部署，可它也要读库存表，结果被营销流量堵在后面，用户下单按钮转圈，超时重试又把队列堵死。说白了，这就是个资源争抢的问题，但根子在于设计阶段没人画过系统间的依赖图。

后来他们改了方案，把库存拆成两个服务：一个只读，给营销页用，数据每五秒同步一次；另一个管扣减，只接受订单服务的调用。同步用消息队列，流量高峰时允许营销页看到稍旧的库存，但订单扣减绝对实时。改完上线，双十一再没出过事。这个案例让我想起另一个教训——某政务系统的预约模块，用户提交表单后页面直接跳转成功，但后台处理是异步的，结果用户重复提交了七次，数据库里多了六条重复记录。前端没做防重，后端也没做幂等校验，就这么裸奔了两年。

WEB系统分析最怕只盯着性能调优，忽略流程设计。性能问题通常有现成解法，加缓存、限流、扩容，都是明牌。但流程漏洞像暗礁，平时看不见，一撞就沉。比如那个政务系统，如果后端在写入前先查一下身份证号是否已在处理中，或者在数据库层面加唯一索引，根本不会出这种事。可开发团队当初图省事，觉得异步处理能提升体验，结果连个状态机都没画。

我自己的观察是，很多团队做架构评审时爱看接口文档和数据表设计，却很少模拟异常路径。正常流程谁都会写，但用户会双击按钮、会断网重连、会开着两个浏览器标签页操作同一份数据。这些场景不测，生产环境迟早给你颜色看。有个做在线教育的朋友跟我说，他们视频播放页的续播功能偶尔失效，排查半天发现是用户切换网络时，前端把播放进度存在了localStorage，但后端只认cookie里的session，两者对不上，进度就丢了。你说这是技术问题吗？不如说是没想清楚“客户端状态”和“服务端状态”到底谁说了算。

WEB应用分析到最后，其实是在分析人的决策。技术选型、接口划分、异常处理策略，背后都是当时那批开发者的权衡。有些权衡当时看合理，比如为了快速上线牺牲一点健壮性，但欠下的技术债会连本带利地还。那个电商系统要是早半年做一次全链路压测，双十一的崩溃完全能避免。可惜，很多团队都是被事故推着走，而不是被设计推着走。