Nous travaillons actuellement sur notre nouveau produit / projet, il s'agit d'une application client-serveur destinée à certaines entreprises industrielles / de services spécifiques. Nous construisons un serveur (langage C et Linux uniquement) exécutant un protocole personnalisé au-dessus de TCP avec un frontal Java. Nous sommes à environ 20% dans le travail de codage et sommes confrontés à une situation devant choisir entre une architecture de noyau micro ou monolithique.
Je suis conscient que Micro vs Monolithic est généralement lié à l'architecture du noyau, mais nous parlons spécifiquement de serveurs.
Pourquoi un serveur personnalisé et pas quelque chose d'existant?
- Nos besoins en matière d'interface utilisateur sont importants et très dynamiques, donc les solutions basées sur le Web / navigateur Web n'étaient pas appropriées.
- Le traitement statistique est important du côté client et donc, encore une fois, les navigateurs ont été de peu d’aide. (Bien sûr, nous pourrions faire le traitement côté serveur et transmettre les données traitées au client, mais cela impliquerait beaucoup de charge sur le serveur et un gaspillage des ressources client).
- De plus, avec au moins trois technologies (JS / HTML / CSS) pour gérer même un seul événement rend toute l'expérience comme balayer la maison au milieu d'une tempête du désert - vous la balayez n fois, la poussière s'accumule n + 1 fois.
Qu'en est-il du serveur micro et monolithique? Que dis-tu?
Tenez compte de la demande du client (hypothétique) suivante:
request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010
Lors de la réception d'une telle demande, un serveur, généralement, le fait (nous ignorons les techniques de concurrence comme les threads et les fourchettes pour plus de simplicité):
- Analyser la chaîne de requête
- Identifier l'action (aller chercher
HistoricDataSets LIMIT Year (2010)
dans notre cas) - Interagissez avec la couche de persistance (Oracle, disons, dans notre exemple) et récupérez les données.
Formatez les données selon le protocole. Ex:
response-id: 123
success: true
response-text: DataSetsRépondez au client avec les données ainsi formatées.
C'est ce que nous appelons un serveur monolithique (semblable à un noyau monolithique où tous les fonctionnements du système d'exploitation sont effectués dans l'espace du noyau).
Considérez à nouveau la même demande, à réception, cette fois le serveur (nous avons supposé que la mémoire partagée était IPC, encore une fois pour plus de simplicité):
- Place la demande dans la mémoire partagée du
Parser
processus - L'
Parser
analyse la chaîne, identifie la tâche et dirige leExecutioner
processus pour exécuter les tâches. - Le
Executioner
passe ensuite les données auFomatter
processus qui, après avoir formaté les données en une chaîne de protocole, retourne au serveur. - Le serveur le distribue au client (réponse).
Bien sûr, au lieu de Parser
, Executioner
et Formatter
cela aurait pu être un processus unique mais séparé. C'est ce que nous appelons un Micro Server (semblable à un micro noyau faisant à peine le minimum requis). Le serveur n'écoute et ne répond efficacement que lorsque toutes les étapes sont prises en charge par différents processus.
Lequel choisir? Nous sommes confus! Alors que les serveurs monolithiques sont essayés et testés (la plupart des serveurs HTTP-Web?), Ils sont plus faciles à programmer et peuvent très bien gérer la concurrence. Les micro-serveurs, à première vue, semblent rapides et conformes au principe UNIX d'un programme pour effectuer une tâche, mais sont également compliqués à développer, en particulier. en gardant à l'esprit la simultanéité.
Question (s)
- Quels sont (pourraient être) les avantages et les inconvénients de chaque approche?
- Quand utiliser quoi? (Cela pourrait également être interprété comme une question générale: quand utiliser IPC?)
- Si le micro noyau est choisi, alors quelles fonctions doivent faire partie du serveur principal et quoi non?
Questions similaires / connexes
- Dangers d'une énorme application monolithique
- Navigateur Vs Embedded externe (Tangentiel)
- Conseils pour convertir une application monolithique en multithread (tangentiel)
Quelques informations qui peuvent être utiles:
- Nos clients potentiels peuvent être divisés en deux catégories:
- Large: environ 1700 à 2000 demandes par minute
- Petit: environ 650 à 700 demandes par minute
- On peut supposer que le volume de données par cycle de demande (demande et réponse ultérieure) est normalement distribué avec une moyenne d'environ 1,20 Mo et, dans le pire des cas, entre 250 et 300 Mo.
- Le concept du produit est relativement nouveau mais a la capacité d'avoir un impact sur les opérations de base, par conséquent, nous nous attendons à ce que les budgets des clients soient flexibles uniquement après un certain délai (9-12 mois) après le déploiement, cela limite la quantité de matériel que le client sera prêt engager esp. les petits.
- Chaque client aura sa propre pile client-serveur. Le serveur fonctionnera sur le matériel du client géré par l'équipe du client, tandis que les clients seront déployés sur les machines des employés fonctionnels
- Les mises à jour à distance pour les applications client et serveur sont indispensables
- Les
PUSH
services en temps réel par le serveur peuvent être «hautement» souhaités si le produit clique!