企业 IT 的单租户与多租户架构对比

在single tenant vs multi tenant（单租户与多租户）的辩论中，最常见的建议也是最没用的：单租户安全，多租户便宜，而决策最终只取决于一张采购评分表。这种设想在网络设计具有最大商业影响力的建筑环境中是行不通的。

在酒店、学生公寓、多家庭住宅、医院园区或联合办公空间中，决定性的问题是谁来控制网络边界。即使是专用的平台，也可能会因为不当的策略而导致流量泄露。而只要在设计中妥善处理身份、身份验证、路由和注销，共享的物理架构同样可以保护每个租户。租户数量只是一个标签，边界控制才是真正的架构。

美国住房数据使这一区别变得不容忽视。政府分析确定了 459,262 个属于或可能是混合产权的开发项目，包含 333 万套经济适用房，相当于官方住房统计中确定的 421 万套经济适用房的 79%。然而，经济适用房租户的平均比例为 80%，而中位数为 97%，这表明开发项目虽然可以包含多种产权，但仍高度集中在一种居住类型上。专为特定用途建造的公寓占 已确定多住宅开发项目的 54%，其经济适用房租户比例中位数为 91%，而改建公寓的这一比例为 50%。物业形态改变了运营边界问题，而不仅仅是租赁合同。(英国政府关于英格兰社会住房混合产权的分析)

为什么单租户与多租户的选择不仅限于 SaaS 领域

企业团队通常是从 SaaS 采购中继承这类讨论的。他们将专属实例与共享应用基础设施进行比较，然后假设同样的结论也适用于物理建筑。事实并非如此。在共享物业中，更重要的问题是运营商能否将每个居民、访客、部门或承包商保持在正确的访问和策略边界内。

单租户部署通常会给工程师带来更干净的物理隔离。这有助于审计范围、变更控制和故障抑制。但这并不能消除运营风险。一个未及时打补丁的控制器、弱管理员凭据、配置错误的防火墙规则或范围划分不当的身份验证服务，对专属环境的破坏力与对共享环境的破坏力是一样的。

多租户网络带来了一种不同的责任。运营商共享接入点、交换机、控制器、上行链路以及通常的管理平面，然后使用逻辑控制来隔离用户。这些控制必须在无线、身份验证、路由、DNS、监控和支持层之间协同工作。仅仅因为拥有不同的 SSID 或登录页面，并不意味着租户就处于隔离状态。

实际边界并不是 SSID。它是从身份到授权、流量转发、遥测以及撤销的完整链条。

待测试的三个边界

从三个独立的问题来审视架构：

• 物理边界：哪些射频、交换机、控制器、电路和设备是共享的？
• 身份边界：网络如何识别正在连接的是哪个人、设备、房间、部门或公司？
• 管理边界：谁可以创建凭据、更改策略、检查遥测数据、批准访问以及撤销访问？

这种方法在酒店和住宅 WiFi 网络中至关重要，因为用户并不关心厂商称其设计是云原生、共享还是专用的。他们期望自己的设备能轻松连接，且邻居的设备保持隔离。员工期望在他们的目录账户被禁用时，访问权限立即消失。运营商期望有一个统一的支持工作流程，而不是为每个房间或住户提供一套独立的网络基础设施。

美国的消防安全政策提供了一个有用的平行案例。2021 年消防安全法案明确了消防安全命令适用于具有两套或两套以上国内住宅的多户住宅建筑的结构、外墙、阳台和公寓入口门。相关法规于 2023 年 1 月 23 日生效，而历史上的多房出租（HMO）控制措施是在发生严重火灾后发展起来的，并为多户住宅建筑确立了一个独特的风险类别。(美国政府混合产权研究与消防安全背景)

网络架构师得到的教训是直接的。共享占用需要明确的控制，但答案并不自动就是专用硬件。它是一个与建筑物的风险、商业模式和运营能力相匹配的、可证明的边界。

单租户与多租户架构深度解析

在网络领域，单租户意味着一个组织或占用者拥有专用的基础设施堆栈或专用的运行实例。这可能包括独立的接入点、控制器、VLAN、身份验证域、监控和管理权限。该设计限制了共享依赖项，当组织拥有每个终端和策略决策时，这使得环境更易于管理和理解。

