我正致力于跟踪车辆的应用程序。将有大约10k或更多的车辆。每个都将在每分钟发送~250bytes。数据包含gps位置和CAN总线的所有内容（我们可以从车辆计算机和仪表板读取的每个数据）。数据由GSM / GPRS（使用UDP协议）发送。每天使用此数据估算的行数约为2000k。
我看到有3个主要块（块 - >表示主要模块）。
1。 多线程套接字服务器（MSS） - 我有它。 MSS将接收到的数据存储到队列中（使用NServiceBus）。
2。 规则处理器服务器（RPS） - 这是该系统的核心。该块负责解析收到的数据，存储在数据库中，处理规则，向Notifier Server发送消息（这将发送电子邮件/短信文本）。
规则示例。 正如我之前所说，收到的字节会有关于当前速度的信息。当速度高于120时，则：在Web应用程序中为指定用户显示警报，发送电子邮件，发送短信文本。
（同一台机器上可以有多个RPS实例）。
3。 Web应用程序 - 允许用户报告和定义规则，监控警报等。
我正在寻找如何设计RPS和Web应用程序之间的通信的建议。
有些问题：
Web应用程序和RPS是否有分离的数据库或一个中央数据库就足够了？
我在网络应用程序中有一个域模型。如果有一个中央数据库，那么我可以在RPS上使用相同的模型（对象）吗？那么，如何将更改的规则发送给RPS？
我尝试尽可能地解耦这些块。我打算为每个客户端创建不同的应用程序实例（每个客户端都有分离的数据库）。一个客户将拥有10k辆汽车，其他客户只有100辆汽车。
答案 0 :(得分：3)
您正在尝试构建一个允许其用户配置的多租户SaaS系统。为此，我不建议使用技术块作为顶级架构部分。相反，寻找更多面向业务的解耦线 - 这可能包括更加关注域中时间的影响。
例如，从用户更改规则开始，它需要多快才能生效？
您可能会发现不同的规则具有不同的生效时间。
找出原因。尝试了解为什么一组规则需要在5秒内生效（例如安全）背后的业务原因，而其他规则需要在月末生效（例如计费）。
此信息将推动许多架构选择向前发展。
虽然您可能会在解决方案中使用上面提到的技术组件，如何配置它们，与它们交谈的数据库等等 - 所有这些都是由上述不同的业务环境驱动的。
我的建议是在继续之前回过头来获得更多商业洞察力。
答案 1 :(得分：0)
你几乎就在那里，因为你使用的是NSB，你可以订阅Bus.Send你已经在做了。从那里你可以将处理程序串起来创建一个规则管道。最后一个处理程序可以是将处理状态保存到数据库的处理程序。如果要将该处理与Web应用程序中的处理分离，可以从Web应用程序创建单独的DB，并将报告设置为只读。您可以在处理结束时触发事件以更新此其他数据库。在他的blog上查看Udi的Command Query Segregation帖子。
答案 2 :(得分：0)
听起来你真正想要的是CEP（复杂事件处理）。 CEP系统观察事件流并使用定义的查询来捕获某些出现或出现的序列，然后对它们作出反应。
.Net中的开源选项是NEsper。