La plupart des applications Web que je construis finissent par avoir besoin d'un ouvrier en arrière-plan. Certaines tâches lentes ou lourdes doivent être exécutées indépendamment, telles qu'une intégration avec un serveur tiers, un scraper Web, la création de PDF, etc.
À ce stade, l'application franchit une barrière et dispose désormais d'une architecture multiservices. Il y a une nouvelle couche de complexité à gérer.
La conteneurisation et la popularité croissante de microservices ont créé un écosystème d'outils incroyablement riche pour prendre en charge les architectures multiservices. La plupart sont destinées aux grandes équipes de développement et aux grands utilisateurs, mais une petite équipe peut-elle également en bénéficier?
Quand la complexité et la surcharge d'une telle architecture sont-elles appropriées? Jusqu'où le prendre? Et comment l'appliquent-ils vraiment?
J'ai essayé de répondre à ces questions en essayant de trouver un point idéal pour la petite équipe de ~ 2-20 développeurs, ce qui fonctionne très bien avec un framework existant Django / Laravel / Node / Rails, qui Recueillir les principaux avantages sans ajouter trop de charge.
Perspective d'une petite équipe
Ce qui aurait été une simple base de données ou une transaction d'union devient beaucoup plus difficile, ce qui nécessite des interactions entre plusieurs services et éventuellement des confirmations en deux phases.
Puisque nous ne voulons pas diviser notre application en microservices distincts, définissons une "architecture de microservice" comme désignant quelque chose de plus général: les services de conteneur qui s'exécutent derrière un contrôleur passerelle / équilibreur de charge / revenu avec certains formulaire d'authentification centralisé.
Ok, défini, nous pouvons maintenant l'appeler "microservices" et pas seulement "Docker", mais pourquoi le voulons-nous?
Une touche de bon service
Avec une architecture de microservice en place, il est assez facile d'ajouter de petits services qui complètent votre application principale. Si vous devez faire du scraping Web, vous pouvez décider d'ajouter un service Chrome sans tête, en le codant en JavaScript au lieu de PHP / Python / Ruby dans une bibliothèque conçue à l'origine pour des tests fonctionnels.
Une fois la plomberie microservice installée, l'ajout d'un nouveau service est très simple.
Vous ne souhaitez peut-être pas introduire trop de langues dans votre projet, mais Docker Hub regorge de services utiles ne nécessitant pas de code personnalisé. Votre application a-t-elle besoin de la reconnaissance optique de caractères? Vous pouvez placer le meilleur service OCR de sa classe. Avec l'authentification centralisée déjà mise en œuvre, vous pouvez également l'exposer en tant que point de terminaison d'API indépendant. Si cela vous semble plus logique que de l'utiliser en tant qu'agent d'arrière-plan, cela dépend de vous.
Riches travailleurs de fond
Les travailleurs de fond nous ont conduits à cela, nous pourrions bien faire. Lorsqu'un utilisateur termine, nous envoyons les résultats à l'utilisateur via WebSockets. Notre nouvelle plomberie l'admet également.
Un agent de messagerie à usage intensif tel que RabbitMQ ne conviendra pas pour tous les projets, mais il convient très bien si nécessaire. Une bonne infrastructure guide les décisions futures. Une fois, j'ai dû intégrer une application Rails à un horrible système ERP. Aucune des bibliothèques tierces Ruby n'a fonctionné.
La bibliothèque fournie par le vendeur fonctionnait mais était dans une langue différente. Même en ignorant le problème de la mise en œuvre, notre système d'arrière-plan basé sur Ruby ne fonctionnerait pas dans cet environnement. L'ajout d'un nouveau courtier de messages était trop à prendre en compte à ce moment-là. J'ai donc choisi quelque chose de hacky et de restrictif: j'ai enregistré les demandes de mon système local et les ai converties en modèles de chaîne que notre application enverrait.
Espace à développer
Après avoir payé le coût de complexité initial d'une architecture de microservice, vous bénéficiez d'autres avantages. Si certains utilisateurs passent des appels d'API abusifs, imposer des limites de vitesse à la passerelle d'API ne constitue pas une étape importante. Ou peut-être que vous allez configurer la passerelle pour soutenir les lancements canariens, où vous pouvez essayer un changement terrifiant dans une petite partie de votre auditoire avant de tous les lancer. (Et le faire revenir automatiquement s'il trouve de nouvelles erreurs).
Bien que le grand nombre d'utilisateurs ne soit pas un facteur important pour de nombreuses petites équipes, l'avantage de la mise à l'échelle automatique n'est pas négligeable. Même avec une légère augmentation de la charge, certaines fonctionnalités ou certains services sont susceptibles de dépasser les autres en termes de consommation de ressources. Pouvoir les dimensionner séparément est très agréable.
À quel prix?
Examinons les inconvénients ...
Ressources lourdes
L'exécution de nombreux services dans des conteneurs consomme de la mémoire et du processeur. Lorsque je limite Docker à 2 cœurs de processeur dans mon système de développement, l'exemple de projet Webstack-micro (ci-dessous) semble assez lent, en particulier au début. L'exemple ne comporte que 9 services relativement légers: une application plus importante serait pénible avec cette affectation.
Un système de développement moderne et robuste présente de nombreuses possibilités. Si vous utilisez Java ou .NET ou avez plusieurs services différents, le projet pourrait submerger un ordinateur portable de développement typique. Si vous atteignez ce point, vous devrez peut-être changer le mode de développement sur le cloud, qui nécessite toujours un accès en ligne (plus un paiement si vous utilisez un service commercial comme Okteto), ou vous devez écrire des scripts qui omettent ou bloquent des services, un autre. paiement en complexité
Cet inconvénient concerne principalement le mode de développement: il ne prévoit pas nécessairement des coûts de logement plus élevés, mais c'est une possibilité.
Vivre dans des conteneurs
En général, l'environnement de développement local ressemble beaucoup à tout projet utilisant une machine virtuelle pour le mode de développement (comme les projets Vagrant). Il partage les mêmes inconvénients:
- vous devez configurer la télécommande de débogage pour parcourir le code;
- Il existe une étape supplémentaire pour exécuter des commandes dans vm / container et elles s'exécutent plus lentement.
Courbes d'apprentissage
Si vous introduisez de nouvelles technologies dans votre projet, au moins une personne devra apprendre chacune d'elles. En particulier: Docker Compose, API Gateway (par exemple, Traefik) et probablement Kubernetes.
En fonction des services que vous décidez d'inclure dans votre projet et de la composition de votre équipe, vous pouvez introduire d'autres courbes d'apprentissage, telles que RabbitMQ, Redis, WebSockets, etc.
En outre, le processus de déploiement va changer À un stade antérieur, nous avons finalement implémenté des fonctionnalités de développement sophistiquées telles que les implémentations à chaud et l'absence de points de défaillance uniques, mais cela a demandé beaucoup d'efforts et beaucoup de scripts spécifiques au fournisseur.
La conteneurisation facilite beaucoup de choses comme celles-ci (et offre l'avantage d'être assez portable parmi les hébergeurs), mais elle a toujours le coût initial pour mettre en œuvre quelque chose et apprendre comment tout fonctionne.
Alternatives
Au lieu d'adopter une architecture similaire à microservices, vous pouvez l'éviter ou la différer de plusieurs manières, en fonction du problème rencontré par votre projet.
Au lieu d'utiliser des travailleurs de fond. , vous pouvez télécharger ces tâches sur un service hébergé tel que Serverless ou AWS Lambda. De même, de nombreux centres de données offrent des solutions gérées, non seulement pour la persistance de la base de données, mais également pour des services tels que RabbitMQ. Vous pouvez également trouver des services commerciaux distincts pour WebSockets et l'authentification.
Bien sûr, vous pouvez également aller dans la direction opposée, en exécutant des serveurs qui font le nécessaire, avec ou sans passerelle API, avec ou sans conteneurisation, avec ou sans surveillance.
J'ai utilisé webstack-micro comme terrain de jeu pour tenter de trouver un équilibre entre fonctionnalité et complexité pouvant convenir à des équipes relativement petites.
Configurez Traefik en tant que contrôleur API Gateway / Ingress. Traefik interagit avec l'un des exemples de services pour imposer une authentification centralisée pour tout itinéraire marqué comme protégé, ce qui nécessite la connexion de l'utilisateur ou un jeton JWT. L'exemple inclut également la plomberie pour la diffusion en arrière-plan, avec des exemples d'utilisations de travailleurs d'arrière-plan qui envoient des résultats via WebSockets.
Crédit pour l'oeuvre:
- https: // unsplash .com / photos / ECjHeJtRznQ
- https://unsplash.com/photos/afq5-t0ZGtQ
- https : //unsplash.com/photos/ZihPQeQR2wM
- https://unsplash.com/photos/j_Ckc_r25zc
[ad_2]