La plupart des systèmes e-commerce regroupent, sur un même serveur, le Front office et le back office.
Bon, quand on se lance, il est complètement normal de tout mettre sur un seul serveur : on n’a pas l’argent pour se payer plusieurs machines. Et puis le trafic des premiers mois ne pose pas vraiment de problème…
Par la suite, c’est une autre histoire.
Le site e-commerce représente un chiffre d’affaire concéquent… Et la moindre interruption de service met en danger l’équilibre de « la petite entreprise e-commerce ».
Le Front office doit donc être en ligne 24h sur 24, 7 jours sur 7.
Pour garantir ce résultat, il faut isoler le Front au maximum.
C’est le meilleur moyen de garantir que le front est « centré » sur sa mission : répondre, dans un temps très court, aux requêtes des internautes.
Le back office n’entre pas dans cette mission… Il doit donc être découplé du Front.
Une première étape peut être de monter une architecture à trois niveaux :
- Le Front office, composé d’un ou plusieurs serveurs Web
- La base de données, hébergée sur son propre serveur
- Le Back office, hébergé sur un autre serveur
C’est une bonne solution, qui a l’avantage de pouvoir être mise en oeuvre pratiquement sans modifier les solutions e-commerce du marché.
Avantages :
Les programmes back office ne pénalisent plus le Front.
Limites majeures :
Si une page du back sollicite beaucoup la base de données, les temps de réponses du front seront bien impactés par l’utilisation du back…
Autre limite : toute bêtise sur le back sera instantannément visible sur le Front.
Et puis, pour un site plus pro, on souhaite un découplage plus fort :
On veut, par exemple, mettre à jour le catalogue, et pouvoir « recetter » les modifications, avant qu’elles soient en ligne.
L’étape d’après consiste donc à avoir un ensemble front complet, composé de serveurs front, avec une base de données dédiée.
Le back office est complètement séparé, avec sa propre base de données.
Si on part d’une solution e-commerce toute faite, on peut arriver à ce résultat assez facilement…
Toute la question, sur un tel système, c’est : comment synchroniser les données entre les bases du Front et du Back.
Là, pas de solution magique : il va faloir développer une couche de synchronisation.
Et ça, ça sera l’occasion de pleins d’autres billets…
François,
Comme je te rejoins !
Depuis 8 ans c’est en effet l’architecture que nous avons déployé chez Oxatis. Nous avons quelque peu raffiné le système. Quelques pistes, sans tout dévoiler:
– En plus des back et des front, on ajoute des serveurs de tâches qui servent par exemple à faire tous travaux longs ou asynchrones Par exemple t le travail en fin de commande (envoi des mail, décrémentation des stocks, envoi de mail de seuil de stock dépassé, préparation des étapes d’une commande, etc.) ou alors les taches d’export vers les moteurs marchands, les taches de mises à jour massives, les traitements par lots, etc. Mieux on fait communiquer tout cela par des queues en base de données, comme cela si, par exemple, les mails serveurs plantent et bien rien ne se perd, c’est simplement traité lorsqu’ils reprennent vie.
– En ce qui concerne les bases de données, on double, triple voir quadruple le tout en optimisant les codes sources pour faire en sorte que les opérations qui ne font que lire la base (affichage d’un catalogue, remises dynamiques, promotions…) se fassent sur les serveurs auto-répliqués et que les opérations d’écriture soient elles traitées par le serveur principal.
– On multiplie aussi les serveurs de front et de back de façon à ce que si un serveur claque la vie continue sur les autres et que les visiteurs puissent poursuivre leurs achats sans problème.
Comme tu le dis cela demande plus de peine, de codage et de moyens, mais le résultat est à la hauteur tant en tenue de charge qu’en fiabilité. Au final cela donne une fiabilité de 99,96% sur 8 ans http://www.oxatis.com/OxMonitoring.asp
A noter que cette valeur est indiquée changement de logiciel et de matériel compris car quand on ajoute de nouveaux serveurs les autres continuent à servir puis sont gentiment déconnectés. Si on finalise cela par un code source unique placé sur le SAN, on peut envisager des mises à jour avec des interruptions qui se comptent en minutes voir en secondes. Chez Oxatis nous avons dépassé les 300 mises à jour logiciel en 3 ans (voir ici : http://www.oxatis.com/OxNewsBoard.asp )
Bref, tout le monde a le droit au meilleur de la technologie lorsqu’il s’agit de faire du business !
Marc Schillaci
On rencontre aussi une autre architecture, un peu différente : on ne sépare pas le front, le back et la BDD, mais les couples (front + bdd front) et (back + bdd back)
Cela permet à coup sur de travailler sur le back de manière parfois conséquente (import de gros fichier pour mise à jour de tarif promo en masse, par exemple) sans impacter les performances des requêtes du front.
Cela permet aussi de scinder le catalogue en deux : un très gros catalogue sur le back, contenant les produits passé, à venir, sans stock … Et sur le front, les produits effectivement « vendables », avec un stock superieur au seuil limite, …
Cette séparation des données améliore les performances du front, puisque seules les données nécessaires sont présentes et que sa bdd n’est jamais impactés par le travail sur le back office.
La limite : la fameuse synchro des données dont tu parles, François, est encore plus importante : catalogue, stock,tarifs,… qui est à faire non seulement entre la gestion commerciale et le back, mais aussi entre le back et le front, puis entre le front et le back (et oui, pour les commandes, sinon pas de « vrai séparation »).
Le temps réel étant assez souvent un « objectif » plutôt qu’une réalité (et l’utilisation de web-services posant parfois des question de temps de réponses, de disponibilité … et de rapidité!), un bon vieux système de batchs, lancés plusieurs fois par jour, fait souvent l’affaire. Par exemples
liaison front / back : toutes les heures
liaison back / front : toutes les heures
liaison gest com / back : toutes les nuits
Dans le cas d’une telle architecture, on parle souvent de front-office, de middle office (pour le « back » du site) et de back office pour la gestion commerciale que l’on interface.
100% d’accord avec wizeoo, et c’est sans compter les systèmes de cache, de réplication, les synchros avec les environnements de pré-prod.
Pour certains batchs et synchros il peut être intéressant d’utiliser Talend (ETL français je crois). Un des problèmes récurrents étant la reprise de l’existant ou l’intégration sur un SI déjà en place, la seule option c’est la ‘moulinette of the death’ ^^
Pour éviter les problèmes de synchro/performance, j’aurai tendance à proposer des systèmes à la mqseries sur certaines taches, particulièrement quand des traitements de masse ne sont pas nécessaires.
Je ne parle pas des mainframes avec une planif qui change tout le temps, des problèmes d’encodage, des systèmes hétérogènes, des problèmes de sécurité…
Du coup des fois on se retrouve avec : front, middle, back et applis tierces genre boite noire que personne ne connait.
Coté positif : c’est extraordinairement intéressant ^^
Par contre, faut pas rêver, même en utilisant un produit existant c’est plutôt couteux. La performance et l’inter operabilité a un cout non négligeable.
@Cobolian : Talend édite Open Studio, un ETL libre assez facile à mettre en oeuvre (après, cela dépend de l’objectif final, évidemment).
L’intérêt est le coté visuel de cette mise en œuvre : on peut construire ses batchs « graphiquement », en construisant son process d’interface avec des composants, le code est écrit par le soft, java ou perl, c’est au choix.
Cela permet de réaliser des batchs en se souciant peu de syntaxe, en se concentrant sur un schéma de flux plutôt que sur une grammaire technique.
L’utilisation de Open Studio pourrait faire l’objet d’un bon post, non ? Messieurs, à vos plumes !
Plus de détail sur leur site : http://fr.talend.com/
(PS : je n’ai pas d’actions chez Talend, mais j’ai assisté à un atelier de leur « roadshow », l’outil m’a paru vraiment intéressant)
@Marc> Merci pour ces infos intéressantes. Je reparlerais sans doute à l’occasion de ta solution, et de ton archi.
@Wizeo (1) > Yep, l’archi dont tu parles est bien celle que j’ai en tête, mon billet ne devait pas être très clair 😉
OK également sur la notion de temps réel, pas toujours réellement utile… La synchro régulière fait bien souvent l’affaire.
@Cobolian> Yep, Talend est une solution intéressante, mais traite une partie du problème (le mapping des données).
@wizeoo : j’ai vu également la démo, et j’ai essayé de faire joujou avec il y a 2 ans. Carrément sympa. Et carrément mieux depuis qu’il génére autre chose que du PERL (enfin a l’epoque je crois que c’était du perl).
Et quand on connait SQL Server (ou PACBASE a la limite) on est pas trop dépaysé par l’interface et le principe ^^
Pendant la démo, en moins d’une heure, le demonstrateur nous à généré le code d’une moulinette qu’on aurait mis plusieurs jours à faire…