基础设施与交付设计¶

设计一个面向 1,000 个服务的企业级 CI/CD 与制品晋级平台¶

需求澄清

• 用户是约 300 个研发团队、1,000 个服务，语言和部署目标多样；平台提供黄金路径但允许受控扩展，不要求把所有构建系统重写。
• 峰值每天 20,000 次 CI¹、2,000 次环境部署，其中生产约 300 次；公共/内部仓库并存，fork PR²视为不可信。要求从 commit 到运行实例可追溯、构建一次多环境晋级、生产支持滚动/金丝雀/蓝绿。
• 控制面可用性目标 99.95%；已有应用运行不依赖控制面持续在线。发布控制面 RTO 与元数据 RPO³ 分别为 30 分钟和 5 分钟；制品要求跨区域保存且最后两个已知良好版本始终可用。
• 合规要求最小权限、双人高风险批准、审计保留、短期云身份、秘密不进入构建；非功能目标包含公平排队、成本归集和平台升级不造成全公司同时失败。

估算

日均20,000次 CI 若高峰集中在4小时，约1.4次/秒启动；按5倍突发设计7 jobs/s。平均 job 10分钟、峰值并发约4,200个执行槽（7×600），通过语言/规格池和租户配额分配。假设每次构建上传300MiB，则未去重上传量约5.72TiB/日；若只有25%为新 blob，净新增约1.43TiB/日。若每份新数据再复制到一个灾备区域，复制传输量约1.43TiB/日、双副本物理新增约2.86TiB/日，即约86TiB/月，尚未计元数据、保留余量和临时层。容量表应分别列逻辑上传、净新增、跨区流量、物理副本与保留周期，不能用一个“原始增量”混写。部署事件2,000/日不大，但生产事件价值高，需要强审计而非只追求吞吐。

相关技术说明

平台分为控制面与执行/数据面⁴。控制面含 SCM⁵ webhook入口、事件去重、工作流编译器、队列/调度器、策略引擎、运行元数据数据库和发布协调器；执行面是按信任域隔离的一次性 runner⁶池、受信 builder、制品/签名仓库和各集群内 pull-based CD agent。工作流模板按版本解析成 DAG⁷，每个节点有不可变输入、资源预算、超时、重试类别与输出摘要。

制品以 digest⁸为主键，build 产生 SBOM⁹ 和 provenance¹⁰，由受信工作负载身份签名。环境晋级记录引用同一digest、配置版本和证据；准入端验证发行者、仓库、分支和策略。CD发布使用generation/CAS保证同环境旧任务不能覆盖新任务。Schema迁移作为独立有状态workflow，强制expand/contract；长操作返回operation ID，可取消但对外部结果未知时先查询对账。

架构

SCM/Webhook -> Event Gateway -> Durable Queue -> Workflow Compiler/Policy
                                      |                 |
                                      v                 v
                              Fair Scheduler -> Ephemeral Runner Pools
                                                   |
                                     Trusted Builder + Test Sandboxes
                                                   |
                           Artifact Registry (digest) + SBOM/Provenance
                                                   |
                       Promotion Ledger -> Release Orchestrator
                                                   |
                         Regional Pull Agents -> Workload Clusters

Metadata DB/Outbox、Audit Store、OIDC Broker、Secrets Provider 与上述控制面相连。

调度器以组织/仓库做加权公平队列，限制单租户并发；job lease过期可重新领取，但步骤输出用run ID和幂等键去重。元数据数据库保存workflow状态，事务outbox向队列发布，避免“状态已写、事件丢失”。runner 池至少分 public-PR、internal-CI、trusted-build、production-deploy 四个信任域；生产部署最好不在通用runner执行，而由区域agent拉取经过批准的期望状态。

数据与流量路径

1. webhook带delivery ID进入入口，验签、去重后写事件与outbox；工作流编译器固定模板SHA和依赖，产出DAG。
2. scheduler发短租约给一次性runner。PR池无秘密、仅允许读取公开依赖缓存；受信builder通过OIDC取15分钟身份，固定依赖与基础digest构建。
3. builder上传blob、manifest、SBOM和provenance，签名后写候选记录。测试结果绑定“输入digest+测试镜像+数据集版本”，防止重跑结果错配。
4. promotion ledger在策略满足后写环境期望；区域agent拉取，先验证签名/复制可用，再5%→25%→100%部署。每波次写指标判定、批准人与实际实例digest。
5. 回滚是新generation指向上一已验证digest；若数据库阶段不兼容，状态机阻止自动回滚并执行预先批准的兼容/补偿步骤。

高可用与灾备

webhook入口、队列、调度器和API跨三个可用区；数据库主从/同步多AZ并持续备份，按5分钟RPO做跨区日志复制。区域agent缓存最近期望状态，控制面宕机时不改变现有工作负载并可在本区执行预授权回滚。注册表跨区域复制digest和签名，发布前检查复制水位；每季度从备份恢复元数据并随机抽取制品验证摘要。

