111 lines
9.7 KiB
Markdown
111 lines
9.7 KiB
Markdown
# Orbit 生产验收与发布门槛
|
||
|
||
> 版本 0.2 · 2026-09-17。本文是全平台生产发布门槛。P0–P2 已积累阶段证据，见 [开发计划](08-development-plan.md) 与 [P2 验收](reports/phase-2.md)；P3的逐项功能及故障证据边界见[阶段核对](reports/phase-3.md)，新增[相对延迟与重试全停恢复](reports/phase-3-delay-recovery.md)。未覆盖的场景继续实施，尚无全平台生产验收或容量结论。
|
||
|
||
## 1. 验收对象与证据
|
||
|
||
统一验证平台中的 Pulse 任务模块、Weave 流程模块、MySQL、HTTP / WS 协议和业务 SDK。包含模拟业务处理器及模拟外部渠道，以验证副作用与结果确认边界。
|
||
|
||
每份验收报告记录：版本、数据库配置、拓扑、硬件、网络条件、参数、数据量、复现步骤、预期与实际结果、关键指标、异常记录和遗留问题。
|
||
|
||
稳定性目标必须表述为在指定故障模型与负载下满足约定，不使用脱离环境的“绝不丢失”或“支持无限租户”作为测试结论。
|
||
|
||
## 2. 必须覆盖的正确性与故障场景
|
||
|
||
| 编号 | 场景 | 期望结果 |
|
||
| --- | --- | --- |
|
||
| A01 | 相同幂等键重复提交、并发提交 | 返回同一任务，不创建第二份工作；参数冲突明确拒绝 |
|
||
| A02 | 受理已提交，HTTP 响应丢失 | 使用原键可查到任务，重试不重复创建 |
|
||
| A03 | 多节点同时领取同一任务 | 仅一个有效授权，配额与尝试记录一致 |
|
||
| A04 | 派发落库后节点宕机，消息未送达 | 未开始尝试可回收，任务仍可追踪并恢复 |
|
||
| A05 | 开始确认或完成确认丢失 | SDK 按操作身份核对/重报，不能错误地再执行一次已确认操作 |
|
||
| A06 | 业务写入成功，Worker 在上报前崩溃 | 平台允许恢复；业务幂等返回原结果，副作用未知时转核查 |
|
||
| A07 | 旧 Worker 暂停后恢复，租约已被替代 | 旧结果不覆盖新状态，资源端防护按接入契约生效 |
|
||
| A08 | 续租与过期回收、完成操作竞争 | 事务条件决定唯一合法转换，额度不重复释放 |
|
||
| A09 | WS 断线后重连不同节点 | 重新鉴权与恢复核对，旧会话不能继续控制新会话归属 |
|
||
| A10 | Worker 容量消息重复、发送缓冲满 | 不重复发放额度，不无限积压内存，不丢弃关键结果恢复信息 |
|
||
| A11 | 取消与开始/完成竞争 | 终态与已知结果一致，取消意图不伪装成业务回滚 |
|
||
| A12 | 外部平台已受理但响应超时 | 按处理器安全策略核查，不能盲目重复提交 |
|
||
| A13 | 多调度节点处理同一触发点 | 仅一个有效触发实例，任务与计划进度原子更新 |
|
||
| A14 | 停机、时区变化、计划修改与恢复 | 补跑/跳过/合并遵守已定义版本边界，全部可追溯 |
|
||
| A15 | 结果接收方停机或确认丢失 | 事件保留并可重投，接收方去重，积压可观测 |
|
||
| A16 | 同业务键并发与跨节点配额竞争 | 有效许可满足约束，过期执行副作用按业务防护处理 |
|
||
| A17 | 使用另一应用/队列身份读写或恢复任务 | 被拒绝，敏感参数与凭据不泄露 |
|
||
| A18 | MySQL 短暂不可用或主节点切换 | 不发出无依据的成功确认；恢复后任务可核对 |
|
||
| A19 | 平台与 Worker 滚动升级 | 兼容版本继续服务，旧任务找到兼容处理器或明确等待 |
|
||
| A20 | 清理与归档同时发生重复补交/事件补投 | 幂等与未确认事件不被无声破坏 |
|
||
| W01 | 创建流程下一步任务时中断事务 | 流程状态与任务创建同时提交或回滚 |
|
||
| W02 | 任务完成后流程处理节点宕机 | 内部结果事件可恢复消费，步骤不重复推进 |
|
||
| W03 | 信号提前、重复或迟到 | 已存在实例可保存早到信号，消费去重且匹配正确步骤 |
|
||
| W04 | 人工等待或定时等待期间重启 | 等待状态恢复，不长期占用业务 Worker |
|
||
| W05 | 并行步骤部分成功、部分失败 | 汇合规则明确，成功副作用保留，重试不越过业务安全规则 |
|
||
| W06 | 新流程版本发布 | 已运行实例继续使用冻结版本，不悄悄改变历史步骤 |
|
||
| W07 | 取消流程时仍有任务执行 | 流程如实反映取消推进与待核查状态，不宣称已撤销副作用 |
|
||
| W08 | 同一汇合点的多个结果并发到达 | 按汇合规则只推进一次、只创建一份后继任务 |
|
||
| W09 | 信号受理、定时唤醒与取消竞争 | 原子决定唯一有效推进；已按时受理信号不因消费积压被误判超时 |
|
||
| W10 | 人工恢复后收到旧激活结果或重复恢复请求 | 旧结果不推进新激活，恢复去重，保留审计与业务幂等 |
|
||
| W11 | 查询正常返回处理中，期间部分请求失败 | 查询轮次与 Pulse 尝试独立计数；处理中按间隔进入下一轮，请求重试不新增轮次 |
|
||
| W12 | 轮次用完、总时限到达或单轮重试耗尽 | 按规则转核查；不换任务或轮次绕过上限，不再次调用业务提交接口 |
|
||
| W13 | 保存查询结果、建立等待或创建下一轮时宕机 | 从持久化轮次与检查点恢复，同一轮只创建一项任务，预算不丢失或重复扣减 |
|
||
| W14 | 暂停与创建步骤、任务领取、开始及重试竞争 | 按控制版本及门控决定唯一有效顺序，暂停后不新增授权；已授权工作继续收集结果 |
|
||
| W15 | 暂停期间收到结果/信号、到期或重启，然后继续 | 结果和待续推进记录可恢复，原版本与预算保留；按冻结计时规则处理到期，不集中补查 |
|
||
| W16 | 最终回执、查询结果与下一轮唤醒并发或迟到 | 只完成一次等待并创建一份后继工作，停止后续轮次，冲突或旧结果不能覆盖结论 |
|
||
| W17 | SDK 重复发布、同版本内容冲突或发布非法定义 | 同内容幂等，不同内容拒绝；非法表达式、引用及无界预算被拒绝，运行实例版本不变 |
|
||
|
||
W11–W17 中的字段与暂停/计时算法按技术评审后的规范执行；这些验收项不表示当前建议已经实现或测试通过。
|
||
|
||
验收还需覆盖日志脱敏、权限撤销、消息超限、死锁、连接重连风暴、磁盘容量告警及进程强制终止。
|
||
|
||
## 3. 性能负载模型
|
||
|
||
租户数量用于推导业务量，不能直接等同于连接数、队列数或每秒任务数。至少建立以下维度：
|
||
|
||
- 平均与峰值提交任务数、批量大小、瞬时集中触发规模。
|
||
- 同时运行任务数、任务耗时分布、续租频率与重试比例。
|
||
- Worker 连接数、每连接并发、空闲连接比例、重连频率。
|
||
- 参数/结果大小、事件数量、保存周期、历史查询并发。
|
||
- 定时计划数、到期分布、漏跑补偿规模与允许的恢复窗口。
|
||
- 流程实例数、每实例步骤数、并行度、等待实例数与信号速率。
|
||
- 查询轮次与单轮尝试分布、渠道请求峰值，以及大量暂停实例继续时的待续推进规模。
|
||
|
||
采用短任务、中长任务、混合负载、集中触发、长期积压和故障恢复六类场景。既测空处理器的框架开销，也测可控延迟的模拟外部调用。
|
||
|
||
## 4. 必须度量的指标
|
||
|
||
| 指标 | 定义 |
|
||
| --- | --- |
|
||
| 受理延迟 | 发起请求至可靠受理响应，统计 p50 / p95 / p99 |
|
||
| 调度延迟 | 原计划到期时间至变为可派发状态，单独统计漏跑补偿 |
|
||
| 排队与派发延迟 | 可执行时间至授予执行权，以及授予至 Worker 收到/开始 |
|
||
| 吞吐 | 可靠受理、开始、完成、事件交付分别统计 |
|
||
| 数据库负载 | 查询/写入、锁等待、死锁、连接池、日志与磁盘 I/O、复制滞后 |
|
||
| 连接与内存 | 连接数、重连、发送队列、内存、GC、CPU 与网络 |
|
||
| 恢复效果 | 故障发现、重新授权、流程恢复、积压清空的时间与错误数量 |
|
||
| 公平性 | 单个应用突发时其他应用的延迟与额度兑现情况 |
|
||
| 流程推进 | 内部事件至步骤完成/后续任务创建的延迟与积压 |
|
||
| 有界查询与暂停 | 活跃查询节点、轮次/尝试消耗、到期转核查量、暂停实例数、继续后的推进延迟及渠道请求速率 |
|
||
|
||
开启生产所需持久化、复制、鉴权和审计后再测，报告任何性能优化对可靠性或恢复窗口的影响。
|
||
|
||
## 5. 发布前必须确定的参数
|
||
|
||
生产容量、延迟、可用性目标与 RPO / RTO 仍待实际拓扑验证。当前已实现的消息上限、租约/续租/心跳/重连与恢复扫描参数见 [Worker 手册](api/worker.md)，这些正确性基线不等于生产调优结论。批量/补跑预算、流程查询与暂停预算、保留及兼容范围随对应阶段落实并验证。
|
||
|
||
配置之间需要校验，例如续租间隔与安全余量必须允许在租约到期前发现失败；代理空闲超时需与 WS 活性策略协调；最长恢复补发窗口应与幂等和事件保留周期匹配。
|
||
|
||
## 6. 备份恢复与上线门槛
|
||
|
||
恢复演练必须实际恢复到隔离环境，核对任务、尝试、计划、幂等、结果事件、流程、暂停控制与执行门控、查询轮次及预算、信号和权限配置。恢复旧数据后需要隔离旧连接与执行凭据，并核查可能已发生的外部效果。
|
||
|
||
上线前至少具备：
|
||
|
||
- 已评审的功能、状态机、协议与兼容矩阵。
|
||
- 实际 MySQL 的持久化、复制确认、故障切换及恢复说明。
|
||
- 上述关键故障场景的复现证据与结果核对。
|
||
- 满足约定峰值且保留容量余量的压力测试记录。
|
||
- 监控告警、值守与恢复操作说明，必要的管理权限和审计。
|
||
- 业务接入方的幂等及结果核查验收；真实业务副作用前先完成隔离环境演练。
|
||
- 发布、迁移、回滚/前向修复策略，以及明确的停止扩量条件。
|
||
|
||
仅有单机演示、正常路径测试或一次吞吐测试，不构成本项目的生产验收通过。
|