分享laravel-echo-server廣播服務搭建

#                                                                        

##上對中由

Laravel

#aravel-echo-server廣播服務搭建，希望於教學課程建立，希望能幫助您完成教學課程的需求！

動機

目前專案中許多場景採用Redis 佇列和定時任務來處理執行時間較長的任務，這些任務執行的狀態和執行結果只能透過前端重新發送請求來取得。

目標

為了優化程式體驗，讓使用者盡可能早的關注到任務執行結果，我們評估了各種方案。為了降低前後端的溝通成本避免重複造輪子，我們決定採用 Laravel 框架內建的廣播功能。

選擇服務

官方推薦採用 pusher 來建立應用，pusher 的好處是搭建起來非常簡單。但考慮到是國外的服務，有存取穩定性風險；且目前專案規模較小，於是嘗試自行建立 Websocket 服務，使用的就是 Laravel 框架官方提到的 tlaverdure/laravel-echo-server 專案。

laravel-echo-server 服務特點

這個專案的使用方法可以直接去他們的github 頁面取得，我們看中的幾點如下：

1. 可透過Redis 的發布訂閱功能來取得事件資訊並廣播出去，這點的效率要高於向pusher 的HTTP API 發送推送請求；
2. 同時相容pusher 的HTTP API ，如果某些服務無法透過Redis 發布事件，則可以採用這種模式推送事件；

#搭建Websocket 服務

我們一開始使用了oanhnn/laravel -echo-server 這個鏡像來啟動容器，在調試過程中發現這個服務並不穩定，Node 的服務會在異常時直接退出，這是我們碰到的第一個坑。為了快速解決這個問題，我們再這個鏡像基礎上加入了 supervisor 來負責進行服務進程的退出後重啟的任務，並做成了我們自己的鏡像。

Redis 訂閱

在試用Redis 訂閱時，除了常規的資料庫位址和密碼等參數以外，key 前綴是我們碰到的另一個坑，對應在laravel-echo-server 服務中的laravel-echo-server.json 檔案中的 keyPrefix 設定項，一開始沒有找到正確的方法，不管怎麼設定都不對。後來發現如果想知道要廣播事件的程式目前的 Redis key 前綴是什麼，就在 tinker 中執行以下腳本即可。

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

Nginx 代理程式

由於生產環境採用了HTTPS 協議，所以需要為服務增加證書，但因為我是Node 小白，沒有Node 程式使用證書的配置經驗，所以一輪嘗試之後基本上放棄了，之後採用了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 廣播將頻道分為：公共、私有和出席（我可能翻譯的不對，請指正），其中後兩者是需要授權存取。我們需要用到的是私有頻道，只有經過授權的人才能從前端訂閱我們的事件。這也是我們遇到的一個坑。

經過我們觀察和原始碼閱讀，發現laravel-echo 的整體授權過程是：

1. 前端程式先向laravel-echo-server 服務發送一個HTTP POST 請求；
2. laravel-echo-server 根據配置中authEndpoint 和authHost
這兩項，向應用程式伺服器發送一個HTTP POST，POST 資料是channel 名字，同時透傳header 中的Authorization 資料；
3. laravel-echo-server 會根據應用伺服器的回應來判斷授權結果，如果應用伺服器回應的是非HTTP 200 狀態，就表示發生了錯誤，授權失敗。

我們在實務上遇到兩個問題。第一個問題是，我們專案的授權守門邏輯並非 laravel 預設的，所以預設的 Broadcast::routes() 所引入的路由無法直接使用。發現問題後，我們重新加入了我們自己的授權路由，並配置到 laravel-echo-server.json 的 authEndpoint

組態項目中。 ###

另一個問題是，我們沒有採用標準的 RESTFul 協定規則：回應對應的 HTTP Code 來描述錯誤狀態。致使laravel-echo-server 即使在授權失敗的時候也不能發現問題並反饋給前端程序，情況類似下圖：

遲早還是要還債的…

總結

這個功能開發的，沒有當初想的那麼順利，主要的問題有以下幾點：

1. laravel-echo-server 沒有預想的那麼健壯，以後有時間還得找找替代方案，貌似也有用swoole 做的項目，可以嘗試一下；
2. 預先忘記考慮到SSL 的問題，導致發佈時臨時處理得手忙腳亂；
3. laravel-echo-server 和laravel-echo 本身都是很小的項目，遇到問題應該優先考慮去分析其程式碼減少嘗試的時間。

以上是分享laravel-echo-server廣播服務搭建的詳細內容。更多資訊請關注PHP中文網其他相關文章！