企业官网建设流程全解析

去年冬天排查过一个挺典型的问题：某业务线的接口在灰度环境一直返 502，运维看实例列表全是健康的，配置也来回改了三遍。折腾到晚上才发现，转发规则里域名指向的是新建的集群，可那个集群下面挂的子集群还是空的，实例全挂在旧子集群上。BFE 这套产品线、集群、子集群、实例的四层模型，看起来只是四个名词，实际上是一条从"业务域名"一路走到"某台机器某个端口"的完整寻址链，任何一环对不上，流量就落不了地。这篇就把这四个概念掰开揉碎讲清楚：它们各自负责什么、配置怎么在这四层之间继承和覆盖、请求进来之后按什么顺序匹配、以及落地时最容易在哪儿翻车。不管你是刚接手流量接入配置的新人，还是已经在维护几十个集群的老手，都能从里面找到能直接抄的配置骨架和排错顺序。

1. 为什么这四个词必须放在一起理解

1.1 扁平化配置在多业务场景下的失控现场

先说说没有层次模型会是什么样子。早期很多接入层配置就是一张大表：域名一行，后端地址一行，谁要用就往上加一行。业务只有两三个服务的时候这么干没问题，等到服务数量上到几十个、机房从一扩到三、还开始做灰度发布，这张表就彻底失控了。同一个服务的后端地址散落在十几个域名规则下面，改一次扩容要同步改十几处，漏一处就是流量打到已经下线的机器上。

更麻烦的是策略没法差异化。你希望订单服务用短超时、快速失败，商品服务用长超时、多重试，但在扁平表里这些参数只能全局配一套，或者每个域名重复写一遍。重复写就意味着不一致，不一致就意味着某天某个域名的超时是 3 秒、另一个是 30 秒，出了问题查半天。

层次模型解决的核心问题就是把"变的部分"和"不变的部分"分开。服务身份、协议、重试策略这些相对稳定的东西沉到集群层；机房、版本、灰度分组这些经常变的东西放到子集群层；IP 和端口这种最易变的放到实例层。这样扩容只需要动实例列表，切机房只需要动子集群的流量比例，改超时只在集群层改一处。

1.2 四层模型本质是一条"从业务到网卡"的寻址链

换个角度理解：这四层其实是一条逐级收窄的寻址链。产品线回答"这是哪个业务的地盘"，集群回答"要访问哪个服务"，子集群回答"这个服务的哪一批机器"，实例回答"具体是哪台机器的哪个端口"。每一层都在上一层圈定的范围内继续缩小范围，直到定位到一个可连接的 socket 地址。

这个视角很重要，因为它解释了为什么层级不能乱。如果你跳过集群直接在产品线下面挂实例，那所有服务共用一份实例列表，负载均衡就变成了瞎分；如果你在集群层配机房信息，那同一个服务想按机房调度就得建多个集群，集群数量爆炸，规则表跟着爆炸。每一层的抽象都是为了承接下一层的多样性，同时把上一层的稳定性保留下来。

我习惯把这四层画成一个倒三角：产品线在最上面，最宽、最稳定、变更最少；实例在最下面，最窄、变更最频繁。变更频率从下往上递减，这个规律记住了，后面配置该放哪一层基本不会错。

1.3 先把术语对齐：四个词各自的边界

在往下拆之前，先把四个词的定义钉死，避免后面混淆：

这张表建议贴在配置管理页面的旁边。实际工作中大量的配置错误，本质都是"把该放 A 层的东西放到了 B 层"，比如把机房信息写进集群名、把超时参数写到实例上、把灰度分组塞进域名规则里。位置放错了，后面所有基于层级的继承和覆盖都会跟着错。

提示：不同版本、不同部署形态下，产品线的落地方式可能是配置文件分目录管理，也可能是配置中心里的一个命名空间，具体形式以你手头的版本为准。但"产品线是顶层隔离单元"这个语义是一致的。

2. 产品线：最外层的隔离墙，不只是目录名

2.1 产品线承担的三种隔离，缺一不可

很多人把产品线理解成"配置文件的文件夹"，觉得就是个分类作用，这种理解会吃大亏。产品线实际承担三种隔离，任何一种缺失都会在规模化之后变成事故源。

配置隔离是最基础的：不同产品线的域名规则、集群表、实例表互不可见。A 产品线定义了一个叫order-api的集群，B 产品线也可以定义同名集群，两者完全独立。这个特性让不同团队可以各自用自己习惯的命名，不用为了避让去加一长串前缀。

