发行策略：蓝绿色和金丝雀
（部分： 技术和基础设施）
简短摘要
蓝绿色在两个完整的堆栈（蓝色/绿色）之间进行即时切换，并具有最简单的回滚。金丝雀在SLO门控制（潜伏期，错误率，业务指标）下逐渐增加新版本的流量份额。对于iGaming来说，这是比赛和股票高峰期在没有市区的情况下发布的一种方式，同时保持稳定的p99和质量。
1）什么时候选择
蓝绿色-快速发布,最小难度,需要"双重"群集/资源预算。适用于没有复杂状态迁移的API/前沿。
金丝雀-高风险发布（新漏洞，关键更改），允许"捕获"1-5％的流量退化。它需要遥测和自动门。
2）建筑原则
1.L7级路由：平衡器/Ingress/Service-mesh（加权流量模块,Cookie/flag-routing）。
2.孤立的依赖关系：配置、ficheflagi、秘密、缓存-分开进行修订。
3.数据兼容性：DB迁移向前兼容（expand→migrate→contract）。
4.可观察性：度量/逻辑/预告片中的单个版本/标签。
5.Autogates：比较p95/p99，error-rate，Business KPI；自动回滚。
3）蓝绿色： 基本模式
线程
1.我们展开绿色（蓝色的副本）→热缓存/连接。
2.我们运行health/smoke测试。
3.将流量（DNS/LB/Ingress）切换到Green。
4.将Blue保持在"温暖"状态，直到窗口结束。
示例： 在Ingress级别切换（想法）
yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80优点/缺点
简单回滚（返回Blue）。
可预测的发布时间。
需要重复资源。
没有金丝雀测量的"大爆炸"风险。
4）金丝雀： 逐步建立
线程
1.影子流量运行（可选）→ 1%的实际流量→ 5% → 25% → 50% → 100%。
2.每个阶段均采用SLO/业务指标。
3.退化-自动回滚和保存诊断工件。
示例： Argo Rollouts（片段）
yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100示例： Flagger+Istio/NGINX（想法）
yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke5）加热和状态管理
缓存/来源：加热Redis/HTTP 缓存/CDN,准备用于DB/PSP的warm-pool连接。
ML/LLM/型号：权重/索引/积木，KV缓存，"热身"的主要查询。
文件/工件：静态内容、模板、configs-提前提交到本地volume/sidecar。
Ficheflagi：在1-5%的受众/细分市场上滚动，紧急杀人的可能性。
6）数据库： "expand → migrate → contract"战略"
1.Expand：添加无用/新列/索引,支持两个版本。
2.Migrate：代码使用新方案；旧路径仍然有效。
3.合同：完全展开后,我们删除旧字段/索引。
在日志中捕获方案和客户端的版本；所有的变化都是相等的。
对于严重的迁移-背景乔巴舞，throttling和"停止世界"窗口。
7）可观察性和门户（SLO/SLA）
SRE指标：p50/p95/p99，error-rate，saturation（CPU/GPU/IO），queue-depth，冷启动时间。
业务指标：支付转换，费率成功，退出时间（TTW），促销响应。
内容质量/LLM：tokens/s，响应长度，毒性，RAG得分。
门户：在超出门槛和/或下降"有用的指标"时自动晋级/回滚。
gate:
p95_latency_ms <= 250 error_rate % <= 1. 0 payment_conv >= baseline - 0. 3%
action:
promote rollback8）发行编排和与CI/CD的集成
GitOps：版本/重量更改-通过PR进入清单存储库。
自动反驳：在流量开始之前,smoke/e2e。
发布计划：金丝雀台阶时间表，负责人，ChatOps频道，回滚窗口。
工件存档：路由configs，dashbords snepshots，比较指标日志。
9）多区域与边缘
顺序：首先是"最不关键"的区域/ROR，然后是基本区域。
基于Latency的路由：关注本地SLO；不要无缘无故溷淆流量。
DR愿景：A地区的Blue可能成为B地区Green的DR站点。
10）安全性和合规性发布
签名图像/图表，SBOM；验证管理策略中的签名。
秘密：只有外部经理；Blue/Green的独立版本。
PII/区域性：不要通过"外国"地区带走PII的流量；比较时掩盖日志。
审计：谁在宣传哪些门工作，回滚在哪里。
11）配置示例
NGINX： 加那利分公司Cookie/标题（想法）
nginx map $http_x_canary $canary {
default 0;
"1" 1;
}
upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }
server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}Feature-flag "fractional rollout"（伪）
yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true12） Runbooks（典型脚本）
在绳索上增加p99：停止促销活动→增加击球/计时，通过旗帜关闭沉重的菲奇，→重新启动部分垫子。
支付转换率下降：比较PSP 路线/fichi,包括阴影成像,回滚到稳定。
DB迁移问题：冻结写入流量、启用只读模式、回滚方桉（如果可能）、紧急修补乔布。
PII事件：切断金丝雀版本，重复秘密，报告和审计。
13）实施支票
1.定义策略：蓝绿色在哪里，金丝雀在哪里；被认为是"关键的"。
2.配置加权路由（Ingress/mesh/路由器）。
3.确定SLO阈值门户和自动回滚。
4.实施DB expand→migrate→contract；迁移测试。
5.启用缓存/模型加热和warm-pool连接。
6.输入GitOps并记录所有发布操作。
7.可视化指标比较（金丝雀vs稳定）。
8.玩游戏日：模拟回滚/失败门/DB问题。
9.记录runbooks和"红色按钮"（kill-switch）。
10.按次序而不是同时安排多区域发布。
14）反模式
没有门和遥测的金丝雀释放→晚期降解检测。
混合DB方案：在代码解开之前破坏迁移。
Blue和Green的一个共享缓存/队列没有隔离→相互影响。
TTL低的DNS切换无需验证-"翻转"流量。
两个修订版的秘密/共鸣→复杂的回滚。
没有影子/烟雾的散布流量是"大爆炸"的风险。
缺少kill-switch/feature-flag可快速关闭。
结果
Blue-green提供即时和简单的切换,canary-管理风险和早期问题检测。在iGaming中，两种模式结合在一起："尖锐"变化上的绳索+蓝绿色作为基本机制，没有中心。添加SLO门、GitOps、预热、DB兼容性和依赖性隔离-即使在高峰期,发布也是可预测的,回滚速度很快,p99和业务指标也是稳定的。