Bonjour, je m'appelle Pavel Savelyev, je suis le chef du département d'automatisation des processus métier chez Lamoda. Nous travaillons avec des tâches très différentes et essayons de choisir les outils les plus pratiques pour chacun. En conséquence, nous utilisons différents langages - dans nos systèmes, vous pouvez trouver Java, Go et un peu de Kotlin pour Android. Dans le même temps, une partie importante du développement est réalisée en PHP; plus de deux douzaines de services y sont écrits qui automatisent non seulement le travail avec les commandes, mais aussi les processus opérationnels d'un large réseau de livraison, des centres d'appels dans trois pays et de notre propre studio photo, ainsi que de fournir tout cela sous la forme services à nos partenaires B2B. Ces services sont pris en charge et développés par 5 équipes de développement de notre département.
À mesure que les services eux-mêmes et l'infrastructure qui les entoure se développent, des tâches similaires se produisent plus souvent dans ces systèmes, telles que la connexion au CLS (Centralized Logging System) commun, le test du stockage de fichiers, la collecte de métriques pour Prometheus et d'autres. Nous essayons de normaliser les moyens de résoudre ces problèmes et d'utiliser des composants communs pour différents systèmes.
Lorsque l'une des équipes est confrontée à l'adaptation ou à l'intégration d'un nouveau service / outil qui peut devenir commun à tous, nous initions le développement de la bibliothèque de cette équipe. Et puis le composant fini est préparé pour une réutilisation future et présenté dans le domaine public.
Donc, un tel processus se déroule régulièrement avec nous, nous avons créé une ligne directrice qui nous permet de le mener sans douleur - j'essaierai d'en faire rapport lors d'une des prochaines conférences.
Plus de deux douzaines de nos bibliothèques PHP ont été rendues publiques sur GitHub. Et nous prévoyons de nous étendre davantage. Pourquoi? Eh bien, nous avons investi beaucoup de ressources et (je veux le croire) avons bien fait. Et nous espérons astucieusement que d'autres développeurs utiliseront nos bibliothèques, les aideront à terminer et à développer davantage, au lieu de passer du temps à écrire leurs analogues à partir de zéro. Dans cet article, je veux parler brièvement de sept bibliothèques conçues pour résoudre des problèmes courants pour les tâches de commerce électronique - je serai heureux si elles vous sont utiles, et je serai encore plus heureux de les développer ensemble :)
1. La fiscalisation en ligne: un client pour ATOL Online
Comme d'autres sociétés russes, nous sommes tenus de respecter pleinement les exigences du FZ-54, dont l'une est la fiscalisation en ligne. Toutes les commandes prépayées sur
lamoda.ru sont toujours taxées: elles génèrent des chèques en ligne qui sont envoyés aux clients. Notre service de fiscalisation fonctionne par API avec le système
ATOL Online, et la première
bibliothèque de notre liste est un client à part entière pour ce service. En plus de la bibliothèque elle-même, nous avons également publié un
bundle , avec lequel vous pouvez facilement le connecter à tous les projets basés sur le framework Symfony. La bibliothèque elle-même peut être intégrée dans n'importe quel autre framework PHP: Laravel, Yii, etc. - il suffit d'écrire un «wrapper» pour la bibliothèque.
2. Paiements prépayés: interaction avec Payture
Pour traiter les paiements prépayés, nous interagissons activement avec le service Payture. Ce service possède plusieurs interfaces logicielles. Nous utilisons l'
option Payture InPay et avons écrit notre propre
client API pour cela. La bibliothèque vous permet de manipuler plusieurs terminaux, prend en charge la journalisation PSR-3 standard. Il est également possible d'utiliser le client Guzzle pré-configuré - cela facilite l'organisation des tests à l'aide du
gestionnaire de simulation Guzzle .
Notre ensemble de
bibliothèques fournit une configuration sémantique des terminaux et vous permet de configurer facilement les paramètres client (jusqu'à présent uniquement des délais) pour diverses opérations d'API.
3. Étiquetage du produit: analyseur de code GS1 Datamatrix
L'un des projets les plus importants de 2019 dans notre entreprise est le soutien à l'étiquetage des marchandises par l'État. Dans le cadre de ce projet, des codes uniques spéciaux seront appliqués à tous les produits de certaines catégories - au format GS1 Datamatrix. Ces codes permettront à tout acheteur de vérifier l'authenticité des marchandises, leur origine et leur historique. Afin que les systèmes internes Lamoda fonctionnent avec ces codes-barres, nous avons développé une
bibliothèque pour l'analyse correcte des codes GS1.
Dans un avenir proche, nous prévoyons également de présenter les codes sources de nos clients développés pour l'interaction avec le système d'information de marquage et de traçabilité (IP MP).
4. Gestion des microservices: middleware pour le bus d'équipe Tactician
Nous avons plus d'une centaine de microservices qui effectuent de nombreuses opérations distinctes: ils vérifient l'état des paiements ou des nouveaux fichiers dans les stockages, envoient des commandes de contrôle aux caissiers, téléchargent et traitent les photos des services externes. Presque toutes ces opérations sont effectuées en arrière-plan et le modèle de bus de commande est excellent pour les gérer. Pour implémenter le bus dans les systèmes PHP, nous avons choisi une solution prête à l'emploi - la bibliothèque
Tactician ouverte.
Cependant, un problème est survenu: nos équipes d'arrière-plan interagissent souvent avec des services externes, qui ont une limite sur le nombre d'opérations en n secondes. Et le tacticien n'a pas la possibilité de contrôler le nombre de commandes exécutables dans une fenêtre de temps spécifique. Par conséquent, nous avons développé un middleware supplémentaire - bibliothèque de
limites de taux pour les tacticiens . Avec son aide, vous pouvez ajouter une nouvelle couche de traitement qui suit le nombre de commandes exécutées sur le bus selon la stratégie de limitation de débit sélectionnée. Les stratégies sont enfichables, les stratégies de la bibliothèque
stiphle sont disponibles
immédiatement .
Également dans le domaine public est notre
paquet Symfony à la bibliothèque.
5. Collecte et rendu des métriques pour Prometheus
Nos microservices génèrent des métriques techniques et commerciales, qui sont ensuite collectées via l'opérateur Prometheus de l'ensemble du cluster k8s. Pour gérer tout cela, nous avons écrit une
bibliothèque qui traite les métriques personnalisées selon le scénario «collect-save-show». Dans le même temps, la bibliothèque prend en charge les modes de fonctionnement dans lesquels l'un des éléments de script peut être omis pour augmenter l'efficacité. Par exemple, pour des mesures rapides et calculables, un scénario simplifié de «collecte-présentation» peut être exécuté. Et travailler avec des mesures commerciales lentes peut se traduire partiellement en arrière-plan, tout en se décomposant en deux étapes: «collecter-enregistrer» + «collecter (à partir du stockage) - afficher».
La bibliothèque possède les niveaux d'abstraction nécessaires à la fois pour écrire ses générateurs de métriques et pour écrire des référentiels. Hors de la boîte, il existe un adaptateur abstrait pour Doctrine, qui peut être configuré sur l'entité pour enregistrer les données dans la base de données.
En tant que formats de rendu métrique, prometheus et telegraf httpjson sont actuellement pris en charge.
La bibliothèque est livrée avec un bundle Symfony, qui fournit une configuration sémantique des sources métriques, des référentiels et des métriques de routage. Il dispose également de commandes d'assistance pour le débogage et l'enregistrement des métriques à partir des sources (par exemple, pour calculer les métriques cron).
6. Tester le stockage des fichiers: travailler avec différents systèmes de fichiers
Pour automatiser les tests, nous utilisons le framework
Codeception , qui nous permet d'écrire des tests de différents niveaux et dispose d'une bibliothèque assez étendue de modules standard. Nous avons récemment écrit plus sur nos approches pour tester le développement dans un
article séparé et parlé lors d'une conférence
PHP Russie . Codeception a des modules prêts à l'emploi pour interagir avec FTP et le FileSystem local, mais dans nos tests, il est nécessaire de travailler avec plus de systèmes de fichiers. Au minimum, nous utilisons également AWS S3 et Webdav. De plus, je voudrais interagir avec tous les systèmes de fichiers en utilisant la même API (il s'agit de tous les systèmes de fichiers :)).
Heureusement, il existe une bibliothèque
FlySystem ouverte qui fournit une interface logicielle unique pour travailler avec différents systèmes de fichiers. Nous n'avions donc besoin que de combiner les deux outils - ce que nous avons fait en écrivant un wrapper sur FlySystem en tant que
module Codeception-flysystem . Il prend désormais en charge SFTP, S3 et Webdav. Il suffit de configurer les paramètres une fois pour se connecter au système de fichiers souhaité dans la configuration de test yml, et après cela, vous pouvez travailler avec tous les systèmes de fichiers en utilisant le même ensemble de méthodes: écrire le fichier, copier le fichier, nettoyer le répertoire, etc. Le module est déjà inclus dans la page des ajouts et recommandations de Codeception:
codeception.com/addons .
7. Utilisation des variables d'environnement en mode multi-tenant
Dans le département d'automatisation des processus métier, il existe des systèmes qui fonctionnent en mode multi locataire. Pour assurer leur travail, il est nécessaire de pouvoir travailler avec des variables d'environnement - pour déterminer quelle variable utiliser à l'heure actuelle.
Notre
bibliothèque propose plusieurs stratégies pour travailler avec des variables d'environnement en mode multi-tenant. En fonction des paramètres passés à l'étape d'initialisation, la bibliothèque détermine la variable d'environnement à laquelle accéder dans la demande en cours.
À suivre
Ce n'est que la première partie des bibliothèques. Nous en avons une douzaine de plus à l'intérieur - ils attendent en ligne lorsque nous les «peignons» un peu et les mettons dans le domaine public. Cela me motive à comprendre que ces bibliothèques peuvent être utiles à quelqu'un d'autre. Je me réjouis des commentaires et des étoiles sur le github, et j'espère continuer à développer des bibliothèques avec d'autres développeurs. En effet, de nombreux projets de commerce électronique russes fonctionnent avec ATOL et Payture. Pour Datamatrix, en plus de l'analyseur de code décrit dans l'article, nous avons également quelques clients que nous utilisons déjà en interne - ces bibliothèques sont les premières dans la file d'attente sur GitHub.
Nous essayons de ne pas oublier les autres langues - nous avons déjà posté la première bibliothèque sur Go (nous en avons
écrit plus
ici sur Habré ) et nous en préparons d'autres. Restez à l'écoute!