【可信空间】基于 SecretFlow 的可信数据空间架构落地指南

一、先讲人话：什么是"可信数据空间"？

很多团队一开始会问：

• 数据不能出域，怎么做联合分析？
• 医院、银行、政务、产业链上下游之间，怎么"用数据"但"不泄露数据"？
• 如果出了问题，怎么追溯是谁发起、谁执行、哪一步失败？

**可信数据空间（Trusted Data Space）**就是解决这类问题的技术与治理体系。

它的核心不是"把所有数据汇总到一个大库"，而是：

• 数据留在各自机构本地；
• 通过隐私计算协议完成联合计算；
• 全程有权限控制、审计记录、可追踪链路；
• 输出最小必要结果，避免数据裸奔。

一句话总结：
让数据"可用不可见、可控可计量、可追溯可审计"。

---

二、推荐生产架构图（可直接放文章）

下面是 Mermaid 架构图
业务系统/前端
API Gateway

认证 鉴权 限流
Compute API 服务

任务提交 查询 取消
幂等与状态机服务

idempotencyKey job状态流转
编排引擎

Argo/Temporal
SecretFlow/Kuscia 控制面
机构A执行节点

Alice SPU/PSI
机构B执行节点

Bob SPU/PSI
A方本地数据域
B方本地数据域
结果存储A

对象存储/安全文件区
结果存储B

对象存储/安全文件区
任务库/幂等库

PostgreSQL/MySQL
事件总线

Kafka/RabbitMQ
回调服务

回写compute_job_result
可观测性

Prometheus Grafana Loki
安全基础设施

KMS TLS RBAC 审计

---

三、这张图到底怎么读？（逐层细讲）

1）接入层：API Gateway（把好入口第一关）

职责：

• 统一接入：所有提交/查询/取消请求都从网关进入；
• 认证鉴权：校验 JWT/OIDC 身份，判断租户与用户权限；
• 安全防护：限流、防重放、防刷、防参数注入；
• 灰度治理：可按租户/版本路由到不同后端能力。

输入与输出：

• 输入：业务系统发起的 HTTP 请求（任务参数、查询参数、Token）；
• 输出：透传后的标准 API 请求，附加统一 traceId、租户上下文。

关键流程：

• 校验 Token 与签名；
• 绑定租户与操作人；
• 生成或透传 requestId；
• 进行限流与黑白名单判断；
• 转发到 Compute API。

落地要点：

• 统一错误码与响应格式，避免前后端协议碎片化；
• 网关日志必须记录 requestId + tenantId + uri + status；
• 对提交接口启用"突发流量保护"。

常见坑：

• 只做认证不做授权，导致"登录了就都能调"；
• 未做租户隔离，跨租户读到任务状态；
• 无重放防护，导致重复请求穿透到后端。

---

2）任务控制层：Compute API + 幂等服务 + 状态机（平台中枢）

职责：

• 解析 psi_job_request 并校验字段合法性；
• 基于 idempotencyKey 做防重；
• 创建 jobId 并进入状态机；
• 统一输出 compute_job_result。

输入与输出：

• 输入：任务入参契约（含 schemaVersion/idempotencyKey/keyColumns/trace）；
• 输出：jobId、任务状态、最终结果对象或错误对象。

关键流程：

• 参数校验（字段完整性、版本兼容性、路径/资源策略）；
• 幂等检查：命中则直接返回已有 jobId；
• 创建任务记录：PENDING；
• 投递编排引擎后状态变更到 RUNNING；
• 收到执行结果后转为 SUCCEEDED/FAILED/CANCELED。

落地要点：

• 幂等唯一约束建议 (tenant_id, idempotency_key)；
• 状态流转必须幂等（重复回调不应破坏状态）；
• 所有状态变化要写审计事件。

常见坑：

• 并发提交下先查后插，出现重复任务；
• 状态机允许非法跳转（如 FAILED -> RUNNING）；
• 错误只写字符串，无结构化 error.code。

---

3）编排层：Argo/Temporal（任务"发动机"）

职责：

