Conseils sur la conception et la construction d'applications distribuées pour le suivi des véhicules

Question

Je travaille sur une application pour le suivi des véhicules. Il y aura environ 10k ou plus de véhicules. Chacun enverra ~ 250 octets dans chaque minute. Les données contiennent l'emplacement GPS et tout de CAN Bus (toutes les données que nous pouvons lire de l'ordinateur du véhicule et tableau de bord). Les données sont envoyées par GSM/GPRS (en utilisant le protocole UDP). Les lignes estimées avec ces données par jour sont ~ 2000k.

Je vois là 3 blocs principaux (blocs -> modules principaux moyens).

1. Serveur de socket multithread (MSS) - Je l'ai. MSS stocke les données dans la file d'attente (en utilisant NServiceBus).

2. Serveur RPC (Rule Processor Server) - c'est le cœur de ce système. Ce bloc est responsable de l'analyse des données reçues, du stockage dans la base de données, du traitement des règles, de l'envoi des messages à Notifier Server (envoi de messages e-mails/sms).

Exemple de règle. Comme je l'ai dit plus tôt, les octets reçus, il y aura des informations sur la vitesse actuelle. Lorsque la vitesse sera supérieure à 120, alors: afficher l'alerte dans l'application Web pour les utilisateurs spécifiés, envoyer un e-mail, envoyer un SMS.

(Il peut y avoir plusieurs instances de RPS sur la même machine).

3. application Web - permet des rapports et la définition de règles par les utilisateurs, les alertes de surveillance, etc.

Je cherche des conseils comment concevoir la communication entre RPS et application Web.

Quelques questions:

• application Web et RPS ont doit-séparés bases de données ou une base de données centrale sera suffisant?

• J'ai un modèle de domaine dans une application web. S'il y aura une base de données centrale, puis-je utiliser le même modèle (objets) sur RPS? Alors, comment envoyer les règles modifiées à RPS?

J'essaie de découpler autant que possible ces blocs. Je prévois de créer une instance d'application différente pour chaque client (chaque client aura une base de données séparée). Un client aura des véhicules 10k, d'autres seulement 100 véhicules.

Answer 1

Vous essayez de créer un système SaaS mutualisé qui permet à ses utilisateurs de le configurer.Pour cela, je ne recommanderais pas d'utiliser des blocs techniques comme éléments architecturaux de haut niveau. Au lieu de cela, recherchez des lignes de découplage davantage axées sur les affaires - cela peut inclure une plus grande concentration sur l'impact du temps dans votre domaine.

Par exemple, à partir du moment où un utilisateur modifie une règle, à quelle vitesse doit-il entrer en vigueur?

Il est possible que des règles différentes aient une durée de validité différente.

Découvrez pourquoi. Essayez de comprendre les raisons commerciales qui expliquent pourquoi un groupe de règles doit entrer en vigueur en moins de 5 secondes (par exemple, la sécurité) et d'autres doivent entrer en vigueur à la fin du mois (par exemple, la facturation).

Cette information va conduire de nombreux choix architecturaux allant de l'avant. Bien que vous ayez probablement les composants techniques que vous avez mentionnés ci-dessus utilisés dans la solution, comment ils sont configurés, la base de données à laquelle ils parlent, etc. - tout cela dépend des différents contextes métier décrits ci-dessus.

Ma recommandation est de revenir en arrière et obtenir plus de perspicacité des affaires avant d'aller de l'avant.

Answer 2

Vous êtes à peu près là, puisque vous utilisez NSB, vous pouvez vous abonner au bus.Envoyez vous déjà. De là, vous pouvez enchaîner les gestionnaires pour créer un pipeline de règles. Le dernier gestionnaire peut être celui qui sauvegarde l'état du traitement dans votre base de données. Si vous souhaitez dissocier ce traitement de ce qui se passe dans l'application Web, vous pouvez créer une base de données distincte à partir de l'application Web et générer des rapports en lecture seule. Vous pouvez déclencher un événement à la fin de votre traitement pour mettre à jour cette autre base de données. Consultez les messages de Séquences de requête de commande de Udi sur son blog.

Answer 3

Il semble que ce que vous voulez vraiment, c'est CEP (Complex Event Processing). Les systèmes CEP surveillent un flux d'événements et utilisent des requêtes définies pour capturer certaines occurrences ou séquences d'occurrences, puis y réagir.

Une option open source dans .Net est NEsper.