学校portal认证计费系统的RadiusProxy升级：新旧认证系统并存怎么平滑过渡不中断

很多高校不是白纸上建网，而是已经有一套跑了很多年的认证计费系统，比如城市热点。要升级又不能让学生集体断网，这时候硬切换是最差的选择。蓝海卓越资料里给出的思路是Radius Proxy，让新旧系统并存、按规则分流，师生基本无感知地完成过渡。

为什么不能直接替换

老系统里沉淀着大量用户数据、套餐、历史账单，也深度绑定着现网设备。直接下掉，老用户上不了网、历史账目断档、设备配置要重做，风险太大。更稳的做法是"兼容延续加开放融合"：老系统继续承担它擅长的认证，新系统叠加新能力，两者通过标准协议协同。Radius Proxy就是实现这种协同的技术路径。

三层架构怎么分工

升级方案通常分三层。核心认证层由原有城市热点系统承担，处理主要认证请求；新业务管理层增加蓝海卓越统一认证计费平台，负责新用户的套餐管理、账务统计、日志审计，同时和老系统对接完成老用户统一认证；对接适配层内置运营商对接模块和校园系统对接模块，通过标准接口做跨系统数据流转。各模块解耦又协同，老系统不被推翻，新能力逐步长出来。

Proxy转发按规则分流

新系统作为Radius Proxy服务器，采用前端代理加后端兜底的部署。师生发起认证，新系统匹配规则决定转发给谁。规则可以组合：用户范围规则，比如某年级及之前的老账号走老系统；接入区域规则，比如老教学楼某些VLAN的请求走老系统；终端类型规则，比如绑定在老系统白名单里的固定终端走老系统。符合条件的请求封装成标准Radius包转发给后端AAA，老系统验证后返回通过或拒绝，新系统再转换成终端能识别的格式反馈给用户。

计费数据要协同不能丢

认证通过之后，新系统按RFC 2866协议向老系统发送计费开始报文，终端下线时发送计费结束报文，带上在线时长和流量消耗，确保老系统的历史账单完整。同时新系统本地同步存储计费数据，避免老系统故障导致计费丢失。这一步很关键，升级期间账务不能断、不能重，否则财务和对账全乱。

高可用兜底保体验

Proxy模式下，新系统每10秒向老系统发Radius心跳包，检测认证和计费端口是否存活，连续3次失败就触发兜底策略，把请求切到新系统本地认证，基于同步的缓存数据放行，同时告警。新系统自身支持双机热备，主节点故障备节点10秒内接管。这些机制保证升级过程中哪怕某段链路出问题，师生基本无感。

三阶段平滑过渡

部署分三步：第一阶段新系统旁挂，和老系统并行，只接测试用户验证功能；第二阶段按区域分批切流量，优先覆盖宿舍区等高密度场景，保留回切机制；第三阶段全面接管，老系统转成历史数据查询节点。整个过程师生感知弱，学校始终保留对认证策略、用户管理、日志审计的控制权。

迁移结论必须结合现场

Radius Proxy方案能力明确，但具体能不能落地，取决于老系统Radius版本、加密方式、字段定义是否可适配，以及并存、回滚、数据一致性方案是否齐备。资料把迁移类结论列为需要现场确认后才能表达的能力，不能脱离旧系统现状直接承诺"平滑升级"。学校要先做数据普查和对接测试，再谈切换节奏。

数据备份兜底历史账

升级最怕数据丢。方案要求定时全量备份加实时增量备份，备份数据保留90天以上，认证和计费数据在过渡期双写，老系统故障也不丢账。备份不是可选项，是并存升级的底线。学校要确认备份窗口、保留周期和恢复演练是否到位，不能只配不验。

双轨保障应对突发

上线不是交钥匙。资料建议建立双轨支持机制，原厂工程师加校内运维团队联合保障，7乘24小时响应故障。过渡期尤其需要现场值守，因为新老系统并行时问题最杂。学校要把保障责任和响应时效写进项目约定，而不是上线后各管各的。双轨的意义是出问题有人接，不空窗。

用压力测试验证指标

升级方案里给出的认证成功率、响应时间等指标，要靠压测验证。资料提到每类对接模式至少进行3轮压力测试，模拟1000并发认证，试点接入500到1000名用户监控关键指标。这些数字不是自动成立的，是测出来的。学校验收时要看压测报告和试点数据，不能只看方案里的目标值。

并存期间的账号范围要划清

Radius Proxy分流靠规则，规则的核心是先划清哪些账号走老系统、哪些走新系统。划错范围，老用户被导到新系统认证失败，或者新用户被导到老系统找不到，都会引发大面积投诉。学校在切换前要和业务方核对账号前缀、院系标识、区域VLAN这些划分依据，规则配置后先做小范围验证再放大，不要一次性全量切。