做校园网的同行应该都遇到过一个经典场面：学校网络中心的人说"我们的认证系统很完善了，你们计费系统只要对接一下就行"，然后你进场一看，发现"对接一下"这四个字背后藏着三套不同的认证逻辑、两个版本的数据库、还有一堆没人维护的旧脚本。这时候你才意识到，校园WiFi网络计费系统和认证系统之间的关系，远比"对接一下"复杂。

认证管身份，计费管钱

先说清楚两者的基本分工。认证系统回答的问题是"你是谁、你有没有权限上网"，它做的工作是：核对账号密码（或者证书、或者微信授权），确认这个用户在网络准入策略里是不是合法的，然后通过或者拒绝。计费系统回答的问题是"这个用户用了多少流量、在线多久、该付多少钱"，它做的工作是：记录用户的上网时长和流量消耗，按照预设的套餐规则计算费用，处理充值扣费，生成账单报表。

理论上分工很清晰，但实际部署的时候，两者的边界经常会模糊。比如"在线时长"这个数据，认证系统其实也能记录——用户什么时间认证的，什么时间下线的，一减就是在线时长。那计费系统还需要自己记录吗？还是直接读认证系统的数据？

我们在一个项目里采取的方案是：认证系统负责"上线/下线"的事件通知，计费系统收到通知后自己维护一套在线状态表。这样做的好处是，计费系统不依赖认证系统的在线时长计算逻辑，即使认证系统换了，只要它还能发"上线/下线"通知，计费就能正常工作。

Radius计费属性：标准但不够用

最基础的对接方式是利用Radius协议里的计费属性（Acct-Status-Type、Acct-Input-Octets、Acct-Output-Octets等等）。认证系统作为Radius服务器，在用户上线时发一个Accounting-Start报文，下线时发Accounting-Stop报文，计费系统收到后更新用户的时长和流量记录。

这个方式的优点是标准、通用，大部分认证系统都支持。但缺点是，Radius计费属性的粒度比较粗——它只能告诉你"这个用户上线了"和"这个用户下线了，期间用了多少流量"，中间的过程是黑盒。如果用户在线的四个小时里，前两个小时用的是套餐A，后两个小时套餐改成了套餐B，Radius计费属性是反映不出来的，计费系统只能按"下线时统一结算"来处理。

所以对计费精度要求高的场景，仅仅靠Radius计费属性不够，还需要认证系统开放更多的接口，让计费系统能实时查询"当前在线用户列表"和"当前已用流量"。我们在一个上万人规模的学校项目里，就是采取的这种混合方式：用Radius做基础的对齐，用定制接口做实时流量同步。

数据库直读：简单但风险高

有些学校的认证系统和计费系统是同一厂商的套装产品，这种情况下两者可能共用同一个数据库。计费系统直接读认证系统的用户表、在线状态表，拿到数据后做计费计算。

这个方式实现简单，不需要做接口对接开发。但风险在于：如果认证系统升级了，数据库表结构变了，计费系统就可能读不到数据，或者直接读错。我们见过一个案例，认证系统从3.0升级到4.0，用户表的字段名改了，计费系统没有同步升级，结果所有用户的套餐到期判断都出错了，导致该断网的没断，学校损失了不止一个月的套餐费。

所以如果采取数据库直读的方式，一定要跟认证系统厂商确认：数据库表结构在版本升级时是不是向后兼容的？如果不兼容，有没有升级指引说明哪些表结构变了？

API中间件：灵活但开发成本高

现在越来越多的校园WiFi网络计费系统开始支持REST API对接。认证系统提供一组API：查询在线用户、查询用户流量、推送上线/下线事件；计费系统通过调用这些API来获取它需要的数据，而不是依赖Radius协议或者数据库直读。

这个方式最灵活，因为API返回的数据格式是结构化的，扩展起来方便。比如学校后来要增加一个"按应用类型计费"的需求（微信流量免费、视频流量收费），只要在API里增加一个"应用类型识别"的字段，计费系统就能拿到这个数据做差异化计费。

但开发成本也最高。API对接需要双方的开发团队反复沟通接口定义、联调测试、处理各种异常场景（网络超时了怎么办？认证系统返回了错误码怎么办？）。我们评估过一个项目，如果走API对接，定制开发的工作量大概是三到四周；如果走Radius对接，大概是三到五天。差距还是挺大的。

一个经常忽略的问题：时间基准

这个问题听起来很基础，但实际项目里出过不止一次事故。认证系统和计费系统如果部署在不同的服务器上，两台服务器的时间如果有偏差，就会导致计费不准确。比如认证系统记录的用户上线时间是14:00:00，计费系统因为本地时钟快了30秒，记录的上线时间是14:00:30，那么结算在线时长的时候就会少算30秒。单个用户看不出来，上万人累积一天，偏差就很可观了。

解决办法不复杂：两台服务器都接NTP时间服务器，保证时间偏差在可接受的范围内。但这个事要在部署阶段就做好，不能等出了问题再查。

校园WiFi网络计费系统和认证系统之间的边界，看起来是技术架构问题，实际上更多是关于"谁负责什么"的责任划分。边界划清楚了，后续运维的时候才知道出了问题该找谁；边界模糊，最后就是两方互相推，学校的人夹在中间头疼。