laravel-echo-server 방송 서비스 구축 공유

                                                        Ar 다음은 aLaravel

튜토리얼 칼럼의 labavel-Echo-Server 방송 서비스입니다. 도움이 필요한 친구들에게 도움이 되길 바랍니다!

동기

현재 프로젝트의 많은 시나리오는 Redis 대기열과 예약된 작업을 사용하여 실행하는 데 오랜 시간이 걸리는 작업을 처리합니다. 이러한 작업의 실행 상태 및 실행 결과는 요청을 다시 보내야만 얻을 수 있습니다. 프런트 엔드에서.

Goal

프로그램 경험을 최적화하고 사용자가 작업 실행 결과에 최대한 빨리 주의를 기울일 수 있도록 다양한 옵션을 평가했습니다. 프런트엔드와 백엔드 간의 통신 비용을 줄이고 바퀴를 재발명하는 것을 피하기 위해 우리는 Laravel 프레임워크에 내장된 브로드캐스트 기능을 사용하기로 결정했습니다.

서비스 선택

푸셔를 사용하여 애플리케이션을 구축하는 것을 공식적으로 권장합니다. 푸셔의 장점은 구축이 매우 간단하다는 것입니다. 다만, 해외 서비스라는 점을 고려하면 접근 안정성에 대한 위험성이 있고, 현재 프로젝트 규모도 작기 때문에, 공식적으로 언급한 tlaverdure/laravel-echo-server 프로젝트를 이용하여 직접 웹소켓 서비스를 구축해 보았습니다. 라라벨 프레임워크.

laravel-echo-server 서비스 기능

이 프로젝트의 사용 방법은 github 페이지에서 직접 확인할 수 있습니다. 다음 사항이 마음에 듭니다.

이벤트 정보는 게시 및 구독 기능을 통해 얻을 수 있습니다. Redis. 이는 pusher의 HTTP API로 푸시 요청을 보내는 것보다 더 효율적입니다.

Pusher의 HTTP API와도 호환됩니다. 일부 서비스가 Redis를 통해 이벤트를 게시할 수 없는 경우 이 모드를 사용하여 이벤트를 푸시할 수 있습니다.

Websocket 서비스 구축
1. 처음에는 oanhnn/laravel-echo-server 이미지를 사용하여 컨테이너를 시작했습니다. 디버깅 프로세스 중에 예외가 발생하면 Node 서비스가 바로 종료되는 것을 발견했습니다. 우리가 만난 첫 번째 구덩이입니다. 이 문제를 빠르게 해결하기 위해 이 이미지를 기반으로 종료 후 서비스 프로세스를 다시 시작하는 작업을 담당할 Supervisor를 추가하고 자체 이미지를 만들었습니다.

Redis 구독Redis 구독을 시도할 때 일반 데이터베이스 주소, 비밀번호 및 기타 매개변수 외에도 키 접두사는 우리가 직면한 또 다른 함정입니다. 이는 laravel-echo-의 laravel-echo-에 해당합니다. server service server.json 파일의 keyPrefix 구성 항목이 처음에 올바른 방법을 찾지 못했고 어떻게 구성했는지에 관계없이 잘못된 것입니다. 나중에 이벤트를 브로드캐스팅하려는 프로그램의 현재 Redis 키 접두사를 알고 싶다면 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의 전체 인증 프로세스는 다음과 같습니다.

프런트 엔드 프로그램은 먼저 laravel-echo-server 서비스에 HTTP POST 요청을 보냅니다.

laravel- authEndpoint 및 authHost 구성에 따른 echo-server는 HTTP POST를 애플리케이션 서버에 보냅니다. POST 데이터는 채널 이름이며 헤더의 인증 데이터를 투명하게 전송합니다.

laravel-echo-server는 애플리케이션 서버의 응답에 따라 인증 결과를 결정합니다. 애플리케이션 서버가 HTTP 200이 아닌 상태로 응답하면 오류가 발생하여 인증에 실패한 것입니다.

실제로 우리는 두 가지 문제에 직면합니다. 첫 번째 문제는 우리 프로젝트의 인증 게이트키핑 로직이 laravel의 기본값이 아니기 때문에 기본 Broadcast::routes()에 의해 도입된 경로를 직접 사용할 수 없다는 것입니다. 문제를 발견한 후 자체 인증 경로를 다시 추가하고 laravel-echo-server.json의 authEndpoint 구성 항목에 구성했습니다.

1. 또 다른 문제는 표준 RESTFul 프로토콜 규칙(오류 상태를 설명하기 위한 응답 해당 HTTP 코드)을 사용하지 않는다는 것입니다. 결과적으로 laravel-echo-server는 인증이 실패하더라도 문제를 감지하지 못하고 프론트엔드 프로그램에 대한 피드백을 제공하지 못합니다. 상황은 아래 그림과 유사합니다:

   

   조만간 부채를 상환해야 합니다. ...

   Summary

   이 기능 개발은 원래 생각만큼 원활하지 않습니다. 주요 문제는 다음과 같습니다.

   1. laravel-echo-server는 예상만큼 강력하지 않습니다. 나중에 시간이 나면 대안을 찾아봐야겠습니다. swoole을 사용하는 프로젝트도 있는 것 같습니다.
   2. SSL 문제를 미리 고려하는 것을 잊어버려서 급하게 처리하게 되었습니다. release;
   3. laravel-echo-server 및 laravel-echo 자체는 소규모 프로젝트이므로 문제가 발생하면 코드 분석에 우선순위를 두어야 합니다. 시도하는 데 소요되는 시간을 줄이세요.

위 내용은 laravel-echo-server 방송 서비스 구축 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!