2

我正在研究跟踪车辆的应用程序。将有大约 10,000 辆或更多车辆。每个将在每分钟发送约 250 个字节。数据包含 GPS 位置和来自 CAN 总线的所有内容（我们可以从车载计算机和仪表板读取的所有数据）。数据通过 GSM/GPRS 发送（使用 UDP 协议）。每天使用此数据的估计行数约为 2000k。

我看到有 3 个主要块（块-> 表示主要模块）。

1. 多线程套接字服务器 (MSS) - 我有。MSS 将接收到的数据存储到队列中（使用 NServiceBus）。

2. 规则处理器服务器（RPS）——这是这个系统的核心。该块负责解析接收到的数据，存储在数据库中，处理规则，向通知服务器发送消息（这将发送电子邮件/短信文本）。

规则示例。正如我之前所说，接收到的字节会有关于当前速度的信息。当速度高于 120 时：在 Web 应用程序中为指定用户显示警报、发送电子邮件、发送短信。

（同一台机器上可以有多个 RPS 实例）。

3. Web 应用程序 - 允许用户报告和定义规则、监控警报等。

我正在寻找如何设计 RPS 和 Web 应用程序之间的通信的建议。

一些问题：

  • Web 应用程序和 RPS 应该有独立的数据库还是一个中央数据库就足够了？

  • 我在 Web 应用程序中有一个域模型。如果会有一个中央数据库，那么我可以在 RPS 上使用相同的模型（对象）吗？那么，如何将更改后的规则发送到 RPS？

我尝试尽可能多地解耦这些块。我计划为每个客户端创建不同的应用程序实例（每个客户端都有单独的数据库）。一位客户将拥有 10,000 辆汽车，其他客户只有 100 辆汽车。

4

3 回答 3

3

您正在尝试构建一个允许其用户对其进行配置的多租户 SaaS 系统。为此，我不建议使用技术块作为顶级架构部分。相反，寻找更多面向业务的解耦线——这可能包括更加关注时间在您的领域中的影响。

例如，从用户更改规则开始，需要多长时间才能生效？

您可能会发现不同的规则有不同的生效时间。

Find out why. Try to understand the business reasons behind why one group of rules needs to go into effect in under 5 seconds (for example safety), and others need to go into effect at the end of the month (for example billing).

This information will drive many architectural choices going forwards.

Although you will likely have the technical components you mentioned above used in the solution, how they get configured, which database they talk to, etc - all of that is driven by the different business contexts described above.

My recommendation is to go back and get more business insight before going forward.

于 2010-04-24T11:03:26.003 回答
0

你几乎在那里，因为你正在使用 NSB，你可以订阅你已经在做的 Bus.Send。从那里您可以将处理程序串在一起以创建规则管道。最后一个处理程序可以是将处理状态保存到数据库的处理程序。如果您想将该处理与 Web 应用程序中正在发生的事情分离，您可以从 Web 应用程序和只读报告创建一个单独的数据库。您可以在处理结束时触发事件以更新此其他数据库。在他的博客上查看 Udi 的命令查询隔离帖子。

于 2010-04-22T02:23:32.357 回答
0

听起来您真正想要的是 CEP（复杂事件处理）。CEP 系统监视事件流并使用定义的查询来捕获某些事件或事件序列，然后对它们做出反应。

.Net 中的一个开源选项是NEsper。

于 2010-04-23T11:54:29.323 回答