Eclipse Dataspace Components on AWS: Architecture patterns in production

Eclipse Dataspace Components 在 AWS 上的架构模式 | AWS 架构博客

Eclipse Dataspace Components 在 AWS 上的架构模式

在 AWS 上以生产环境运行 Eclipse Dataspace Components (EDC) 连接器需要围绕隔离性、托管服务和安全分层做出明确的架构决策。在本系列文章的第一部分中，我们介绍了数据空间架构的基础知识以及 EDC 的国际数据空间协会（IDSA）标准。如果您是 EDC 的新用户，建议从那里开始。我们展示了如何通过自定义连接器功能来支持与 Amazon Web Services (AWS) 云服务的原生集成。例如，使用 Amazon Simple Storage Service (Amazon S3) 进行数据存储，以及使用 AWS Secrets Manager 进行凭证管理。在本文中，我们将深入探讨 AWS 上连接器部署架构，并介绍适用于生产环境的模式和实践。

基础架构构建模块

EDC 连接器由控制平面和数据平面组成，客户通常以容器形式部署。根据数据集成需求和对特定协议和功能的支持情况，可能需要按照本系列第一部分所述实现自定义 EDC 构建流程。例如，数据平面可能需要 OAuth 2.0 客户端凭证以连接到后端系统。您需要将生成的 EDC 容器镜像存储在容器注册表中，例如 Amazon Elastic Container Registry (Amazon ECR)。图 1 展示了遵循生产最佳实践的 EDC 连接器在 AWS 上的部署示例架构。

图 1：AWS 上生产就绪的 EDC 连接器部署

您可以将架构拆分为以下四个子组件：

• Amazon Elastic Container Service (Amazon ECS) 和 AWS Fargate 提供无服务器容器编排。这使得在不管理任何底层基础设施的情况下实现可扩展的 EDC 部署成为可能。

• EDC 需要持久化存储以保存密钥和关系型控制平面数据，并提供分发 OAuth 2.0 客户端凭证的机制。AWS Secrets Manager、Amazon Aurora 和 Amazon Cognito 可作为托管服务提供这些功能。

• Amazon S3 提供持久的数据存储，用于处理通过数据空间共享和接收的入站和出站数据。

• 最后，Amazon API Gateway 和网络负载均衡器通过 VPC 链接，在隔离的 Amazon Virtual Private Cloud (Amazon VPC) 中为 EDC API 提供安全的私有网络连接。

采用这种方法后，单个 EDC 连接器实例所属的所有云资源将形成一个隔离的架构单元。您可以通过 S3 存储桶访问该单元，将要作为 EDC 资产共享的数据传入，或从第三方接收数据作为 EDC 数据传输的一部分。其次，可以配置 API Gateway 以从管理 API、数据平面 API 和 Dataspace Protocol (DSP) API 中暴露选定的 EDC API 资源。您可以使用 AWS Identity and Access Management (AWS IAM) 和 AWS Signature Version 4 (SigV4) 协议保护与 EDC 架构单元交互的两种方式。

大型企业参与数据空间时，可能根据对故障隔离、数据治理以及共享数据与接收数据分离的需求，选择运营多个EDC实例。常见的模式是按用例部署独立的连接器实例。基础设施即代码（如AWS Cloud Development Kit (CDK)）可实现EDC连接器的自动化、模板化部署与管理，同时降低运维工作量。通过使用AWS上的Dataspace Connector参考实现，一个完整的连接器单元可通过单条CDK命令部署，即可进行合同协商和数据传输。Amazon API Gateway还支持Model Context Protocol (MCP)代理，这使EDC API能够被授权的AI代理和MCP客户端调用，实现自主的数据收集与共享。除了与智能体系统的集成，客户通常采用基于工作流的方式将EDC与云数据环境连接。他们通过API和周边的S3存储桶交互，以安全方式暴露和检索外部信息。

这些架构模式的实际验证可参考生产环境中的部署案例，如教育领域用例中的Prometheus-X数据空间连接器。该实现采用我们推荐的核心架构：使用Amazon ECS与AWS Fargate进行容器编排，S3用于数据存储，结合AWS Lambda和Amazon EventBridge实现事件驱动处理。这展示了这些模式如何在不同行业领域生产环境中有效运行。

生产就绪的关键原则

