最近在给一家做智慧物流的公司做系统优化，他们上了5G之后，设备接入量直接翻了十倍。原本跑得好好的调度系统开始频繁卡顿，后台服务器CPU动不动就飙到90%以上。问题出在哪？其实就是5G环境下的资源管理没跟上。
连接数爆炸，服务器扛不住
4G时代一个基站大概支持几千个设备连接，到了5G，理论能撑百万级。这对服务器来说意味着啥？以前一个API网关每秒处理几百个请求就够用，现在可能要扛几万个并发。像智能仓储里的AGV小车，每辆车每秒上报位置、电量、任务状态，数据像洪水一样涌进来，不提前规划资源，服务器分分钟被压垮。
边缘计算成了必选项
把所有数据都传回中心机房处理根本不现实。我们最后在区域分拣中心加了边缘节点，把车辆路径规划这种实时性要求高的计算放在本地处理。只把汇总数据和异常告警传回主服务器。这样主干网络压力小了，响应也快了。配置文件里就得明确划分哪些服务放边缘，哪些留云端：
<service-deployment>
<service name="route_planning" location="edge" />
<service name="inventory_sync" location="cloud" />
<service name="device_heartbeat" location="edge" />
</service-deployment>动态资源调度是关键
5G场景下流量波动特别大。比如双十一期间快递分拨中心的数据量可能是平时的五倍。静态分配资源等于浪费钱。我们上了Kubernetes做自动扩缩容，配合Prometheus监控指标，一小时能根据负载自动调整Pod数量。早八点到十点业务高峰，自动扩容3倍实例，半夜低峰期缩回去，既保证性能又省成本。
切片技术不是万能药
运营商喜欢提网络切片，说能隔离不同业务。但实际用起来发现，切片只管无线和传输层，到了服务器这边还得自己操心。比如同时跑着高清视频巡检和温湿度传感器数据，虽然用了不同切片，后端共用同一套微服务，资源争抢照样发生。最后只能在服务网关层加优先级标记，确保视频流这种高带宽需求不被小数据包拖慢。
功耗管理容易被忽视
很多人只盯着性能，忘了功耗。5G模组比4G费电，设备频繁上报数据，电池撑不了几天。我们在服务器端做了数据聚合策略，把每10秒一次的上报合并成每30秒批量推送，通过MQTT协议一次性处理。这样终端省电了，服务器的I/O压力也降了下来，算是双赢。