Cet article décrit une série d'approches architecturales que vous pouvez utiliser pour créer des plate-formes de commerce évolutives à l'aide de microservices dans Google Cloud.
Exigences relatives au commerce de détail et microservices
Les charges de travail relatives au commerce de détail nécessitent un certain nombre de fonctionnalités cloud natives afin de répondre à la demande des appareils et des plates-formes grand public toujours plus nombreux :
- En règle générale, ces déploiements doivent être multirégionaux afin de toucher une clientèle internationale.
- Ils doivent être compatibles, dans une certaine mesure, avec l'autoscaling ou le scaling planifié, en s'adaptant pour répondre aux pics de demande pendant les périodes chargées ou pour réduire les coûts d'infrastructure lorsque la demande est faible.
- Les déploiements relatifs au commerce de détail doivent pouvoir fournir des fonctionnalités aux clients de manière rapide et efficace afin de répondre à l'évolution du marché.
- Les déploiements relatifs au commerce de détail doivent bénéficier d'une infrastructure gérée pour permettre aux développeurs de se concentrer sur les fonctionnalités destinées aux clients.
- Enfin, ces déploiements doivent être sécurisés et gérés de manière centralisée.
Les microservices sont parfaitement adaptés à toutes ces exigences. Des microservices individuels peuvent se déployer et s'adapter indépendamment les uns des autres, ce qui vous permet de fournir rapidement de nouvelles fonctionnalités. Ces services peuvent être petits, modulaires, faiblement couplés, et organisés en fonction des capacités et des besoins spécifiques de votre entreprise. Ils peuvent exploiter la recherche de services et utiliser des mécanismes simples (tels que HTTP) pour faciliter la connectivité avec une grande variété d'appareils.
Architecture backend
Pour les charges de travail relatives au commerce de détail, organisez les microservices en fonctions discrètes (nécessaires à la création d'une interface utilisateur destinée aux clients). Par exemple, vous pouvez configurer un service de métadonnées produit qui récupère (et éventuellement, met en cache) les métadonnées d'un produit particulier. Vous pouvez également configurer un service de tarifs par produit qui récupère le prix d'un produit pour un client donné.
Vos microservices sont exposés aux clients via des API REST, et vos applications clientes communiquent avec les API REST via une passerelle API.
Le schéma ci-dessous illustre un exemple d'architecture de microservices backend axée sur le commerce.
Architecture frontale
L'interface utilisateur destinée aux clients dans vos charges de travail relatives au commerce de détail comprend généralement des applications Web réactives (souvent distribuées sous forme de progressive web apps) et éventuellement des applications mobiles natives. En plus de l'architecture backend illustrée précédemment, construisez vos applications en associant plusieurs composants d'interface qui correspondent aux API et aux services backend et communiquent avec eux.
Le schéma ci-dessous illustre un exemple d'interface d'application Web axée sur le commerce.
Stockage de données
Les charges de travail relatives au commerce de détail doivent présenter plusieurs catégories de données, y compris les suivantes :
- Catalogue de produits : attributs de produit, tels que le nom, la description, la couleur et la taille.
- Profils des acheteurs : données client, telles que le nom, l'âge, les préférences et les adresses de facturation et d'expédition.
- Transactions des acheteurs : informations liées aux achats des clients, telles que les articles achetés et la date d'achat.
- Données relatives aux flux de clics : informations permettant de suivre le parcours d'un client sur le site Web.
- Images et vidéos du produit : supports multimédias relatifs à un produit particulier, y compris le contenu propriétaire et le contenu fourni par le client.
- Notes et avis : opinions et commentaires des clients sur un produit.
- Inventaire des produits : données indiquant si un article est en stock ainsi que la date de réapprovisionnement prévue.
Chaque catégorie de données peut être mise en correspondance avec un mécanisme de stockage Google Cloud, comme indiqué dans le tableau suivant.
| Objet | Non relationnel | Relationnel | Entrepôt | ||
|---|---|---|---|---|---|
| Cloud Storage | Cloud Datastore | Cloud Bigtable | Cloud SQL | Cloud Spanner | BigQuery |
| Images Vidéos |
Catalogue Profils Factures |
Flux de clics Tarification |
Transactions Inventaire Notes |
Transactions Inventaire Notes |
Analytics Entreposage |
Catalogue de produits
Dans les catalogues de produits, les produits sont associés à un ensemble d'attributs : nom, description, etc. Toutefois, à mesure que la diversité de votre catalogue de produits augmente, le nombre d'attributs distincts croît en conséquence. Chaque nouvelle catégorie de produits possède son propre ensemble d'attributs pouvant être utilisés pour les opérations de recherche ou de filtrage, par taille et par couleur de l'article, ou par type et modèle de l'article.
Pour les catalogues de produits, l'option de stockage la plus appropriée constitue donc une base de données NoSQL axée documents qui est dotée d'un schéma flexible et qui peut stocker des attributs par catégorie ou par objet. Datastore est une base de données NoSQL entièrement gérée et axée documents, compatible avec ce cas d'utilisation. Dans Datastore, vous stockez des objets en tant qu'entités et chaque entité accepte des paires clé/valeur imbriquées, d'une manière similaire à la structure du format JSON. Datastore est disponible dans plusieurs régions Google Cloud et s'exécute en tant que service permanent.
Supports multimédias associés au produit
Chaque produit d'un catalogue de produits peut comporter des images ou des vidéos propriétaires, ainsi que des images ou des vidéos fournies par le client. Vous pouvez conserver ces types de ressources dans un système de stockage d'objets évolutif, capable de distribuer ces ressources directement aux applications Web ou mobiles. Cloud Storage est un service de stockage d'objets géré capable de diffuser des données dans plusieurs régions. Cloud Storage offre différents niveaux d'accès aux données et de disponibilité des données en fonction de vos besoins. Pour des performances élevées, Cloud CDN exploite les emplacements en périphérie du réseau Google distribués à l'échelle mondiale pour accélérer la diffusion du contenu à partir de Cloud Storage. Ainsi, vos éléments statiques sont situés le plus près possible des utilisateurs finaux afin de minimiser la latence de téléchargement.
Profils des acheteurs
Les profils des acheteurs disposent d'un ensemble cohérent d'attributs et sont souvent multidimensionnels. Par exemple, certains de vos clients peuvent avoir plusieurs adresses de livraison ou méthodes de paiement, chacune avec sa propre adresse de facturation.
Vous pouvez stocker les profils des acheteurs dans des bases de données relationnelles à l'aide de plusieurs tables. Toutefois, vous pouvez également utiliser des bases de données NoSQL axées sur les documents pour stocker des profils d'acheteurs. Ainsi, ils sont conservés sous la forme d'objets riches et uniques contenant toutes les données d'un client spécifique. Datastore est une base de données NoSQL entièrement gérée et axée documents qui est compatible avec ce cas d'utilisation.
Notes et avis
Les notes et avis sur les produits laissés par les clients consistent en des ensembles de données relativement simples. Vous pouvez conserver ces informations à l'aide de différents mécanismes de stockage. Il est courant d'utiliser des schémas relationnels contenant des champs tels que l'ID de produit, l'ID de client, la valeur de la note et le texte contenu dans l'avis. Vous pouvez stocker ces données à l'aide de Cloud SQL ou de Cloud Spanner. Dans la plupart des cas d'utilisation, Cloud SQL représente le système le plus approprié pour stocker des données concernant les notes et avis. Si vos applications nécessitent un débit transactionnel supérieur et une évolutivité horizontale, il est recommandé d'utiliser Spanner. Pour en savoir plus sur le service de base de données à utiliser, consultez la page sur les produits de stockage.
Transactions et factures
Comme pour les notes et les avis, vous pouvez conserver des transactions et des factures concernant l'acheteur, ainsi que les détails des commandes, à l'aide de différents mécanismes de stockage. Les transactions doivent être stockées dans des systèmes de base de données compatibles avec la sémantique ACID et en particulier avec la possibilité de valider des écritures de manière atomique. Datastore, Cloud SQL et Spanner sont tous compatibles avec les opérations atomiques. Dans la plupart des cas d'utilisation, les systèmes relationnels sont parfaitement adaptés pour les transactions, car les données gardent une cohérence structurelle d'une écriture à l'autre. Le choix du système de stockage dépend en grande partie de vos connaissances du système SQL ou NoSQL et de la possibilité de personnaliser les applications en fonction de la base de données choisie.
Les factures peuvent également être stockées à l'aide de bases de données NoSQL ou relationnelles. Les cas d'utilisation en aval doivent déterminer le système que vous choisissez. Dans les charges de travail commerciales modernes, les bases de données NoSQL axées documents telles que Datastore sont souvent utilisées pour conserver des factures ou des détails de commande, car l'intégralité de la facture peut être stockée sous la forme d'un objet riche unique. Cloud SQL ou Spanner peuvent également être appropriés aux charges de travail commerciales plus traditionnelles.
Pour en savoir plus sur le service de base de données à utiliser pour les factures et les transactions, consultez la page dédiée aux produits de stockage.
Si votre environnement est entièrement basé sur le cloud, vos données de transaction et de facturation résident entièrement dans l'infrastructure cloud. Par ailleurs, si vous travaillez dans un environnement hybride, vous devez synchroniser les données entre l'environnement cloud et votre environnement sur site. Dans le scénario hybride, les données de transaction et de facturation résident généralement dans l'infrastructure sur site. Dans ce cas, vous pouvez synchroniser les systèmes de backend avec l'infrastructure de données cloud à l'aide d'une combinaison d'applications personnalisées, de Pub/Sub ou de réplication de base de données.
Données relatives aux flux de clics
Les données relatives au trafic client sont souvent enregistrées par le biais de solutions analytiques telles que Google Analytics. Toutefois, vous souhaitez peut-être collecter ces données de navigation (données de flux de clics) en temps réel.
Il existe de nombreuses méthodes permettant d'enregistrer les données de flux de clics. L'une de ces méthodes consiste à utiliser le suivi de pixels sans serveur à l'aide de Google Cloud. Les ensembles de données destinés au suivi des flux de clics sont souvent très volumineux et utilisés comme sources pour le machine learning ou l'analyse prédictive. Ce type de données est généralement stocké dans des systèmes NoSQL orientés colonnes tels que Bigtable. Bigtable est compatible avec les ensembles de données à grande échelle (jusqu'à plusieurs centaines de pétaoctets) et offre une faible latence et un débit élevé, ce qui est utile pour ce cas d'utilisation.
Inventaire de produits
Les données relatives à la disponibilité d'un produit sont d'une importance cruciale pour l'expérience client globale. Les données d'inventaire sont souvent constituées d'ensembles de données contenant le code produit, l'inventaire actuel et la date prévue pour le réassort. Toutefois, compte tenu de la manière dont ces données sont souvent utilisées dans les applications, le mécanisme de stockage doit accepter les transactions et les opérations atomiques afin de refléter avec précision les niveaux d'inventaire. Datastore, Cloud SQL et Spanner sont tous compatibles avec les opérations atomiques. Dans la plupart des cas d'utilisation, les systèmes relationnels sont parfaitement adaptés pour les données d'inventaire, car celles-ci sont structurées de manière cohérente. Pour en savoir plus sur le service de base de données à utiliser, consultez la page sur les produits de stockage.
Si votre environnement est entièrement basé sur le cloud, les données d'inventaire résident dans l'infrastructure cloud. Si vous travaillez dans un environnement hybride, vous devez synchroniser les données entre l'environnement cloud et votre environnement sur site. Dans le scénario hybride, les données d'inventaire résident généralement dans l'infrastructure sur site. Dans ce cas, vous pouvez synchroniser les systèmes de backend avec l'infrastructure de données cloud à l'aide d'une combinaison d'applications personnalisées, de Pub/Sub ou de réplication de base de données.
Architectures de déploiement
Lorsque vous utilisez Google Cloud, vous déployez généralement des microservices à l'aide de Cloud Run ou de Google Kubernetes Engine. Cloud Run est une plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs sans état accessibles via des requêtes Web ou des événements Pub/Sub. GKE s'appuie sur Kubernetes, un mécanisme Open Source d'orchestration de conteneurs et de gestion des clusters. Le choix de la plate-forme pour votre déploiement dépend du niveau de flexibilité dont vous avez besoin et de la complexité de votre infrastructure applicative.
Pour plus d'informations, consultez la page sur les options de calcul. Dans ce guide, nous vous présentons les deux options de déploiement.
Utiliser Cloud Run
Le schéma suivant illustre un exemple de déploiement de microservices à l'aide de Cloud Run.
Cloud Run adapte automatiquement le nombre d'instances exécutant vos applications en fonction du trafic entrant. Lorsque vous déployez votre application dans une architecture de microservices à l'aide de Cloud Run, votre application est empaquetée en tant que conteneur et déployée en tant que service. Les services peuvent s'exécuter sur plusieurs instances de conteneur et évoluer indépendamment. Cloud Run provisionne automatiquement les ressources d'équilibrage de charge et permet de gérer les révisions de microservices individuels ainsi que de répartir le trafic entre les versions.
Cloud Run étant basé sur Knative, vous pouvez exécuter des conteneurs entièrement gérés dans Cloud Run, dans votre cluster Google Kubernetes Engine ou sur site avec Cloud Run pour Anthos. Les services Cloud Run sont déployés dans une seule région ou dans un seul espace de noms de cluster GKE. Ils sont automatiquement répliqués dans plusieurs zones de la région dans laquelle ils se trouvent pour la redondance et le basculement. Un même projet Google Cloud peut exécuter de nombreux services dans différentes régions ou différents clusters GKE.
Vous devez provisionner et gérer une infrastructure de stockage de données séparément de Cloud Run. Par exemple, votre application dans Cloud Run peut se connecter à une base de données PostgreSQL gérée par Cloud SQL pour le stockage de données relationnelles.
Le schéma suivant montre un exemple d'architecture de déploiement Cloud Run multirégional.
Utiliser GKE
Le schéma suivant illustre un exemple de déploiement incluant des microservices à l'aide de GKE.
Lorsque vous utilisez GKE, chaque microservice dispose d'un cycle de vie de développement et de déploiement distinct, et est empaqueté sous la forme d'un conteneur Docker. Pour déployer ce conteneur en tant que pod et service Kubernetes, optez pour l'une des méthodes suivantes :
- Commandes impératives (à l'aide de kubectl)
- Spécifications déclaratives (déploiements Kubernetes)
- Empaqueté sous la forme de graphiques Helm
GKE accepte l'autoscaling des pods en fonction de l'utilisation du processeur par le biais de l'autoscaler horizontal de pods. En outre, les clusters GKE acceptent également l'autoscaling à l'aide de l'autoscaler de cluster GKE, qui redimensionne automatiquement les clusters si les ressources sont saturées ou sous-exploitées.
Les clusters GKE sont des ressources régionales. Pour les déploiements nécessitant une haute disponibilité, vous devez créer des déploiements dans plusieurs zones. Pour en savoir plus, consultez la page sur les clusters régionaux.
Pour les déploiements qui doivent toucher une clientèle internationale, déployez plusieurs clusters GKE au sein d'un même projet, sur la base d'un par région. Le stockage des données pour chaque microservice est fourni et exploité à partir du même projet que celui contenant les clusters GKE.
Étape suivante
- Guides d'utilisation sur Cloud Run
- Clusters GKE régionaux
- Explorez des architectures de référence, des schémas, des tutoriels et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.