医院信托机构、国防基地或企业园区可能会为核心流量选择这种模式，因为其内部身份识别、合规性和事件响应流程需要一个受到严格控制的环境。专用基础设施还可以支持定制的射频规划、不寻常的设备需求以及难以在不相关的租户之间协调的变更窗口。

多租户网络在应用针对每个组织、家庭、房间、部门或服务的逻辑控制的同时，使用通用的物理架构。VLAN、VRF、RADIUS 属性、基于身份的私有预共享密钥、防火墙策略和策略引擎可以创建独立的访问上下文，而无需复制每个设备。

物理网络是共享的。安全上下文和用户体验则不应共享。酒店连锁集团可能会在所有物业中运营一个集中管理的平台，而学生公寓运营商则可能会将每位居民或单元映射到独立的策略和凭据上下文中。

单租户与多租户网络一览

维度	单租户 (Single Tenant)	多租户 (Multi Tenant)
物理隔离	专用的基础设施或运维实例	共享的交换机、接入点、控制器或线路
逻辑隔离	通常更简单，因为共享该环境的租户较少	至关重要，通过身份、VLAN、VRF、防火墙规则和策略强制执行
管理平面	专用或严格限定于单一组织	集中式管理，具备租户感知管理和委托权限
成本扩展	每个租户都会重复产生基础设施和运维工作	共享基础设施并集中管理
典型场景	受监管的企业、国防、医疗核心、专用企业资产	酒店款待、学生公寓、多家庭住宅、托管服务、共享办公空间
主要失效模式	重复的资产产生偏差或维护不足	策略或身份错误可能会影响多个租户

比较部署模式的团队可以将此 多租户 WiFi 架构指南 作为实用参考，但设计仍需要针对实际建筑物和运营模型进行测试。

选择不在于安全与不安全。而是在具有更高重复性的物理隔离与具有更高设计和治理要求的逻辑隔离之间进行选择。

核心衡量标准横向对比

架构决策取决于建筑和运营模式，而非 SaaS 标签。医疗网络、学生公寓、多家庭住宅和酒店都可能将 WiFi 作为公用事业来提供，但它们可接受的故障界限、支持职责和流量模式却各不相同。

当故障必须限制在单个组织的物理区域内时，请选择单租户。工程师可以更改控制器、防火墙或身份验证服务，而无需协调共享的维护窗口。这种优势只有在每个专用环境都获得妥善的补丁管理、监控、文档记录和恢复测试时才能持久。专用基础设施提供的是控制力，而不是自动的弹性。

当单一运营商必须跨多个住户或物业交付可重复的服务时，请选择多租户模式。共享的网络架构支持标准策略、集中监控和一致的引导流程。但运营商也因此承担了更大的治理责任：凭据、流量、遥测和管理访问权限必须针对每个租户保持正确的范围限制。

决定网络设计的五个要素

评估标准	单租户 (Single Tenant)	多租户 (Multi Tenant)	核心定位点
隔离性	物理隔离限制了共享的影响范围	逻辑隔离必须跨每个控制层保持生效	隔离强度随着隔离程度的提高而增加，从共享架构到每个租户独立的数据库
安全性	更少的共享依赖关系创造了更清晰的审计边界	集中控制提高了 consistency，但单个策略错误可能会影响多个租户	安全取决于身份保证、配置、补丁和监控，而非架构标签
成本	硬件、许可证、支持路径和维护需要为每个租户重复投入	共享基础设施提高了利用率并减少了重复工作	每租户成本随着隔离强度的增加而上升。详细的成本对比见下一章节 (US SaaS 架构对比)
性能	专用容量避免了租户之间的资源争夺	共享容量需要准入控制、QoS 和主动监控	运营商需要对吵闹邻居和高需求设备进行显式控制
运维	每个环境可能更简单，但整体资产会变得重复繁琐	只要身份和策略自动化足够成熟，单一平台即可高效运行	单租户将运维工作集中在每个环境上。多租户则将其集中在治理和控制平面上

