运营中心客户端：毫秒响应，交互如呼吸

　　去年八月那阵子，我原以为运营中心客户端的卡顿是常规的流量波动——毕竟业务方刚推了新活动，注册量涨了三成。可运维老张凌晨三点打来电话，说监控大屏上的响应时间曲线像被狗啃过，一会儿零点三秒，一会儿跳到三秒，用户侧反馈“点按钮像在戳沼泽”。我盯着屏幕上的锯齿状折线，泡面凉了都没顾上吃，手机还在震，工单系统里“页面加载超时”的报警已经堆了二十多条。

　　第一反应是查CC攻击。可WAF日志里没见大量异常请求，防火墙规则也没触发，倒是数据库连接池的告警红得刺眼——每秒新建连接数从三百飙到三千，可实际查询量根本没涨。运维小王蹲在服务器前翻日志，嘴里嘟囔：“这他妈像有人故意卡着点，每秒发三百个合法请求，专挑连接池满的时候挤进来。”我凑过去看，发现这些请求的User-Agent全是Chrome最新版，IP分布散得离谱，北京、上海、广州甚至乌鲁木齐都有，可请求路径清一色指向“/api/getDashboardData”——正是运营中心最核心的仪表盘接口。

　　业务方那边已经炸了锅。运营总监拍着桌子喊：“用户说登录后要等五秒才能看到数据，这跟死机有什么区别？”我一边安抚一边翻代码，突然想起三个月前他们为了“提升用户体验”，把仪表盘的初始加载从分页查询改成了全量拉取。当时我就反对过，说“数据量太大，网络波动一下就会超时”，结果被怼“用户要的是实时，不是分页”。现在可好，全量数据包从原来的二十KB涨到两百KB，稍微有点延迟就卡死。

　　可问题真这么简单？我盯着日志里的时间戳，发现卡顿总出现在整点过三分——比如十点零三分、十一点零三分。运维小王突然喊：“我查到了！这些请求的源IP虽然分散，但用的都是同一批CDN节点！”他调出CDN的访问记录，果然，每个卡顿时段都有几十个节点同时向我们的接口发请求，频率精准得像定时任务。我原以为是对手在搞恶意竞争，结果业务方的人插嘴：“会不会是我们自己的爬虫？上周测试组不是上了个新脚本，说要监控竞品数据？”

　　测试组的负责人被叫来时，一脸懵：“我们脚本只跑竞品域名啊，怎么可能访问自己的接口？”可当他看到日志里的请求参数，脸色变了——有人把测试环境的API地址写成了生产环境，而脚本里又没加限速，每秒能发五百个请求。更绝的是，这脚本用的是公司统一的代理池，IP自然分散得像真实用户。我气得直拍桌子：“你们测试环境和生产环境的域名就差一个字母，就不能用环境变量区分？”他挠挠头：“之前觉得麻烦，直接硬编码了……”

　　问题总算定位了，可修复更头疼。全量拉取的数据包必须砍，可业务方死活不同意，说“用户已经习惯了实时看到所有数据”。我妥协改成分页加载，结果他们又嫌“翻页操作太老土”。最后折中方案是“初始加载前二十条，滚动时再懒加载”，可测试组又报“滚动事件触发太频繁，导致请求堆积”。那几天我往返于开发、测试、业务三方，来回折腾三趟，改代码、调参数、压测试，手机震得手都麻了——全是业务方在催“什么时候能好”。

文章配图，仅供参考

　　后来复盘时，运维小王说：“其实最险的是连接池那部分，如果攻击者再狠点，把连接数再翻一倍，数据库直接就挂了。”我点点头，心想这哪是攻击，分明是优胜劣汰——我们的系统太脆弱，连自己人的误操作都扛不住，更别说真正的恶意流量了。业务方现在倒是听话了，主动要求加限流、做降级，可我知道，这不过是暂时妥协——等下次KPI压力大时，他们又会嚷着“要实时、要全量、要流畅”，而我们这些架构师，又得在性能和稳定之间找平衡。

　　现在运营中心客户端的响应时间确实稳了，可我心里清楚，这不过是暂时的。下次再遇到类似问题，可能就不是误操作，而是真的攻击了——到时候，是继续靠“优胜劣汰”硬扛，还是能提前防住？我还没想好，反正先补个觉吧，这五天熬的，眼睛都快睁不开了。手机又震了，估计是业务方在问“新功能什么时候能上线”——得，又有的忙了。

（编辑：站长网）

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