您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關laravel-echo-server廣播服務搭建的示例分析,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
當前項目中很多場景采用 Redis 隊列和定時任務來處理執(zhí)行時間較長的任務,這些任務執(zhí)行的狀態(tài)和執(zhí)行結果只能通過前端重新發(fā)送請求獲取。
為了優(yōu)化程序體驗,讓用戶盡可能早的關注到任務執(zhí)行結果,我們評估了各種方案。為了降低前后端的溝通成本避免重復造輪子,我們決定采用 Laravel 框架內(nèi)置的廣播功能。
官方推薦采用 pusher 來搭建應用,pusher 的好處是搭建起來非常簡單。但考慮到是國外的服務,存在訪問穩(wěn)定性風險;且目前項目規(guī)模較小,于是嘗試自己搭建 Websocket 服務,使用的就是 Laravel 框架官方提到的 tlaverdure/laravel-echo-server 項目。
這個項目的使用方法可以直接去他們的 github 頁面 獲得,我們看中的幾點如下:
可通過 Redis 的發(fā)布訂閱功能來獲取事件信息并廣播出去,這點的效率要高于向 pusher 的 HTTP API 發(fā)送推送請求;
同時兼容 pusher 的 HTTP API ,如果一些服務無法通過 Redis 發(fā)布事件,則可以采用這種模式推送事件;
我們一開始使用了 oanhnn/laravel-echo-server 這個鏡像來啟動容器,在調(diào)試過程中發(fā)現(xiàn)這個服務并不穩(wěn)定,Node 的服務會在異常時直接退出,這是我們碰到的第一個坑。為了快速解決這個問題,我們再這個鏡像基礎上加入了 supervisor 來負責進行服務進程的退出后重啟的任務,并做成了我們自己的鏡像。
在試用 Redis 訂閱時,除了常規(guī)的數(shù)據(jù)庫地址和密碼等參數(shù)以外,key 前綴是我們碰到的又一個坑,對應在 laravel-echo-server 服務中的 laravel-echo-server.json 文件中的 keyPrefix 配置項,一開始沒有找到正確的方法,無論怎么配置都不對。后來發(fā)現(xiàn)如果想知道要廣播事件的程序當前的 Redis key 前綴是什么,就在 tinker 中執(zhí)行以下腳本即可。
# php artisan tinkerconfig('database.redis.options.prefix');
由于生產(chǎn)環(huán)境采用了 HTTPS 協(xié)議,所以需要給服務增加證書,但因為我是 Node 小白,沒有 Node 程序使用證書的配置經(jīng)驗,所以一輪嘗試之后基本上放棄了,之后采用了 Nginx 代理的方式使用證書,經(jīng)過幾輪嘗試,終于配置成功。
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 廣播將頻道分為:公共、私有和出席(我可能翻譯的不對,請指正),其中后兩者是需要授權訪問。我們需要用到的是私有頻道,只有經(jīng)過授權的人才能從前端訂閱我們的事件。這也是我們遇到的一個坑。
經(jīng)我們觀察和源碼閱讀,發(fā)現(xiàn) laravel-echo 的整體授權過程是:
前端程序先向 laravel-echo-server 服務發(fā)送一個 HTTP POST 請求;
laravel-echo-server 根據(jù)配置中 authEndpoint
和 authHost
這兩項,向應用服務器發(fā)送一個 HTTP POST,POST 數(shù)據(jù)是 channel 名字,同時透傳 header 中的 Authorization 數(shù)據(jù);
laravel-echo-server 會根據(jù)應用服務器的響應來判斷授權結果,如果應用服務器響應的是非 HTTP 200 狀態(tài),就說明發(fā)生了錯誤,授權失敗。
我們在實踐中遇到兩個問題。第一個問題是,我們項目的授權守門邏輯并非 laravel 默認的,所以默認的 Broadcast::routes()
所引入的路由無法直接使用。發(fā)現(xiàn)問題后,我們重新加入了我們自己的授權路由,并配置到 laravel-echo-server.json 的 authEndpoint
配置項中。
另一個問題是,我們沒有采用標準的 RESTFul 協(xié)議規(guī)則:響應對應的 HTTP Code 來描述錯誤狀態(tài)。致使 laravel-echo-server 即便在授權失敗的時候也不能發(fā)現(xiàn)問題并反饋給前端程序,情況類似下圖:
關于“l(fā)aravel-echo-server廣播服務搭建的示例分析”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。