Étude de cas d'ingénierie · Instagram Automation Platform
Superviser des automatisations web multi-sessions depuis une interface unique
Cette plateforme donne aux opérateurs un plan de contrôle pour lancer, suivre et interrompre des automatisations web multi-sessions avec état persistant, logs temps réel et modules d'exécution isolés.
Problème
L'automatisation web multi-sessions devient instable lorsque les sessions de navigateur, les threads du serveur web et les tâches asynchrones se disputent le contrôle. Le système avait aussi besoin de sélecteurs résilients, d'un état persistant et d'une visibilité pour l'opérateur.
Solution
Flask et Socket.IO fournissent le plan de contrôle, tandis que des threads de travail isolés possèdent chacun leur propre boucle d'événements asyncio pour les workflows de navigateur. SQLite stocke l'état opérationnel, des répertoires de navigateur persistants préservent les sessions, et une journalisation par callback relie les workers au tableau de bord.
Preuve
Boucle d'événements asyncio isolée par thread de travail
- Rôle
- Architecture Python, automatisation web contrôlée, conception de la concurrence, tableau de bord, persistance, outils de débogage et documentation client.
Responsabilités du système
- Automatisation
- Intégration IA
Technologies
- Python
- Flask
- Socket.IO
- Playwright
- +3
- AsyncIO
- SQLite
- OpenAI Vision
Certains détails métier, opérationnels ou techniques ont été généralisés pour respecter la confidentialité client.
Aperçu
Les opérateurs devaient piloter plusieurs sessions web de façon indépendante depuis une interface unique, avec des sessions préservées, des contrôles d'arrêt et une visibilité temps réel sur l'exécution.
- Faire fonctionner plusieurs sessions de façon indépendante.
- Préserver les sessions de navigateur authentifiées.
- Contrôler l'automatisation depuis une interface web.
- Diffuser les journaux en temps réel.
- Respecter les délais d'exécution configurés.
- Détecter les états bloquants côté session.
- Prendre en charge plusieurs formats d'import client.
Le problème
L'automatisation web multi-sessions devient instable lorsque les sessions de navigateur, les threads du serveur web et les tâches asynchrones se disputent le contrôle. Le système avait aussi besoin de sélecteurs résilients, d'un état persistant et d'une visibilité pour l'opérateur.
Contraintes qui ont façonné le système
- Flask et Socket.IO fonctionnent selon un modèle de concurrence différent de Playwright asynchrone.
- Les interfaces de navigateur changent.
- Les sessions web nécessitent une isolation.
- Les opérateurs ont besoin de contrôles d'arrêt.
- L'état de l'automatisation doit survivre aux redémarrages.
- Les données d'entrée client arrivent dans des formats hétérogènes.
Architecture du système
Flask et Socket.IO fournissent le plan de contrôle, tandis que des threads de travail isolés possèdent chacun leur propre boucle d'événements asyncio pour les workflows de navigateur. SQLite stocke l'état opérationnel, des répertoires de navigateur persistants préservent les sessions, et une journalisation par callback relie les workers au tableau de bord.
client
Tableau de bord opérateur
Décisions d'ingénierie clés
Isoler les boucles d'événements par worker
AcceptéFlask et Socket.IO fonctionnent selon un modèle de concurrence différent de Playwright asynchrone.
Chaque worker d'automatisation possède sa propre boucle asyncio au sein d'un thread dédié.
Pourquoi
- Éviter les erreurs Playwright inter-boucles.
- Garder le plan de contrôle web réactif.
- Isoler les échecs par compte.
Registre externe de sélecteurs
AcceptéLes interfaces de navigateur changent, et disperser les sélecteurs dans les scripts rend la maintenance fragile.
Stocker des sélecteurs ordonnés en JSON plutôt que de les disperser dans les scripts.
Pourquoi
- Maintenance centralisée.
- Les sélecteurs stables sont priorisés en premier.
- Débogage et comportement de repli facilités.
Alternatives envisagées
- Sélecteurs dispersés directement dans les scripts d'automatisation
Sessions persistantes
AcceptéLes sessions web nécessitent une isolation, et l'état de l'automatisation doit survivre aux redémarrages.
Attribuer à chaque session son propre répertoire de données Chromium.
Pourquoi
- Réduire les connexions répétées.
- Isoler les cookies et l'état.
- Faciliter la récupération manuelle.
Points clés de l'implémentation
- Contrôles d'exécution réalistes et observables.
- Délais d'exécution configurés et historique d'activité.
- Import de données multi-formats.
- Compréhension optionnelle des stories via des modèles de vision.
- Six modules opérationnels.
- Scripts de déploiement Windows et VPS.
- Documentation d'architecture et client détaillée.
Qualité et exploitation
Tests
- Couverture Pytest pour la logique centrale.
- Outils de débogage dédiés.
Exploitation
- Événement d'arrêt partagé en toute sécurité avec les workers.
- Journaux de callback en temps réel.
- Détection des états bloquants côté session.
Résultats et preuves
- Fait d'implémentation
Boucle d'événements asyncio isolée par thread de travail
- Fait d'implémentation
Sessions Chromium persistantes et isolées
- Fait d'implémentation
Stratégie de sélecteurs externalisée
- Métrique vérifiée
Modules opérationnels6
- Capacité observable
Journaux opérationnels en temps réel
- Fait d'implémentation
Scripts de déploiement Windows et VPS
- Fait d'implémentation
Documentation client livrée
Leçons tirées du système
- Les frontières de concurrence doivent être explicites.
- L'automatisation web nécessite de l'observabilité et des outils de récupération.
- La stratégie de sélecteurs est une préoccupation de maintenabilité, pas un détail d'implémentation mineur.