Partager la construction du service de diffusion laravel-echo-server

                                                     

Ce qui suit est mis en place par

Laravel La colonne tutoriel présentera le service de diffusion Laravel-Echo-Server, j'espère qu'il sera utile aux amis dans le besoin !

Motivation

De nombreux scénarios dans les projets actuels utilisent des files d'attente Redis et des tâches planifiées pour gérer des tâches avec des temps d'exécution longs. l'état d'exécution et les résultats de l'exécution ne peuvent être obtenus qu'en renvoyant une demande depuis le front-end.

Objectif

Afin d'optimiser l'expérience du programme et de permettre aux utilisateurs de prêter attention aux résultats de l'exécution des tâches le plus tôt possible, nous avons évalué diverses options. Afin de réduire le coût de communication entre le front et le back end et éviter de réinventer la roue, nous avons décidé d'utiliser la fonction de diffusion intégrée au framework Laravel.

Sélectionnez un service

Recommande officiellement d'utiliser pusher pour créer des applications. L'avantage de pusher est qu'il est très simple à construire. Cependant, étant donné qu'il s'agit d'un service étranger, il existe un risque de stabilité d'accès ; et la taille actuelle du projet est petite, j'ai donc essayé de créer moi-même un service Websocket, en utilisant le projet tlaverdure/laravel-echo-server officiellement mentionné par le Cadre Laravel.

Fonctionnalités du service Laravel-echo-server

Comment utiliser ce projet peut être obtenu directement à partir de leur page github. Les points suivants sont ce que nous aimons :

Les informations sur les événements peuvent être obtenues et diffusées via la fonction de publication et d'abonnement de Redis. Ceci est plus efficace que l'envoi de requêtes push à l'API HTTP du pusher.
1. Il est également compatible avec l'API HTTP du pusher. Si certains services ne peuvent pas publier d'événements via Redis, vous pouvez utiliser ce mode pour pousser des événements

Créer un service Websocket

Nous avons initialement utilisé oanhnn/laravel - echo-server Cette image est utilisée pour démarrer le conteneur. Lors du processus de débogage, nous avons constaté que ce service n'est pas stable. Le service de Node se fermera directement lorsqu'une exception se produit. Afin de résoudre rapidement ce problème, nous avons ajouté un superviseur basé sur cette image pour être responsable de la tâche de redémarrage du processus de service après la sortie, et avons créé notre propre image.

Abonnement Redis

Lors de l'essai de l'abonnement Redis, en plus de l'adresse et du mot de passe habituels de la base de données et d'autres paramètres, le préfixe de clé est un autre piège que nous avons rencontré, correspondant à L'élément de configuration keyPrefix dans le fichier laravel-echo-server.json du service laravel-echo-server n'a pas trouvé la bonne méthode au début, et elle était incorrecte quelle que soit la façon dont elle était configurée. Plus tard, j'ai découvert que si vous souhaitez connaître le préfixe de clé Redis actuel du programme qui souhaite diffuser l'événement, exécutez simplement le script suivant dans Tinker.

# php artisan tinkerconfig('database.redis.options.prefix');

Proxy Nginx

Étant donné que l'environnement de production utilise le protocole HTTPS, je dois ajouter un certificat au service, mais comme je suis un novice Node, pas de Node Le programme utilise l'expérience de configuration du certificat, j'ai donc essentiellement abandonné après une série de tentatives, puis j'ai adopté la méthode proxy Nginx pour utiliser le certificat. Après plusieurs séries de tentatives, la configuration a finalement réussi.

server {
    listen port;
    server_name your-domain;
    ssl on;
    ssl_certificate     path-to-pem;
    ssl_certificate_key path-to-key;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    location /socket.io {
        proxy_pass http://container-name:6002;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }}

Autorisation de chaîne privée/de présence

La diffusion Laravel divise les chaînes en : publique, privée et de participation (j'ai peut-être mal traduit, veuillez me corriger), cette dernière deux dont un accès autorisé est requis. Ce que nous devons utiliser, c'est une chaîne privée, afin que seules les personnes autorisées puissent s'abonner à nos événements depuis le front-end. C'est aussi un écueil que nous avons rencontré.

Après notre observation et la lecture du code source, nous avons constaté que le processus d'autorisation global de laravel-echo est :

Le programme frontal envoie d'abord une requête HTTP POST à ​​laravel -echo-server service ;
1. laravel-echo-server envoie un HTTP POST au serveur d'application en fonction des deux éléments
2. et authEndpoint dans la configuration. Les données POST sont le nom du canal et de manière transparente. transmet les données d'autorisation dans l'en-tête ; authHost
laravel-echo-server jugera le résultat de l'autorisation en fonction de la réponse du serveur d'applications. Si le serveur d'applications répond avec un statut non HTTP 200, cela signifie qu'un. une erreur s'est produite et l'autorisation a échoué.

Nous rencontrons deux problèmes en pratique. Le premier problème est que la logique de contrôle d'autorisation de notre projet n'est pas celle par défaut de Laravel, donc la route introduite par défaut

ne peut pas être utilisée directement. Après avoir découvert le problème, nous avons réajouté notre propre route d'autorisation et l'avons configurée dans l'élément de configuration Broadcast::routes() de laravel-echo-server.json. authEndpoint

Un autre problème est que nous n'utilisons pas les règles standard du protocole RESTFul : répondez au code HTTP correspondant pour décrire l'état de l'erreur. Par conséquent, laravel-echo-server ne peut pas détecter les problèmes et renvoyer au programme frontal même en cas d'échec de l'autorisation. La situation est similaire à l'image ci-dessous :

.

Tôt ou tard, vous devrez encore rembourser la dette…

Résumé

Le développement de cette fonction n'a pas été aussi fluide qu'on le pensait initialement. . Les principaux problèmes sont les suivants :

1. laravel-echo-server n'est pas aussi robuste que prévu. Je devrai chercher des alternatives quand j'aurai le temps dans le futur. les projets utilisant swoole Vous pouvez l'essayer ;
2. J'ai oublié de considérer le problème SSL à l'avance, ce qui a entraîné la précipitation du processus de publication
3. laravel-echo-server et laravel-echo eux-mêmes ; petits projets. Lorsque vous rencontrez des problèmes, vous devez donner la priorité à l'analyse de leurs codes pour réduire le temps d'essai.

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!