De nombreuses applications modernes doivent être développées dans toute l'entreprise, parfois même sur Internet. Chaque application doit répondre aux exigences d'évolutivité, de disponibilité, de sécurité, de fiabilité et de résilience.
Dans cet article, je présenterai quelques modèles de conception qui peuvent facilement vous aider à atteindre les capacités ci-dessus. Je vais couvrir chaque modèle, comment utiliser ce modèle dans le cloud, et quand l'utiliser et quand non.
Certains de ces modèles ne sont pas si nouveaux, mais sont très utiles dans le monde du cloud Internet d'aujourd'hui.
Voici une liste des modèles dont je parlerai dans cet article:
- Disjoncteur
- Ségrégation des responsabilités de commande et de requête (CQRS)
- Sourcing événementiel
- Side-car
- Backend pour Frontend
- Étrangleur
Alors, commençons.
1. Disjoncteur
Les systèmes distribués doivent être conçus en tenant compte des pannes. Il existe de nos jours des microservices dans le monde, et ces services dépendent principalement d'autres services distants. Ces services à distance peuvent ne pas répondre à temps pour diverses raisons telles que le réseau, le téléchargement d'applications, etc. Dans la plupart des cas, la mise en œuvre de nouvelles tentatives devrait permettre de résoudre les problèmes.
Mais parfois, il peut y avoir de graves problèmes tels que la dégradation des services ou une défaillance complète des services en soi. Cela n'a aucun sens de continuer à essayer dans de tels cas. Dans ce cas, le modèle de disjoncteur peut être utile.
Le schéma ci-dessus montre une implémentation d'un schéma de disjoncteur où lorsque le service 1 se rend compte que le service appelant 2 a des échecs / délais continus au lieu de réessayer, le service 1 déconnecte les appels au service 2 et renvoie une réponse en cas de panne.
Il existe des bibliothèques open source populaires comme Netflix Hystrix
ou Reselience4J qui peuvent être utilisées pour implémenter ce modèle très facilement.
Si vous utilisez des passerelles API ou des proxys
comme Envoy , cela peut être réalisé au niveau du proxy lui-même.
Remarque:Il est très important que suffisamment de journaux et d'avertissements soient mis en œuvre lorsque la chaîne est ouverte pour garder une trace des demandes reçues pendant cette période et que l'équipe des opérations en soit consciente.
Vous pouvez également implémenter un demi-disjoncteur pour continuer à servir les clients dont le service est altéré.
Quand utiliser ce modèle
- Lorsqu'un service dépend d'un autre service distant, et dans certains scénarios, il est susceptible d'échouer.
- Lorsque le service a une très forte dépendance (comme les services de données de base).
Quand ne pas utiliser ce modèle
- Lorsqu'il s'agit de dépendances locales, un disjoncteur peut créer une surcharge.
2. Command and Query Responsibility Segregation (CQRS) ( (CQRS))
CQRS est un modèle très utile pour les applications d'entrepôt de données modernes. Il est basé sur le principe de la séparation des opérations de lecture (requête) et d'écriture / mise à jour (commande) dans le magasin de données.
Supposons que vous construisiez une application qui nécessite de stocker des données dans une base de données comme MySQL / PostgreSQL, etc. Comme chacun sait, lors de l'écriture de données dans le stockage, une opération doit passer par plusieurs étapes - par exemple, la validation, la modélisation et la persistance - et par conséquent, les opérations d'écriture / mise à jour typiques prennent plus de temps que les simples opérations de lecture.
Lorsque vous utilisez une seule banque de données pour effectuer des opérations de lecture et d'écriture en même temps et à grande échelle, vous pouvez commencer à voir des problèmes de performances.
Dans de tels cas, le modèle CQRS peut être utile. Le modèle CQRS suggère d'utiliser différents modèles de données pour les opérations de lecture et d'écriture. Certaines variantes suggèrent également d'utiliser des magasins de données séparés pour ces modèles.
Remarque: la plupart des bases de données PaaS offrent aujourd'hui la possibilité de créer des réplicas lisibles ( Google Cloud SQL , Azure SQL DB , Amazon RDS
, etc.) des magasins de données, ce qui facilite grandement la réplication des données.
De nombreuses bases de données d'entreprise offrent également cette fonctionnalité si vous utilisez des bases de données locales.
Remarque: de nos jours, certaines personnes choisissent également d'implémenter des répliques lisibles sous forme de bases de données NoSQL rapides et performantes telles que MongoDB et Elasticsearch.
Quand utiliser ce modèle
- Lorsque vous envisagez de mettre à l'échelle une application qui attend une énorme quantité de lectures et d'écritures
- Lorsque vous souhaitez configurer les opérations de lecture et d'écriture séparément.
- Lorsque vos opérations de lecture sont proches du réel ou finalement cohérentes.
Quand ne pas utiliser ce modèle
- Lorsque vous créez une application CRUD ordinaire qui ne s'attend pas à une énorme quantité de lectures et d'écritures en une seule fois.
3. Recherche d'événements
Une source d'événements est un modèle de conception intéressant dans lequel une séquence d'événements de domaine est stockée sous forme de journal, et une vue de journal agrégée donne l'état actuel de l'application.
Ce modèle est couramment utilisé pour les systèmes qui ne peuvent pas se permettre de verrouiller le stockage des données et qui ont besoin de conserver l'historique des audits et des événements - par exemple, des applications telles que les hôtels / conférences / sièges.
Étant donné un système de réservation de chambre d'hôtel où les utilisateurs sont censés réserver ou annuler une réservation. Ici, vous devez enregistrer votre réservation et votre annulation comme une série d'événements. Les salles disponibles sont présentées dans un résumé avant chaque réservation en examinant les journaux d'événements.
Remarque:La plupart des fournisseurs de services cloud prennent en charge les services de messagerie tels que Google Pub / Sub, Azure Service Bus, AWS SQS, etc. Ces services, associés à des magasins de données cohérents solides, peuvent être utilisés pour mettre en œuvre ce schéma.
Quand utiliser ce modèle
- Lorsque les opérations CRUD normales ne sont pas assez bonnes pour répondre aux exigences
- Convient généralement aux systèmes de réservation de sièges tels que les bus, les trains, les conférences, les cinémas, etc. - ou pour les systèmes de commerce électronique, qui consistent en des activités telles que les transactions de panier, les paiements, etc.
- Lorsqu'il est nécessaire de procéder à un audit et à une relecture d'événements solides pour créer l'état actuel et passé des applications.
Quand ne pas utiliser ce modèle
- Lorsque les opérations CRUD normales sont suffisamment bonnes pour répondre aux besoins des utilisateurs.
4. Sidecar (modèle de conception de side-car)
Le modèle Sidecar est devenu populaire avec l'avènement des microservices. Dans ce schéma, le composant d'application est déployé dans un processus ou un conteneur distinct. Cela aide à réaliser l'abstraction et l'encapsulation.
Envoy Proxy est l'un des serveurs proxy sidecar les plus populaires et est largement utilisé. Il vous aide à découpler les principales fonctionnalités de l'application en utilisant une machine latérale pour isoler les fonctions courantes telles que la mise en réseau, l'observabilité et la sécurité.
Ce type de side-car peut aider le type abstrait de communication L4 / L7. Les side-cars comme Envoy Proxies contribuent même à améliorer la sécurité en implémentant le TLS mutuel.
Vous pouvez l'utiliser en combinaison avec une grille de services pour améliorer la connectivité et la sécurité entre les différents microservices. Vous pouvez en savoir plus à ce sujet dans mon article précédent .
Quand utiliser ce modèle
- Lorsque vous avez affaire à de nombreux microservices hétérogènes dans un portefeuille de produits.
- Lorsqu'il s'agit d'applications héritées qui ont tendance à ne pas gérer les défis d'interopérabilité et de sécurité de la nouvelle ère.
Quand ne pas utiliser ce modèle
- Lorsque vous avez affaire à un nombre limité de services qui doivent communiquer entre eux.
- Petites applications où le déploiement d'un fauteuil roulant latéral peut être peu économique ou peu pratique à utiliser
5. Backend-for-Front (BFF)
Dans un cycle de développement de produit typique, les ingénieurs back-end sont responsables de la création de services qui interagissent avec les entrepôts de données, tandis que les ingénieurs front-end se chargent de créer des interfaces utilisateur. De nos jours, les applications doivent être conçues en pensant à la fois aux mobiles et aux ordinateurs de bureau.
Alors que l'écart entre les appareils mobiles et de bureau se resserre en termes de matériel, la connectivité et l'utilisation restent un défi pour les appareils mobiles.
Dans de tels scénarios, les modèles BFF deviennent très pratiques. Ici, vous devez créer / configurer des services internes pour un frontal particulier.
Pour optimiser les performances des clients mobiles, vous souhaiterez peut-être créer un service principal distinct qui répond par des réponses légères et paginées.
Vous pouvez également utiliser ce modèle pour agréger divers services afin de réduire la communication de données entre le back-end et le front-end.
Remarque: ces jours-ci, si vous utilisez une passerelle API, le modèle BFF peut être facilement implémenté dans la passerelle elle-même et vous n'aurez pas besoin de servir des services séparés.
Quand utiliser ce modèle
- Lorsque vous souhaitez fournir un produit / service à divers clients tels que les clients de bureau et mobiles.
- Lorsque vous souhaitez optimiser votre réponse pour un type de client spécifique.
- Lorsque vous souhaitez réduire le chat entre les clients mobiles et différents services.
- , .
- , .
6. Strangler ( )
Si vous travaillez pour une organisation qui est sur la voie de la modernisation des applications, le modèle de conception Strangler est un must. Le modèle Strangler signifie créer une superposition de façade au-dessus de votre héritage et de votre nouvelle application, donnant aux consommateurs la possibilité de regarder les choses de manière objective.
Ce modèle sépare les clients de l'activité de migration entre les anciennes et les nouvelles parties de l'application.
Remarque: dans une organisation informatique typique, si vous migrez d'un système ERP vers un autre, ce type de schéma sera extrêmement utile. Si vous utilisez l'API de passerelle, il sera plus facile de l'implémenter dans la passerelle proxy elle-même.
Vous devez décider si vous souhaitez conserver le complément (façade) à la fin de la migration ou le supprimer.
Quand utiliser ce modèle
- Lorsque vous migrez ou mettez à niveau une application complexe et hautement dépendante telle qu'une migration ERP
Quand ne pas utiliser ce modèle
- Lorsque la migration est facile et que le remplacement direct est la meilleure option.