多机房单元化架构“完全隔离”的核心是数据、服务、状态、资源、治理行为五层面互不感知：数据分片自治且禁跨单元写入；服务路由闭环与注册隔离；缓存命名空间硬隔离；资源通过cgroups和网络策略硬限；治理行为（熔断、限流等）全独立。
多机房单元化架构要实现“完全隔离”，核心不是物理隔开，而是让每个单元在**数据、服务、状态、资源、治理行为**五个层面互不感知、互不影响。所谓“完全”，是指一个单元故障时，其他单元的请求处理、数据一致性、资源调度、监控告警全部不受干扰——连熔断阈值、限流计数器、缓存Key空间都不共享。
数据层：分片自治 + 无跨单元写入
每个单元拥有独立数据库实例（非只读副本），用户ID哈希或地域规则决定归属单元，写请求只落本单元库。禁止任何跨单元的UPDATE/DELETE语句，也禁用全局序列号、分布式事务协调器（如Seata TC）等中心化状态组件。若需跨单元查询（如客服查多省订单），走异步消息聚合或只读视图服务，不穿透单元边界。
服务层：路由闭环 + 注册隔离
API网关按用户ID路由到对应单元，且该路由结果在一次会话内固定（避免重试跳转）。服务注册发现系统（如Nacos/ZooKeeper）按单元部署独立集群，跨单元服务不注册、不订阅。RPC框架强制开启“同单元优先”策略，即使配置了跨单元地址，也会在运行时自动忽略——不是靠配置过滤，而是编译期或启动时就裁剪掉非本单元服务元数据。
状态与缓存：命名空间硬隔离 + 生命周期绑定
Redis、本地缓存、Session存储全部按单元划分命名空间，格式统一为unit:{id}:cache:{key}，且每个单元使用独立连接池和TTL策略。关键点在于：状态代理服务（State Proxy）拦截所有外部写入，校验目标Key前缀是否匹配本单元ID；不匹配则直接拒绝，不记录日志、不触发告警——从协议层切断越界可能。
资源与运行时：cgroups权重 + 网络策略硬限
K8s中每个单元部署在专属NodePool，CPU/Memory QoS Class设为Guaranteed，并通过cgroups v2绑定动态权重（如高优单元cpu.weight=1000，低优单元=100）。网络层面启用Calico NetworkPolicy，只允许本单元Pod间通信及指定入口流量，禁止跨单元Pod IP直连。哪怕两个单元部署在同一物理机，OS内核也会在iptables和eBPF层拦截非法包。
