laravel-echo-serverブロードキャストサービス構築を共有する

                                                       

次のチュートリアルコラムでは、laravelの構築について紹介します。 -echo-server ブロードキャスト サービス。困っている友達のお役に立てれば幸いです。

モチベーション

現在のプロジェクトの多くのシナリオでは、実行に時間がかかるタスクを処理するために Redis キューとスケジュールされたタスクを使用しています。実行状況や実行結果は、フロントエンドからリクエストを再送信することでのみ取得できます。

目標

プログラム エクスペリエンスを最適化し、ユーザーができるだけ早くタスクの実行結果に注目できるようにするために、さまざまなオプションを評価しました。フロントエンドとバックエンド間の通信コストを削減し、車輪の再発明を避けるために、Laravel フレームワークに組み込まれているブロードキャスト機能を使用することにしました。

サービスを選択してください

公式では、プッシャーを使用してアプリケーションを構築することを推奨しています。プッシャーの利点は、構築が非常に簡単であることです。ただし、外部サービスであることを考慮するとアクセスの安定性に不安があり、現状のプロジェクト規模が小さいため、公式で言及されているtlaverdure/laravel-echo-serverプロジェクトを利用してWebsocketサービスを自分で構築してみました。 Laravel フレームワーク。

laravel-echo-server サービスの特徴

このプロジェクトの利用方法は github ページから直接入手できますが、以下の点が気に入っています:

Redis のパブリッシュおよびサブスクライブ機能を使用して、イベント情報を取得およびブロードキャストできます。これは、プッシャーの HTTP API にプッシュ リクエストを送信するより効率的です。

プッシャーの HTTP API とも互換性があります。一部のサービスが Redis 経由でイベントを公開できない場合は、このモードを使用してイベントをプッシュできます;

2. Websocket サービスの構築

最初は oanhnn/laravel を使用しました - echo-server このイメージはコンテナの起動に使用されます。デバッグ プロセス中に、このサービスが安定していないことがわかりました。例外が発生するとノードのサービスは直接終了します。これが最初に遭遇した落とし穴です。この問題を迅速に解決するために、このイメージに基づいて、終了後にサービス プロセスを再開するタスクを担当するスーパーバイザーを追加し、独自のイメージを作成しました。

Redis サブスクリプション

Redis サブスクリプションを試すとき、通常のデータベース アドレス、パスワード、その他のパラメーターに加えて、キー プレフィックスがもう 1 つの落とし穴に遭遇しました。 laravel-echo-server サービスの laravel-echo-server.json ファイル内の keyPrefix 設定項目が最初に正しいメソッドを見つけられず、どのように設定されていたとしても正しくありませんでした。後でわかったのですが、イベントをブロードキャストするプログラムの現在の Redis キー プレフィックスを知りたい場合は、次のスクリプトを tinker で実行するだけです。

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

Nginx プロキシ

本番環境では HTTPS プロトコルが使用されているため、サービスに証明書を追加する必要がありますが、私はノードの初心者なので、ノードはありませんプログラムは証明書の構成エクスペリエンスを使用するため、基本的に 1 ラウンドの試行であきらめ、Nginx プロキシ方式を採用して証明書を使用しました。

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

プライベート/出席チャンネルの認証

Laravel ブロードキャストでは、チャンネルがパブリック、プライベート、出席 (翻訳が間違っている可能性がありますので修正してください) に分けられ、後者は2 つの許可されたアクセスが必要です。使用する必要があるのはプライベート チャネルなので、許可されたユーザーだけがフロントエンドからイベントをサブスクライブできます。これは私たちが遭遇した落とし穴でもあります。 観察してソースコードを読んだ結果、laravel-echo の全体的な承認プロセスは次のとおりであることがわかりました。

フロントエンド プログラムは、まず HTTP POST リクエストを laravel に送信します。 -echo-server service;

laravel-echo-server は、構成内の 2 つの項目

authEndpoint
1. と
authHost
2. に基づいて HTTP POST をアプリケーション サーバーに送信します。 POST データはチャネル名であり、ヘッダーで透過的に送信されます。認可データ; laravel-echo-server はアプリケーション サーバーの応答に基づいて認可結果を決定します。アプリケーション サーバーが非-HTTP 200 ステータスは、エラーが発生し、認証が失敗したことを意味します。
実際には 2 つの問題に遭遇します。最初の問題は、プロジェクトの認可ゲートキーピングロジックがlaravelのデフォルトではないため、デフォルトの
3. Broadcast::routes()
によって導入されたルートを直接使用できないことです。問題を発見した後、独自の認証ルートを再度追加し、laravel-echo-server.json の

authEndpoint

構成項目で構成しました。 <p>もう 1 つの問題は、標準の RESTFul プロトコル ルールを使用していないことです。対応する HTTP コードに応答してエラー ステータスを説明します。その結果、認可が失敗した場合でも、laravel-echo-server は問題を検出できず、フロントエンド プログラムにフィードバックすることができません。状況は次の図に似ています。 </p>#遅かれ早かれ、借金は返済しなければなりません。…<p><img src="https://img.php.cn/upload/article/000/000/020/ce24538de7ea16b3b939356a59350b87-0.jpg" alt=""></p> <blockquote>##要約<p></p>この機能の開発は当初ほどスムーズではありませんでした。 </blockquote> <h2><span class="header-link octicon octicon-link">laravel-echo-server は期待したほど堅牢ではありません。今後時間があるときに代替案を探さなければなりません。 swoole を使用したプロジェクト. 試してみることができます; </span></h2>SSL の問題を事前に考慮するのを忘れた結果、リリース中の一時処理が多忙になりました; <p></p>laravel-echo-server および laravel-echo 自体小規模なプロジェクトであるため、問題が発生した場合は、コードを解析することを優先して、試行時間を短縮する必要があります。 <ol><li></ol>

以上がlaravel-echo-serverブロードキャストサービス構築を共有するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。