3. 通信机制总览：品类策略与寻源算法之间的通信需求、数据流方向、通信协议分层模型
在智能寻源系统中，品类策略（Category Strategy）与寻源算法（Sourcing Algorithm）并非孤立运行的两个模块，而是通过一套明确的通信机制进行协同。本章从通信需求、数据流方向、协议分层三个维度，建立两者之间的通信全景视图。
3.1 通信需求：品类策略为何需要与寻源算法对话
品类策略负责定义“买什么、怎么买”，寻源算法负责执行“从哪买、多少钱”。两者之间的通信需求可归纳为以下四类：
| 需求类别 | 描述 | 典型场景 |
|---|---|---|
| 策略下发 | 品类策略将约束条件、偏好权重、候选供应商名单传递给寻源算法 | 策略指定“优先选择绿色认证供应商”，算法据此调整评分模型 |
| 状态反馈 | 寻源算法将执行进度、中间结果、异常事件回传给品类策略 | 算法发现某供应商报价异常，触发策略重新评估风险阈值 |
| 参数协商 | 双方就冲突目标（如成本 vs 交期）进行动态调参 | 策略要求成本优先，但算法反馈无合格报价，双方协商放宽交期权重 |
| 结果确认 | 寻源算法输出最终推荐结果，品类策略进行合规性校验与确认 | 算法推荐三家供应商，策略检查是否满足品类准入规则 |
关键原则：通信不是单向指令，而是双向协商。品类策略与寻源算法之间采用“请求-响应-确认”的闭环模式，确保每次决策都有迹可循。
3.2 数据流方向：从策略定义到寻源执行的数据管道
数据流在品类策略与寻源算法之间形成清晰的上下游管道。根据数据流向，可划分为三个主要阶段：
- 下行流（策略 → 算法）：品类策略将品类属性、约束规则、评分权重、候选供应商名单等结构化数据，通过标准化消息格式下发至寻源算法。
- 上行流（算法 → 策略）：寻源算法将报价数据、供应商响应、评分中间值、异常事件等实时或批量反馈给品类策略。
- 控制流（双向）：用于心跳检测、版本协商、参数同步、暂停/恢复/终止等控制指令，确保通信链路健康。
以下 SVG 图展示了数据流在三层通信模型中的完整路径：
实践建议：在实现数据管道时，优先使用消息队列（如 Kafka）承载上行流和下行流，保证数据不丢失、可回溯。控制流建议使用独立的 gRPC 或 WebSocket 通道，避免与业务数据流互相阻塞。
3.3 通信协议分层模型：从物理连接到业务语义
品类策略与寻源算法之间的通信协议采用四层分层模型，每一层解决不同粒度的通信问题。分层设计使得上下层解耦，便于独立演进和测试验证。
| 分层 | 名称 | 职责 | 典型协议/技术 |
|---|---|---|---|
| L4 | 业务语义层 | 定义品类策略与寻源算法之间的业务消息结构、字段含义、枚举值 | Protobuf Schema、JSON Schema、领域事件定义 |
| L3 | 会话与事务层 | 管理请求-响应生命周期、事务边界、超时重试、幂等性保证 | gRPC 双向流、消息队列事务、Saga 模式 |
| L2 | 传输与路由层 | 负责消息的可靠投递、路由寻址、负载均衡、流量控制 | Kafka、RabbitMQ、HTTP/2、gRPC |
| L1 | 网络与连接层 | 物理连接、TLS 加密、连接池管理、心跳保活 | TCP/IP、TLS 1.3、WebSocket、HTTP/3 |
以下 SVG 图展示四层协议分层的堆叠结构及各层之间的依赖关系：
常见误区：不要将业务逻辑直接写在传输层（如 Kafka 消息中嵌入大量业务判断），这会导致分层混乱、难以测试。业务语义层必须独立定义，传输层只负责可靠投递，不解析业务内容。
3.4 通信模式对比：同步 vs 异步
品类策略与寻源算法之间的通信支持两种模式，根据场景选择合适的方式：
| 特性 | 同步通信 | 异步通信 |
|---|---|---|
| 典型场景 | 策略下发后立即等待算法返回初步评估 | 批量寻源任务、长时间运行的优化计算 |
| 协议载体 | gRPC 一元调用、HTTP REST | 消息队列（Kafka/RabbitMQ）、gRPC 双向流 |
| 超时处理 | 固定超时（如 30s），超时后回退或重试 | 消息持久化，消费者按需拉取，无固定超时 |
| 幂等要求 | 低（请求-响应天然幂等） | 高（需实现去重和幂等消费） |
| 测试复杂度 | 较低，可单步调试 | 较高，需模拟消息中间件和时序 |
推荐策略：对于品类策略下发约束、参数协商等需要即时反馈的场景，使用同步通信；对于批量寻源、长时间优化计算、异常事件上报等场景，使用异步通信。两种模式在分层模型中共享 L1-L3 层，仅在 L4 业务语义层区分消息类型。
3.5 通信机制测试验证要点
针对通信机制的测试验证，需覆盖以下关键维度：
- 消息格式验证：检查品类策略下发的消息体是否符合 Protobuf/JSON Schema 定义，字段类型、取值范围、必填项是否合规。
- 数据流完整性：验证下行流、上行流、控制流在正常和异常场景下是否都能正确传递，无数据丢失或重复。
- 分层隔离测试：对 L1-L4 每层独立进行单元测试和接口测试，确保层间契约稳定。
- 超时与重试：模拟网络延迟、服务不可用等场景，验证超时重试机制是否按预期工作，幂等性是否保证。
- 并发与压力：模拟多品类策略同时下发、多寻源算法实例并行处理，验证通信链路不出现瓶颈或死锁。