隔离是一项设计属性

通过流量测试隔离情况，而不是看图表。一名居民能否发现另一名居民的设备？宾客能否访问员工服务？支持管理员能否查看另一个租户的会话数据？被注销的身份是否会立即失去访问权限，包括从之前已授权的设备上失去访问权限？

同样的测试适用于这两种模式。专用控制器不会自动解决这些问题，而共享控制器也不会使这些问题变得无法解决。决定性的问题在于执行发生在何处、管理员的范围如何界定，以及每个租户之下有多少公共基础设施。

在学生公寓和多家庭住宅中，尽管整个建筑共享交换机、无线网络和上行连接，居民依然期望获得私密访问。酒店也面临着宾客、员工和运营服务之间的相同边界。医疗保健行业则增加了受管临床设备和遗留系统，因此策略模型必须保护这些依赖项，同时又不能让日常支持变得无法执行。

性能表现随需求模式而变

酒店在办理入住、活动和晚间使用期间会出现集中需求。学生公寓则结合了密集的设备群和频繁的人员流动。医疗保健环境混合了托管设备、个人设备和专用系统。单租户可以保留容量，而多租户在运营商测量空口时间、应用 QoS 并将关键流量与娱乐使用分离时，同样可以满足相同的需求。

在这些物业中，WiFi 现在已成为一项公用事业。服务中断会影响居民体验、访客运营和商业成果，而不仅仅是一个技术仪表盘。

实际测试很简单：运营商能否在用户报告之前观察到冲突，识别负责的租户或服务，并在不重建网络的情况下更改策略？如果不能，则所选的隔离模型是不完整的。

成本、规模以及隔离带来的隐性开销

专用基础设施在项目计划中看起来很简单。每个租户都会获得自己的控制器、交换机、接入点、许可证、监控集成、身份库、固件计划和支持流程。账单中包含了部署、记录、测试、打补丁和恢复每个副本所需的工程时间。

单租户设计还会导致运维工作重复。工程师必须维护独立的模板、在不同的控制台中查看类似的警报、重复进行固件验证，并保留独立的恢复程序。当租户需要独特的合规边界或特殊的网络控制时，这种隔离所付出的成本才是值得的。但如果每个租户都接受相同的服务，且没有任何策略要求进行物理隔离，那么这就变成了对利润空间的侵蚀。

早先的成本对比仍然适用，但网络运营商必须考虑 SaaS 表格中未显示的费用。单独的控制器许可证可能带有其自身的合同范围。每个新增平台在部署前都可能需要支持协议、维护窗口和固件验证。工程师们还需要花时间在多个环境中测试认证、监控、故障转移和租户交接。在繁忙的学生公寓、多户住宅或酒店组合中，这些工时对服务利润率的影响与硬件一样直接。

单租户成本明细

成本明细项	单租户（每个租户）	多租户（每个租户）	备注
物理基础设施	专用或预留堆栈	共享架构分配	单租户会重复设备和现场工作
控制器和平台许可	独立的实例或许可范围	共享平台、租户感知许可	合同条款可能会改变结果
身份与认证	独立的域或专用集成	带有范围策略的共享服务	多租户需要强大的租户映射
监控	独立的仪表板和警报路径	带有租户过滤器的中央仪表板	糟糕的过滤可能会带来访问控制风险
支持与变更管理	租户特定的窗口和运行手册	带有异常处理的标准化工作流	只有在策略成熟时，标准化才能提高规模效率
恢复与测试	独立的恢复计划	共享平台恢复加租户验证	运营商必须证明租户级的恢复能力

只有当运营商能够一致地强制执行租户边界时，共享平台才能减少重复。它需要策略模板、分阶段部署、配置验证、租户范围的日志和经过测试的回滚。如果没有这些控制，一个共享控制台可能会把隔离问题变成访问控制问题。

网络设计在生产环境变更之前应进行测试。团队可以使用 iPSK 网段设计器 来模拟基于身份的隔离，检查子网分配，并及早发现地址或策略冲突。