权限隔离是工程上更值钱的部分：产品线是天然的权限边界。接入层的配置权限通常要收得很紧，因为一条错误规则可能让整个业务不可用。有了产品线，就可以做到"谁的业务谁管"，A 团队只能改 A 产品线的规则，改不了 B 的。没有这层隔离，要么所有人都有全量权限（风险极高），要么所有变更都要走一个中心化的审批（效率极低）。

故障隔离是最容易被忽视的：某个产品线配了一条死循环的重写规则，或者把健康检查间隔配成了 1 秒导致后端被打爆，这些故障应该被限制在这个产品线内部。如果所有业务共用一套配置表，一条错误规则的影响面就是全站。

2.2 什么该放产品线级，什么坚决不能放

产品线级的配置项要慎之又慎，因为它的影响面是整个产品线。适合放在这一层的东西通常只有两类：一类是全局开关，比如这个产品线是否启用某个实验特性、是否开启访问日志；另一类是兜底策略，比如所有集群默认的健康检查间隔、默认的连接超时。

不适合放在产品线级的东西也很有规律：任何需要按服务差异化的参数都不该放这里。超时、重试次数、负载均衡算法这些，不同服务的合理值差异巨大，订单服务可能需要 500 毫秒超时快速失败，报表导出服务可能需要 60 秒。放在产品线级就意味着所有服务被迫用同一个值，最后一定有人偷偷在集群层覆盖，覆盖着覆盖着配置就乱了。

还有一个常见误区是把环境塞进产品线。有人图省事，一个产品线里同时放生产和测试的域名，靠域名后缀区分。这么做的直接后果是灰度发布没法做——你想让测试流量打到新版本，结果规则一改，生产流量也跟着走新集群。正确做法是生产和测试分成两个产品线，或者至少是两个完全独立的规则集，物理上隔开。

2.3 多产品线共存时的命名与资源约定

产品线一多，命名约定就成了刚需。我的建议是产品线名采用业务名-环境的形式，比如trade-prod、trade-staging，不要用prod1、prod2这种没有语义的名字。原因很实际：排查问题时你看日志里打印的产品线标识，得一眼能认出来是哪个业务。

资源层面还有几个约定值得提前定下来。监听端口通常是多个产品线共享的，靠域名区分，所以要确保不同产品线的域名没有重叠，尤其要小心通配域名。比如 A 产品线配了*.example.com，B 产品线配了api.example.com，这两个就会打架，具体谁生效取决于匹配优先级，而这类问题在配置评审时极难发现。

另外建议给每个产品线单独配一份监控看板。产品线级的 QPS、错误率、延迟分位数这几个指标，是判断"问题出在接入层还是业务层"的第一手依据。如果某个产品线的整体错误率突增，而单个集群都正常，那多半是规则层出了问题；如果只有某个集群异常，那就往下钻到子集群和实例。

3. 集群与子集群：把服务身份和部署形态拆开

3.1 集群是服务身份，绑定一切相对稳定的策略

集群这层的定位非常明确：一个集群就是一个后端服务的逻辑身份。它绑定的是这个服务的"性格"——用什么协议跟后端通信、连接超时和读超时设多少、失败重试几次、健康检查怎么探、负载均衡用轮询还是最少连接。

这些参数有个共同特点：它们描述的是"这个服务应该怎么被访问"，而不是"这个服务现在部署在哪"。订单服务无论是部署在北京机房还是上海机房，它的超时策略都应该是同一个，所以这些参数属于集群，不属于子集群。

集群的粒度怎么定？我的经验是按服务边界定，不按部署单元定。一个服务一个集群。不要因为想按机房分流就建三个集群，那是子集群的活；也不要为了省事把三个服务塞进一个集群，那样超时和健康检查就没法差异化配置了。判断标准很简单：如果两个东西的协议、超时、重试策略可以完全一样，那可以合；只要有一项需要不同，就必须拆。

集群名一旦上线就要当成不可变标识来对待。规则表、监控、日志、告警全都在引用这个名字，改一次名要同步改一圈地方，漏一个就是流量黑洞。真需要改名，正确做法是新建集群、切流量、观察、再下线旧集群，而不是原地改。

3.2 子集群是部署形态，承载机房、版本和灰度

子集群解决的是"同一个服务的不同部署批次"这个问题。典型场景有三类：

多机房调度：服务在北京和上海各有一批机器，希望北方用户优先走北京机房。这时建两个子集群，配上基于来源的调度策略，接入层根据客户端 IP 决定往哪个子集群分流。这是子集群最经典的用法，也是它存在的原始动机。

