校园网认证系统的升级平滑过渡：Radius Proxy与新旧系统并存回退

高校做认证系统升级，最怕的不是上新系统，而是割接那一刻全校断网。很多学校已经有了一套运行多年的认证计费系统，比如城市热点这类，师生账号、套餐、历史账单都在老系统里。新系统要进来，不能是"把老的推倒重来"，而应当是"兼容延续、开放融合"，让新老系统在一个过渡期内并存，再分批切换。

Radius Proxy是实现这种非侵入式协同的核心技术路径。新系统作为代理服务器放在前面，老系统作为后端AAA留在后面。新系统接收终端的认证请求之后，按预先配置的规则，把符合条件的请求封装成标准Radius包转发给老系统，老系统负责最终的认证判定。整个过程老系统不用大改，新系统的引入对老用户基本无感。

规则配置是并存的关键。系统要能精细化地区分"走老系统认证的用户"和"走新系统认证的用户"，可以按用户范围、接入区域、终端类型组合条件。比如老用户、某个老教学楼、绑定在老系统白名单里的固定终端，继续走老系统；新覆盖的区域和新账号，走新系统。这种分流让升级可以一块一块推，而不是一刀切。

计费数据的连续性也要保住。认证通过之后，新系统按标准计费协议向老系统发送计费开始和结束报文，把用户的在线时长和流量同步过去，保证老系统的历史账单完整。同时新系统本地也存一份，避免老系统临时故障导致计费丢失。这套双向对账，是升级期间财务不出错的前提。

高可用和兜底机制，决定升级期间师生是否"无感"。新系统可以每十秒向老系统发一次心跳，检测认证和计费端口是否存活；连续几次失败就自动切换到本地认证兜底，并告警。新系统自身支持双机热备，主节点故障，备节点十几秒内接管转发。这些机制合起来，才让"升级基本无感"这句话有底气，而不是嘴上说说。

过渡策略要分三步走，不能跳。第一阶段新系统旁挂部署，和老系统并行，只接测试用户验证功能；第二阶段按区域分批切换认证流量，优先覆盖宿舍区这类高密度场景，同时保留回切机制；第三阶段才全面接管，老系统转为历史数据查询节点。每一步都有回退通道，任何一步出问题都能退回上一步，这才是工程上稳妥的升级，而不是赌一把。

这里有几个判断必须稳，不能拍胸脯。一是"零改造直接迁移"不能说，老系统和新系统的协议版本、加密方式、字段定义都要适配，不存在免联调。二是"无需联调即可上线"不能说，属性映射、计费字段一致性、失败回退路径都必须联调验证。三是"任意旧系统都能无条件对接"不能说，不同学校的老系统差异很大，能对接到什么程度，要看现场。

实施周期一般按周算，准备、对接开发、试运行、全面上线加起来大约一个半到两个月。准备阶段做数据普查和运营商确认，对接开发阶段做接口和每类模式的压力测试，试运行阶段选一两个宿舍楼实战验证，最后才全面铺开并安排现场值守。这个阶段最忌讳压缩联调和试运行，因为账号体系一旦出错，影响的是全校日常。

把升级的平滑过渡讲清楚，是想说明：高校认证系统升级，考验的不是新系统多强，而是它能不能和老系统平稳共存。Radius Proxy、精细化分流、计费同步、兜底热备、三阶段回退，这几件事做实了，升级才从"冒险"变成"工程"。

数据一致性是并存期间最容易被低估的风险。新老系统用户数据难免出现不一致，比如一边改了密码、另一边还没同步，这时候以哪边为准要有明确规则。常见的做法是新系统代理优先以老系统响应结果为准，同时记录数据差异日志，每天生成一份一致性报告，让运维能及时发现和处置。没有这份报告，两个系统的数据慢慢漂开，等到发现时往往已经影响了一批用户。

备份策略也要跟着升级节奏走。系统一般支持定时全量备份加实时增量备份，备份数据保留九十天以上，关键业务要能快速恢复。升级期间任何一步出错，能靠备份回退，才是真正的兜底。很多学校平时不关心备份，等到切换失败才想起没有可用副本，这种教训在高校信息化里并不少见，应当在准备阶段就把备份和恢复演练一遍。

试点区域的选择也有讲究。通常优先覆盖宿舍区这类高密度场景，因为那里用户最集中、问题最容易暴露，也能最快验证代拨、计费、无感知这一整条链路。反而不一定先动教学区，因为教学区对中断的容忍度更低。先在高密度但容错空间相对大的区域跑通，再向全校铺开，这个次序比"先动最重要的区域"更稳妥。