企业在部署WiFi计费系统时，面临的第一道选择题就是架构选型。AC集中式控制和AP分布式架构各有优劣，选错了不只是多花钱的问题，后期扩容困难、运维复杂、认证体验差等一系列麻烦都会找上门。这篇文章把两种架构的核心差异讲透，帮助你根据实际场景做出正确选择。

AC集中式架构。这种模式下，所有无线控制器的功能都集中在AC设备上，AP只负责无线信号的收发，所有用户的认证、计费、策略下发都要经过AC处理。好处是管理集中，策略一致性有保障，适合AP数量多、需要统一管控的大型网络。坏处是AC本身成为性能瓶颈，一旦AC故障影响面广，而且随着AP数量增加，AC的处理能力上限直接决定系统天花板。更关键的是，在WiFi计费场景下，所有用户的认证请求都要经过AC，如果同时在线用户多、认证频率高，AC的CPU和内存压力会非常明显。很多企业在招标时只看AC的AP承载数量指标，却忽略了实际WiFi计费场景下的并发认证压力，结果上线后用户集中认证时系统卡顿，投诉率飙升。

AP分布式架构，也叫APFIT架构或者无所谓AC架构。这种模式下，每个AP都是一个独立的功能节点，内置认证、计费、Portal等功能模块，AP之间通过协议互相通信，不需要一个中心化的AC来统一处理所有请求。这种架构的好处是天然的高可用——任何一个AP故障只影响本区域的几个用户，不会引发全局性的服务中断。而且扩容非常灵活，新增AP只需要在网关上简单配置，不需要升级AC硬件。在WiFi计费场景下，分布式架构一个独特优势：认证流量本地消化，不需要所有请求都穿过中心节点，系统整体的并发处理能力随着AP数量线性增长。缺点是管理复杂度相对较高，每个AP都要单独配置和升级，策略一致性需要借助控制器模板或者自动化工具来保证。对于AP数量在几十台以内的小型网络，分布式架构的复杂度劣势不明显；但对于上百台AP的规模，如果没有好的管理平台，运维成本会快速上升。

实际选型时，有几个关键指标需要重点考察。并发认证能力。WiFi计费系统有个特点：用户上线认证集中在特定时间段，比如上班早高峰、学生下课后的傍晚。一旦同时认证的用户数量超过系统上限，新用户会认证失败，已在线用户可能也会被挤掉。招标时一定要问清楚设备在每秒处理多少次认证请求、满负载时平均认证延迟是多少。有些厂商给的是理论峰值数据，实际测试时打个五折六折很常见。建议用实际规模一半的用户量做压力测试，留足余量。计费精度。预付费用户卡点扣费、后付费用户实时账单生成，这些功能听起来简单，做精准却不容易。尤其是跨时段费率切换（比如工作日和节假日不同价格）、流量和时长混合计费这些场景，考验的是系统的计费引擎设计。很多小厂商的WiFi计费系统在这些边界条件下会出现计费错误，用户投诉量大的话直接冲击运营商的口碑。冗余备份机制。AC架构下，AC本身的HA备份是必选项，冷备还是热备、切换时间多少，这些直接影响用户体验。分布式架构下，虽然单点故障风险分散了，但AP与AC或者AP与Portal服务器之间的通信链路也需要冗余设计。第三方对接能力。WiFi计费系统很少孤立运行，通常要和Portal服务器、Radius认证服务器、营账系统、酒店管理系统等多个外部系统对接。对接的灵活性直接决定系统能否适配已有的IT环境。对接方式包括标准协议（Radius、COA、Diámeter）和私有API两种，标准协议兼容性好但功能有限，私有API功能强但厂商绑定深，需要根据实际情况权衡。

选型时一个容易踩的坑：把WiFi设备和WiFi计费系统混为一谈。买了一套企业级无线AP和AC，就以为自带计费功能，实际上计费模块需要另外采购，或者功能非常简陋只能做简单的时长计费，无法支持复杂的套餐、促销、审计等场景。反过来，有些专门的WiFi计费平台提供完整的认证计费能力，但无线覆盖部分需要对接第三方设备，这种情况下无线质量和计费系统是两套独立的东西，各自的SLA要分开谈，责任边界要提前划分清楚。

。WiFi计费系统选型，核心看三个维度：并发认证能力（决定系统天花板）、计费精度（决定用户信任度和运营风险）、对接灵活性（决定能否融入现有IT架构）。架构选型方面，五十台AP以下、预算有限、管理要求相对简单的场景，优先考虑分布式架构；五十台AP以上、需要集中管控、对策略一致性要求高的场景，选择AC集中式但务必做好AC的冗余备份。实际项目中，很多企业最终选择了混合架构：核心区域用AC集中式保障管理效率，边缘区域用分布式AP降低单点故障风险，同时通过统一的网管平台实现策略一致性。这种方案的前提是选一个支持混合架构统一管理的WiFi计费系统平台，否则两套系统各自为政，运维成本反而更高。