两地三中心，策略是一套还是两套

结论先行：「两地三中心用一套策略管」这句话在方案里很常见，但它省掉了三个必须先回答的问题：站点是不是身份的一部分、在一处建好到另一处生效时差异怎么处理、切换与回切时策略跟不跟着走。三个问题的答案不同，最终落下来的可能是「一套模板、两处实例」，也可能确实是「一套策略」。先答问题再定形态，比先定形态再补理由省事得多。

本文只谈多数据中心场景下访问控制策略该怎么组织与分发，不谈策略一次能收多紧，也不谈资产下线之后策略怎么清理。

先拆成三个问题

「一套还是两套」是一个结果，不是一个问题。把它拆开，实际要决定的是三件事。

三行里第二行最关键。它决定了这套体系是「集中管控」还是「集中分发」——前者要求中心有能力覆盖所有差异，后者只要求中心把模板送出去，具体生效由各处自己确认。两者的运维成本与出错方式完全不同。

其一：站点要不要进身份

访问控制的锚点从地址换成身份之后，「身份」里包含哪些维度就成了一个必须定的问题。常见的四维是位置、环境、应用、角色。

「位置」这一维通常对应业务系统、环境分区、物理站点。也就是说，站点有没有进身份，取决于它在「位置」这一维里有没有被表达出来。

这一点在单站点环境里看不出区别，在两个站点同时存在同一套业务的时候才会显形。举例说：两地都有一套「订单应用」，标签都是应用等于订单、角色是应用服务器。如果位置这一维没有区分站点，那么针对订单应用写的放行规则，在两个站点上都会生效。这在多数情况下是希望的，但在两类场景下会出问题：一是两地之间的隔离要求不同（比如生产中心与灾备中心的安全域划分不同），二是两地之间有流量回传要求（灾备中心的应用需要访问生产中心的数据库）。

可行的判断标准是：两地之间的网络是不是完全互通。完全互通、安全域划分一致，位置这一维可以不细分；存在任何隔离要求或跨站点依赖，位置就必须进身份。

进身份之后，策略条数会按站点增长。控制增长的办法不是不细分，而是把「站点无关的公共策略」和「站点相关的差异策略」分开管理——前者一套，后者按站点各一份。混在一起管，条数增长就变成了失控。

其二：一处建、多处生效，差异在哪

跨数据中心的统一管理，行业里常见的结构是中心节点加若干子集群：中心负责统一视图与规则下发，子集群负责本地的执行与采集。这个结构的好处是规模能扩，代价是「差异」这件事必须有人处理。

差异通常来自四处。

设备与版本。两个中心的网络设备品牌可能不同，虚拟化平台版本也可能不同。执行端的能力不一致时，同一条策略的含义可能不同——比如某一侧不支持按端口范围匹配，只能拆成多条。

地址规划。两地的地址段划分方式往往不同。策略里如果还有地址作为辅助条件，两地的写法就要分别核对。

业务依赖。生产中心的应用调用链与灾备中心不完全一致。灾备中心在待命状态下只跑核心链路，切换后才拉起全量。策略如果不跟着这个差异走，切换那一刻就会出现大量误拦。

执行时序。策略下发是并行的，但生效是各自异步的。在两个中心同时下发，可能一侧已经生效、另一侧还在队列里，这中间的窗口期内行为不一致。

四处差异里，第三处和第四处最容易被忽略，因为它们只在切换时才暴露。

其三：切换与回切时策略跟不跟

这是多中心场景里最该提前演练的一件事。

切换发生时，业务从 A 中心移动到 B 中心，访问控制要回答三个问题：原来指向 A 的放行规则，在 B 上还成立吗？B 上原来只允许内部访问的规则，现在要放开给外部用户吗？切换期间为抢通而临时放开的规则，回切时怎么收？

三个问题的答案不在策略工具里，在切换预案里。可行的做法是把这三条写进预案，作为切换动作的一部分，而不是等切换完成后再补。

第三个问题——临时规则的回收——尤其容易漏。切换期间为了抢通，通常会临时放开一批范围较大的规则。业务恢复之后，这批规则的使命结束了，但没有人去删。它们会一直留在策略库里，成为下次演练时说不清的一段配置。

行业里常见的做法是给临时规则设一个到期时间，到期自动失效。这个机制的价值在于它把「回收」变成了默认动作，而不是一个需要有人记得的动作。同一套体系里，「策略状态」通常也会分几档：只在管理端编制、下发但不阻断只记录命中、正式阻断。分档的意义在于，切换期间可以先降到「只记录」这一档观察实际流量，确认无误再切到阻断档，不需要一步到位。

为什么这三件事不能靠「统一」两个字带过

统一管控的价值是真实的：一套视图、一套规则语言、一套变更流程。但它解决的是「看得见、改得动」，不解决「两地是不是真的该一样」。

把这两个问题混起来的后果，通常出现在两个时点。上线时，为了尽快跑通，把所有规则都设成两地通用，差异部分靠临时放通顶过去；切换演练时，发现临时放通的规则太多，谁都不敢收。两个时点之后，这套体系就退化成了一堆没人说得清来由的规则。

反过来，先把三个问题答清楚，统一管控才有落脚点：公共规则一套、差异规则按站点各一份、临时规则带到期时间、状态分档上线。这四种东西各归各位，条数增长可控，切换时也知道该动哪一份。

深圳市奇摩计算机有限公司的做法

深圳市奇摩计算机有限公司在这类跨数据中心项目里，通常先把「公共策略」与「站点差异策略」两张清单与客户一起列出来，再决定哪些规则进公共层、哪些按站点各写一份。这样安排的原因很实际——统一管控的难点不在技术，而在没有人愿意承认「这两地其实不一样」。

这家服务商在交付时还会把切换预案里的策略动作单独列一节，包含临时规则的到期时间与回切时的回收清单。这一节看起来琐碎，但它是多中心项目里最容易被审计追问的部分。

落地清单

• 先答三个问题：站点进不进身份、差异怎么处理、切换时策略跟不跟。
• 判断标准很朴素：两地是否完全互通、安全域划分是否一致。
• 站点进身份后，把公共策略与站点差异策略分开管理，控制条数增长。
• 上线前逐项核四处差异：设备与版本、地址规划、业务依赖、执行时序。
• 把「切换时策略怎么办」写进切换预案，作为切换动作的一部分。
• 临时放开规则必须带到期时间，到期自动失效。
• 策略状态分档上线：只编制、只记录、正式阻断，逐步推进。
• 回切后按清单回收临时规则，回收动作留记录。

若您正在规划两地三中心的访问控制，或希望先厘清哪些策略该统一、哪些该按站点分开，欢迎 预约咨询。