Quand un gros produit est conçu ou qu'un petit logiciel commence à devenir un léviathan, quelle voie de développement dois-je choisir? Dois-je tout réécrire à partir de zéro ou continuer les traditions «historiquement établies»? Quoi qu'il en soit, vaut-il la peine de revoir le concept même d'architecture?
Bonjour, Khabrovites! Je m'appelle Konstantin et je suis le développeur principal d'un système assez important qui a commencé une fois comme une expérience. Un petit site PHP créé littéralement "à genoux" et, bien sûr, un monolithe. Au fil du temps, le site s'est agrandi et s'est heurté à un certain nombre de problèmes, dont la solution posait la question "et alors comment?".
Monolith ou microservices? Que choisir? La différence fondamentale entre les approches, à mon avis, est qu'un monolithe implique un cycle centralisé de traitement de la demande d'un utilisateur et des microservices - décentralisés. Les avantages et inconvénients communs des deux approches sont largement connus et répertoriés plusieurs fois (par exemple
ici ,
ici ou
ici ). Cependant, il n'y a pas de facteurs aussi évidents et évidents qui influencent le choix de l'architecture.
- Chargement des employés à temps plein . Avec le développement rapide du produit, un pool de tâches s'accumule, qui ne peut pas être résolu dans un délai acceptable - tout le monde est occupé. Et si un tel «blocage» est unique, cela n'a aucun sens d'élargir le personnel des développeurs. La solution évidente est les sous-traitants externes (entreprises ou indépendants). Mais comment leur donner un morceau de produit pour fonctionner sans risquer de le transformer en OpenSource, grosso modo? Dans le cas de l'utilisation de microservices, cette tâche est beaucoup plus facile à résoudre.
- La difficulté de la plongée . Plus le produit est grand, plus il faut de temps à un nouvel employé pour s'y mettre à l'aise. Surtout s'il y a beaucoup de valeurs par défaut différentes dans le code (oui, une bonne documentation facilite le processus, mais si ce n'est pas le cas?) Et des personnalisations pour des cas particuliers. De ce point de vue, traiter une petite pièce indépendante est beaucoup plus facile qu'avec le produit entier immédiatement.
- Ressources aux pics de charge . Dans ma pratique, il y avait un cas où la charge sur les serveurs atteignait parfois des valeurs inacceptables (et si spécifiquement - la RAM était épuisée, un swap était activé et le serveur se transformait en légume pendant un certain temps), pendant le travail libre tout le reste du temps (le chargement ne dépassait pas 30% en termes de RAM ) Et ces pics se sont produits de manière irrégulière et avec de longues pauses. Dans le cas d'un monolithe (nous pensons qu'il n'y a nulle part où optimiser le code), seule la connexion de nouveaux serveurs avec une copie de l'ensemble du système pour l'équilibrage de charge est sauvegardée. Et dans le cas des microservices, vous pouvez organiser une file d'attente de traitement (bien sûr, cela ne s'applique qu'aux opérations urgentes qui sont rapides et imprévues, comme le déchargement d'un tableau Excel).
- Effectuer des tâches en arrière-plan . La manière dont ce facteur «secoue le bateau» dépend de sa taille et de sa complexité. En règle générale, un monolithe et une minuterie (cron) suffisent. Mais si les tâches commencent à s'accumuler en grands groupes, des problèmes surviennent également. Il est déjà nécessaire d'équilibrer les tâches cron. Les microservices facilitent grandement cette situation.
- La complexité du suivi . Dans le cas des microservices, les exigences pour la maintenance du fer sont augmentées - où, quoi et comment doivent être configurés. Monolith - en gros, certains paramètres pour tous les nœuds, microservices - les paramètres dépendent des exigences de microservices spécifiques qui s'exécutent sur le nœud.
- Exigences de qualification . Plus le zoo utilise de technologies (et il se développe généralement si le système est microservice), plus les exigences en matière de compétences et de connaissances des employés réguliers sont élevées. Après tout, s'il y a des améliorations ou des problèmes, ils doivent y faire face. Ou plus de professionnels sont nécessaires pour couvrir toute la pile.
Faut-il choisir? Le jeu en vaut-il la chandelle? Je pense que ça vaut vraiment le coup. Mais il faut aborder la question avec tête froide. Sinon, certains problèmes seront simplement remplacés par d'autres.
Dans mon cas, un tournant s'est produit lorsque le site a cessé de "s'intégrer" dans les ressources d'un serveur. Ensuite, il a été décidé de réécrire le système selon la meilleure option à mon avis - un hybride. Il existe
des recommandations générales pour le développement de produits dans le «cas hybride». Mais je voudrais le compléter par quelques recommandations.
Lors de la conception d'un monolithe de démarrage, les possibilités de connexion supplémentaire des services externes doivent être immédiatement définies. Construisez immédiatement des communications inter-composants comme si ces composants étaient déjà (ou presque déjà) des «services externes». Surtout si elles sont gourmandes en ressources.
Réfléchissez immédiatement à une politique d'utilisation des caches et des stockages de données (bases de données et fichiers). Par exemple, partagez la session d'un utilisateur.
Et le plus important n'est pas de se précipiter vers les extrêmes. Pour ma part, j'ai déduit la formule suivante pour un bon projet: "un système efficace est un système équilibré". En particulier, cela s'exprime dans le fait que dans les microservices je ne retire que de gros fragments logiquement isolés du noyau. Et puis, seulement si au moins une des conditions est remplie:
- une limitation de la charge et des prévisions sont nécessaires, le retard dû à l'exécution de la tâche n'est pas critique à son tour
- l'isolement entraînera une augmentation significative de la productivité.
Grâce à cette approche, nous avons obtenu un système, 95% des fonctionnalités situées dans le noyau et 5% dans des microservices. Mais en même temps, le cœur ne représente que 60% de la charge totale. Et en même temps, vous pouvez garantir que la charge sur les serveurs individuels ne dépasse pas les valeurs critiques.
Les microservices sont donc (à partir d'une certaine taille du produit) bons si vous ne les utilisez qu'en cas d'absolue nécessité, et non à cause de la mode ou "parce que c'est cool". Il existe de gros
produits qui vivent avec succès comme un monolithe. Mais parfois, un monolithe ne peut pas résoudre le problème ...
Je vous remercie!