灰度发布：新版本先上两台机器，希望只放 5% 的流量过去。建一个service-canary子集群挂这两台机器，把权重调到 5%，观察一段时间再逐步放大。这个流程比直接改实例权重清晰得多，因为灰度结束后整个子集群下线就行，不用一个个去恢复权重。

版本或规格隔离：有些服务会同时跑两套实现，比如老版本和新版本并行一段时间，或者 GPU 机器和 CPU 机器混部。用子集群隔开，调度策略上就能精细控制。

子集群这层还可以覆盖集群的部分参数。比如某个机房的网络延迟天然高一些，可以在这个子集群上把超时调大；某个灰度子集群想跳过重试直接暴露问题，也可以单独关掉。这个覆盖能力很实用，但要克制——覆盖项越多，配置的可读性越差，出问题时越难判断实际生效的是哪个值。

3.3 拆子集群的时机判断：什么时候是必要的，什么时候是过度设计

这是我见过最多余和最缺失并存的地方。有的团队一个机房、没有灰度需求，硬是拆出三个子集群，运维每天要维护三份实例列表，扩容时容易漏；有的团队已经在做多机房容灾了，还在用一个子集群挂所有机房的机器，机房挂了流量还在往上打。

判断标准可以归纳成三条，满足任意一条就该拆：

• 需要按来源或比例分流：多机房、灰度、A/B 实验，这些都需要一个可以独立调权重的调度单元。
• 需要差异化配置：不同批次的机器需要不同的超时、健康检查参数或协议版本。
• 需要独立下线：某批机器要整体摘除，且不希望逐个操作实例。

反过来，如果只是机器数量多、需要扩缩容，那不该拆子集群，直接改实例列表就行。子集群不是"实例分组"的意思，它是"调度单元"，没有调度需求就不需要它。

还有一个折中方案值得提：即使当前只有一个机房，也可以先建一个和集群同名的子集群，把实例挂在下面。这样做的好处是模型完整，将来加第二个机房时直接在旁边加一个子集群就行，不用做结构迁移。成本几乎为零，收益是未来的平滑演进。我个人倾向于这种"结构先行"的做法。

4. 实例：模型末端，也是最容易出问题的一层

4.1 实例标识与权重语义，别把相对权重当百分比

实例就是最终的IP:Port，加上一个权重值。这里有两个细节经常被误解。

第一个是实例标识的唯一性。同一个子集群内，IP:Port必须唯一，这是硬约束。但不同子集群之间可以重复，因为它们是不同的调度单元。有些实现还会给实例加一个业务侧的标识（比如容器 ID 或主机名），这个标识主要用于和服务发现对接，做实例的增删比对，不要拿它当路由依据。

第二个是权重的语义。权重是相对值，不是百分比。一个子集群里两个实例权重分别是 10 和 30，实际分到的流量是 25% 和 75%，不是 10% 和 30%。这个区别在扩容时特别重要：新加一台机器，权重给多少？如果原来两台都是 100，新机器给 100 就是均分；如果新机器还在预热，给 10 就是先接少量流量。很多人以为权重是百分比，配了 50、30、20 三台，结果发现加起来不是 100 就慌了，其实完全没问题。

权重的另一个坑是只在同一子集群内生效。跨子集群的流量分配靠的是子集群级的调度策略，不是实例权重。有人想通过给某个机房的实例加权重来让流量偏向那个机房，这是无效的，得去调子集群的调度比例。

4.2 健康检查状态和"看起来健康"之间的差距

实例列表里通常会显示一个健康状态，绿色代表健康，红色代表异常。但这个状态只能说明"健康检查通过了"，不能说明"业务真的可用"。中间的差距有几个来源：

健康检查通常只探一个固定的路径和端口，如果业务的核心依赖挂了但探活接口还能返回 200，实例就会一直显示健康，流量持续打过去，用户持续看到错误。这种情况在依赖数据库或下游服务的场景里非常常见。

主动健康检查有间隔，从实例真正故障到被摘除，中间有一个时间窗，这个窗口内流量还会打过去。间隔配得越长，窗口越大。反过来，间隔配得太短会给后端带来额外的探活压力，尤其是实例数量多的时候。这个参数要在"发现速度"和"探活开销"之间找平衡，我的经验是 3 到 5 秒比较常见，核心服务可以更短。

