事件驱动架构 - 服务合同设计

Question

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

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

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

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

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

• 'when'由专用的调度组件管理。由于与下载相关的成本，我们希望在日内批量处理请求。

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



因为每个职责都分为三个不同的组件，我们通过异步消息传递获得各种潜在的竞争条件。例如，当Scheduler告诉Downloader完成其工作时，因为'Append to Download Definition'命令是异步的，所以无法保证客户A的待处理请求实际上已得到服务。但这一切都尖叫着高度耦合我;为什么调度程序必须知道在调用下载之前需要执行的任何“先决条件”客户端请求？

我们玩弄过的一些潜在解决方案：

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

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

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

Answer 1

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

脱离我的头脑：

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

这有帮助吗？