Architecture de serveur micro vs monolithique

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: DataSets

• Ré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 Parserprocessus
• L' Parseranalyse la chaîne, identifie la tâche et dirige le Executionerprocessus pour exécuter les tâches.
• Le Executionerpasse ensuite les données au Fomatterprocessus 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, Executioneret Formattercela 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)

• 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 PUSHservices en temps réel par le serveur peuvent être «hautement» souhaités si le produit clique!

L'économie régit parfois la réponse beaucoup plus critique que la théorie fondamentale derrière les choix. La chose la plus importante est que si vous regardez quelque chose de `` vaste '' dans votre cas, où votre application a besoin d'un déploiement vraiment difficile - moins le nombre de roues que vous inventez vous-même, mieux c'est. Si ça marche, je m'en fiche si c'est monolithique ou micro; sinon, je m'en fiche!

Il est peut-être vrai que les applications basées sur des pages Web très conventionnelles ne sont peut-être pas pour vous - mais vous devez jeter un œil plus large et voir que vous pouvez utiliser les choses prêtes à l'emploi et évoluer plus tard pour voir si vous pouvez remplacer cet élément par quelque chose mieux. De cette façon, non seulement vous gagnerez du temps pour la première chose - mais vous améliorerez également votre compréhension de ce qui compte vraiment dans la vie réelle. Voici quelques conseils que vous pourriez considérer.

1. Si vous avez vraiment besoin d'une évolutivité très élevée, réfléchissez à la façon dont vos serveurs répartiront la tâche plutôt que de réduire les nombres aussi rapidement qu'ils le peuvent. Finalement, vous aurez une charge qu'un serveur ne peut pas vraiment supporter même si Intel fait le processeur le plus rapide sur terre et que le client est prêt à payer! Le routage des demandes et l'équilibrage de charge sont donc plus importants que l'efficacité du protocole lui-même.

2. HTTP est toujours le meilleur - si vous avez besoin de passer à l'échelle supérieure. (Vous pouvez également obtenir facilement des équilibreurs de charge si vous l'utilisez). Le protocole personnalisé nécessite des arrangements personnalisés.

3. HTTP ne signifie pas que vous devez jeter du HTML, du script java du tout. Cela ne signifie même pas que vous devez avoir un serveur Apache et un navigateur Web réguliers. Vous pouvez utiliser HTTP entre deux clients personnalisés et des éléments comme le serveur AOL ou lighthttpd qui peuvent être utilisés comme bibliothèque si la communication n'est pas un énorme transfert de données. Vous pouvez également utiliser SOAP des deux côtés avec des kits d'outils comme gSOAP .

4. Même si HTTP ne correspond certainement pas à la facture, pensez à quelque chose comme BEEP , qui vous aide à rendre les choses plus efficaces. Il existe également de nombreux mécanismes RPC et RMI éprouvés.

5. Essayez de voir que vous pouvez faire plus de travail maximal en effectuant un traitement parallèle dans le back-end et les serveurs ne sont interrogés que lorsque le travail est terminé. Si cela fonctionne, il existe des cadres comme MPI , ou il existe de nombreux autres kits d'outils informatiques distribués qui peuvent être utiles.

6. Enfin, bien que je ne sois peut-être pas en mesure de connaître les besoins exacts, mais vous devrez peut-être distribuer beaucoup de données ou faire beaucoup de calculs, si vous avez besoin des deux - il y a encore des inefficacités architecturales fondamentales.

Pour moi, créer un nouveau protocole et créer un nouveau cadre de serveur est une double expérience que vous ne devriez pas faire ensemble. Si vos enjeux sont si élevés, vous devez d'abord essayer d'expérimenter avec les outils existants pour voir les limites de ce qui a été fait jusqu'à présent - alors seulement vous connaîtrez les vrais défis.

Beaucoup plus a été accompli dans la recherche de systèmes distribués que de simples applications Web. Vous devriez donc rechercher cela.

Dipan.

Cela me semble très académique. Et franchement, je trouve la deuxième approche tout aussi monolithique. C'est aussi loin que vous devriez aller:

1. Analyser la demande
2. Gérer la demande

Le gestionnaire de demande choisi en fonction des paramètres de la demande doit encapsuler tous les aspects de la gestion de la demande. Que le gestionnaire effectue ou non des requêtes sur votre magasin de données et qu'il utilise ou non une mise en forme standard pour renvoyer les données est sans importance pour la couche ci-dessus. En fait, cela fera probablement cela, mais il n'y a aucune valeur à faire des hypothèses à ce sujet.

1. Le noyau monolithique est beaucoup plus ancien que Microkernel . Il est utilisé sous Unix. tandis que l'idée de micro-noyau est apparue à la fin des années 80 .

2. l'exemple des systèmes d'exploitation ayant les noyaux monolithiques sont UNIX, LINUX tandis que les systèmes d'exploitation ayant Microkernel sont QNX, L4, HURD , initialement Mach (pas mac os x) plus tard, il sera converti en noyau hybride, même MINIX n'est pas du noyau pur car le pilote de périphérique est compilé dans le cadre du noyau.

3. Le noyau monolithique est plus rapide que le micro-noyau . tandis que le premier micro-noyau Mach est 50% plus lent que le noyau monolithique tandis que la version ultérieure comme L4 n'est que 2% ou 4% plus lente que le noyau monolithique .

4. Le noyau monolithique est généralement volumineux . tandis que le noyau monolithique pur doit être de petite taille, même s'insérer dans le cache de premier niveau du processeur (micro-noyau de première génération).

5. dans le pilote de périphérique du noyau monolithique résident dans l' espace du noyau . tandis que dans le pilote de périphérique Microkernel réside dans l' espace utilisateur .

6. puisque le pilote de périphérique réside dans l'espace du noyau, il rend le noyau monolithique moins sûr que le micro-noyau. (Une défaillance du pilote peut entraîner un plantage) tandis que les micro-noyaux sont plus sûrs que le noyau monolithique, donc utilisé dans certains appareils militaires.

7. Les noyaux monolithiques utilisent des signaux et des sockets pour assurer l'IPC tandis que l'approche micro-noyau utilise des files d'attente de messages . 1 génération de micro-noyau IPC mal implémentée était donc lente sur les changements de contexte.

8. ajouter une nouvelle fonctionnalité à un système monolithique signifie recompiler tout le noyau tandis que vous pouvez ajouter une nouvelle fonctionnalité ou des correctifs sans recompiler .