分享laravel-echo-server廣播服務(wù)搭建

2314

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

下面由laravel教程欄目給大家介紹laravel-echo-server廣播服務(wù)搭建，希望對需要的朋友有所幫助！

分享laravel-echo-server廣播服務(wù)搭建

動機

當前項目中很多場景采用 redis 隊列和定時任務(wù)來處理執(zhí)行時間較長的任務(wù)，這些任務(wù)執(zhí)行的狀態(tài)和執(zhí)行結(jié)果只能通過前端重新發(fā)送請求獲取。

目標

為了優(yōu)化程序體驗，讓用戶盡可能早的關(guān)注到任務(wù)執(zhí)行結(jié)果，我們評估了各種方案。為了降低前后端的溝通成本避免重復(fù)造輪子，我們決定采用 Laravel 框架內(nèi)置的廣播功能。

選擇服務(wù)

官方推薦采用 pusher 來搭建應(yīng)用，pusher 的好處是搭建起來非常簡單。但考慮到是國外的服務(wù)，存在訪問穩(wěn)定性風險；且目前項目規(guī)模較小，于是嘗試自己搭建 Websocket 服務(wù)，使用的就是 Laravel 框架官方提到的 tlaverdure/laravel-echo-server 項目。

laravel-echo-server 服務(wù)特點

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

  1. 可通過 Redis 的發(fā)布訂閱功能來獲取事件信息并廣播出去，這點的效率要高于向 pusher 的 HTTP API 發(fā)送推送請求；
  2. 同時兼容 pusher 的 HTTP API ，如果一些服務(wù)無法通過 Redis 發(fā)布事件，則可以采用這種模式推送事件；

搭建 Websocket 服務(wù)

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

Redis 訂閱

在試用 Redis 訂閱時，除了常規(guī)的數(shù)據(jù)庫地址和密碼等參數(shù)以外，key 前綴是我們碰到的又一個坑，對應(yīng)在 laravel-echo-server 服務(wù)中的 laravel-echo-server.json 文件中的 ?keyPrefix 配置項，一開始沒有找到正確的方法，無論怎么配置都不對。后來發(fā)現(xiàn)如果想知道要廣播事件的程序當前的 Redis key 前綴是什么，就在 tinker 中執(zhí)行以下腳本即可。

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

Nginx 代理

由于生產(chǎn)環(huán)境采用了 HTTPS 協(xié)議，所以需要給服務(wù)增加證書，但因為我是 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"; ????}}

私有/出席頻道授權(quán)

Laravel 廣播將頻道分為：公共、私有和出席（我可能翻譯的不對，請指正），其中后兩者是需要授權(quán)訪問。我們需要用到的是私有頻道，只有經(jīng)過授權(quán)的人才能從前端訂閱我們的事件。這也是我們遇到的一個坑。

經(jīng)我們觀察和源碼閱讀，發(fā)現(xiàn) laravel-echo 的整體授權(quán)過程是：

  1. 前端程序先向 laravel-echo-server 服務(wù)發(fā)送一個 HTTP POST 請求；
  2. laravel-echo-server 根據(jù)配置中 authEndpoint 和 authHost 這兩項，向應(yīng)用服務(wù)器發(fā)送一個 HTTP POST，POST 數(shù)據(jù)是 channel 名字，同時透傳 header 中的 Authorization 數(shù)據(jù)；
  3. laravel-echo-server 會根據(jù)應(yīng)用服務(wù)器的響應(yīng)來判斷授權(quán)結(jié)果，如果應(yīng)用服務(wù)器響應(yīng)的是非 HTTP 200 狀態(tài)，就說明發(fā)生了錯誤，授權(quán)失敗。

我們在實踐中遇到兩個問題。第一個問題是，我們項目的授權(quán)守門邏輯并非 laravel 默認的，所以默認的 Broadcast::routes() 所引入的路由無法直接使用。發(fā)現(xiàn)問題后，我們重新加入了我們自己的授權(quán)路由，并配置到 laravel-echo-server.json 的 authEndpoint 配置項中。

另一個問題是，我們沒有采用標準的 RESTFul 協(xié)議規(guī)則：響應(yīng)對應(yīng)的 HTTP Code 來描述錯誤狀態(tài)。致使 laravel-echo-server 即便在授權(quán)失敗的時候也不能發(fā)現(xiàn)問題并反饋給前端程序，情況類似下圖：

分享laravel-echo-server廣播服務(wù)搭建

遲早還是要還債的…

總結(jié)

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

  1. laravel-echo-server 沒有預(yù)想的那么健壯，以后有時間還得找找替代方案，貌似也有用 swoole 做的項目，可以嘗試一下；
  2. 預(yù)先忘記考慮到 SSL 的問題，導(dǎo)致發(fā)布時臨時處理得手忙腳亂；
  3. laravel-echo-server 和 laravel-echo 本身都是很小的項目，遇到問題應(yīng)該優(yōu)先考慮去分析其代碼減少嘗試的時間。

以上就是分享

? 版權(quán)聲明
THE END
PHP框架
# laravel
喜歡就支持一下吧
點贊14 分享