0

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

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

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

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

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

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

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

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

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

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

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

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

4

1 回答 1

0

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

从我的头顶冒出：

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

这有帮助吗？

于 2013-06-11T21:59:36.543 回答