2. 数据传输基础：模式、协议与序列化

在变更冻结闸口场景中，数据传输是连接测试验证节点与核心系统的关键链路。理解传输模式、协议与序列化格式，是设计可靠闸口的基础。本节从三个维度展开：同步/异步模式的选择、常见传输协议的特性对比、以及序列化格式对性能与兼容性的影响。

2.1 数据传输模式：同步与异步

数据传输模式决定了发送方与接收方在时间上的耦合关系。在冻结闸口中，同步模式适用于实时校验，异步模式适用于批量处理与解耦。

2.2 常见传输协议

不同协议在性能、语义、生态上各有侧重。以下为冻结闸口中最常用的三种协议。

2.2.1 HTTP/REST

• 风格： 资源导向，使用 GET/POST/PUT/DELETE 操作。
• 数据格式： 通常搭配 JSON，也可支持 XML。
• 适用场景： 闸口对外 API、微服务间轻量调用。
• 优点： 简单、广泛支持、防火墙友好。
• 缺点： 文本协议开销大，无内置流控。

2.2.2 gRPC

• 风格： RPC 调用，基于 HTTP/2，支持双向流。
• 数据格式： 默认使用 Protobuf 序列化。
• 适用场景： 内部服务间高性能通信、流式数据传输。
• 优点： 低延迟、强类型、支持流式。
• 缺点： 调试相对复杂，浏览器支持有限。

2.2.3 消息队列（MQ）

• 风格： 生产者-消费者，异步解耦。
• 常见实现： RabbitMQ、Kafka、RocketMQ。
• 适用场景： 变更事件广播、数据管道、削峰填谷。
• 优点： 高可用、持久化、发布订阅。
• 缺点： 引入中间件复杂度，端到端延迟增加。

2.3 数据序列化格式

序列化格式直接影响传输效率与跨语言兼容性。JSON 与 Protobuf 是当前最主流的两种选择。

2.3.1 JSON 示例

{
  "changeId": "CHG-20250321-001",
  "type": "emergency",
  "targetSystem": "payment-core",
  "riskLevel": "P0",
  "timestamp": "2025-03-21T14:30:00Z"
}

2.3.2 Protobuf 定义与编码示例

syntax = "proto3";
message ChangeRequest {
  string change_id = 1;
  string type = 2;
  string target_system = 3;
  string risk_level = 4;
  int64 timestamp = 5;  // Unix 毫秒时间戳
}

Protobuf 编码后体积约为 JSON 的 30%~50%，在闸口高并发场景下能显著降低带宽与延迟。

2.4 闸口场景下的综合选型建议

• 实时准入校验： gRPC + Protobuf，低延迟、强类型，适合高频调用。
• 对外 REST API： HTTP/REST + JSON，兼容性好，便于第三方集成。
• 变更事件广播： MQ + Protobuf，异步解耦，减少核心链路压力。
• 审计日志上报： MQ + JSON，便于后续日志解析与检索。