当业务需要物理边界时，为物理隔离付费。不要仅因为设计团队没有构建出值得信赖的逻辑边界，就为此付费。

正确的答案通常是混合模式。将临床、支付、楼宇管理或企业流量保持在受到严格控制的专用路径上。而对访客、居民、承包商和其他变动人群，则使用共享且具有租户感知能力的网络。这种分配将隔离应用于发生故障会带来商业、监管或安全后果的场景，同时通过共享基础设施来处理受益于规模效应的需求。

企业 IT 和网络运营商的真实应用场景

当明确了所有者、使用者和故障影响时，架构决策就会变得更加清晰。供单一组织使用的网络并不自动等同于单租户问题，而为多人服务的网络也不自动等同于多租户问题。

场景一：拥有 5,000 个席位的大型企业园区

具有严格数据驻留要求的大型企业园区应默认将核心服务设为单租户。决定因素不是员工人数，而是对齐物理、管理和审计边界的需求。

专用的控制器、认证服务、管理访问和流量路径使所有权的界定更加容易。安全团队可以将管理员访问权限限制在组织员工内，定义单一的变更流程，并在无需过滤不相关租户活动的情况下调查事件。

访客访问仍可使用独立的逻辑服务。核心员工网络不应依赖与临时访客、承包商或活动参与者相同的策略路径。

场景二：多场所酒店连锁集团

在单一品牌下运营多家物业的酒店集团通常应选择 multi tenant。中央网络运营中心需要在酒店、餐厅和场所之间保持一致的准入引导、Captive Portal 策略、报告和事件响应。在每个物业重复部署完整的管理体系会让标准化变得更加困难，而不是更安全。

在物业、访客、员工和服务层面，边界依然需要存在。访客设备不应访问销售点系统。员工身份不应继承访客权限。物业团队应该只能查看其工作所需的信息，而不是获得对每个场所不受限制的访问权限。

权衡显而易见。集中式控制胜出，前提是运营商能够强制执行租户感知的管理和流量策略。

场景三：美国多家庭住宅和学生公寓

在多家庭住宅和学生公寓中，混合多租户模式通常更具优势。居民期望获得公寓级或房间级的隐私，而运营商则受益于单一的物业级物理网络、单一的支持模式和集中式服务管理。

英国学生公寓证据表明，在苏格兰接受调查的房东中，有93%使用单一租赁协议，而7%使用多重租赁协议。这表明行政上的简便性仍在影响着运营模式。(英国学生公寓证据)

这些建筑中的网络连接越来越多地由运营商提供服务，而不是由每位居民签署合同。在 Save the Student 的 2026 年全国学生住宿调查中，80% 的学生表示他们的租金至少包含了一项额外服务，48% 的学生表示捆绑了宽带，仅次于水费 (63%)、电费 (61%) 和燃气费 (54%)。可靠地交付网络是更难的部分：Jisc 对 15,398 名英国高等教育学生的 2024/25 调查发现，60% 的人报告在校园内或校园外遇到过 WiFi 连接问题。(Save the Student，2026 年全国学生住宿调查；Jisc 数字化体验洞察 2024/25)

因此，网络需要提供私密体验，而无需将每个居民变成一个单独的基建项目。基于身份的访问、按单元策略、简单的计费和即时撤销，比架构标签更为重要。

在不复制网络的情况下实现租户隔离

现代身份驱动的网络在“每个租户一个物理堆栈”与“无控制的共享网络”之间提供了第三种选择。运营商共享底层架构，然后将访问权限绑定到个人、单元、房间、部门或设备身份。

iPSK 是住宅和混合设备环境的实用起点。运营商无需向整栋建筑发放一个共享密码，而是分配不同的私有密钥，并将其映射到策略上下文中。密钥可以根据运营需求识别公寓、房间、居民、设备组或服务等级。

分层构建控制平面

