系列：《Cloud GIDO 三产品特性深讲》第 13/15 篇
标签：架构串联、事件驱动、特征、实时决策
开篇：单产品特性讲完后，最常见的问题
「我们是不是三个都要上？」
「先上哪个？」
「它们在数据流上怎么接？」
这篇用特性视角把链路串起来。
端到端参考链路
用户行为 / 业务交易
│
▼
┌───────────────────┐
│ GISO │ Schema·SDK·网关·隔离·质量
│ 产出：可信事件流 │
└─────────┬─────────┘
▼
Kafka 等总线
│
├──────────────► 分析 / 数仓（Doris...）
│
▼
┌───────────────────┐
│ GIDO Stream/Batch │ 近实时/离线加工
│ GIDO Serve │ 特征与指标 API
└─────────┬─────────┘
▼
┌───────────────────┐
│ GiRisk │ 规则·敞口·限额·审计·回放
│ 产出：决策结果 │
└───────────────────┘串联时的特性对齐点
| 连接点 | 要对齐的特性 |
|---|---|
| GISO → Kafka | 事件名、版本、环境分流、隔离策略 |
| Kafka → GIDO | 消费组、水位、失败重试、schema 兼容 |
| GIDO → GiRisk | 特征时效、API 契约、缺失值策略 |
| GiRisk → 业务 | 决策枚举、原因码、超时降级 |
三种落地组合（按特性成熟度）
组合 A：先治理输入
只上 GISO → 事件可信 → 再谈中台/风控。
适合埋点长期混乱的团队。
组合 B：先服务化出口
GIDO Serve（+必要 Batch）先打通「数到 API」。
适合业务催接口、调度可后置的团队。
组合 C：关键决策路径
GiRisk + 必备上游特征（可能来自现有流计算，不必一步上全 GIDO）。
适合已有实时链路、缺证据链特性的团队。
反模式
-
上游事件不可信，却先上复杂风控规则
-
只上 Studio，不上调度实例与告警，就宣布「中台完成」
-
决策无审计回放，却接入资金/交易关键路径
今日小结
三产品可独立采用，但链路串联时要对齐 契约、时效、原因码、降级 这些特性接口。
讨论： 以你们现状，组合 A/B/C 哪个最贴近？
下篇：特性对照表------先上谁。
延伸