做系统的人都知道，所谓“稳定”两个字，写进PPT里只需要一秒钟，真要落到现实场景里，往往得拿真金白银和无数个通宵去换。
我们这次拿来做“体检”的，是一套已经铺设到多个城市街角的马路边停车收费智能系统。它不算什么炫技的产物，没有花哨的大屏，也不靠概念融资，核心任务非常朴素：车牌识别要准、计费要稳、断网能撑、高峰不崩。但越是这种嵌在市政毛细血管里的东西，越经不起马虎——早高峰一条路两百个车位同时进出，后台要是打个磕睡，投诉电话能打爆城管热线。
为了摸清楚它的底，我们没用那些温吞的压力测试脚本，而是直接上了硬货：在隔离环境里，用分布式压测集群模拟了十万次并发访问。什么概念？相当于把一个中等城市核心区所有路边车位在同一分钟内全部触发一遍入场、识别、计费、支付回调全流程。这种量级的冲击，很多云原生系统都会先抖三抖。
结果有点出乎意料，也印证了我们对这套架构的判断。
首先，最直观的指标——CPU温度。在持续四十分钟的十万级并发轰击下，边缘计算节点的CPU温度始终维持在工业设计阈值的“淡定区”，没有出现过降频，更没有触发过热保护。我们拆开看过散热设计，很克制，没有堆料狂魔式的双风扇，就是合理的风道加上宽温级芯片选型。这说明底层的任务调度确实把指令切得够碎，没有让某个核在某一秒被突然涌进来的请求活活噎住。
再往深里看，系统的队列机制才是真正的主心骨。十万并发不是瞬间砸进去就完事，它内部用了一套分级缓冲：本地SRAM先接得住突发的车牌流，再异步往Flash里落账，最后才和云端对账。这种设计不性感，但特别“抗造”。我们故意在压测中途拔了一次网线，系统本地继续记账，恢复连接后零丢单。对停车收费这种场景，账错一分钱都是事故，这点比跑分重要得多。
当然，也有老问题。比如极端光照下的车牌识别率，在压测里我们顺手灌了五千张雨夜模糊图，识别率掉到九成出头。这属于光学和算法的老江湖难题，不算系统崩，但值得后续迭代。
总的来看，这套马路边停车收费智能系统经住了“体检”。十万并发下的CPU淡定，不是运气，是边缘侧把活儿分明白了。对市政项目来说，这种不声不响的靠谱，比任何发布会上的掌声都值钱。
18581869297
