校园网计费系统和认证网关之间的关系，是影响整个网络稳定性的核心架构决策。很多项目上线后出问题，追根溯源都在这个地方。选型的时候没问清楚，后期改架构的成本极高。

紧耦合：一套设备搞定，但风险集中

紧耦合的方案，计费模块嵌在认证网关里面。典型形态是：一台BRAS或者认证网关，既做Portal/802.1X认证，也做计费策略执行和账单生成。代表产品是一些厂家的"一体化网关"。

好处很明显：部署简单，一套设备、一套配置界面，运维人员不用管两个系统。小型校园网（比如不到1000人的中职学校）用这种方案没问题，故障面小，配置工作量也低。

坏处是：计费逻辑和认证逻辑在同一个设备上，升级固件的时候两个功能一起动，风险集中。而且计费策略的变更需要重启认证服务或者重启设备，对网络可用性有影响。如果计费模块出bug，认证也会受影响——学生连不上网，不是因为认证有问题，是因为计费模块崩溃了。

松耦合：独立服务+标准协议，灵活性高

松耦合的方案，认证网关（BRAS/AC/Portal网关）只负责接入认证，计费作为独立服务运行在另一台服务器上。两边通过标准协议通信——最常用的是Radius计费报文（Accounting-Request/Response）和REST API。

这种架构的好处是各自独立升级、互不影响。认证网关换固件，计费服务不用动；计费策略大调整，认证网关无感。故障面也分散——计费服务宕机，认证还可以正常工作（取决于具体配置，有的可以配置成"计费失败时允许放行"）。

坏处是对运维能力要求高。你需要理解两个系统之间的协议交互，会看Radius报文，懂REST API的调用逻辑。如果运维团队只有一个人，而且这个人没有协议层面的理解能力，松耦合的架构会增加故障排查的难度。

怎么选：看校园规模和运维能力

1000人以下的校园网，紧耦合通常够用。理由：规模小，计费策略相对简单（基本就是包月或者按流量计费），故障影响面也小。而且这类学校通常没有专职网管，紧耦合的"一套设备搞定"更符合实际运维能力。

1000人以上的校园网，建议松耦合。规模大了以后，计费策略的复杂度会上一个台阶——可能有教职工免费、学生按套餐计费、访客临时通行码、多运营商代拨等多种策略并存。这些东西放在认证网关里做，配置会非常乱。独立计费服务可以做到策略清晰、模块化。

还有一个判断维度：有没有多运营商代拨的需求。如果学校跟多家运营商合作，学生可以选择走电信或者联通，计费系统需要动态路由到对应运营商的BRAS。这个场景下，松耦合几乎是必须的——认证网关只管身份识别，计费服务根据套餐选择路由。

选型时必须问清楚的3个问题

不管厂家怎么宣传，选型的时候把这3个问题问清楚：

第一，计费模块是紧耦合还是松耦合？如果厂家说"我们两套都支持"，让他演示两套方案的区别，不要只听宣传。

第二，计费服务宕机后，认证还能工作吗？如果能，是"放行所有用户"还是"按上一次计费策略继续执行"？这两种Fail-Open策略的安全性差异很大。

第三，后期调整计费策略，需要重启认证设备吗？如果回答"需要"，这个产品不适合中大型校园网。

这三个问题答不清楚的厂家，直接pass。不是产品一定不行，是厂家的技术支持能力可能跟不上，后期出问题找不到人。

实际项目里的选型建议

我参与过的一个高职院校项目，最终选了松耦合方案，上线后运行了一年多，中间计费服务出过一次故障（磁盘满了导致无法写入新账单），但认证不受影响，学生正常上网。运维人员有时间修磁盘、清理日志，修完之后计费服务自动恢复，缺漏的报文通过"会话保活检测"补录回来了。如果是紧耦合方案，计费模块崩溃等于认证也挂了，全校断网，投诉电话能打爆运维的手机。

不过也要说一句公道话：紧耦合方案如果厂家靠谱、产品稳定，小规模校园网用它完全没问题。问题是很多学校选了紧耦合之后，过几年规模扩大了想改成松耦合，迁移成本很高——认证网关和计费逻辑解耦，相当于重新做一次项目。所以选型的时候要考虑3-5年后的扩展性。