事件驱动架构——服务契约设计

Question

我很难将我的需求概念化为适合我们新生的 SOA/EDA 的东西

我们有一个组件，我称之为数据下载器。这是外部数据提供者的外观，它具有高延迟和与每个请求相关的成本。我想使用这个组件并通过明确的合同定义从中创建一个可重用的服务。由我来决定该合同的运作方式，但它的责任有两个：

1. 为即将进行的预定下载维护参数列表（称为下载定义）
2. 管理与外部服务通信的技术细节

基本上，它管理通信的“方式”。 'what' 和 'when' 是另外两个组件的职责：

• “什么”由负责的“客户”管理 确定下载参数。

• “何时”由专用调度组件管理。由于与下载相关的成本，我们希望在当天批量处理请求。

希望这个序列图能够解释服务的职责：

由于每个职责都分为三个不同的组件，因此我们会通过异步消息传递获得各种潜在的竞争条件。例如，当调度器告诉下载器完成它的工作时，因为“附加到下载定义”命令是异步的，不能保证来自客户端 A 的未决请求实际上已经得到服务。但这一切对我来说都是高耦合的。为什么调度程序必须知道在调用下载之前需要执行的任何“先决条件”客户端请求？

我们尝试过的一些潜在解决方案：

• 使“附加到下载定义”命令成为阻塞请求/响应操作。但这会破坏性能。拥有 EDA 的可扩展性优势

• 在下载器中构建一些东西以确保它仅在其传入请求队列中没有待处理命令时运行。但这会引入对底层消息传递基础架构的依赖，我也不喜欢。

让我觉得我在以一种完全落后的方式思考这个问题。或者这只是一个经典案例，有人试图将同步 RPC 需求融入异步事件驱动架构？

Answer 1

我最喜欢 EDA 和 SOA 的一点是，它几乎完全消除了竞争条件的概念。只要您的事件与某个关联键（例如 downloadId）相关联，您描述的问题就可以通过不同复杂性的几种解决方案来解决 - 具体取决于您的需要。我不确定我是否完全理解所描述的用例，但我会尽力而为

想不通：

1. DataDownloader 维护收到的下载定义列表和触发下载列表。当接收到定义时，将根据触发器列表检查是否已触发相关下载，如果已触发，则执行下载。接收到 TriggerDownloadCommand 时，将根据具有关联 downloadId 的定义检查定义列表。
   1. 对于更复杂的情况，请考虑使用 Saga 模式，该模式由一些 3rd 方消息传递基础架构实现。通过一些简单的配置，它将处理这两个消息，并在满足所需条件时启动实际下载。这更适合分布式系统，其中内存中的集合是不可能的。
   2. 您还可以将调度程序（或触发命令处理程序）配置为在发出错误信号（例如异常）时重试，以避免出现争用情况，并最终在指定超时后放弃。

这有帮助吗？