3. 蓝绿发布原理：蓝绿部署策略、流量切换、回滚机制对日志系统的影响

蓝绿部署（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零停机发布与快速回滚的部署策略。在自动化发布流程中，蓝绿部署对日志系统的连续性、完整性以及数据治理提出了独特的挑战。本节将深入剖析蓝绿部署的核心原理，并重点分析其对 Loki 日志数据治理与压缩优化的具体影响。

3.1 蓝绿部署核心策略

蓝绿部署的核心思想是始终保留两套生产环境：一套为当前提供服务的“活跃”环境（如蓝色），另一套为待发布的“空闲”环境（如绿色）。发布流程如下：

1. 准备阶段：在空闲环境（绿）中部署新版本应用，并进行内部验证。
2. 流量切换：通过负载均衡器或网关，将用户流量从活跃环境（蓝）瞬间切换至已验证通过的环境（绿）。
3. 观察与保留：旧环境（蓝）保持运行，作为回滚备份，持续观察新环境（绿）的运行状态。
4. 清理或复用：确认新环境稳定后，回收旧环境资源，或将其作为下一次发布的空闲环境。

3.2 流量切换机制与日志连续性

流量切换是蓝绿部署的核心操作，通常由负载均衡器（如 Nginx、HAProxy）或服务网格（如 Istio）完成。切换方式分为两种：

无论采用哪种方式，都会产生一个 “双写窗口”。在这个窗口内，蓝绿两套环境可能同时产生日志，且这些日志可能包含相同的请求追踪 ID 或事务 ID。Loki 作为日志聚合系统，必须能够处理这种来自不同标签源（如 environment=blue 与 environment=green）的重复或交错日志。

3.3 回滚机制与日志一致性

蓝绿部署的最大优势在于回滚速度极快。当新环境（绿）出现异常时，只需将流量切回旧环境（蓝）即可，无需重新部署。然而，这种快速回滚对日志系统的影响不容忽视：

• 日志时间线混乱：回滚操作意味着日志流从“绿环境”瞬间切回“蓝环境”。如果蓝环境在回滚期间已经停止运行，其日志时间戳会与绿环境的日志时间戳产生“跳跃”或“重叠”。
• 事务日志不完整：在回滚瞬间，绿环境中正在处理的事务可能被中断，这些事务的日志可能只有前半段（请求进入）而没有后半段（响应返回），导致 Loki 中出现大量“孤儿日志”。
• 标签污染：如果回滚后未及时清理绿环境的日志采集器，或者标签配置错误，Loki 中可能会出现 env=green 标签的日志与 env=blue 标签的日志混合存储，干扰后续的日志查询与治理。

3.4 蓝绿发布对日志数据治理的挑战

从可观测性角度看，蓝绿部署对日志数据治理提出了三个核心挑战：

针对这些挑战，在 Loki 日志治理中需要引入 “发布版本标签”（如 release_id、deploy_version）和 “环境角色标签”（如 env_role=active、env_role=standby），而非仅依赖静态的 environment 标签。这样可以在查询时精确过滤出“活跃环境”的日志，避免双写窗口的干扰。

3.5 蓝绿发布下的日志压缩优化策略

蓝绿发布产生的重复日志和无效日志，是日志压缩优化的重点对象。在 Loki 中，可以通过以下策略进行针对性优化：

1. 基于标签的压缩优先级：对带有 env_role=standby 或 deploy_status=rolled-back 标签的日志流，设置更短的保留周期或更高的压缩比。
2. 双写窗口去重：在日志采集端（如 Promtail）或 Loki 的查询前端，通过 trace_id 或 request_id 进行去重，减少存储到 Loki 中的重复日志量。
3. 回滚日志标记与清理：在自动化发布脚本中，当触发回滚操作时，自动向 Loki 发送一条“回滚标记日志”，并触发一个清理任务，删除或压缩回滚环境产生的日志流。