Ruby老兵眼中的Android实时数据驱动创新

　　去年六月份那阵子，我原以为只是普通的业务压力测试，结果运维半夜把我薅起来，说Android端的实时数据接口被冲了。我盯着屏幕上的请求瀑布流，心里直犯嘀咕——这哪是压力测试？分明是有人把扫描器调成了“狂暴模式”，每秒两千多的请求，持续了快二十分钟，防火墙日志刷得跟瀑布似的，连泡面凉了都没顾上吃。

　　业务方一开始还嘴硬，说“我们用户量涨了，正常波动”。我指着日志里清一色的POST /api/v3/data/push，反问：“哪个正常用户会每秒发两千次同样的请求？还都是带随机参数的，摆明了是自动化工具。”业务方挠挠头：“那…可能是爬虫？”我差点没把键盘砸了——爬虫会这么密集？爬虫会只盯着实时数据接口？这分明是有人想搞我们。

　　运维在旁边补刀：“而且IP分布很散，全国都有，但大部分集中在几个云服务商的节点。”我翻了下历史记录，发现这种攻击不是第一次了，只是之前规模小，没引起注意。我原以为只是小打小闹，结果这次直接把接口打挂了，Android端的实时数据更新延迟了快半小时，用户投诉像潮水一样涌进来，手机一直在震，工单系统都快爆了。

　　业务方这时候才慌了神，问我：“能防住吗？”我叹了口气：“防是能防，但得加钱。”他们一听要加钱，又开始犹豫：“能不能先优化代码？”我差点笑出声——优化代码？这攻击根本不是代码问题，是有人故意搞你。我指着日志里的请求头：“你看，User-Agent全是乱填的，有的甚至直接写‘Mozilla/5.0 (Android) AttackTool’，这摆明了是挑衅。”

　　那晚我熬了一整夜，跟运维一起调WAF规则，把可疑的IP全拉黑，还临时加了限流策略。可攻击者像是有无穷无尽的IP，拉黑一批又来一批，防火墙日志还是刷得飞快。窗外天亮了，攻击才慢慢停了下来。我揉了揉眼睛，看了眼时间——早上六点，泡面早就凉透了，手机还在震，工单又多了几十条。

　　业务方第二天来找我，说用户流失了不少，问我怎么办。我反问：“你们之前没做压力测试吗？”他们支支吾吾：“做了，但没想到会有人这么搞。”我冷笑：“压力测试是模拟正常用户，可现实里总有人不按套路出牌。”他们又问：“那以后怎么防？”我摊手：“防不住，只能尽量减少损失。比如加监控，发现异常立刻切流量；或者做熔断，接口被打挂了就直接返回错误，别让用户一直等。”

　　其实那事后我想了很久，为什么Android端的实时数据接口会被盯上？后来才明白，是因为我们太依赖“实时”了。用户习惯了数据秒级更新，一旦延迟就会抱怨，业务方为了用户体验，只能不断优化接口性能，可性能越好，越容易被攻击——因为攻击成本低了，随便发个请求就能测试你的极限。我原以为“实时”是优势，结果成了弱点。

　　后来我跟几个做Android开发的朋友聊天，发现他们也遇到过类似的事。有的被CC攻击，有的被弱口令扫描，还有的被挂马。大家倒苦水时，有个朋友说了句话我印象特别深：“这行就这样，优胜劣汰。你技术好，别人就盯你；你防不住，就被淘汰。”我点头——确实，Ruby老兵看Android实时数据驱动创新，最站得住的地方就是“优胜劣汰”。你得不断进化，才能活下去。

文章配图，仅供参考

　　至于那晚的攻击是谁干的？没查清。运维说可能是竞争对手，业务方说可能是黑产，我说可能是个无聊的极客。其实谁干的不重要，重要的是我们得知道，这种攻击会一直存在，防不住，只能尽量减少损失。下一步我打算跟业务方商量，做个更灵活的限流策略，比如根据用户行为动态调整阈值，而不是一刀切。可业务方会不会听？谁知道呢——反正我已经尽力了，剩下的，看命吧。

（编辑：站长网）

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