认证系统宕机意味着什么？在酒店里，意味着所有新入住的客人连不上网，投诉电话打爆前台；在商场里，意味着顾客WiFi连不上，很多依赖微信认证的营销活动全部失效；在学校里，意味着整栋宿舍楼的学生全部掉线。WiFi网络认证系统的可用性往往比它的功能更重要——功能不够用是体验问题，系统挂掉是运营事故。

认证系统的典型故障模式

了解常见的故障模式，才能有针对性地设计高可用架构。认证系统的故障通常来自几个方向：

认证服务器本机故障：硬件损坏、操作系统崩溃、磁盘空间耗尽、进程异常退出。这类故障是最直接的，服务器不响应，所有认证请求都挂起。

数据库故障：认证系统通常依赖数据库存储用户账号、Session、日志等数据。数据库服务异常、连接池耗尽、慢查询拖垮整个服务，都是常见问题。

网络链路中断：认证系统在网络拓扑中处于关键位置，如果认证服务器和网络设备之间的链路断了，认证请求无法到达服务器，所有新建连接都会失败。

外部依赖失效：短信网关、第三方身份核验接口、微信公众号授权接口，这些外部依赖如果出问题，依赖它们的认证方式就会全部失败。

主备架构的设计思路

最常见的高可用方案是主备架构——部署两台认证服务器，正常情况下主服务器处理所有请求，备服务器处于热备状态；主服务器故障时，流量自动切换到备服务器。

主备架构看起来简单，实际上有几个细节容易处理不好：

数据同步问题。主备之间需要实时同步的数据包括：在线用户Session（切换后在线用户不被踢下线）、账号数据（备机要有完整的账号信息）、日志（切换后日志不断）。这三类数据的同步机制不同，Session需要毫秒级同步，账号数据允许秒级延迟，日志允许分钟级延迟。设计同步机制时要把这些区别考虑进去，而不是全部用同一种同步方式。

切换判断的准确性。什么时候触发故障切换？简单地"Ping不通"作为判断条件太粗糙——服务器还活着但服务进程挂了，Ping是正常的。健康检查需要针对服务进程做，检测认证服务的HTTP端口或RADIUS端口是否能正常响应。

切换速度和切换代价的权衡。切换太慢，故障影响时间长；切换太快，可能因为网络抖动导致频繁的"假切换"，反而制造更多问题。通常的做法是设置连续检测失败N次才触发切换，而不是一次失败就切。

本地认证逃生通道

对于部分场所来说，认证系统临时不可用但网络仍可使用的需求是存在的。比如酒店深夜认证服务出问题，如果直接断网，会引发严重的客诉；但如果允许所有设备在认证失败时直接上网，合规要求又没有保障。

一种折中方案是配置本地认证逃生：当认证服务器不可达时，网络设备降级到"已认证设备继续通行，新设备需要等认证服务恢复后再认证"的模式。这种模式依赖网络设备本地缓存已认证设备的MAC列表，认证服务器不可用期间，缓存内的设备维持在线状态，新连接请求则进入等待队列或显示维护提示页。

这个方案的前提是网络设备支持本地Session缓存，且缓存有效期内不强制重新认证。具体能不能落地，取决于网络设备型号和固件版本，在设计阶段要和设备厂商确认。

外部依赖的降级策略

WiFi网络认证系统依赖的外部服务可能因各种原因失效，降级策略是减少这类影响的关键。

短信网关降级：配置多家短信服务商，主服务商发送失败时自动切换到备用服务商。这个功能大部分短信服务商都支持，只需要在认证系统里配置好备用服务商的API即可。

身份核验接口降级：当身份证核验接口不可用时，降级到"仅手机号认证"。这种降级会降低合规级别，但比让用户完全无法上网更合理。降级期间需要打好日志，事后补充核验记录。

微信授权降级：当微信授权接口不可用时，Portal页自动隐藏微信授权选项，引导用户使用短信认证。这个切换要对用户透明，不要让用户看到一个失败的微信授权按钮。

监控和告警体系

高可用架构是被动保障，监控告警是主动发现问题。认证系统需要监控的核心指标包括：认证成功率（突然下降说明出问题了）、认证延迟（超过3秒说明系统压力大或有故障）、在线用户数（异常下降说明有大批用户被踢下线）、日志写入速率（停止写入可能是磁盘满了）。

告警触发后，通知要到人。在很多场所，告警发到了IT部门的邮件群组，但半夜没有人看邮件。合理的做法是把高优先级告警发到值班人员的手机，确保有人能在故障发生后第一时间响应。

定期演练和恢复验证

高可用架构不是配好就万事大吉。主备切换的逻辑如果长期没有被触发过，到真正出问题时可能会发现切换失败，或者切换后还有其他问题。定期的故障演练很有必要——在低峰期手动关停主服务器，验证备服务器能否正确接管、Session是否保持、日志是否连续。

演练的频率不需要很高，每季度一次就足够，但每次演练都要记录结果，形成历史档案。如果某次演练发现了问题，修复后要再次验证，不能只修复不复测。这个习惯在认证系统的长期运维中非常重要。