被动健康检查（根据真实请求的失败情况判断）能弥补主动检查的盲区，但它依赖失败样本。如果某个实例分到的流量本来就少，可能要很久才能积累够失败次数触发摘除。所以主动和被动通常要配合使用，单靠一种都有漏洞。

4.3 动态注册场景下的一致性难题

当实例列表来自服务发现而不是手写配置时，会遇到几个新的问题。

推拉时序问题：服务发现推送了实例变更，但接入层的配置还没加载完，这中间有个时间差。如果新实例刚注册就来了流量，而它其实还没预热好，就会失败。常见的缓解办法是注册后延迟一段时间再加入调度，或者先给一个很低的权重慢慢爬坡。

陈旧实例残留：实例下线了但服务发现没及时推送，或者推送了但接入层加载失败，这个实例就会变成"幽灵"，流量打过去直接连接超时。这类问题的排查特征是：错误集中在少数几个 IP 上，且这些 IP 在服务发现里已经查不到了。所以实例层的排错第一步永远是核对实际在调度的实例列表和服务发现里的列表是否一致。

配置与注册的冲突：有些部署形态下，实例既可以从配置文件静态加载，也可以从服务发现动态注册。两者同时存在时以谁为准，必须在团队内明确约定，否则会出现"我在配置文件里删了这台机器，怎么还在接流量"的困惑。

5. 四层如何接力：匹配顺序与参数覆盖的完整链路

5.1 一个请求从进来到落地的完整寻址过程

把四层串起来看，一个请求的处理过程大致是这样的：

第一步，请求到达监听端口，接入层根据请求的 Host 头（或 SNI、或监听端口本身）去产品线的规则表里匹配域名。匹配通常遵循精确优先于通配、通配中更具体的优先于更宽泛的这个原则。比如同时存在api.example.com和*.example.com，请求api.example.com会命中前者。

第二步，域名规则指向一个集群。如果规则里还配了路径前缀，还要再做一次路径匹配，不同路径可以指向不同集群，这是做 API 网关式路由的基础。

第三步，拿到集群之后，要看这个集群有没有配子集群级的调度策略。如果配了基于来源的调度，就根据客户端 IP 或请求特征选一个子集群；如果只有默认子集群，就直接用它。

第四步，在选中的子集群内部，按照配置的负载均衡算法和实例权重，挑一个实例发起连接。

这条链路里每一步都可能成为故障点，所以排错时要从两头往中间对：一头是请求实际命中了什么，另一头是配置期望命中什么。

5.2 参数覆盖规则：就近优先，但有例外

配置的继承关系总体遵循"就近覆盖"：实例级覆盖子集群级，子集群级覆盖集群级，集群级覆盖产品线级。但有几个例外必须记住。

不是所有参数都能在低层覆盖。协议类型这种决定连接方式的参数，通常只能在集群层定义，子集群和实例不能改。道理很简单，一个集群里混着 HTTP 和 HTTPS 的后端，负载均衡和健康检查都没法统一处理。

覆盖不是合并。如果集群层配了一个复杂的健康检查结构（路径、间隔、阈值、期望状态码），子集群层只覆盖了间隔，那其余字段是继承还是重置？不同实现的处理不一样，有的做深度合并，有的整体替换。这个必须查清楚你手头版本的文档，理解错了会出现"我只改了间隔，怎么探活路径也变了"的情况。

空值不等于未配置。有些配置项设成 0 或空字符串是有明确语义的（比如重试次数设 0 表示不重试），和"没配所以继承上层"是两回事。配置时要想清楚是要关掉这个特性，还是只是没填。

5.3 配置下发与实际生效之间的时间差

配置改完不等于流量立刻按新规则走，这中间有几层延迟需要理解。

第一层是配置加载。接入层加载配置通常是异步的，加载完成到新配置对外生效还有一个短暂的切换窗口。批量变更（比如一次加几百个实例）时这个窗口会更明显。

第二层是长连接复用。已经建立的连接不会因为配置变更而断开，它们会继续打到原来的后端，直到连接自然结束或被主动关闭。这就是为什么"我把某个实例权重调到 0 了，怎么监控上还有流量"——那些流量来自旧连接。要立刻生效，需要在变更后主动清理连接池，但这会引起一批请求失败，要权衡。

第三层是客户端缓存。如果变更涉及 DNS 或服务地址，客户端侧可能还有缓存，实际生效时间会更长。

理解了这三层，"配置生效了但表现没变"这类问题就有一半能自己解释清楚了。剩下的一半，通常是真的没生效，需要用后面的排查链路去定位。