• 将一个计算任务拆分成可观测、可重试的步骤；
• 管理依赖关系、超时和补偿动作；
• 向任务控制层持续回报进度。

输入与输出：

• 输入：jobId + 规范化任务参数；
• 输出：阶段状态事件、最终执行结果、失败原因。

关键流程（示例）：

• Step1 参数与资源检查；
• Step2 下发 SecretFlow 任务；
• Step3 轮询/订阅执行状态；
• Step4 收集结果产物与哈希；
• Step5 回写标准结果与审计事件。

落地要点：

• 每个步骤定义独立超时；
• 区分"可重试错误"和"不可重试错误"；
• 补偿逻辑要可回放（例如撤销临时凭证、清理中间产物）。

常见坑：

• 所有失败都重试，导致雪崩；
• 无超时边界，任务长时间卡住；
• 编排日志不带 jobId/requestId 难以排障。

---

4）隐私计算层：SecretFlow / Kuscia / SPU（真正"算"的地方）

职责：

• 在多方节点执行 PSI/Join/MPC；
• 保证原始数据不出本方域；
• 输出各方授权可见的结果。

输入与输出：

• 输入：计算协议参数、参与方身份、数据引用（非数据明文搬运）；
• 输出：交集结果、统计指标、执行日志摘要。

关键流程：

• 节点间建立可信通信；
• 各方加载本地数据并执行协议；
• 生成分方输出并加签/哈希；
• 回传执行状态与产物元信息。

落地要点：

• 明确"谁是接收方（receiver）""是否广播结果（broadcast）"；
• 多方节点版本要一致，避免协议不兼容；
• 先跑小样本压测，再上生产数据规模。

常见坑：

• 网络联通不稳定导致任务间歇失败；
• 键列标准不一致（空格、大小写、编码）导致交集异常；
• 权限策略不清导致结果越权可见。

---

5）数据与结果层：对象存储 + 元数据回写（可审计、可复用）

职责：

• 保存产物文件（按参与方隔离）；
• 记录哈希、路径、过期时间；
• 生成标准结果对象供查询和回调。

输入与输出：

• 输入：计算层产物路径、哈希、统计指标；
• 输出：标准 compute_job_result 与可追溯审计记录。

关键流程：

• 产物落对象存储；
• 元数据写 DB；
• 回写回调系统；
• 前端按 jobId 查询展示。

落地要点：

• 产物与元数据分离存储（大文件不直接入库）；
• 保留 sha256 支持审计与防篡改；
• 设置 TTL 与归档策略控制成本。

常见坑：

• 只存文件不存元数据，后续无法检索；
• 路径可见性不区分租户；
• 回写成功但数据库未落盘，造成状态不一致。

---

6）可观测与安全层：生产稳定性"底盘"

职责：

• 监控性能与可用性；
• 建立全链路日志与追踪；
• 管理密钥、证书、权限；
• 提供审计取证能力。

输入与输出：

• 输入：网关/API/编排/计算层日志与指标；
• 输出：仪表盘、告警、审计报表、追踪链路。

关键流程：

• 指标采集（QPS、P95、失败率、重试率）；
• 日志聚合（按 jobId/requestId 检索）；
• 告警触发（超时、失败突增、资源饱和）；
• 安全审计（谁在何时做了什么）。

落地要点：

• 至少维护 4 个核心SLA：成功率、时延、超时率、回调成功率；
• 告警要分级（P1/P2/P3）并有值班机制；
• 密钥和证书要有轮换计划。

常见坑：

• 只有日志没有指标，无法评估趋势；
• 告警过多无分级，最终无人处理；
• 缺少审计链路，合规检查难通过。

---

四、核心数据契约：为什么要模板化？

你可以把生产系统的数据契约抽象为三类对象：

• psi_job_request.json：任务入参契约（输入、策略、trace）
• compute_job_result.json：结果出参契约（状态、产物、审计、错误）
• compute_job_result(instance)：一次真实执行后的记录实例

关键字段解释（工程语义）

