在 AWS 上理解 Eclipse Dataspace Components：从数据空间协议到控制面与数据面

预计阅读时间：10 分钟

企业之间共享数据，难点通常不在“把文件传过去”，而在于谁能发现数据、依据什么条款使用、如何建立信任，以及传输后怎样保留审计记录。Eclipse Dataspace Components（EDC）试图解决的正是这组跨组织问题：参与方保留各自的数据控制权，通过标准协议协商合同，再按约定完成数据传输。

这套系列内容分三部分，从 IDSA、Dataspace Protocol（DSP）和 EDC 架构讲起，再逐步进入 Amazon ECS、Amazon Aurora 等 AWS 生产部署模式。理解第一部分的概念边界，是后续设计网络、数据库和高可用方案的前提。

数据空间不是一个集中式数据湖

传统数据平台往往把数据汇总到一个中心系统。数据空间采用不同思路：数据仍由各参与方控制，平台负责建立可互操作的发现、协商和传输机制。

在这个模型中，典型参与方包括：

提供方：发布数据资产及其使用策略，决定向谁提供数据。
消费方：检索资产、发起合同协商，并在合同成立后请求传输。
身份与信任服务：帮助连接器验证对方身份和凭证。
连接器：执行目录查询、策略判断、合同协商和传输编排。

IDSA 提供数据主权、连接器和可信交换等总体思想，DSP 则定义数据空间参与方之间的互操作协议。EDC 是这些概念的一种开源实现基础，但它不是一个安装后即可覆盖所有业务的数据交易成品。身份体系、策略模型、数据源适配、运维和审计仍需要结合场景设计。

EDC 的关键边界：控制面负责决定，数据面负责搬运

理解 EDC 架构时，最重要的区分是控制面与数据面。

控制面处理元数据和业务状态，例如：

注册资产及数据地址。
发布目录和合同报价。
评估访问策略。
执行合同协商。
创建并跟踪传输流程。

数据面执行实际的数据读取和写入。它可能从对象存储、数据库或 HTTP 服务读取数据，再把数据写到消费方指定的位置。

这种分离直接影响 AWS 部署方式。控制面通常更重视一致性、持久化状态和管理接口隔离；数据面更关注网络吞吐、弹性扩缩和对具体存储协议的支持。两者可以分别部署为 ECS 服务，并根据负载使用不同的任务规格和扩缩策略。

状态也不应只留在容器本地。合同协商、策略定义和传输流程等信息需要持久化，生产环境可以采用 Amazon Aurora 承担关系型状态；密钥和数据库口令则应进入 AWS Secrets Manager，而不是写进镜像或 ECS 任务定义。

一次数据交换究竟发生了什么

从消费方视角看，一次交换通常经历以下阶段：

消费方通过 DSP 查询提供方目录。
提供方返回资产、合同报价和使用策略。
消费方选择报价并提交合同协商请求。
双方连接器验证身份、约束条件与策略。
协商成功后形成合同协议。
消费方依据协议发起传输流程。
控制面选择合适的数据面并下发传输参数。
数据面完成传输，控制面记录状态和结果。

这里有两个容易混淆的边界。目录中暴露的是资产描述和报价，不应直接泄露底层数据库密码或对象存储凭证；合同协商成功也不等于数据已经传输，它只是为后续传输建立授权依据。

策略设计同样不能停留在一句“允许访问”。真实系统往往需要表达参与方身份、用途、有效期、地域或再分发限制。策略越复杂，测试成本和跨组织解释成本越高，因此应从双方能够稳定执行的最小规则开始。

可以这样准备 AWS 部署基础

下面是一个可复制执行的 AWS CLI 示例，用于创建 EDC 服务的 CloudWatch 日志组，并把数据库凭据放入 Secrets Manager。它不是完整的 EDC 部署模板，而是后续构建 ECS 与 Aurora 环境时可以直接改造的基础步骤。

运行前需要安装并配置 AWS CLI。请将区域、数据库地址和密码替换为实际值；生产环境不要把真实密码提交到 Shell 历史或代码仓库。

#!/usr/bin/env bash
set -euo pipefail

AWS_REGION="ap-southeast-1"
PROJECT="edc-dataspace"
DB_HOST="replace-with-aurora-endpoint"
DB_NAME="edc"
DB_USER="edc_app"
DB_PASSWORD="replace-with-a-strong-password"

aws logs create-log-group \
  --region "$AWS_REGION" \
  --log-group-name "/ecs/${PROJECT}/control-plane" 2>/dev/null || true

aws logs create-log-group \
  --region "$AWS_REGION" \
  --log-group-name "/ecs/${PROJECT}/data-plane" 2>/dev/null || true

aws logs put-retention-policy \
  --region "$AWS_REGION" \
  --log-group-name "/ecs/${PROJECT}/control-plane" \
  --retention-in-days 30

aws logs put-retention-policy \
  --region "$AWS_REGION" \
  --log-group-name "/ecs/${PROJECT}/data-plane" \
  --retention-in-days 30

SECRET_JSON=$(printf '{"host":"%s","database":"%s","username":"%s","password":"%s"}' \
  "$DB_HOST" "$DB_NAME" "$DB_USER" "$DB_PASSWORD")

if aws secretsmanager describe-secret \
  --region "$AWS_REGION" \
  --secret-id "${PROJECT}/database" >/dev/null 2>&1; then
  aws secretsmanager put-secret-value \
    --region "$AWS_REGION" \
    --secret-id "${PROJECT}/database" \
    --secret-string "$SECRET_JSON"
else
  aws secretsmanager create-secret \
    --region "$AWS_REGION" \
    --name "${PROJECT}/database" \
    --secret-string "$SECRET_JSON"
fi

printf 'Prepared logging and database secret for %s in %s\n' "$PROJECT" "$AWS_REGION"

接入 ECS 时，可以让任务角色读取该 Secret，并通过 ECS 的 secrets 配置注入字段。不要让应用在启动日志中打印完整连接字符串。控制面管理 API、DSP 协议端点和数据面入口也应使用不同的负载均衡规则或安全组边界：管理 API 只对内部运维网络开放，DSP 端点才面向经过允许的合作方。

数据库层面需要提前回答一个问题：多个控制面实例是否共享同一组持久化状态。如果答案是肯定的，就必须验证所选 EDC 扩展、数据库迁移机制和并发处理方式，而不能仅靠增加 ECS 任务数量来宣称高可用。

从概念验证走向生产的检查清单

采用 EDC 时，可以按以下顺序收敛风险：

明确参与方身份由谁签发、验证和撤销。
为资产、策略、合同协议和传输流程定义持久化边界。
分离管理 API、DSP API 与实际数据传输网络。
使用 Secrets Manager 或同类服务管理凭据，并定期轮换。
分别为控制面和数据面设置容量、超时及扩缩策略。
记录合同协商状态、传输状态和策略拒绝原因，但避免记录令牌与敏感数据。
用两个独立连接器完成端到端测试，而不只测试单个 REST 接口。
演练任务重启、数据库故障、重复请求和传输中断后的恢复行为。

EDC 的价值不只是增加一个传输服务，而是把数据发现、规则协商和实际传输拆成可审计的流程。AWS 服务可以解决容器运行、持久化、密钥和弹性问题，但无法替代参与方之间的身份治理与合同语义设计。生产部署前，团队应先把信任模型、策略边界和失败恢复机制说清楚，再决定 ECS、Aurora 与网络拓扑的具体规格。