PC & Mobile

Modèle de conception de micro-service: décomposition par dépendance (DDD)

Modèle de conception de micro-service: décomposition par dépendance (DDD)


Lorsque vous construisez de grands systèmes, vous devez inévitablement vous intégrer aux bibliothèques et aux apis tiers. Souvent, vous trouvez des kits de développement client (SDK) qui simplifient énormément le travail d’intégration, mais ils exposent également de nombreuses fonctionnalités dont vous n’auriez probablement pas besoin ou que vous utiliserez jamais. Néanmoins, le code (et ses dépendances!) Est toujours là, en sommeil sur vos serveurs.

Cela conduit à des générations de ballonnements, des démarrages lents à froid, des configurations de projet complexes et une exposition étendue aux vulnérabilités de sécurité.

Il existe certaines solutions à ce problème pour le monde côté client, telles que le "shake d'arbre" de Webpack qui regroupe uniquement le code que votre application utilise pour être envoyé au client, mais même ces solutions ne sont pas optimisées pour le serveur. monde.

Dans le monde des serveurs sans serveur, les paquetages et les dépendances d'infrastructure sont installés et mis en cache dans la couche conteneur, mais à chaque exécution, un nouveau processus est généré où le gestionnaire de fonctions est réellement exécuté. Cela signifie que pour chaque exécution de fonction, tous les modules importés de manière synchrone doivent être évalués et exécutés, ainsi que toutes les connexions et tous les appels de base de données d'initialisation, avant que votre logique métier ne s'exécute. Cela tue les performances - et si votre fournisseur de cloud calcule les coûts en fonction de l’utilisation du processeur, vous risquez également de tuer les cartes de crédit. Pour les applications à forte dépendance, l'utilisation de serveurs est beaucoup plus logique que sans serveur, car vous réalisez des économies d'échelle.

Des constructions allégées signifient également une intégration continue plus rapide / une livraison continue (CI / CD), ce qui signifie que vos développeurs passent moins de temps à attendre des versions et plus de temps à résoudre leurs problèmes. Nous avons des dizaines de builds fonctionnant en parallèle à tout moment - chaque fois que nous pouvons réduire la base de démarrage des conteneurs est énorme.

Maintenant, tout n’est pas à propos de CI / CD, mais aussi du temps de développement et du temps de test. Avec de nombreux packages NPM importés de manière synchrone, le temps de démarrage à froid de votre application est complètement écrasé.

Vous souhaitez utiliser nodemon dans votre flux de travail de développement? Oublie. Si vous devez attendre 5 à 10 secondes pour que votre application démarre, il n’est pas possible que vous exécutiez vos applications localement en mode veille.

Voulez-vous utiliser la plaisanterie plutôt que le moka? En aucune façon. Mocha exécute les tests de manière synchrone et exploite le cache de modules intégré du noeud afin que les importations soient effectuées une seule fois. Avec Jest, chaque suite génère un nouveau processus qui déclenche simultanément la résolution de tous les modules et verrouille votre unité centrale.

Il existe certaines solutions au problème, telles que l’évaluation paresseuse, mais même à l’exécution toutes les dépendances doivent être résolues - à un moment donné, vous payez le prix du fer. C'est un problème très réel dans JavasScript, d'autant plus que nous entrons dans l'ère du serveur.

Ainsi, dans le cadre de la série Faire fondre le monolithe, je souhaitais mettre en évidence et présenter un autre motif que j’ai reconnu à l’état sauvage, que j’aime appeler «décomposition pilotée par la dépendance» ou DDD.

Extrayez des composants sans état avec une cohésion élevée, un couplage faible et des dépendances coûteuses ou non fondées dans des fonctions sans serveur. Doublez le domaine principal et maintenez-le mince et concentré. Résumé des appendices.

Maintenant, si vous pensez que c’est l’un des qualificatifs - de quoi parle ce gars - vous aurez raison. C’est une bouchée et, à vrai dire, ces composants sont un peu comme des licornes. Ils sont plutôt rares et constituent plutôt une optimisation, mais il est toujours bon d’avoir ces outils disponibles dans votre ceinture d’outils.

Ces composants sont généralement des composants d'ordre supérieur: ils encapsulent des packages ou des utilitaires existants, mais avec certaines hypothèses ou conventions incorporées utilisées par votre équipe, qui facilitent leur utilisation.

Voici un exemple.

Génération PDF. Pendant un moment, nous avons utilisé PhantomJS. Phantom avait besoin d'un binaire indépendant pour être installé et exécuté sur la machine, suivi d'une bibliothèque cliente pour que le noeud puisse y accéder. Plus tard, PhantomJS est devenu obsolète et la bibliothèque de génération de PDF préférée est devenue wkhtmltopdf avec essentiellement le même binaire sous-jacent. À un moment donné, nos quatre packages se trouvaient dans notre référentiel principal. À ce moment-là, il s’agissait des seuls packages installés nécessitant une recompilation des binaires natifs lors de l’installation. Cela a ajouté 45 bonnes secondes à notre construction (à chaque construction, chaque test). conteneur!) pour un total général de 2 points finaux qui sont très rarement utilisés. Ce n’est qu’un des nombreux composants que nous avons pu intégrer au cœur pour accélérer nos temps de construction et gagner en rapidité d’ingénierie.

Encore une fois, l’essentiel de ce modèle consiste à optimiser la gestion de vos dépendances au sein de vos services essentiels avec état. Échangez un saut de réseau contre des «composants de niche» au sein de votre nuage contre un ralentissement de la vitesse d'ingénierie - ceux-ci se cumulent Nous sommes conscients de la réduction de la disponibilité en ce qui concerne les microservices à chaîne synchrone. C'est bien.

Pouvez-vous penser à d 'autres? Faites le moi savoir! Parlons-en dans les commentaires ci-dessous avant de nous passer d’un serveur à l’autre!

Merci pour la lecture!

Ben Lugavere est ingénieur en chef et architecte chez Boxed Wholesale, où il développe principalement à l'aide de JavaScript et de TypeScript. Ben écrit sur tout ce qui concerne JavaScript, la conception et l'architecture du système. Vous pouvez le trouver sur twitter à l'adresse @benlugavere.

Suivez-moi sur support pour plus d'articles ou sur github pour voir mes contributions open source!

Afficher plus

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Articles similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bouton retour en haut de la page
Fermer