6. 排查实录：五类典型故障的定位过程

6.1 子集群建好了但流量始终为零

现象很直白：新建的子集群在监控上 QPS 一直是 0，实例都是健康的。

排查顺序我一般这么走。先确认规则层到底有没有把这个子集群纳入调度——很多调度策略是"按比例分配"，新建的子集群默认权重是 0，需要在策略里显式给一个非零比例。这一步最容易被漏掉，因为子集群建完看起来一切正常，实例也加进去了，就是没流量。

如果比例配了还是零，接着确认调度条件。基于来源的调度策略依赖客户端 IP 的归属判断，如果测试机的 IP 不在任何已配置的地址段里，请求会落到默认子集群。这种时候换一个符合条件来源的客户端测一下就能验证。

最后确认实例列表。子集群的实例列表是独立的，从别的子集群复制配置时容易漏掉实例，或者实例加进去了但端口写错了，健康检查一直失败所以不参与调度。

6.2 域名请求落到了错误的集群

这类问题的特征是：请求能通，但返回的内容不是预期的服务，或者日志里记录的集群名不对。

第一步查匹配优先级。有没有存在一个更宽泛的通配规则把这个域名也覆盖了？通配规则和精确规则的优先级在不同实现里可能不同，一定要以实际行为为准，别凭印象。

第二步查路径规则。如果同一个域名下配了多条路径规则，请求的路径有没有可能命中了另一条？路径前缀匹配是"最长优先"还是"配置顺序优先"，这个也要确认。

第三步查默认集群。有些实现会配一个兜底集群，所有没匹配上的请求都往那儿送。如果规则本身写错了（比如域名少写一个字符），请求就会静默落到兜底集群，表现就是"能通但不是想要的服务"。这种问题特别隐蔽，建议给兜底集群配上明显的标识，或者干脆不配兜底，让未匹配的请求直接报错，问题暴露得更快。

6.3 权重调整了但流量分布没变化

先排除 5.3 提到的长连接因素。如果调整后过了足够长的时间（超过最长连接存活时间）还是没变化，那就是别的原因。

检查权重是不是配在了错误的层。前面说过，跨子集群的分布靠调度策略，不是实例权重。如果目标是让流量偏向某个机房，改实例权重是无效的。

检查负载均衡算法是不是权重无关的。有些算法（比如一致性哈希）的分流结果由哈希环决定，权重只影响虚拟节点的数量，调整小幅度权重可能看不出明显变化。这种情况要改的是算法或者虚拟节点数，不是权重值。

还有一种情况是实例数量太少导致统计失真。两个实例、权重 1:1，短时间窗口内观察到 60:40 是完全正常的波动，别急着调参。

6.4 健康检查把正常实例摘掉了

现象是实例反复在健康和异常之间跳，或者一批实例同时被摘除导致容量骤降。

先看探活配置。探活路径是不是需要鉴权？如果探活请求被业务的鉴权中间件拦了，返回 401，实例就会被判异常。这类问题在接入新服务时高频出现，解决办法是给探活路径加白名单。

再看超时设置。探活超时如果比业务的实际响应时间还短，业务稍微抖一下实例就被摘了。探活超时应该明显大于正常响应时间，但小于业务可接受的最大延迟。

还要看摘除阈值。连续失败几次才摘除、连续成功几次才恢复，这两个参数决定了系统的"敏感度"。阈值太低会导致频繁抖动，太高会导致故障实例长时间不被摘除。多个实例同时被摘，还要怀疑是不是探活源本身的网络出了问题，而不是所有后端一起挂了。

6.5 集群改名引发的连锁失效

这是最伤的一类，因为影响面大且报错信息通常很含糊。

典型的连锁反应是这样的：集群改了名，但域名规则里的引用没改，请求匹配不到集群，直接报错；或者规则改了但监控和告警还挂着旧名字，出问题时没有任何告警；或者服务发现那边推的还是旧集群名，实例注册不进来，新集群下面空空如也。

预防的办法只有一个：把集群名当主键对待，不做原地修改。需要改名时走"新建—切流—观察—下线"的流程。如果确实要改，改完之后按这个顺序验证：规则表里搜旧名字确认无残留、实例列表确认新集群下有实例、监控看板确认指标在采集、告警规则确认已更新。

排查时我习惯从实例往上反查：先在实例列表里找到实际在接流量的 IP，反查它属于哪个子集群，再反查这个子集群属于哪个集群，最后反查哪个域名规则指向这个集群。这个逆向链路能快速定位到是哪一层断了，比从上往下猜要快得多。

