3. 灰度发布核心原则

灰度发布（Canary Release / Gradual Rollout）在低延迟回测引擎中并非简单的流量切换，而是一套风险控制体系。回测引擎直接处理历史行情数据、资金模拟与策略逻辑，任何版本缺陷都可能导致回测结果失真或系统雪崩。以下五大原则构成了灰度发布的决策与执行骨架。

3.1 渐进式暴露（Gradual Exposure）

版本变更不应一次性推送到所有回测节点或所有用户。渐进式暴露通过分阶段、分维度的流量放大，让每个阶段都有足够的数据验证版本稳定性。

3.2 可观测性（Observability）

灰度发布期间，必须能实时感知新旧版本的行为差异。回测引擎的可观测性不仅包括传统的 Metrics（延迟、吞吐量），还必须包含回测结果一致性校验。

• Metrics（指标）：任务调度延迟、内存分配速率、GC 暂停时间、CPU 缓存命中率。
• Logging（日志）：结构化日志，包含版本号、任务 ID、策略名称、时间窗口。
• Tracing（链路）：每个回测任务从提交到完成的完整调用链，识别性能瓶颈。
• 一致性校验（Critical）：对同一段历史数据，新旧版本分别运行，对比资金曲线、最大回撤、夏普比率等关键指标。

3.3 快速回滚（Fast Rollback）

当灰度版本出现异常时，回滚速度直接决定了故障影响范围。回滚不是简单的“切回旧版本”，而是一套原子化、可验证的流程。

3.4 流量隔离（Traffic Isolation）

灰度版本与稳定版本之间必须实现资源隔离和数据隔离，防止灰度版本的问题污染稳定环境。

• 计算资源隔离：灰度版本部署在独立的 K8s Node 或独立容器组，使用 cgroup 限制 CPU/内存上限。
• 数据存储隔离：灰度版本使用独立的 Redis 实例、独立的数据库表或独立的 Schema。
• 消息队列隔离：灰度版本消费独立的 Topic 或 Consumer Group，避免消息污染。
• 回测结果隔离：灰度版本的回测结果写入独立的结果表，与稳定版本结果物理分离。

3.5 版本兼容性（Version Compatibility）

灰度版本必须与稳定版本保持双向兼容，确保在灰度期间，两个版本可以共存并正常处理回测任务。

• API 兼容性：灰度版本不得修改已有 API 的入参、出参结构。如需新增字段，使用 optional 模式。
• 数据格式兼容性：回测结果、中间状态、缓存数据的序列化格式必须向前向后兼容。推荐使用 Protobuf 或 Avro 并维护 schema 版本。
• 配置兼容性：新增配置项必须提供默认值，旧版本忽略未知配置项。
• 依赖兼容性：灰度版本使用的第三方库版本不得引入破坏性变更（如 JDK 版本、Python 包版本）。