• schemaVersion：结构版本号，保障新旧模板兼容解析；
• idempotencyKey：同一业务动作唯一标识，重复提交不重复执行；
• keyColumns：匹配键，可单列也可复合列；
• trace：链路追踪上下文（requestId/contractId/tenant/operator...）；
• error：标准错误结构（便于前端、告警、自动重试）。

---

五、从 Demo 到生产：分四步落地

第一步：最小闭环

• 提供 POST /api/compute/jobs；
• 能接收入参模板、返回 jobId；
• 结果先落本地文件也可以。

第二步：治理能力补齐

• 加幂等表；
• 加状态机；
• 加标准错误码；
• 加 trace 透传。

第三步：接入真实 SecretFlow/Kuscia

• 编排层接管执行流程；
• 节点间网络与证书打通；
• 跑通跨机构 PSI。

第四步：生产化运营

• 监控与告警；
• 审计报表；
• SLA 指标；
• 灰度发布与容量规划。

---

六、常见误区与避坑建议

误区1：把幂等当缓存

正确理解：

幂等核心是"同一业务动作只产生一个权威任务"。

是否缓存完整结果是策略问题，不是幂等本身的定义。

误区2：只关注算法，不做治理

现实里真正影响上线的，往往是：

• 权限模型；
• 审计留痕；
• 错误处理；
• 运维可观测性。

误区3：结果只存一方

建议按最小披露策略设计，但元数据应完整可追溯（至少要有哈希与 trace）。

---

七、接口示例（建议最小四个）

• POST /api/compute/jobs：提交任务
• GET /api/compute/jobs/{jobId}：查询状态
• POST /api/compute/jobs/{jobId}/cancel：取消任务
• POST /api/compute/callbacks/result：回写结果

这四个接口就能组成"最小可运营闭环"。

---

八、关键代码片段

1）提交任务 API（示例：Java Spring）

@PostMapping("/api/compute/jobs")
public ResponseEntity<Map<String, Object>> submitJob(@RequestBody PsiJobRequest req) {
    String idemKey = req.getIdempotencyKey();
    Optional<JobRecord> existing = jobService.findByIdempotencyKey(idemKey);
    if (existing.isPresent()) {
        return ResponseEntity.ok(Map.of(
            "jobId", existing.get().getJobId(),
            "status", existing.get().getStatus(),
            "idempotentHit", true
        ));
    }

    JobRecord created = jobService.createPending(req);
    orchestrator.dispatch(created.getJobId(), req);
    return ResponseEntity.accepted().body(Map.of(
        "jobId", created.getJobId(),
        "status", "PENDING",
        "idempotentHit", false
    ));
}

2）幂等表结构（示例：PostgreSQL）

create table compute_idempotency (
  id bigserial primary key,
  tenant_id varchar(64) not null,
  idempotency_key varchar(128) not null,
  job_id varchar(64) not null,
  status varchar(32) not null,
  result_hash varchar(128),
  expired_at timestamptz,
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now(),
  unique (tenant_id, idempotency_key)
);

3）任务状态机（示例：伪代码）

PENDING -> RUNNING -> SUCCEEDED
PENDING -> RUNNING -> FAILED
PENDING -> CANCELED
RUNNING -> CANCELED

4）标准错误回写结构（示例：JSON）

{
  "status": "FAILED",
  "error": {
    "code": "PSI_INPUT_KEY_MISSING",
    "message": "Input key column is missing",
    "detail": {
      "party": "bob",
      "hint": "Check keyColumns and CSV header consistency"
    }
  }
}

---

九、给初学者的学习路径（按优先级）

• 先学数据契约：psi_job_request 与 compute_job_result；
• 再学幂等和状态机（这是平台骨架）；
• 再学 SecretFlow/Kuscia 的部署与任务执行；
• 最后补齐监控、安全、审计和运营能力。

---

十、总结

如果你希望把隐私计算真正落到业务里，请记住一句话：

生产可用的可信数据空间 = 隐私计算能力 + 平台治理能力 + 安全合规能力。

脚本能帮助你快速理解"算得出来"；

架构与治理决定你能否"长期稳定地跑在生产环境里"。

---