events - 基于事件的消息系统（zeromq、OpenDDS、..）

Question

我正在尝试设计一个基于事件的消息传递系统，其工作方式如下：

假设一家商店有多种产品，它们的价格每天都在变化。客户可以登录应用程序，并请求（通过 SMS）了解特定产品在特定日期（例如从登录之日起 1 个月）的价格。

使用zeromq时如何引入事件的概念（如上所述）？OpenDDS 是否更适合这种情况？

Answer 1

看来解决方案需要结合三四种不同的技术。

(1) 一些存储技术，如数据库，用于保存长期信息并支持自定义查询。基本上是为了保存“静态数据”。经典的 RDBMS 可能非常适合。

(2) 一种消息传递技术，用于更新状态、获取状态变化通知、信号和协调不同应用程序和进程之间的集成。消息中间件技术，如 DDS/RTPS、ZeroMQ、JMS/AMQP 似乎是最适合此的。

(3) Web 客户端和服务器技术。诸如用于客户端的 Java Script 和 Node.js 或其他一些 HTTP/REST 后端。

(4)一种协议中介和集成技术。允许集成不同协议和技术的东西。例如，通过获取消息远程检测对数据库的更改，在 HTTP/REST 服务、消息传递技术和数据库之间进行集成，在 SMS 和后端之间进行集成等。Apache Camel 和 Enterprise Service 总线提供的东西。

我和最熟悉的构建系统以 DDS 作为消息传递平台为中心。如果您选择了 DDS，那么不同的 DDS 供应商已经提供了很多这些构建块。例如在网上搜索我发现了与 Apache Camel 集成和 Node.js 的集成。Hans 已经提到了 PrismTech 的 Vortex。RTI 已与关系数据库 ( https://www.rti.com/products/dds/database-integration.html )进行了现成的集成，因此对数据库所做的任何更改都会反映在消息总线上，反之亦然，如以及与 Web/HTTP/REST ( http://www.slideshare.net/GerardoPardo/london-connext-dds-conference-web-enabled-dds ) 以及其他几个已经提到的 Web 技术的集成。

您可以采取的另一种方法是围绕某个 ESB 开发您的方法，并使用它为不同技术提供的适配器。这可能是最简单的方法之一，但它的缺点是一切都将由 ESB 代理，这对您的应用程序可能或很多无关紧要。你可能想看看我写的这篇文章，我在其中描述了一些权衡：http ://soa.sys-con.com/node/467488

杰拉尔多

Answer 2

阅读您的用例可能不是关于“事件”，而是关于分布式访问建模对象（在这种情况下是您的产品）的“状态”（在这种情况下是潜在的历史价格）。

DDS 作为一种开放标准技术直接支持这一点，它通过使用发布/订阅消息传递与关系数据建模的智能组合提供对共享数据的分布式访问。它还标准化并支持大量服务质量 (QoS) 策略，这些策略可以与数据的生产者/消费者以及数据“本身”相关。在您的用例中，它的数据“持久性”QoS 将允许 DDS 基础架构维护数据对象的每个唯一标识的“实例”（在 DDS 术语中称为主题）的历史数据。

在 DDS 方法中重要的是为特定用例确定适当的“数据模型”，在您的情况下，它看起来非常简单，即具有唯一产品代码的产品（ID 将是DDS 中的 key-attribute'，就像在 RDBMS 中一样），可能是描述，然后是价格。每次价格变化时，都会发布该数据类型的新“实例”，并且由于其 QoS 策略将被定义为 PERSISTENT，因此它将由中间件（通常由一个或多个“持久性服务”维护） DDS 实施的一部分）

DDS 中的应用程序订阅这些主题，并将自动提供产品主题的历史数据。一些 DDS 实现允许根据内容、时间和/或数量（数量）的组合来指定对历史数据交付的改进。在您的用例中，它将选择“正确的产品”（按 ID 或名称）和时间。

最后，假设您的系统是“支持网络的”，即应该在互联网规模上工作，也许支持基于云的数据永久存储，以便在 PC、移动设备等上进行分布式访问。那么我建议您看看在 Vortex (www.prismtech.com/vortex)。请注意，还有一个可用的 Vortex OpenSplice 产品的开源版本 (www.prismtech.com/dds-community)。

祝你好运 ！