3. 数据传输协议基础：HTTP/HTTPS、gRPC、WebSocket在CI/CD中的应用场景对比

CI/CD流水线的本质是自动化任务链，其核心效率瓶颈往往不在于计算资源，而在于各环节之间的数据交换机制。选择错误的传输协议，会导致流水线在等待、轮询、序列化/反序列化上浪费大量时间。本章从SRE视角出发，对比三种主流协议在CI/CD场景下的适用边界。

3.1 协议核心特征速览

3.2 HTTP/HTTPS：CI/CD的“通用语言”

HTTP/HTTPS是CI/CD系统中最基础的通信协议，几乎所有CI/CD平台（Jenkins、GitLab CI、GitHub Actions）都将其作为默认的触发与状态查询接口。

• Webhook触发：代码Push、PR合并等事件通过HTTP POST发送到流水线入口，Payload通常为JSON格式的Git事件数据。
• REST API管理：查询流水线状态、触发手动构建、获取构建日志等操作均通过HTTP GET/PUT/DELETE完成。
• 制品下载：构建产物（Docker镜像、JAR包）通过HTTPS从制品仓库拉取，利用Range请求支持断点续传。

3.3 gRPC：微服务间的高性能通道

当CI/CD流水线拆分为多个微服务（如代码检查、单元测试、集成测试、打包发布各自独立部署）时，服务间需要高频、低延迟的数据交换。gRPC基于HTTP/2和Protobuf，成为内部通信的首选。

• 构建任务分发：调度器通过gRPC双向流将构建任务分发给多个Worker节点，Worker实时上报进度。
• 元数据交换：测试覆盖率、代码质量报告等结构化数据通过Protobuf高效传输，减少网络带宽占用。
• 流式日志聚合：多个构建节点的日志通过gRPC服务端流汇聚到日志中心，避免HTTP轮询带来的延迟。

// gRPC服务定义示例：构建任务分发
service BuildService {
  // 双向流：调度器下发任务，Worker上报状态
  rpc DistributeTask(stream TaskRequest) returns (stream TaskStatus);
}

message TaskRequest {
  string pipeline_id = 1;
  string stage_name = 2;
  bytes build_script = 3;  // 二进制脚本
}

message TaskStatus {
  string worker_id = 1;
  enum State { PENDING = 0; RUNNING = 1; SUCCESS = 2; FAILED = 3; }
  State state = 2;
  int64 progress_percent = 3;
}

3.4 WebSocket：实时状态推送的利器

CI/CD流水线中，实时性要求高的场景（如构建日志实时展示、测试结果即时通知）不适合使用HTTP轮询。WebSocket通过一次握手建立持久连接，实现服务端主动推送。

• 实时构建日志：Jenkins Pipeline的Blue Ocean界面、GitLab CI的Job日志均通过WebSocket推送，避免前端每秒轮询REST接口。
• 流水线状态广播：当流水线状态变更（如Stage从Running变为Failed），服务端通过WebSocket广播给所有订阅的Dashboard。
• 交互式调试：在CI/CD的交互式调试模式中，开发者通过WebSocket发送命令到远程构建环境，实时查看输出。

3.5 协议选择决策流程

以下SVG图展示了在CI/CD流水线设计中，如何根据场景特征选择数据传输协议：

3.6 混合协议架构实践

在实际CI/CD系统中，单一协议无法满足所有场景需求。成熟的流水线通常采用混合协议架构：

• 外部触发层：Git事件通过HTTPS Webhook进入流水线入口，兼容所有Git平台。
• 内部调度层：调度器与Worker之间使用gRPC双向流分发任务、收集状态，保证高吞吐和低延迟。
• 实时展示层：前端Dashboard通过WebSocket接收日志流和状态推送，提供实时交互体验。
• 制品管理层：构建产物下载通过HTTPS（支持Range请求和CDN缓存），元数据查询通过gRPC。

3.7 协议迁移与兼容性考量

从HTTP/HTTPS迁移到gRPC或WebSocket时，需关注以下兼容性问题：