我们讨论了图1中突出显示的最佳实践图示所依据的架构原则，这些原则涉及AWS Well-Architected Framework框架的三个支柱。

运营卓越

通过基础设施即代码实现一致性：以声明方式定义所有基础设施，以支持可重复、版本控制和可测试的部署。使用CDK Nag等工具进行自动化验证，可在部署前发现配置错误和安全问题，将安全检查提前至开发周期。代码本身即成为架构的实时文档。

将可观测性作为首要关注点：将监控和日志视为核心基础设施组件。Amazon CloudWatch Container Insights、Amazon CloudWatch Logs和EDC的结构化健康检查端点可提供系统行为的可见性，支持主动问题检测和快速故障排查。EDC的健康检查API可通过API Gateway和IAM实现受限访问的暴露。

优先使用托管服务而非自建基础设施：使用AWS托管服务（Aurora、Secrets Manager、Fargate、Cognito）替代部署和维护兼容的自建解决方案。这将非差异化的基础工作转移至AWS，降低运维负担。您可获得高可用性、内置的安全最佳实践、合规认证以及自动更新功能。

安全

纵深防御：通过多个独立的安全层实现安全防护，而非依赖单一控制点。网络隔离（VPC私有子网）、安全组分段（限制组件间流量）、IAM最小权限（按服务划分权限）以及加密（静态数据和传输中数据）各自提供独立的控制机制。这些安全层协同工作，即使某一层被绕过，其他层仍能继续提供保护。

最小权限原则：每个组件仅获得其特定功能所需的最低权限。将IAM角色限定到单个服务（控制平面、数据平面），并限制安全组的端口和来源。由API网关前端的仅限内部网络负载均衡器保护EDC API和数据，防止意外的公网暴露。这种设计也有助于对EDC作为开源软件进行安全审查和审批，因为API可以单独列入白名单并进行验证。

全方位加密：在数据生命周期的每个阶段默认启用加密：静态数据（Aurora、S3、Secrets Manager）、传输中数据（强制实施TLS、仅限HTTPS出站）以及处理过程中的数据（加密的环境变量）。无论信息存储在系统何处，都能实现全面的数据保护。

可靠性

快速失败，自动恢复：系统能快速检测故障并无需人工干预自动恢复。ECS断路器可自动回滚失败的部署，自动化健康检查会移除不健康的实例，时间点恢复支持快速数据库还原。这能最小化恢复时间（MTTR），即使在单个EDC架构单元内也能减少故障影响范围。

设计区域级弹性：跨可用区负载均衡将流量分发到多个可用区（AZ），Aurora自动在可用区之间复制数据，Fargate任务可在任意可用区调度。高亮显示的架构可在AWS区域内的可用区故障时保持服务连续性。有关可用区和区域的更多信息，请参见AWS全球基础设施。

明确边界的解耦组件：将控制平面和数据平面部署为具有独立职责、安全上下文和扩展特性的独立服务。这种分离支持独立更新、针对性扩展以及协调逻辑与数据传输操作之间的故障隔离。

性能效率、成本优化和可持续性这三个Well-Architected框架支柱将在本系列的第三篇文章中讨论，其中我们将探讨在AWS上运行EDC连接器的成本优化策略。

结论

随着数据空间和EDC作为数据空间连接器的日益普及，区分适用于测试和实验的部署环境与适用于生产的部署环境变得尤为重要。生产环境要求业务关键流程依赖于参与者之间机密信息的及时、成功传输。本文定义的架构结合了社区的EDC部署最佳实践和AWS建议，在保持运营复杂度最低的同时，实现了故障容忍、可扩展性和安全性。

在第 3 部分中，您将学习如何通过实施成本优化策略，高效运行生产就绪的连接器，并通过支持供应链网络中的数据共享业务用例，最大化其带来的价值。同时，您可以探索 AWS 上的 Dataspace Connector 项目，了解本文介绍的模式和最佳实践如何在端到端的参考实现中整合应用。

参考资料

• https://github.com/awslabs/dataspace-connector-on-aws

• https://github.com/awslabs/minimum-viable-dataspace-on-aws

• https://aws.amazon.com/blogs/publicsector/accelerating-innovation-in-education-implementing-the-prometheus-x-data-space-connector-on-aws/

作者简介

'"`