大学WiFi网络计费系统升级：新旧并存的Radius Proxy分流怎么设计
升级不是"换一套系统"这么简单
高校的认证计费系统往往用了很多年，账号、余额、计费记录、与运营商和校园系统的对接，都长在旧系统上。大学WiFi网络计费系统升级最忌的一句话是"推倒重来"。现实中更稳妥的做法，是新旧系统并存一段时期，让认证请求在两个系统之间按规则分流，逐步过渡。并存期的技术核心，不是数据怎么搬，而是认证请求怎么分：哪些用户还走旧系统、哪些用户已经走新系统，由规则说了算。理解这套分流机制，比纠结选哪个新系统更决定升级的成败。
并存架构：前端代理加后端兜底
新旧并存通常采用"前端代理、后端兜底"的分层结构：新系统作为Radius Proxy服务器，部署在认证链路的前端，接收终端发来的认证请求；原系统作为后端AAA服务器，继续承担一部分用户的认证结果判定和基础数据校验。终端侧看到的认证入口不变，变化发生在新系统内部：它把请求按规则决定是自己处理，还是封装成标准Radius协议包转发给旧系统。这样做的价值是，升级期间师生的认证体验保持连续，不用因为换了系统重新学一遍登录流程。
分流规则：用户、区域、终端三个维度
代理转发不是"全部转"或"全部留"，而是按精细化规则区分"走新系统的用户"和"走旧系统的用户"。规则支持多条件组合，常用的有三个维度：一是用户范围，比如旧账号前缀（2022级及之前的账号）转发给旧系统，新账号直接走新系统；二是接入区域，比如尚未完成覆盖的老教学楼VLAN范围内的请求转发给旧系统；三是终端类型，比如绑定在旧系统白名单里的固定终端继续由旧系统认证。三条规则可以叠加使用，分流比例也能动态调整——过渡期间先放少量用户到新系统，验证稳定后逐步扩大。
属性映射与协议参数一致性
转发能不能成立，取决于协议兼容性和参数一致性。新旧两套系统的Radius协议版本、加密方式、字段定义要对得上，请求封装过去，旧系统才能正确解析并返回结果。属性映射要在联调阶段逐字段核对：用户名、呼叫地址、共享密钥这些关键字段，两边定义不一致，转发就会失败或返回错误结果。这个环节不能靠文档对齐，要靠真实请求跑通验证。联调时要专门准备边界数据：老账号、新账号、跨区域终端、异常密码，把这些情况都过一遍。
计费字段一致性：对账的地基
并存期最容易出问题的是计费字段一致性。认证通过后，新系统按RFC 2866协议向旧系统发送计费开始报文，终端下线时发送计费结束报文，包含在线时长、流量消耗等字段，旧系统据此维持历史账单完整。如果字段口径不一致——比如时长单位、流量统计范围对不上——新旧系统的账单就对不齐，对账时解释不清。所以计费字段的映射和口径核对，是和认证字段同等重要的工作，要在联调阶段一起完成，而不是上线后再补救。
数据不一致与失败回退
新旧系统用户数据不一致是常态：比如密码在一边改过、另一边没同步。设计上要定好冲突处理规则：认证结果以原系统的响应为准，同时记录数据差异日志，每日生成一致性报告供运维核对。原系统临时故障时，不能全校断网：新系统定期向旧系统发心跳检测，连续检测失败就触发兜底策略，请求切换到新系统本地认证（基于同步的用户缓存数据），同时向运维平台告警。缓存有效期可以配置，旧系统恢复后再切回。这套兜底机制要在过渡期演练过，不能只停留在文档里。
边界：不承诺"零改造上线"
升级并存的边界要守住几条：不承诺"零改造直接迁移"，不承诺"无需联调即可上线"，不承诺"任意旧系统都能无条件对接"。可做升级与并存，但能否落地取决于属性映射、联调条件与回退方案完整性。运营商链路、校园系统对接链路要分开评估，单条链路验证通过不能外推到全部链路。边界要在项目启动时就说明白，执行才不会跑偏。升级项目最后交付的不只是新系统，还有一份清楚的过渡记录和可独立运维的学校团队。
分流规则的运营配套
分流规则上线后要有人维护。过渡期间的分流比例、转发规则、缓存有效期这些参数要形成台账，谁改的、什么时候改的、为什么改，都记录清楚；并存期结束后，规则要整体清理，避免残留转发配置影响后续运维。每条规则生效前，先在测试环境用真实账号验证一遍，确认该账号走新系统还是走旧系统符合预期，再放到生产环境。这些看似细碎的动作，决定了并存期的认证准确率。