跨区域控制面切换用明确leader/写区域，避免双主发布；DR时先只读恢复审计和release ledger，再开放新发布。队列消息至少一次投递，所有消费者按event/run/step ID幂等。容量降级顺序是停止夜间/PR低优先级、保留安全修复和生产回滚，而不是让所有租户公平失败。

安全

OIDC信任同时约束issuer、audience、subject、repo、受保护branch/environment和workflow引用；云角色细分到环境/资源，session短期。第三方action固定commit并受允许列表管理；构建默认无出站，仅经依赖代理。runner用临时VM/强沙箱、任务后销毁磁盘，无宿主socket；缓存按信任域内容寻址。审计仓库WORM/受控保留，记录主体、委托链、before/after、digest和break-glass理由。

可观测性

平台RED/USE之外，核心SLO是 webhook接受延迟、排队等待、job成功/基础设施失败、制品复制水位、部署达到稳定状态时间和审计完整率。按租户看队列年龄与配额，按runner池看启动/故障/成本；把代码失败与平台失败分类，避免错误归责。发布观测比较候选和基线的错误、P99、饱和及业务KPI，无数据即暂停。每个run贯穿trace ID，但日志脱敏token和构建秘密。

发布与演进

先接入只读CI与非生产部署，平台只建议不阻断；选低风险团队验证模板和公平调度。第二阶段启用构建一次/摘要晋级和签名，旧系统保留回退；第三阶段启用生产金丝雀及策略阻断。平台自身以单租户→5%组织→全量升级，模板版本显式固定，不能中心修改瞬间影响全部仓库。break-glass演练、runner逃逸红队、registry/数据库恢复和控制面断网每季度进行。

实践经验

复合落地中，最容易失败的不是队列吞吐，而是把统一模板做成不可升级的巨型脚本。可将少量强制契约（制品摘要、身份、审计、超时）固定，语言构建通过版本化组件扩展。曾见的典型止血是当runner供应不足时暂停低优先级PR而保留回滚，不盲目扩共享持久runner；成本上接受一次性runner冷启动，换取信任隔离，并用干净预热池优化。

权衡

• pull agent降低中心到集群凭证暴露和网络依赖，但增加agent版本治理与最终一致延迟。
• 单写区域简化release顺序和审计，跨区故障切换较慢；相比多主，更符合“发布可暂停、运行不可停”的目标。
• 强制digest和证明增加初次接入成本，却是所测即所发与事件响应的基础。
• 全量金丝雀统计平台复杂；按风险允许低风险服务较短波次，高风险服务保持代表性分层样本。

设计一个三地域高可用 API 入口与服务间流量平台¶

需求澄清

• 对公网提供HTTP/1.1、HTTP/2/gRPC，逐步试点HTTP/3；三地域 active-active，正常就近访问。峰值20万请求/秒，平均响应20KiB，P99入口额外延迟预算20ms（不含跨洲物理RTT）。
• 内部有约2,000个服务，服务间 mTLS¹¹、身份授权、限流、deadline传播和可观测；部分WebSocket/长gRPC流、大文件上传需独立策略。
• 单可用区故障无明显用户影响；单地域故障15分钟内把核心流量恢复到健康地域。路由/证书配置RPO 1分钟、控制面RTO 30分钟；控制面故障不应中断已建立数据面。
• 安全要求DDoS/WAF、TLS自动轮换、客户端IP可信链、租户隔离和审计。数据驻留服务不得跨区自动转移，入口需按合规标签路由并fail closed。

估算

20万RPS×20KiB约4GiB/s，即约32Gbit/s响应净载荷；计入协议、TLS和30%余量约45Gbit/s。正常三地域各承载约6.7万RPS，失去一地后其余每地需承载10万RPS，因此至少按50%正常冗余并再留突发空间。若平均并发由Little定律、端到端200ms估算约4万请求；长连接单独按200万连接、每连接内存/keepalive和重连速率建模，不能用RPS容量替代。

相关技术说明

平台分全局流量管理、区域边缘、内部服务网络和配置控制面。全局DNS/Anycast只做粗粒度地域选择，TTL与现有连接使切换不是瞬时；区域L4承接TCP/UDP和DDoS，L7 Gateway终止TLS、认证、路由、请求大小/并发限制。Gateway API表达平台Gateway与团队Route的角色分离，跨namespace后端用ReferenceGrant；实现支持度按版本核验。

内部代理/sidecar或节点代理通过工作负载身份建立mTLS，服务授权基于SAN身份而非IP。超时从入口deadline向下传播，每条调用链只有明确一层负责重试，配全抖动和重试预算；隔舱、熔断和优先级负载削减防止依赖慢拖垮核心。DNS缓存、NAT端口和conntrack按连接率建容量，网络指标覆盖PMTU、重传和每跳upstream时间。

架构

