一栋宿舍楼的计费好做，几十栋楼、分散在几个校区、每栋情况还不一样，管起来就完全是另一回事。有的楼是新盖的、网络条件好，有的是老楼、线路老旧，有的归本部管、有的归后勤集团管。这种规模下，如果不做统一的架构设计，就会变成每栋楼一套小系统、各管各的，数据对不齐、报表拉不通、运维忙不过来。这篇讲多栋楼统一管理时，架构上要怎么搭才既能统得住又能分得开。

先想清楚统一到什么程度

统一管理不等于所有东西都揉成一锅。要先分清哪些必须统一、哪些应该保留各楼的灵活。通常账号体系、计费规则框架、身份认证、数据报表这些要统一，保证全校口径一致；而具体的免费额度、某些楼的特殊套餐、本地设备的运维，可以在统一框架下留一定的自主空间。我们见过两种极端都出问题：一种是完全各自为政，全校几十套系统数据打架；另一种是统得太死，某个校区的特殊需求完全没法满足。合理的架构是搭一个统一的底座，上面允许分楼、分校区做有限的差异化。

用计费域把组织结构映射进来

多栋楼统一管理，核心是要在系统里建立清晰的层级。比较实用的做法是引入计费域的概念，把学校的实际管理结构映射进系统：校区是一级、楼栋是二级、楼层或者房间是三级。每一级都能单独查数据、单独出账单、单独配策略。这样后勤想看某个校区的整体情况能看，想追到某栋楼某个房间也能追。关键是系统里的这套域结构要和学校真实的行政管理结构对齐，别自己另搞一套划分，否则出了事对不上人。我们建议架构设计初期就把这张组织映射表画出来，作为整个系统的骨架。

认证和计费的部署要考虑校区分布

校区分散时，认证服务器放哪是个要认真算的问题。全部集中在一个中心机房，好处是管理统一，但如果校区之间网络链路不稳，远端校区认证就会又慢又容易断。全部分散到各校区本地，认证快了，但运维和数据同步的复杂度上去了。比较常见的折中是核心的计费和数据集中，认证节点在各校区本地部署，本地认证、集中计费。这样即使某个校区到中心的链路出问题，本地学生还能正常认证上网，计费数据等链路恢复再同步。架构设计时要根据学校的校区网络实际情况来定这个集中和分散的比例。

报表既要能合又要能分

统一管理最直接的价值，体现在报表上。财务要全校的总收入，后勤要各楼的运营情况，某个校区的负责人要自己校区的数据。所以报表系统必须支持从全校汇总到单栋楼、甚至单个房间的逐级下钻，也要支持按校区、按楼、按时间横向对比。我们见过报表做得糙的系统，只能导一堆原始流水，财务自己拿Excel加班加点算，费时还容易错。好的架构应该让不同层级的管理者登录后，看到的就是自己权限范围内、已经算好的数据。报表能分能合，统一管理才算真正落地，而不只是设备接在了一起。

权限要按管理层级分配

几十栋楼统一管理，不可能所有事都由一个管理员干。系统必须有分级权限：校级管理员能看全校、配全局规则；校区或者楼栋管理员只能管自己范围内的事；财务只看账目不动配置；一线运维只处理故障不碰计费规则。权限划分得清楚，既能放权让各层级自己处理日常，又能防止越权操作出乱子。我们经手过一个项目，早期没做权限分级，所有人共用一个超级管理员账号，结果有人误改了全局计费规则，全校扣费出错，追责时连是谁改的都查不出来。权限体系是统一管理架构里最不该省的一块。

为后续扩容留出余地

学校是会发展的，今年管十栋楼，过两年可能新建校区、新增宿舍楼、学生规模翻番。架构设计时如果只按当前规模算，很快就会被撑爆。要在容量、授权、部署结构上都留出余地：认证服务器能横向扩、数据库能扛更大的数据量、软件授权模式支持增加楼栋和账号。我们建议架构评审时专门问一句，如果三年后规模翻一倍，这套架构改不改得动。答得上来的方案才是能长久用的方案。多栋楼统一管理的架构，从一开始就要按成长的眼光去设计，而不是按此刻的规模去凑合。

多校区多栋楼的本质是组织复杂度。学校宿舍上网计费系统要做的，不是消灭这种复杂，而是用清晰的计费域、合理的部署、能分能合的报表和分级的权限，把复杂管住。架构上肯在前期花心思，后面运营就轻松；架构糊过去，规模一大就处处掣肘。统一管理不是把系统堆在一起，而是让复杂的结构在系统里变得井井有条。