2026-06-27

今日主题

• Spinnaker 部署模型层级
• Frigga 命名解析机制

新增认知

Spinnaker 部署模型层级

• Cluster 存在的理由——蓝绿部署：Spinnaker 的三层模型 Application → Cluster → Server Group 中，
  Cluster 不是冗余层级。它的核心作用是提供"同一服务的不同版本"的归属关系：每次部署产生新 Server Group（如 v001、v002），
  Cluster 把它们归为一组，使得蓝绿部署时 Spinnaker 能知道哪些 Server Group 之间应该切换流量、哪些旧版本应该销毁。
  没有 Cluster 这一层，就无法区分"同一服务的不同版本"和"完全不同的服务"。

• 环境用 stack 区分，不用 Application：
  Spinnaker 官方明确建议不要把 test/staging/prod 拆成不同 Application。
  原因是 Pipeline 天然跨环境（Bake → 部署 test → 部署 staging → 审批 → 部署 prod），
  不同环境在同一个 Application 内才能串联。
  环境区分通过 Frigga 命名中的 stack 字段实现（如 my-service-staging-v001 vs my-service-prod-v001），
  不同 stack 值自动形成不同 Cluster。

• Region 是云平台原生维度，不编码在命名中：Server Group 在云平台上的实现（如 AWS ASG）天然绑定 Region，
  Spinnaker 不需要在名字里编码 Region。Server Group 的真正唯一标识是三元组 (name, account, region)，
  同一个名字可以在不同 account/region 下独立存在。Cluster 是"全球视图"——
  它把不同 Region 下同 cluster 前缀的 Server Group 聚合在一起。

• Zone 是 Server Group 内部配置，不是独立层级：在 AWS 中一个 ASG 本身就跨多个 AZ，
  只需在 Deploy Stage 配置 AZ 列表即可，不需要为每个 AZ 创建独立 Server Group。
  Frigga 的 z0 标签（如 z0useast1a）是 Netflix 历史遗留，用于极少数需要按 AZ 独立 ASG 的故障隔离场景，现代实践中几乎不用。

Frigga 命名解析机制

• 脉络——从 Asgard 到 Spinnaker 的命名继承：Frigga 是 Netflix 开源的 Java 库，
  唯一职责是解析和生成 AWS 资源命名。它起源于 Netflix 早期云管平台 Asgard（Spinnaker 的前身），
  Spinnaker 继承了这套命名规范。核心思想是：把元信息（应用归属、环境、版本）编码在资源名字里，通过字符串解析提取，而不是依赖数据库或配置中心。

• 命名格式与三层解析：完整格式为 app-stack-detail-vNNN，还可带可选后缀标签（如 c0国家、d0阶段、z0可用区）。
  Frigga 的 Names.java 解析分两步：先用 PUSH_PATTERN 剥离末尾版本号得到 cluster（group 去掉 -vNNN），
  再用 NAME_PATTERN 从 cluster 中拆出 app（第一个 - 之前）、stack（第一个 - 和第二个 - 之间）、detail（第二个 - 之后）。
  group 是原始全名，cluster 是去版本号后的前缀，所有 cluster 相同的 Server Group 归为同一个 Cluster。

• 字符集约束实现确定性解析：Frigga 的健壮性不靠严格格式校验，而靠字符集差异消除歧义。
  app 和 stack 的合法字符集是 [a-zA-Z0-9._]（不含连字符），detail 的合法字符集额外包含 -。这意味着从左到右用 - 切分时，
  app 遇到第一个 - 就停止，stack 遇到第二个 - 就停止，detail 可以包含连字符吃掉剩余部分。
  这种"约束即解析"的思路让格式在解析时不可能产生歧义，不需要事后校验格式是否正确。