7. 从零落地一套四层模型的操作顺序

7.1 先画拓扑再写配置，顺序错了后面全乱

我的习惯是动手配之前先在纸上（或者画图工具里）画三张图。

第一张是服务清单图：有哪些后端服务，每个服务的协议是什么、超时大概多少、需不需要重试。这张图直接决定要建几个集群，以及每个集群的关键参数。

第二张是部署分布图：每个服务部署在几个机房、有没有灰度批次、有没有异构机器。这张图决定每个集群下面要建几个子集群。

第三张是流量入口图：有哪些域名、每个域名对应哪个服务、有没有按路径分流的需求。这张图决定规则表怎么写。

三张图画完，配置结构基本就定了，剩下的只是往模板里填。跳过这一步直接开配，最常见的后果是集群粒度和子集群粒度反复调整，每调一次就要改一圈引用，很容易出错。

7.2 一份可以直接改的最小配置骨架

下面给一份结构示意，字段名以你实际使用的版本为准，重点是看四层之间的关系：

{ "product": "trade-prod", "host_rules": [ { "hostname": "api.example.com", "path": "/order/", "cluster": "order-api" }, { "hostname": "api.example.com", "path": "/item/", "cluster": "item-api" } ], "clusters": { "order-api": { "protocol": "http", "timeout_connect_ms": 200, "timeout_read_ms": 1000, "retry_max": 2, "health_check": { "path": "/healthz", "interval_s": 5, "timeout_ms": 500, "rise": 2, "fall": 3 } } }, "sub_clusters": { "order-api-bj": { "cluster": "order-api", "scheduler": { "type": "weighted", "weight": 80 } }, "order-api-sh": { "cluster": "order-api", "scheduler": { "type": "weighted", "weight": 20 } } }, "instances": [ { "sub_cluster": "order-api-bj", "addr": "10.0.0.11:8080", "weight": 100 }, { "sub_cluster": "order-api-bj", "addr": "10.0.0.12:8080", "weight": 100 }, { "sub_cluster": "order-api-sh", "addr": "10.0.1.11:8080", "weight": 100 } ] }

这份骨架里有几个地方值得注意。域名规则用了路径前缀来区分两个服务，这比起两个域名更省证书也更贴近实际。子集群的调度权重 80/20 是机房分流比例，和实例权重是两回事，别混。实例权重这里都给 100，是均分的意思，实际扩容预热时可以给低值。

7.3 三层验证法：配置加载、规则命中、后端可达

配置写完不能只看"保存成功"，要分三层验证。

第一层验证配置加载：确认配置真的被接入层加载了，没有语法错误、没有字段被忽略。有些实现会在加载失败时保留旧配置继续服务，表面上一切正常，实际上你的新配置根本没生效。所以要看加载日志，确认版本号和变更时间对得上。

第二层验证规则命中：用真实请求打过去，看日志里记录的命中集群是不是你期望的。这一步能抓出匹配优先级、通配覆盖、兜底集群这类问题。建议至少测三种请求：精确匹配的、通配匹配的、故意不匹配的，确认三种情况下的行为都符合预期。

第三层验证后端可达：确认流量到了集群之后能正常连到实例。看实例的连接数、健康状态、错误率，必要时在实例侧抓包确认请求真的到了。这一层最容易被跳过，因为前面两层都过了就觉得没问题了，结果上线才发现实例的端口写错。

7.4 演进节奏：什么时候该从单子集群走向多子集群

最后说说演进。我建议的节奏是：起步阶段一个集群配一个默认子集群，实例直接挂上去；出现第一个真实的调度需求（第二个机房上线、第一次灰度发布）时，再拆第二个子集群；子集群数量超过三个之后，就要开始考虑调度策略的复杂度了。

子集群数量增长带来的主要成本是配置同步。每个子集群都要维护一份实例列表，扩容时容易漏掉某个子集群，导致容量不均。这时候要么把实例管理交给服务发现自动同步，要么至少做一个配置检查脚本，定期比对各子集群的实例数量差异，差异过大就告警。

还有一点经验：不要为了"结构好看"提前拆分子集群。我见过一个服务只有一个机房，硬是按功能拆了三个子集群，结果每次扩容要改三处，还经常漏。子集群是调度单元，没有调度需求的时候，它就是纯粹的维护负担。结构完整性的价值在于未来演进平滑，但前提是真的会有那个未来。