Teilen Sie den Aufbau des Laravel-Echo-Server-Broadcast-Dienstes

                                                        Ar Das Folgende ist ein Labavel-Echo-Server-Broadcast-Dienst für die Tutorial-Kolumne von aLaravel

. Ich hoffe, dass er den Freunden in Not hilfreich sein wird!

Motivation

Viele Szenarien in aktuellen Projekten verwenden Redis-Warteschlangen und geplante Aufgaben, um Aufgaben zu verarbeiten, deren Ausführung lange dauert. Der Ausführungsstatus und die Ausführungsergebnisse dieser Aufgaben können nur durch erneutes Senden von Anforderungen ermittelt werden vom vorderen Ende.

Ziel

Um das Programmerlebnis zu optimieren und es Benutzern zu ermöglichen, so früh wie möglich auf die Ergebnisse der Aufgabenausführung zu achten, haben wir verschiedene Optionen evaluiert. Um die Kommunikationskosten zwischen Front- und Back-End zu senken und das Rad nicht neu erfinden zu müssen, haben wir uns für die Verwendung der im Laravel-Framework integrierten Broadcast-Funktion entschieden.

Wählen Sie einen Dienst

Offiziell wird die Verwendung von Pusher zum Erstellen von Anwendungen empfohlen. Der Vorteil von Pusher besteht darin, dass es sehr einfach zu erstellen ist. Da es sich jedoch um einen ausländischen Dienst handelt, besteht das Risiko einer Zugriffsstabilität. Da der Umfang des aktuellen Projekts gering ist, habe ich versucht, selbst einen Websocket-Dienst zu erstellen und dabei das offiziell erwähnte Projekt tlaverdure/laravel-echo-server zu verwenden Laravel-Framework.

Funktionen des Laravel-Echo-Server-Dienstes

Wie Sie dieses Projekt nutzen können, erfahren Sie direkt auf der Github-Seite. Die folgenden Punkte gefallen uns:

Veranstaltungsinformationen können über die Veröffentlichungs- und Abonnementfunktion von abgerufen werden Redis. Broadcasting ist effizienter als das Senden von Push-Anfragen an die HTTP-API. Wenn einige Dienste keine Ereignisse über Redis veröffentlichen können, können Sie diese verwenden

Erstellen Sie einen Websocket-Dienst. Wir haben zunächst das Image oanhnn/laravel-echo-server verwendet, um den Container zu starten ist das, worauf wir gestoßen sind. Die erste Grube. Um dieses Problem schnell zu lösen, haben wir einen Supervisor basierend auf diesem Image hinzugefügt, der für die Aufgabe verantwortlich ist, den Serviceprozess nach dem Beenden neu zu starten, und unser eigenes Image erstellt.

1. Redis-Abonnement
2. Beim Ausprobieren des Redis-Abonnements ist neben der regulären Datenbankadresse, dem Passwort und anderen Parametern das Schlüsselpräfix eine weitere Gefahr, auf die wir gestoßen sind, entsprechend laravel-echo- im laravel-echo- Serverdienst Das Konfigurationselement keyPrefix in der Datei server.json hat zu Beginn nicht die richtige Methode gefunden, egal wie sie konfiguriert wurde, sie war falsch. Später habe ich herausgefunden, dass Sie einfach das folgende Skript in Tinker ausführen müssen, wenn Sie das aktuelle Redis-Schlüsselpräfix des Programms erfahren möchten, das das Ereignis übertragen möchte.

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

Nginx-Proxy

Da die Produktionsumgebung das HTTPS-Protokoll verwendet, muss ich dem Dienst ein Zertifikat hinzufügen. Da ich jedoch ein Node-Neuling bin und keine Erfahrung in der Konfiguration von Node-Programmen für die Verwendung von Zertifikaten habe, tue ich das grundsätzlich Nach mehreren Versuchen gab er auf und nutzte dann den Nginx-Proxy. Nach mehreren Versuchen war die Konfiguration schließlich erfolgreich.

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";
    }}

Autorisierung privater/aktueller Kanäle

Die Laravel-Übertragung unterteilt die Kanäle in: öffentlich, privat und aktuell (ich habe es möglicherweise falsch übersetzt, bitte korrigieren Sie mich), wobei die beiden letzteren einen autorisierten Zugriff erfordern. Wir müssen einen privaten Kanal verwenden, sodass nur autorisierte Personen unsere Veranstaltungen über das Frontend abonnieren können. Dies ist auch eine Falle, auf die wir gestoßen sind.

Nach unserer Beobachtung und dem Lesen des Quellcodes haben wir festgestellt, dass der gesamte Autorisierungsprozess von Laravel-Echo wie folgt aussieht:

Das Front-End-Programm sendet zunächst eine HTTP-POST-Anfrage an den Laravel-Echo-Server-Dienst

laravel-; echo-server sendet gemäß der Konfiguration authEndpoint und authHost einen HTTP-POST an den Anwendungsserver. Die POST-Daten sind der Kanalname und übertragen die Autorisierungsdaten transparent im Header.

laravel-echo-server wird anhand der Antwort des Anwendungsservers ermittelt. Wenn der Anwendungsserver mit einem Nicht-HTTP-200-Status antwortet, bedeutet dies, dass ein Fehler aufgetreten ist und die Autorisierung fehlgeschlagen ist.

In der Praxis stoßen wir auf zwei Probleme. Das erste Problem besteht darin, dass die Autorisierungs-Gatekeeping-Logik unseres Projekts nicht die Standardlogik von Laravel ist, sodass die durch die Standardeinstellung Broadcast::routes() eingeführten Routen nicht direkt verwendet werden können. Nachdem wir das Problem entdeckt hatten, fügten wir unsere eigene Autorisierungsroute erneut hinzu und konfigurierten sie im Konfigurationselement authEndpoint von laravel-echo-server.json.

Ein weiteres Problem besteht darin, dass wir nicht die Standardregeln des RESTFul-Protokolls verwenden: Der der Antwort entsprechende HTTP-Code zur Beschreibung des Fehlerstatus. Dadurch kann laravel-echo-server auch bei fehlgeschlagener Autorisierung keine Probleme und Rückmeldungen an das Frontend-Programm erkennen. Die Situation ähnelt dem Bild unten:

Früher oder später müssen die Schulden zurückgezahlt werden ...

Zusammenfassung

Diese Funktionsentwicklung ist nicht so reibungslos wie ursprünglich angenommen. Die Hauptprobleme sind wie folgt:

1. laravel-echo-server ist nicht so robust wie erwartet Ich werde nach Alternativen suchen, wenn ich in Zukunft Zeit habe. Es scheint, dass es auch Projekte gibt, die Swoole verwenden.
2. Ich habe vergessen, das SSL-Problem im Voraus zu berücksichtigen release;
3. laravel-echo-server und laravel-echo selbst sind kleine Projekte, und wenn Sie auf Probleme stoßen, sollten Sie der Analyse ihres Codes Vorrang geben. Reduzieren Sie den Zeitaufwand für den Versuch.

Das obige ist der detaillierte Inhalt vonTeilen Sie den Aufbau des Laravel-Echo-Server-Broadcast-Dienstes. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!