关于设计和构建分布式应用程序以跟踪车辆的建议
我正在开发跟踪车辆的应用程序。大约将有1万辆或更多车辆。每分钟将发送约 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 辆车。
I'm working on application for tracking vehicles. There will be about 10k or more vehicles. Each will be sending ~250bytes in each minute. Data contains gps location and everything from CAN Bus (every data that we can read from vehicle computer and dashboard). Data are sent by GSM/GPRS (using UDP protocol). Estimated rows with this data per day is ~2000k.
I see there 3 main blocks (blocks -> mean main modules).
1.
Multithreaded Socket Server (MSS) - I have it. MSS stores received data to the queue (using NServiceBus).
2.
Rule Processor Server (RPS) - this is core of this system. This block is responsible for parsing received data, storing in the database, processing rules, sending messages to Notifier Server (this will be sending e-mails/sms texts).
Rule example.
As I said earlier, received bytes there will be information about current speed. When speed will be above 120 then: show alert in web application for specified users, send e-mail, send sms text.
(There can be more than one instance of RPS on same machine).
3.
Web application - allows reporting and defining rules by users, monitoring alerts, etc.
I'm looking for advice how to design communication between RPS and Web application.
Some questions:
Should Web application and RPS have separated databases or one central database will be enough?
I have one domain model in web application. If there will be one central database then can I use the same model (objects) on RPS? So, how to send changed rules to RPS?
I try to decouple this blocks as much as possible. I'm planning to create different instance of application for each client (each client will have separated database). One client will be have 10k vehicles, others only 100 vehicles.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您已经差不多完成了，因为您正在使用 NSB，所以您可以订阅您已经在执行的 Bus.Send。从那里您可以将处理程序连接在一起以创建规则管道。最后一个处理程序可以将处理状态保存到数据库中。如果您希望将该处理与 Web 应用程序中发生的情况分离，您可以从 Web 应用程序和只读报告中创建一个单独的数据库。您可以在处理结束时触发一个事件来更新另一个数据库。查看 Udi 在他的 博客 上发布的命令查询隔离帖子。
You are pretty much there, since you are using NSB, you can subscribe to the Bus.Send you are already doing. From there you can string handlers together to create a rules pipeline. The last handler can be the one to save the state of the processing to your DB. If you want to decouple that processing from what is going on in the web app, you can create a separate DB from the web app and reporting that is read only. You can fire an event at the end of your processing to update this other DB. Check out Udi's Command Query Segregation posts on his blog.
听起来您真正想要的是 CEP（复杂事件处理）。 CEP 系统监视事件流并使用定义的查询来捕获某些事件或事件序列，然后对它们做出反应。
.Net 中的一个开源选项是 NEsper。
It sounds like what you really want is CEP (Complex Event Processing). CEP systems watch a stream of events and use defined queries to capture certain occurences or sequence of occurences, and then react to them.
An open source option in .Net is NEsper.
您正在尝试构建一个允许用户对其进行配置的多租户 SaaS 系统。为此，我不建议使用技术块作为顶级架构部分。相反，寻找更多面向业务的解耦路线 - 这可能包括更加关注时间对您领域的影响。
例如，从用户更改规则开始，需要多快才能生效？
您可能会发现不同的规则有不同的生效时间。
找出原因。尝试了解为什么一组规则需要在 5 秒内生效（例如安全），而其他规则需要在月底生效（例如计费）背后的业务原因。
这些信息将推动许多架构选择的发展。
尽管您可能会在解决方案中使用上面提到的技术组件，但它们的配置方式、它们与哪个数据库通信等等 - 所有这些都是由上面描述的不同业务上下文驱动的。
我的建议是在继续之前回去获得更多的业务洞察力。
You're trying to build a multi-tenant SaaS system that allows its users to configure it. For this, I wouldn't recommend using technical blocks as the top-level architectural pieces. Instead, look for more business oriented lines of decoupling - this may include a greater focus on the impact of time in your domain.
For example, from the time a user changes a rule, how quickly does it need to go into effect?
You may find that different rules have a different time-to-effect.
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.