Php forum 2017 - Maisons du Monde

1
Titredelaprésentation- Jour / Mois / Année
PHP Forum 2017
Maisons du Monde
et l'architecture orientée service

Bonjour !
Jour / Mois / Année
2Maisons du Monde / PHPForum -26 /10 /2017
Marc Hugon
● Responsable développement & innovation chez Maisons du Monde
● @marc_hugon sur twitter, marchugon sur linkedin… bref… Marc Hugon

Marc Hugon Productions, #4
Alors oui, j'aime bien Big Bang Theory, donc petit coucou à Chuck Lorre et les vanity cards
(http://www.chucklorre.com/index-bbt.php). J'ai eu plusieurs vies dans le monde du web. Je me
rappelle d'une époque où on utilisait du TCL-TK, et franchement, ce n'était pas glorieux. C'est
pourquoi je me suis senti attiré par le PHP, à l'époque en train de passer à la version 4. Ça m'a plu,
j'ai même eu l'occasion de publier ma petite contribution à l'open source, qui n'a pas eu un succès
retentissant, on ne va pas se mentir, mais pour l'anecdote j'avais proposé une petite librairie qui
permettait de générer des formulaires CRUD à partir d'un fchier de défnitions à la YAML. Basique,
mais ça faisait le job. Ce n'est pas vraiment grâce à ça que je suis rentré chez Sensio, avant que ça ne
s'appelle Sensiolabs (bien avant). J'y ai eu plusieurs vies professionnelles, de développeur à directeur
technique, mais j'ai surtout eu l'opportunité de vivre de l'intérieur le lancement d'un projet qui a fait
pas mal parler de lui depuis, je parle bien entendu de symfony. Je n'ai jamais passé le pas d'être
contributeur actif sur le projet, mon apport a surtout été de travailler sur des versions de ce
framework avant sa mise à disposition dans le monde de l'open source, et donc de jouer le rôle du
bêta testeur, ce qui était très intéressant. Après Sensio, c'est chez Maisons du Monde que je suis allé
participer à un autre projet en devenir, un site e-commerce qui était déjà très recommandable il y a
plusieurs années, même si on était très loin de ce qu'il est devenu maintenant. Mon quotidien est
maintenant parsemé de réunions diverses et variées, mais je continue à avoir une vraie appétence
pour le code, j'essaie de ne pas être trop dépassé par les évolutions de symfony (pas simple), alors
pour me reposer je résous des puzzle sur https://www.codingame.com. Ah, j'oubliais, j'ai des goûts
cinéphiliques discutables, mais bon, je suis persuadé du contraire, donc ça se gère bien.

Maisons du monde
Maisons du Monde a été créée il y a 21 ans
2017 a marqué le passage à plus de 300 magasins physiques en Europe
Le site http://www.maisonsdumonde.com, c’est :
Une présence dans 11 pays, 7 langues, 3 devises
A fn septembre 2017
>153M euros de CA
>Plus de 22 % du CA global groupe
>Une croissance de 28 % par rapport à 2016
Environ 7 millions de visiteurs mensuel
Environ 100 millions de pages vues par mois
Un groupe omnicanal et international

Pour l’équipe web, c’est aussi
Une application de prise de commande en magasin (déployé dans les 300 magasins)
Une application dédiée au service professionnel
Une application dédiée au service client
Un site de ventes privées
Un site de liste de mariages
Ce qui s'ajoute au chifre d'afaire de l'e-commerce !

Une équipe technique… et des techniques
Une équipe
● Une quarantaine de personnes réparties en 6 feature team agiles
Des outils de travail
● Linux / Phpstorm / Jenkins / Bamboo / Scrutinizer / Sensiolabs insight / Blackfre /
NewRelic
Des technologies
● PHP(5/7) / Symfony / Redis / RabbitMq / SOLR / Elasticsearch / Logstash /
Kibana / NewRelic / Zabbix / Chef / Docker / Postgresql
Plus de 600 000 lignes de codes, 2 mises en production par jour, etc...

Une petite chronologie de notre présence sur le web
2004 – 2007
Premières années de l'activité e-commerce
Un code PHP5.0 / framework propriétaire / multi applicatifs / pas de tests
2007
Délégation des activités web à une nouvelle équipe dédiée
Reprise de www.maisonsdumonde.com sur une architecture symfony1.4
2013
Refonte application de prise de commande magasin en Symfony 2.1
Création du site mariages.maisonsdumonde.com en Symfony 2.1
2014
Les premiers web service dédiés arrivent en production en Symfony 2.3
2015
Les web services évoluent et migrent en Symfony 2.7
2016
Mise en place des premières étapes de la transition vers l'architecture SOA

Maisons du monde : la cible
Version simple !
E-commerce Service proService clientMagasin
Commandes Catalogue Client Éditorial Transporteur
Applications
Services

Maisons du monde : la situation actuelle
Version simple aussi !
Applications
Services
70 % 40 % 5 % 5 %
50 % 95 % 50 % 10 % 100 %

C’était un peu trop simple
D'autres web services sont rapidement apparus
● Mock : permet de s'isoler de dépendances externes non maîtrisables en
environnements de tests et de pré-productions (plateformes de paiement, stock, …)
● Ressources : permet d'unifer des besoins communs aux applications et aux
webservices (dates de soldes)
Il manque de nombreuses boîtes
SOLR / RabbitMq / Workers / Tâches / ETL Pentaho / Redis
On est passé en PHP7 sur tous les webservices
On a aussi géré la migration en Symfony3
L'histoire n'est pas fnie, mais on a déjà beaucoup appris

Maisons du Monde : la version moins simple
Applications ancienne génération
Services
Applications nouvelle génération
Mock Resources
Postgresql Redis SOLR Elastic SearchDonnées
Pentaho kettle RabbitMq WorkersTraitements Tâches
Back ofce
Back ofce
What ?

La migration avec des services
L'ajout d'un service ne perturbe pas les systèmes en place
Les applications peuvent migrer à leur rythme pour les utiliser
Les services sont testables
On peut migrer par étapes (appel au service que dans certaines conditions métiers)
Aucune nouvelle fonctionnalité ne doit être ajoutée dans le legacy*
*ok, il peut y avoir des exceptions, mais...

Les principales décisions prises

Microservice ? REST ?
Nous sommes restés pragmatiques
● Il n'était pas possible d'un point de vue performance de tout baser sur des micro
services (un appel HTTP est plus coûteux qu'une requête en base de données)
● Pour des raisons d'optimisation, on a un seul appel pour renvoyer tout ce dont on a
besoin pour afcher une fche produit (plus de 100Ko de Json)
Nous sommes fdèles à REST, mais en même temps on s'autorise des incartades (© E.
Macron)

Gestion des versions
Quand une équipe fait évoluer un service
● Comment savoir qui utilise ce service ?
● Comment s'assurer qu'on ne va pas impacter ces utilisateurs ?
● Doit-on assurer la montée de version de tous les clients ?
● Comment faire la mise en production ?
● Est-ce qu'il faut utiliser des numéros de version majeurs et mineurs ?
Notre état des lieux
● L'utilisation de versions (majeurs / mineurs), on n'y est pas encore, pas sûr qu'on ira
jusqu'à ce niveau
● La règle qu'on s'est fxée est : "si on ne peut gérer la non régression, c'est qu'on doit
créer un nouveau service"

Les dépendances applications / bundle
Nos web services ont beaucoup de points communs (FOSRest, storage,…)
● On partage donc des bundles
La bonne pratique
● Une application a besoin d'un bundle externe
● On déclare le bundle et la version à utiliser dans le composer.json
Problème
● Le bundle est très utilisé et varie régulièrement, plusieurs équipes le font évoluer en
parallèle
● Confits réguliers sur les composer.lock à l'arrivée dans master
● Une PR pour les nouveautés dans le bundle
● Une PR pour chaque application qui a besoin de cette version (tag explicite de la version à
utiliser)
● Mises en production de la mauvaise version du composer.lock

L’assurance qualité
Nous utilisons Sensiolabs Insight et Scrutinizer, l’analyse des applications historiques donne
des résultats peu lisibles.
Les faire évoluer est quasi impossible, l’historique est trop lourd, et l’évolution ne se voit pas
à cause du volume de données
Créer des services permet de poser de nouvelles bases
On mesure plus efcacement l'évolution des tendances

Gestion des logs
Nos outils : NewRelic, ElasticSearch / Kibana / Logtash
Les incidents arrivent, mais dans une architecture orientée service, les questions peuvent
être : pourquoi le service user a eu une erreur ? Quel était le contexte ? Quelle action voulait
faire l'utilisateur ?
Mise en place d'un header spécifque : correlation_id
● Hash généré lors de l'arrivée de la requête
● Chaque application fait suivre ce header dans chacun de ces appels internes
Possibilité de suivre une requête spécifque qui a amené à une erreur
S'assurer qu'on reste dans une limite acceptable en nombre d'appels

Les services et la charge serveur
Le passage à une architecture orientée service peut être coûteux
● Avant : Une requête HTTP, un serveur, une réponse
● Après : Une requête HTTP, un serveur qui appelle d'autres serveurs en faisant des
requêtes HTTP, qui peuvent aussi appeler d'autres serveurs en faisant des requêtes
HTTP, qui pourraient appeler d'autres serveurs HTTP s'ils étaient maladroits
Nos objectifs
● Le premier serveur ne doit faire aucune requête (bdd, autre) en dehors des services
web
● Les chaînes d'appels sont limitées à un relais
● Les web services ont accès à la base de données, Redis ou autre

Et ça fonctionne !
Nouvelle fche produit (vous n'y avez pas encore tous accès)
● Jusqu'à 4 appels vers des services
● Des données déjà préparées dans Redis (serveur de cache, mis à jour en temps réel
par rabbitMq / worker)
● Temps moyen de réponse : 120 ms
Web service catalog
● entre 15 000 et 20 000 appels par minutes, temps de réponse moyen à 60 ms
Php-fpm confguré pour prendre en compte la répartition de la charge des services

Comment rester performant ?
Quels impacts pour les équipes de développement ?

Ça, c’était avant pour les développeurs !
Il y a encore quelques mois, les premiers jours d'un développeur ressemblaient à ceci :
● Récupération d'un ordinateur sous Linux
● Récupération de tous les projets Git (un par application, un par webservice, un par
bundle partagé, et les "à côté"), soit une trentaine de projets
● Initialisation de sa base de données (script fourni)
● Récupération d'une confguration Nginx
● Initialisation des projets
● Lancement de son navigateur : erreur 500

Il y a encore quelques mois, le quotidien d'un développeur ressemblait à ceci :
● Travail sur une branche
● Pull request pour première relecture de code
● Récupération des retours
● Mise à jour de sa branche
● Connexion du navigateur : erreur 500
● Tentative de maîtrise (app/console… , service php-fpm restart)

Ça, c’était avant pour les ingénieurs qualité !
Il y a encore quelques mois, les premiers jours d'un ingénieur qualité ressemblaient à ceci :
● Mise à disposition de "box" pour déployer ces projets
● Gestion dans Jira de sa story, nécessité de connaître tous les projets impactés
● Pour faire ses tests, déploiement de chaque projet avec la bonne branche
(automatisation parfois disponible selon les projets, sinon capistrano en ligne de
commande)
● Nécessité de "nettoyer" la machine (suppression du cache, génération des asset, …)
● Modifcation manuelle des fchiers de confguration pour les nouvelles fonctionnalités

Le passage au mono repo
Tout le code est dans un seul dépôt git !
Un même commit peut être transverse à plusieurs applications et bundle
Meilleure lisibilité de l'historique Git global
La PR est globale, la relecture fait plus de sens
Impact assez délicat à gérer pour l'intégration continue qui travaille maintenant sur des
répertoires, et passage par des repository proxy pour utiliser des outils comme scrutinizer

●
Récupération d’un seul projet Git

Outil de déploiement interne (Empire)
Pourquoi ?
● On utilise notre propre workfow de déploiement (par paliers)
● A un instant t, on sert deux version de l'applicatif
● On a plusieurs socles logiciels distinct, un seul outil ne peut pas tout faire
● On ne veut plus déployer manuellement sur les environnements de test & préprod
Comment on a fait ?
● Basé sur capistrano
● Développement PHP
● Ajout des droits pour diférencier QA & Admin sys
Et depuis ?
On a gagné en fuidité, on va pouvoir continuer à automatiser pour être encore plus réactif

Ça, c’était avant pour les ingénieurs qualité !
Il y a encore quelques mois, les premiers jours d'un ingénieur qualité ressemblaient à ceci :
● Mise à disposition de "box" pour déployer ces projets
● Gestion dans Jira de sa story, nécessité de connaître tous les projets impactés
● Pour faire ses tests, déploiement de chaque projet avec la bonne branche
(automatisation parfois disponible selon les projets, sinon capistrano en ligne de
commande)
● Nécessité de "nettoyer" la machine (suppression du cache, génération des asset, …)
● Modifcation manuelle des fchiers de confguration pour les nouvelles fonctionnalités
Connexion à Empire
Sélection de son tag et de son serveur de destination
Attente
C’est prêt, et ça fonctionne !

Docker pour l’environnement de développement
Pourquoi ?
● Difculté d'installer l'ensemble de la stack (confguration applicatifs & serveurs)
● Temps passé à comprendre pourquoi une application ne répond plus (un service a
évolué)
● Difculté pour suivre l'arrivée des nouvelles briques techniques (redis)
Comment ?
● Une image docker light pour chaque application et briques techniques, et des
spécifques quand nécessaire (postgresql)
● https://traefk.io/ pour reproduire la confguration de l'infrastructure de production
● Création d'une boîte à outils en ligne de commande pour unifer des commandes
génériques (un makefle général sur tous les projets)
Depuis ?

bin/workspace
Quelques commandes disponibles pour tout ou partie des applications
● Cc (le bon vieux clear cache)
● Fix-all
● Logs
● Psql-cli
● Redis-cli
● Restore-dbs
● Switch-env
● ...

./bin/workspace init
Attente
Lancement du navigateur : ok !

Il y a encore quelques mois, le quotidien d'un développeur ressemblait à ceci :
● Travail à partir d'une branche créée par les développeurs back
● Pull request pour première relecture de code
● Récupération des retours
● Mise à jour de sa branche
● Lancement en ssh de commandes bizarres (clear cache, service php-fpm restart)
./bin/workspace fixall
Attente
Lancement du navigateur : ok !

Nos réfexions du moment
On analyse tout ce qui a été réalisé jusqu'ici pour
● Standardiser notre défnition d'un web service (on a essayé un peu trop de standards)
● Décider si on continue d'accepter ou non que les services s'appellent entre eux

Notre bilan à mi-parcours
La migration en basculant sur des web services
● Nous a permis de rester souple et réactif
● D'introduire facilement des technologies qui étaient inaccessibles en legacy
On a su gérer la forte croissance des activités web
On a réussi à gérer l'augmentation de la complexité globale du système
● On a même facilité le travail quotidien des équipes !

Merci !
Des questions ?
Pour les CV, rendez-vous au stand Maisons du Monde:)

Php forum 2017 - Maisons du Monde

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Php forum 2017 - Maisons du Monde

Similaire à Php forum 2017 - Maisons du Monde (20)

Php forum 2017 - Maisons du Monde