Comment je prévois de faire évoluer mon application Laravel (PHP)

Mise à l'échelle de 10MPage.com : une approche pragmatique pour héberger des archives Internet en pleine croissance

10MPage.com vise à capturer l'état d'Internet en 2025 en permettant aux utilisateurs de contribuer à des images de 64 x 64 pixels à une archive en ligne massive. En tant que développeur solo, je donne la priorité à la rentabilité dès les premiers stades, en hébergeant sur un VPS économique. Toutefois, une architecture évolutive est cruciale pour la croissance future. Cet article détaille mon plan de mise à l'échelle par étapes, en mettant l'accent sur la simplicité et un temps d'arrêt minimal.

Architecture des applications :

L'application, construite avec Laravel et PHP, s'appuie fortement sur des processus en arrière-plan (gérés par Laravel Horizon et Supervisor) pour la gestion des images, le placement dans la grille et la livraison des e-mails. Redis gère la mise en cache et les tâches, tandis que MySQL stocke les données. Nginx et PHP-FPM servent les requêtes Web. La configuration initiale d'un serveur unique est illustrée ci-dessous :

Stratégie de mise à l'échelle :

Mon plan de mise à l'échelle implique une transition progressive vers une architecture multi-serveurs, minimisant les temps d'arrêt à chaque étape :

Phase 1 : isolement de Redis (zéro temps d'arrêt)

La première étape consiste à déplacer Redis vers un serveur distinct. L'application peut temporairement utiliser la mise en cache du système de fichiers local et la file d'attente des tâches peut être brièvement suspendue. Cela implique la configuration d'un nouveau serveur, la configuration de l'accès au réseau et la redirection des connexions Redis. Une fois la migration terminée, Redis sur le serveur d'origine est arrêté et désinstallé.

Phase 2 : Implémentation d'un équilibreur de charge (zéro temps d'arrêt)

Ensuite, je présenterai HAProxy en tant qu'équilibreur de charge, tirant parti de ses fonctionnalités avancées telles que les contrôles de santé actifs. Ce serveur gérera également la terminaison SSL. Le DNS sera mis à jour pour pointer vers l'équilibreur de charge, distribuant le trafic vers le serveur Web existant.

Phase 3 : Distribution des serveurs de travail (zéro temps d'arrêt)

La conception de Laravel Horizon permet l'ajout transparent de serveurs de travail. Un nouveau serveur sera configuré, l'application déployée et le travailleur commencera à utiliser Supervisor. Le travailleur d'origine peut alors être arrêté. La mise à l'échelle des travailleurs implique simplement de reproduire ce processus.

Phase 4 : Déploiement de plusieurs serveurs Web (zéro temps d'arrêt)

Semblable aux serveurs de travail, des serveurs Web supplémentaires sont ajoutés, configurés avec Nginx et PHP-FPM et enregistrés auprès de l'équilibreur de charge. La réplication est simple et garantit une haute disponibilité.

Phase 5 : Serveur de base de données dédié (temps d'arrêt minimal)

Enfin, le serveur d'origine devient le serveur de base de données dédié. Tous les logiciels inutiles sont supprimés. Bien qu'un seul serveur de base de données puissant soit suffisant pour l'instant, la mise à l'échelle de ce composant à l'avenir pourrait nécessiter un clustering et un bref temps d'arrêt.

Automatisation du déploiement :

Mon processus de déploiement basé sur Git sera adapté pour gérer plusieurs serveurs, en utilisant des scripts pour déployer et redémarrer les services uniquement lorsque cela est nécessaire (par exemple, vérifier l'état d'Horizon avant de redémarrer).

Résoudre les points de défaillance uniques :

L'architecture actuelle présente des points de défaillance uniques (équilibreur de charge, base de données, Redis). Les améliorations futures incluront la redondance pour l'équilibreur de charge. La mise à l'échelle des bases de données et Redis sera abordée dans un prochain article.

Conteneurs et clusters :

Bien que j'apprécie les conteneurs et les clusters, je pense qu'ils sont excessifs pour l'échelle actuelle de ce projet. L’approche choisie donne la priorité à une configuration initiale rapide et évite toute complexité inutile. Les instantanés de machine et le clonage suffiront pour la mise à l'échelle dans les premières phases.

Conclusion :

Ce plan de mise à l'échelle pragmatique donne la priorité à la simplicité et à la rentabilité tout en garantissant que 10MPage.com peut gérer la croissance future. L'approche progressive minimise les temps d'arrêt et maintient les fonctionnalités tout au long du processus de mise à l'échelle. En me concentrant sur une stratégie claire et progressive, je peux consacrer mes efforts à construire le projet lui-même, en ajoutant une tuile à la fois à cette archive Internet ambitieuse. Contribuez votre propre tuile aujourd'hui !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!