在做郑州物流查询小程序的那段时间，我从用户投诉和运单丢失的工单里看到了行业的痛点：信息更新延迟、接口不稳定、用户高潮时刻没法把握。于是这个项目的第一条非功能需求就是“接近实时”。

      架构上我选择了“拉取—归一—推送”三层：调度服务负责按物流公司节奏抓取或调用官方API，归一服务做协议转换与去重，推送服务负责向小程序实时下发变更。队列层用Kafka做吞吐缓冲，Redis做热点运单缓存，主库仍是MySQL以保证账务一致性。这个组合不是教条，而是基于对并发与一致性的权衡得出的实践结论。

      对接承运商时，总碰到格式不统一与反扒机制。经验是：优先使用官方开放API；若需抓取，采用Playwright的无头浏览器做登录态维护，并用代理池与人类行为节奏避免封禁。抓取层输出统一事件模型——company、tracking_no、status、location、timestamp——便于后端统一处理和缓存更新。

      实时通道上，我先用WebSocket（小程序端用wx.connectSocket）做推送，但准备了三套策略：WebSocket为主、长轮询为备、模板消息作严重变更通知的兜底。要注意微信小程序的socket心跳限制与后台连通性，连接断开需带上断点续传逻辑，避免用户重复收到同一条状态。

      性能优化上，Redis做追踪状态的TTL缓存，避免频繁落库；对高频查询的运单做热点分片；请求第三方API时实行令牌桶限流并按厂商分队列，防止单一承运商接口雪崩。去重与幂等在归一层实现，用事件ID+哈希判定重复并丢弃，日志保留便于追溯。

      运维与观测不能省：Prometheus采集关键指标（队列积压、抓取失败率、推送延迟），Grafana告警；分布式追踪用OpenTelemetry，定位延迟来源时特别省时。CI/CD用GitLab流水线+K8s滚动发布，部署时用Sidecar做流量镜像验证，生产风险更可控。

      前端我偏好把路线展示交给高德/腾讯地图小程序SDK，轨迹用分段线渲染并做聚合定时请求。界面上少即是多：历史更新只保留关键节点，异常状态高亮。离线场景允许读本地缓存，并在恢复网络后做增量同步。

      最后一点建议：把复杂度放在后端，把稳定性当第一次优化目标。技术选型常有两难，我更倾向于先保证可观测与幂等，再去追求极致延迟。未来可以考虑引入gRPC内网通信和边缘计算节点，实操角度，这些都是自然的演进路径。