移动互联时代：应用驱动的万物互联新架构性能验证

　　去年七月那档子事儿，现在想起来还后怕——新架构上线第三天，监控屏突然炸成一片红，告警灯闪得跟迪厅似的。我原以为只是常规的负载飙高，结果一看日志，好家伙，设备注册接口的QPS直接冲到设计值的三倍，可实际成功注册的设备数还没平时多。开发在群里喊“不可能啊，我们压测过”，我盯着屏幕上跳动的“502 Bad Gateway”，心想这压测怕不是拿计算器按的？

　　那天值班的是老张和小李，老张叼着半根烟敲键盘，烟灰掉在跳板机键盘上，他骂了句“艹”又去拿抹布。小李蹲在机柜前摸设备温度，说“这交换机烫得能煎鸡蛋”，我抬头看了眼空调，冷风机嗡嗡响得跟拖拉机似的，温度显示28℃——明明调的是24℃啊。后来发现是空调滤网堵了，可谁有空去换？告警还在狂刷，我直接把手机塞进抽屉，省得被钉钉消息震得手麻。

　　说回正题，这新架构的“应用驱动”听着高大上，实际就是把设备控制权从硬件挪到云端，用API调。理论上能灵活扩展，可实际呢？我们压测时只测了单接口，没考虑设备注册+数据上报+指令下发这三个接口的并发。结果设备注册时，数据库的连接池被占满，后续的数据上报全堵在队列里，等连接释放时，设备早超时重试了——恶性循环，直接雪崩。开发说“我们设计时有熔断机制”，我指着日志里的“TimeoutException”冷笑：“熔断？熔断的是你们的脑子吧？”

　　但话说回来，这架构倒也不是全无优点。比如它有个“优胜劣汰”的机制——设备注册失败三次后，会自动切换到备用节点。那天我们故意把主节点的磁盘打满（inode用光，连日志都写不了），结果不到两分钟，监控显示备用节点的负载开始上涨，设备注册成功率慢慢回升。老张说：“这算不算自动容灾？”我怼他：“算个屁，要不是我们提前把备用节点预热过，它连冷启动都来不及。”可话虽这么说，我心里还是有点服气——至少它没像某些老系统，主节点挂了，备用节点还在睡大觉。

文章配图，仅供参考

　　说到云厂商，那天还闹了个笑话。我们用某云的负载均衡，结果发现备用节点的健康检查老是失败。工单提了三次，云厂商的回复从“可能是网络抖动”到“建议检查防火墙”，最后我们自己抓包发现，是他们的健康检查包发到了主节点的内网IP上——主节点都挂了，内网IP当然不通啊！小李在工单里写：“你们这健康检查是给鬼做的？”云厂商回：“正在排查。”排查了四小时，最后说是“配置同步延迟”。我盯着屏幕上的“已解决”，心想这延迟够发一篇论文了。

　　那天忙到凌晨三点，告警终于消停了。我瘫在椅子上，发现椅子轮子卡着一根网线——难怪刚才转身时差点摔跤。老张递来一罐红牛，说：“要不咱下次压测时，把所有依赖都模拟了？”我喝了一口，苦得皱眉：“模拟？云厂商的DNS故障你能模拟？运营商的带宽限速你能模拟？设备厂商的固件bug你能模拟？”他沉默了，我们同时看向监控屏——绿油油的一片，安静得像什么都没发生过。

　　后来我们改了策略：压测不再只测接口，而是测整个链路——从设备注册到数据上报，从指令下发到状态反馈，连DNS解析、CDN回源、云厂商的限流策略都测。开发说“这样成本太高”，我怼：“成本高总比线上故障高好。”老板倒是支持，但要求“尽量用开源工具，别买商业版”——得，又得研究怎么用JMeter模拟百万级设备并发了。

　　现在回头看，那新架构的“应用驱动”确实有它的道理——它把硬件的不可靠性暴露了出来，逼着我们去优化软件层的容错能力。可这也意味着，性能测试的边界被无限扩大了——以前只测服务器，现在要测网络、测云、测设备、测第三方服务；以前只测功能，现在要测故障、测恢复、测极限。有时候我甚至觉得，我们不是在测性能，而是在测“运气”——毕竟，有些故障，你永远预料不到它会以什么方式出现。

　　上周又有个新项目要上线，开发说“这次绝对没问题，我们做了充分的压测”。我盯着他们递来的测试报告，上面写着“QPS 5000，成功率99.9%”——数据挺漂亮，可我知道，这报告里没写DNS解析延迟、没写云厂商限流、没写设备固件bug。我叹了口气，把报告塞进抽屉，心想：等上线那天，估计又得通宵了。

（编辑：站长网）

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