Clients
  -> Anycast/DNS Traffic Manager + DDoS
  -> Regional L4 Load Balancer
  -> L7 Gateway Fleet (TLS/WAF/Auth/Rate Limit)
  -> Regional Service Routing / mTLS Proxy
  -> Application Services -> Regional Data Stores

Global config source -> Validating/Policy pipeline -> Regional config stores
                                         -> Gateway/Proxy xDS-style control planes
Identity CA/issuer -> short-lived workload certificates
Telemetry agents -> regional metrics/log/trace pipelines -> global summaries

每地域至少三AZ：L4跨AZ，Gateway按AZ分布且不依赖跨区共享会话；应用就近路由，跨AZ费用与容灾通过“优先本AZ、容量不足跨AZ”权衡。控制面分发有版本、checksum、ACK/NACK和last-known-good，错误配置不覆盖现有数据面。路由资源有owner、作用域与配额，中心平台控制listener和安全基线，团队只管理获准hostname/path。

数据与流量路径

1. 客户端解析得到健康地域地址；DNS记录降低TTL只能加速刷新，旧地域保留排空窗口。QUIC不可达时客户端经Alt-Svc/策略快速回退H2。
2. L4保留或通过PROXY protocol传递源地址；L7只信任L4写入，清除外来XFF并生成request/trace ID。TLS选择SNI证书，ALPN协商H2/H1/H3。
3. 网关在读取大body前完成鉴权和准入，按认证主体+租户限流；流式上传走有界流式路径，普通API不全量缓冲。超时预算扣除网关排队后写入下游deadline。
4. 内部代理验证mTLS身份与授权，将请求路由到健康端点；本地重试仅对未发送或明确幂等请求，且消耗共享重试预算。业务trace记录每跳排队、连接、首字节和服务时间。
5. 响应返回时网关应用大小/缓存/脱敏策略；日志记录可信客户端解析结果、路由/版本和错误来源，不记录token或敏感body。

高可用与灾备

AZ故障由区域LB剔除并保证剩余网关容量；健康检查有滞回和最小健康保护，不深度依赖共享数据库。地域故障先阻止新DNS解析/Anycast宣告，再把无驻留限制的服务按容量波次切流；长连接通过有抖动的重连指引避免羊群。第二地域在正常时保留50%以上余量，核心服务有优先级准入，非关键推荐/报表先削减。

配置源跨区复制，区域数据面保留last-known-good且控制面失联不清空路由。证书短期轮换时新旧信任重叠，CA轮换演练按“先信任、再签发、后撤旧”进行。每季度切一项真实低风险域名到灾备地域，验证DNS尾部、NAT/conntrack、证书、依赖和数据一致性，而不仅检查控制台按钮。

安全

边缘做容量型DDoS与WAF，但业务授权在服务端继续执行。客户端IP只从可信代理链解析，不作为强身份。工作负载证书短期、私钥不落通用镜像，授权策略按服务身份/方法/租户；fail-closed仅用于权限与数据驻留，遥测故障不阻断业务。路由和证书变更经过schema、冲突、域名所有权与ReferenceGrant校验，生产变更由短期OIDC身份执行并审计。

可观测性

外部按地域/协议/网络类型监控DNS、TCP、TLS、TTFB与整体成功；网关看accept/drop、TLS alert、连接池等待、upstream reset/504、限流与每路由P50/P99；节点看重传、conntrack、NAT端口、CPU限流和PSI。分布式trace用统一deadline和路由版本，指标控制租户/URL高基数。合成探测覆盖每地域、每DNS解析器、UDP/TCP 53、不同body尺寸、H2/H3回退和证书链。

发布与演进

配置先静态检查与影子编译，再单网关canary、单AZ、单地域、全局；每波次验证NACK、错误、P99和连接重置。代理二进制支持N/N-1配置schema，控制面不一次推送全量。HTTP/3按客户端网络分群试点，保留H2回退；mTLS先观测身份再逐服务enforce，避免一次性阻断未知依赖。紧急回滚加载上一已签名配置版本，数据面不依赖重新构建。

实践经验

复合落地中，典型风险是把所有功能堆在单层L7：大文件缓冲和长流会挤占普通API。可把大流量/长连接放独立listener和资源池，核心API保留低延迟池；这增加证书/配置面，但隔离更清楚。另一个常见止血误区是地域故障立即把100%流量切到第二地，实际会过载；应先削减低优先级、验证容量，再分波次提高权重。

权衡

• DNS/GSLB易扩展但切换受TTL和缓存影响；Anycast¹²更快但路由运营复杂，二者可分层使用。
• sidecar提供细粒度策略与观测但资源/升级成本高；节点代理更省资源却隔离和兼容边界不同，可按服务风险混合。
• active-active提高利用与常态验证，但数据库一致性、驻留与跨区成本复杂；有状态核心可保持区域写主并提供受控故障转移。
• 更长队列和重试提高短抖容忍，却放大尾延迟和过载；平台以deadline、并发准入和重试预算优先保护恢复能力。