1. 将身份与访问权限进行映射。使用 RADIUS 属性、目录组或托管身份服务将用户或设备与正确的租户策略进行关联。
2. 应用基于角色的控制。员工、居民、访客、承包商和建筑系统应获得不同的权限。评估该层级的团队可以查看 基于角色的访问控制软件，以了解按角色制定策略的更广泛解释。
3. 隔离流量。使用 VLAN、VRF、防火墙规则和服务策略来阻止租户之间的横向移动并保护业务系统。
4. 自动化生命周期事件。在居民或员工获得批准时配置访问权限，并在目录或物业管理记录更改时撤销该权限。
5. 划分遥测范围。集中监控应为运营商提供有用的健康数据，而不会向另一个租户泄露某个租户的身份或会话信息。

通过 Microsoft Entra ID 或 Okta 进行的单点登录可以将企业访问权限与既定的身份治理相绑定。这对于员工和受管用户非常有效。而对于居民、访客、传统设备以及无法完成现代企业身份验证流程的设备，iPSK 仍然非常实用。

Purple 的 基于身份的网络平台 就是控制平面方法的一个实例，它支持在共享基础设施上实现特定租户的访问，包括 iPSK 以及与企业身份提供商的集成。它在这种架构中的价值并不在于存在另一个 SSID，而是在于能够将身份、策略、入网和撤销关联起来，而无需为每个占用者配备独立的物理网络。

设计仍需要测试。验证凭据无法越过其预期的策略、设备配置不会绕过分段、管理员拥有租户范围的权限，以及撤销操作能触及活动会话。共享的物理网络可以提供私有租户体验，但前提是运营商将身份和策略视为生产基础设施。

您应该在何时选择何种架构

当组织需要专用的物理边界而不仅仅是独立的登录时，请使用单租户。受监管的医疗保健、支付环境、国防和高敏感度的企业工作负载在核心服务上应以此为起点。该架构简化了证据收集并减少了共享依赖项，尽管它仍然需要严谨的补丁管理、监控和身份管理。

当运营商为许多客户、占用者、房间、部门或物业提供服务，且该服务依赖于可重复的交付时，请使用多租户。酒店、学生公寓、多家庭住宅、托管服务和共享工作空间通常从集中化运营中获益更多，而不是通过复制硬件。其前提是必须执行严格的租户感知策略，而不是放宽安全标准。

当一个场所内既包含高敏感度的内部服务，又包含大量临时或居住用户时，请采用混合模式。

架构推荐矩阵

场景	推荐模式	原因
受监管的企业核心、医疗临床系统或支付流量	单租户	物理和审计边界应与组织的控制边界相匹配
服务于众多客户的 SaaS 提供商或托管服务运营商	多租户	共享基础设施支持可重复的策略、集中式运营和高效扩张
拥有中央宾客服务的酒店集团	多租户	单一运营模式支持跨物业的一致身份、支持和业务交付
多户住宅、学生公寓或弹性工作空间	混合多租户	共享基础设施配合每个占用者的身份、策略、计费和撤销进行工作
拥有员工和访客网络的企事业单位	混合型	保持敏感的企业流量受到严格控制，同时应用租户感知的访客访问
经常发生“吵闹邻居”事件或有审计发现的环境	重新评估，然后隔离受影响的服务	无论架构标签是什么，当前的边界都已失效

迁移决策应遵循相同的逻辑。在选择平台之前，盘点流量类别、身份、设备类型、管理角色和故障域。红线警告包括未解释的跨租户可见性、站点之间策略不一致、访问撤销缓慢、支持团队的管理权限过大，以及由于缺乏控制或功能延迟导致的租户流失。

在签署设计方案前先问一个问题：谁拥有网络边界，他们需要的是专用硬件还是专用策略？

指导性文件的总结非常简单：

• 当物理隔离是业务或合规性要求时，选择 single tenant。
• 当规模化依赖于共享基础设施和成熟的身份控制时，选择 multi tenant。
• 当敏感的核心流量与高吞吐量的共享访问共存时，选择混合模式。

---

Purple 为共享建筑提供基于身份的网络，包括租户级访问控制以及在公共基础设施上基于 iPSK 的隔离。访问 Purple 以评估该方案是否适合您的学生公寓、多家庭住宅、酒店、医疗保健或企业访客 WiFi 网络设计，然后使用您自己的身份、注销和流量策略来测试边界。