도대체 왜 Node.js를 사용할까요? 사례별 자습서

소개

JavaScript의 인기 상승은 많은 변화를 가져왔고 오늘날 웹 개발의 모습은 극적으로 달라졌습니다. 서버와 브라우저에서 실행되는 JavaScript를 사용하여 오늘날 웹에서 할 수 있는 작업은 몇 년 전에는 상상하기 어려웠거나 Flash 또는 Java Applet과 같은 샌드박스 환경에 캡슐화되었습니다.

Node.js 솔루션을 살펴보기 전에 언어 및 데이터 형식(JSON)을 통합하여 개발자 리소스를 최적으로 재사용할 수 있도록 하는 스택 전체에서 JavaScript를 사용할 때의 이점에 대해 읽어볼 수 있습니다. 이것은 특히 Node.js보다 JavaScript의 이점이 더 많기 때문에 여기에서 많이 논의하지 않습니다. 그러나 스택에 Node를 통합할 때의 주요 이점입니다.

Wikipedia에 따르면 "Node.js는 Google의 V8 JavaScript 엔진, libuv 플랫폼 추상화 계층 및 그 자체가 주로 JavaScript로 작성된 핵심 라이브러리의 패키지 컴파일입니다." 그 외에도 Node.js를 만든 Ryan Dahl은 "Gmail과 같은 응용 프로그램에서 영감을 받은" 푸시 기능이 있는 실시간 웹사이트 를 만드는 것을 목표로 하고 있었습니다. Node.js에서 그는 개발자에게 비차단, 이벤트 중심 I/O 패러다임에서 작업할 수 있는 도구를 제공했습니다.

한 문장으로: Node.js는 웹 소켓을 통한 푸시 기술을 사용하는 실시간 웹 애플리케이션에서 빛을 발합니다. 무엇이 그렇게 혁명적입니까? 음, 상태 비저장 요청-응답 패러다임을 기반으로 한 상태 비저장 웹의 20년 이상 후에 마침내 실시간 양방향 연결이 있는 웹 응용 프로그램이 생겼습니다. . 이것은 클라이언트가 항상 통신을 시작하는 일반적인 웹 응답 패러다임과 완전히 대조됩니다. 또한 표준 포트 80에서 실행되는 개방형 웹 스택(HTML, CSS 및 JS)을 기반으로 합니다.

우리는 이것을 Flash와 Java Applet의 형태로 몇 년 동안 사용해 왔다고 주장할 수도 있습니다. 그러나 실제로는 클라이언트에게 전달할 전송 프로토콜로 웹을 사용하는 샌드박스 환경에 불과했습니다. 또한, 이들은 격리되어 실행되었고 종종 추가 권한 등이 필요할 수 있는 비표준 포트를 통해 운영되었습니다.

모든 장점을 갖춘 Node.js는 이제 고유한 이점에 의존하는 많은 유명 기업의 기술 스택에서 중요한 역할을 합니다. Node.js 재단은 Node.js 재단의 사례 연구 페이지에서 볼 수 있는 짧은 프레젠테이션에서 기업이 Node.js를 고려해야 하는 이유에 대한 모든 최선의 생각을 통합했습니다.

이 Node.js 가이드에서는 이러한 이점을 달성하는 방법뿐 아니라 일부 클래식 웹 애플리케이션 모델을 예로 사용하여 Node.js를 사용하려는 이유와 사용하지 않는 이유 에 대해서도 설명합니다.

어떻게 작동합니까?

Node.js의 주요 아이디어: 비차단, 이벤트 기반 I/O를 사용하여 분산 장치에서 실행되는 데이터 집약적인 실시간 애플리케이션에 직면하여 가볍고 효율적으로 유지합니다.

한 입입니다.

이것이 실제로 의미하는 바는 Node.js가 웹 개발 세계를 지배할 은총 같은 새로운 플랫폼이 아니라는 것입니다. 대신 특정 요구 사항을 충족하는 플랫폼입니다 . 그리고 이것을 이해하는 것은 절대적으로 중요합니다. CPU 집약적인 작업에 Node.js를 사용하고 싶지는 않을 것입니다. 사실, 무거운 계산에 그것을 사용하면 거의 모든 이점이 무효화됩니다. 노드가 정말 빛나는 곳은 빠르고 확장 가능한 네트워크 응용 프로그램을 구축하는 데 있습니다. 높은 처리량으로 많은 수의 동시 연결을 처리할 수 있기 때문에 높은 확장성과 동일합니다.

내부에서 작동하는 방식은 꽤 흥미롭습니다. 각 연결(요청)이 새로운 스레드를 생성하여 시스템 RAM을 차지하고 결국 사용 가능한 RAM의 양을 최대화하는 기존 웹 서비스 기술과 비교하여 Node.js는 비차단 I/ O 호출을 통해 이벤트 루프에 보관된 수만 개의 동시 연결을 지원할 수 있습니다.

빠른 계산: 각 스레드에 잠재적으로 2MB의 메모리가 있다고 가정하고 8GB RAM이 있는 시스템에서 실행하면 이론적으로 최대 4,000개의 동시 연결이 가능합니다 (Michael Abernethy의 기사 "Just what is Node"에서 가져온 계산). .js?”, 2011년 IBM developerWorks에 게시됨, 불행히도 이 기사는 더 이상 볼 수 없음) , 스레드 간 컨텍스트 전환 비용이 추가되었습니다. 이것이 당신이 일반적으로 전통적인 웹 서비스 기술에서 다루는 시나리오입니다. 이 모든 것을 피함으로써 Node.js는 1백만 개 이상의 동시 연결과 60만 개 이상의 동시 웹 소켓 연결의 확장성 수준을 달성합니다.

물론 모든 클라이언트 요청 간에 단일 스레드를 공유하는 문제가 있으며 이는 Node.js 애플리케이션을 작성하는 데 잠재적인 함정입니다. 첫째, 과도한 계산은 Node의 단일 스레드를 질식시킬 수 있으며 해당 계산이 완료될 때까지 들어오는 요청이 차단되기 때문에 모든 클라이언트에 문제를 일으킬 수 있습니다. 두 번째로, 개발자는 핵심(최상위) Node.js 이벤트 루프까지 예외가 발생하지 않도록 정말 주의해야 합니다. 이로 인해 Node.js 인스턴스가 종료됩니다(프로그램이 효과적으로 충돌함).

표면으로 버블링되는 예외를 방지하는 데 사용되는 기술은 오류를 콜백 매개변수로 호출자에게 다시 전달하는 것입니다(다른 환경에서와 같이 오류를 던지는 대신). 처리되지 않은 예외가 발생하더라도 Node.js 프로세스를 모니터링하고 충돌한 인스턴스에 필요한 복구를 수행하기 위한 도구가 개발되었습니다(사용자 세션의 현재 상태를 복구할 수 없을 수도 있음). 가장 일반적인 것은 Forever 모듈이거나 외부 시스템 도구 upstart 및 monit 또는 심지어 upstart와 함께 다른 접근 방식을 사용하는 것입니다.

NPM: 노드 패키지 관리자

Node.js에 대해 논의할 때 분명히 생략해서는 안 되는 한 가지는 모든 Node.js 설치와 함께 기본적으로 제공되는 도구인 NPM을 사용한 패키지 관리에 대한 기본 제공 지원입니다. NPM 모듈의 개념은 Ruby Gems 의 개념과 매우 유사합니다. 공개적으로 사용 가능하고 재사용 가능한 구성 요소 집합으로, 버전 및 종속성 관리와 함께 온라인 저장소를 통해 쉽게 설치하여 사용할 수 있습니다.

패키지된 모듈의 전체 목록은 npm 웹사이트에서 찾거나 Node.js와 함께 자동으로 설치되는 npm CLI 도구를 사용하여 액세스할 수 있습니다. 모듈 생태계는 모두에게 열려 있으며 누구나 npm 저장소에 나열될 자신의 모듈을 게시할 수 있습니다.

오늘날 가장 유용한 npm 모듈은 다음과 같습니다.

• express - Express.js(또는 간단히 Express)는 Sinatra에서 영감을 받은 Node.js용 웹 개발 프레임워크이자 오늘날 대부분의 Node.js 애플리케이션에 대한 사실상의 표준입니다.
• hapi - 웹 및 서비스 애플리케이션 구축을 위한 매우 모듈화되고 사용하기 쉬운 구성 중심 프레임워크
• connect - Connect는 Node.js를 위한 확장 가능한 HTTP 서버 프레임워크로 미들웨어로 알려진 고성능 "플러그인" 모음을 제공합니다. Express의 기본 기반 역할을 합니다.
• socket.io 및 sockjs - 오늘날 가장 일반적인 두 가지 웹 소켓 구성 요소의 서버 측 구성 요소입니다.
• pug (이전 Jade ) - Express.js의 기본값인 HAML에서 영감을 받은 인기 있는 템플릿 엔진 중 하나입니다.
• mongodb 및 mongojs - Node.js에서 MongoDB 개체 데이터베이스용 API를 제공하는 MongoDB 래퍼.
• redis - Redis 클라이언트 라이브러리.
• lodash(밑줄, lazy.js) - JavaScript 유틸리티 벨트입니다. Underscore는 게임을 시작했지만 주로 더 나은 성능과 모듈식 구현으로 인해 두 경쟁자 중 하나에 의해 전복되었습니다.
• 영원히 - 아마도 주어진 노드 스크립트가 지속적으로 실행되도록 하기 위한 가장 일반적인 유틸리티일 것입니다. 예기치 않은 실패에 직면하여 프로덕션에서 Node.js 프로세스를 유지합니다.
• bluebird - 매우 우수한 성능의 완전한 기능을 갖춘 Promises/A+ 구현
• moment - 날짜 구문 분석, 유효성 검사, 조작 및 형식 지정을 위한 JavaScript 날짜 라이브러리입니다.

목록은 계속됩니다. 모두가 사용할 수 있는 정말 유용한 패키지가 많이 있습니다(여기서 생략한 패키지에는 불쾌감을 주지 않습니다).

Node.js를 사용해야 하는 위치의 예

채팅

채팅은 가장 일반적인 실시간 다중 사용자 애플리케이션입니다. IRC(당시)부터 비표준 포트에서 실행되는 많은 독점 및 개방형 프로토콜을 통해 표준 포트 80에서 실행되는 웹 소켓을 사용하여 Node.js에서 모든 것을 구현하는 기능에 이르기까지.

채팅 애플리케이션은 실제로 Node.js의 최적의 예입니다. 분산 장치에서 실행되는 가볍고 트래픽이 많으며 데이터 집약적이지만 처리/계산이 낮은 애플리케이션입니다. 또한 단순하기 때문에 학습을 위한 훌륭한 사용 사례이기도 하지만 일반적인 Node.js 애플리케이션에서 사용하게 될 대부분의 패러다임을 다룹니다.

어떻게 작동하는지 묘사해 봅시다.

가장 간단한 예를 들자면, 우리 웹사이트에 사람들이 와서 일대다(실제로는 모두) 방식으로 메시지를 교환할 수 있는 단일 대화방이 있습니다. 예를 들어 웹사이트에 게시판에 연결된 세 사람이 있다고 가정해 보겠습니다.

서버 측에는 두 가지를 구현하는 간단한 Express.js 애플리케이션이 있습니다.

1. 새 메시지 입력을 초기화하기 위해 게시판과 '보내기' 버튼을 모두 포함하는 웹페이지를 제공하는 GET / 요청 처리기,
2. websocket 클라이언트가 내보낸 새 메시지를 수신 대기하는 websockets 서버입니다.

클라이언트 측에는 두 개의 핸들러가 설정된 HTML 페이지가 있습니다. 하나는 '보내기' 버튼 클릭 이벤트를 위한 것인데, 하나는 입력 메시지를 선택하여 웹 소켓으로 전송하고 다른 하나는 새로운 수신 메시지를 수신합니다. websockets 클라이언트에서 (즉, 서버가 이제 클라이언트가 표시하기를 원하는 다른 사용자가 보낸 메시지).

클라이언트 중 하나가 메시지를 게시하면 다음과 같은 일이 발생합니다.

1. 브라우저는 JavaScript 핸들러를 통해 '보내기' 버튼 클릭을 포착하고 입력 필드(즉, 메시지 텍스트)에서 값을 선택하고 우리 서버에 연결된 웹 소켓 클라이언트를 사용하여 웹 소켓 메시지를 내보냅니다(웹 페이지 초기화 시 초기화됨).
2. websocket 연결의 서버 측 구성 요소는 메시지를 수신하고 브로드캐스트 방법을 사용하여 연결된 다른 모든 클라이언트에 전달합니다.
3. 모든 클라이언트는 웹 페이지 내에서 실행되는 websockets 클라이언트 측 구성 요소를 통해 푸시 메시지로 새 메시지를 받습니다. 그런 다음 메시지 내용을 선택하고 게시판에 새 메시지를 추가하여 웹 페이지를 제자리에 업데이트합니다.

이것은 가장 간단한 예입니다. 보다 강력한 솔루션의 경우 Redis 저장소를 기반으로 하는 간단한 캐시를 사용할 수 있습니다. 또는 훨씬 더 발전된 솔루션에서는 클라이언트에 대한 메시지 라우팅을 처리하는 메시지 대기열과 오프라인 상태일 때 등록된 클라이언트에 대한 임시 연결 손실 또는 메시지 저장을 처리할 수 있는 보다 강력한 전달 메커니즘이 있습니다. 그러나 개선 사항에 관계없이 Node.js는 이벤트에 반응하고, 많은 동시 연결을 처리하고, 사용자 경험의 유동성을 유지하는 것과 같은 동일한 기본 원칙에 따라 계속 작동합니다.

객체 DB 상단의 API

Node.js는 실시간 애플리케이션에서 정말 빛을 발하지만 개체 DB(예: MongoDB)의 데이터를 노출하는 데는 아주 자연스럽게 적합합니다. JSON 저장 데이터를 사용하면 Node.js가 임피던스 불일치 및 데이터 변환 없이 작동할 수 있습니다.

예를 들어, Rails를 사용하는 경우 JSON에서 바이너리 모델로 변환한 다음 Backbone.js, Angular.js, 또는 일반 jQuery AJAX에서 데이터를 사용할 때 HTTP를 통해 JSON으로 다시 노출합니다. 전화. Node.js를 사용하면 클라이언트가 사용할 REST API를 사용하여 JSON 개체를 간단히 노출할 수 있습니다. 또한 데이터베이스에서 읽거나 쓸 때 JSON과 다른 무엇이든 변환하는 것에 대해 걱정할 필요가 없습니다(MongoDB를 사용하는 경우). 요컨대, 클라이언트, 서버 및 데이터베이스 전반에 걸쳐 균일한 데이터 직렬화 형식을 사용하여 다중 변환의 필요성을 피할 수 있습니다.

대기 중인 입력

많은 양의 동시 데이터를 수신하는 경우 데이터베이스에 병목 현상이 발생할 수 있습니다. 위에서 설명한 것처럼 Node.js는 동시 연결 자체를 쉽게 처리할 수 있습니다. 그러나 데이터베이스 액세스는 차단 작업(이 경우)이므로 문제가 발생합니다. 솔루션은 데이터가 실제로 데이터베이스에 기록되기 전에 클라이언트의 동작을 확인하는 것입니다.

이 접근 방식을 사용하면 시스템이 과부하 상태에서 응답성을 유지하므로 클라이언트가 성공적인 데이터 쓰기에 대한 확고한 확인이 필요하지 않을 때 특히 유용합니다. 일반적인 예에는 다음이 포함됩니다. 사용자 추적 데이터의 기록 또는 쓰기, 일괄 처리 및 나중에 사용 뿐만 아니라 최종 일관성(NoSQL 세계에서 자주 사용됨)이 허용되는 즉시 반영할 필요가 없는 작업(Facebook의 '좋아요' 수 업데이트 등).

데이터는 RabbitMQ 또는 ZeroMQ와 같은 일종의 캐싱 또는 메시지 대기열 인프라를 통해 대기열에 들어가고 이러한 작업에 대해 더 나은 성능을 제공하는 플랫폼에서 작성된 별도의 데이터베이스 일괄 쓰기 프로세스 또는 계산 집약적인 처리 백엔드 서비스에 의해 요약됩니다. 다른 언어/프레임워크에서도 유사한 동작을 구현할 수 있지만 동일한 하드웨어에서는 동일하게 높은 처리량을 유지 관리할 수 없습니다.

요컨대: Node를 사용하면 데이터베이스 쓰기를 옆으로 밀고 나중에 성공한 것처럼 처리할 수 있습니다.

데이터 스트리밍

보다 전통적인 웹 플랫폼에서 HTTP 요청 및 응답은 격리된 이벤트처럼 처리됩니다. 사실, 그들은 실제로 스트림입니다. 이 관찰은 몇 가지 멋진 기능을 구축하기 위해 Node.js에서 활용될 수 있습니다. 예를 들어, 데이터가 스트림을 통해 들어오고 온라인 방식으로 처리할 수 있기 때문에 파일이 아직 업로드되는 동안 파일을 처리할 수 있습니다. 이것은 실시간 오디오 또는 비디오 인코딩과 서로 다른 데이터 소스 간의 프록시를 위해 수행될 수 있습니다(다음 섹션 참조).

대리

Node.js는 비차단 방식으로 많은 양의 동시 연결을 처리할 수 있는 서버 측 프록시로 쉽게 사용됩니다. 응답 시간이 다른 여러 서비스를 프록시하거나 여러 소스 지점에서 데이터를 수집하는 데 특히 유용합니다.

예: 타사 리소스와 통신하거나, 다른 소스에서 데이터를 가져오거나, 이미지 및 비디오와 같은 자산을 타사 클라우드 서비스에 저장하는 서버 측 애플리케이션을 고려하십시오.

전용 프록시 서버가 존재하지만 프록시 인프라가 없거나 로컬 개발을 위한 솔루션이 필요한 경우 대신 노드를 사용하는 것이 도움이 될 수 있습니다. 즉, 자산 및 프록시/스텁 API 요청을 위한 Node.js 개발 서버로 클라이언트 측 앱을 빌드할 수 있는 반면 프로덕션에서는 전용 프록시 서비스(nginx, HAProxy 등)와의 상호 작용을 처리할 수 있습니다. .).

중개 - 주식 거래자의 대시보드

다시 응용 프로그램 수준으로 돌아가 보겠습니다. 데스크탑 소프트웨어가 지배적이지만 실시간 웹 솔루션으로 쉽게 대체될 수 있는 또 다른 예는 주식 가격을 추적하고 계산/기술적 분석을 수행하고 그래프/차트를 생성하는 데 사용되는 브로커의 거래 소프트웨어입니다.

실시간 웹 기반 솔루션으로 전환하면 브로커가 워크스테이션이나 작업 장소를 쉽게 전환할 수 있습니다. 머지 않아 우리는 플로리다.. 또는 이비자.. 또는 발리의 해변에서 그들을 보기 시작할 것입니다.

애플리케이션 모니터링 대시보드

Node-with-web-sockets가 완벽하게 맞는 또 다른 일반적인 사용 사례는 웹사이트 방문자를 추적하고 실시간으로 상호작용을 시각화하는 것입니다.

사용자로부터 실시간 통계를 수집하거나 방문자가 유입경로의 특정 지점에 도달했을 때 커뮤니케이션 채널을 열어 방문자와 표적화된 상호작용을 도입하여 다음 수준으로 이동할 수도 있습니다. (관심이 있다면 이 아이디어는 이미 CANDDi에서 제품화되고 있습니다.)

방문자가 실시간으로 무엇을 하고 있는지 알고 있다면, 즉 방문자의 상호 작용을 시각화할 수 있다면 비즈니스를 어떻게 개선할 수 있는지 상상해 보십시오. Node.js의 실시간 양방향 소켓으로 이제 가능합니다.

시스템 모니터링 대시보드

이제 인프라 측면을 살펴보겠습니다. 예를 들어 GitHub의 상태 페이지와 같은 서비스 모니터링 페이지를 사용자에게 제공하려는 SaaS 공급자를 상상해 보십시오. Node.js 이벤트 루프를 사용하면 비동기 방식으로 서비스 상태를 확인하고 웹 소켓을 사용하여 데이터를 클라이언트에 푸시하는 강력한 웹 기반 대시보드를 만들 수 있습니다.

이 기술을 사용하여 내부(회사 내) 및 공공 서비스의 상태를 실시간으로 보고할 수 있습니다. 그 아이디어를 조금 더 확장하고 통신 사업자, 클라우드/네트워크/호스팅 제공업체 또는 일부 금융 기관의 NOC(네트워크 운영 센터) 모니터링 애플리케이션이 모두 Node.js 및 웹 소켓으로 지원되는 개방형 웹 스택에서 실행되는 것을 상상해 보십시오. Java 및/또는 Java 애플릿 대신.

Node.js를 사용할 수 있는 곳

서버 측 웹 애플리케이션

Express.js가 있는 Node.js는 서버 측에서 클래식 웹 애플리케이션을 만드는 데에도 사용할 수 있습니다. 그러나 가능한 동안 Node.js가 렌더링된 HTML을 운반하는 이 요청-응답 패러다임은 가장 일반적인 사용 사례가 아닙니다. 이 접근 방식에 대해 찬성과 반대의 주장이 있습니다. 다음은 고려해야 할 몇 가지 사실입니다.

장점:

• 애플리케이션에 CPU 집약적인 계산이 없는 경우 MongoDB와 같은 JSON 스토리지 개체 ​​DB를 사용하는 경우 데이터베이스 수준까지 자바스크립트에서 위에서 아래로 빌드할 수 있습니다. 이것은 개발(고용 포함)을 상당히 용이하게 합니다.
• 크롤러는 단일 페이지 애플리케이션이나 Node.js 위에서 실행되는 웹 소켓 앱보다 훨씬 더 SEO 친화적인 완전히 렌더링된 HTML 응답을 받습니다.

단점:

• CPU를 많이 사용하는 계산은 Node.js 응답을 차단하므로 스레드 플랫폼이 더 나은 접근 방식입니다. 또는 계산 [*]을 확장해 볼 수 있습니다.
• 관계형 데이터베이스와 함께 Node.js를 사용하는 것은 여전히 ​​어려운 일입니다(자세한 내용은 아래 참조). 관계형 작업을 수행하려는 경우 자신에게 호의를 베풀고 Rails, Django 또는 ASP.Net MVC와 같은 다른 환경을 선택하십시오.

Node.js를 사용하면 안되는 곳

뒤에 관계형 DB가 있는 서버 측 웹 애플리케이션

예를 들어 Node.js와 Express.js를 Ruby on Rails와 비교하면 PostgreSQL, MySQL, Microsoft SQL Server와 같은 관계형 데이터베이스에 액세스할 때 후자를 선호하는 명확한 결정이 있었습니다.

Node.js용 관계형 DB 도구는 아직 초기 단계였습니다. 반면에 Rails는 DB 스키마 마이그레이션 지원 도구 및 기타 Gem(말장난 의도)과 함께 즉시 데이터 액세스 설정을 자동으로 제공합니다. Rails 및 해당 피어 프레임워크는 성숙하고 입증된 Active Record 또는 Data Mapper 데이터 액세스 계층 구현을 가지고 있습니다.[*]

하지만 상황이 바뀌었습니다. Sequelize, TypeORM 및 Bookshelf는 성숙한 ORM 솔루션이 되기 위해 먼 길을 왔습니다. GraphQL 쿼리에서 SQL을 생성하려는 경우 Join Monster를 확인하는 것도 좋습니다.

HEAVY 서버 측 계산/처리

계산량이 많은 경우 Node.js는 최고의 플랫폼이 아닙니다. 아니요, Node.js에서 피보나치 계산 서버를 구축하고 싶지는 않을 것입니다. 일반적으로 모든 CPU 집약적 작업은 스레드가 숫자 처리로 점유되는 동안 들어오는 요청이 차단되기 때문에 이벤트 중심의 비차단 I/O 모델로 노드가 제공하는 모든 처리량 이점을 무효화합니다. 요청에 응답하는 것과 동일한 노드 인스턴스에서 계산을 실행합니다.

앞서 언급했듯이 Node.js는 단일 스레드이며 단일 CPU 코어만 사용합니다. 멀티 코어 서버에 동시성을 추가하는 경우 노드 코어 팀에서 클러스터 모듈의 형태로 일부 작업을 수행하고 있습니다[ref: http://nodejs.org/api/cluster.html]. 또한 nginx를 통해 역 프록시 뒤에서 여러 Node.js 서버 인스턴스를 매우 쉽게 실행할 수 있습니다.

클러스터링을 사용하면 더 적절한 환경에서 작성된 백그라운드 프로세스로 모든 무거운 계산을 오프로드하고 RabbitMQ와 같은 메시지 대기열 서버를 통해 통신하도록 해야 합니다.

백그라운드 처리가 처음에 동일한 서버에서 실행될 수 있지만 이러한 접근 방식은 확장성이 매우 높을 가능성이 있습니다. 이러한 백그라운드 처리 서비스는 전면 웹 서버의 로드를 구성할 필요 없이 별도의 작업자 서버에 쉽게 배포될 수 있습니다.

물론 다른 플랫폼에서도 동일한 접근 방식을 사용하지만 Node.js를 사용하면 각 요청이 매우 빠르고 효율적으로 처리되는 작은 작업이기 때문에 우리가 이야기한 높은 reqs/sec 처리량을 얻을 수 있습니다.

결론

우리는 Node.js의 목표와 야망에서 시작하여 스위트 스폿과 함정으로 끝나는 이론부터 실습까지 Node.js에 대해 논의했습니다. 사람들이 Node에 문제가 생기면 거의 항상 차단 작업이 모든 악의 근원 이라는 사실로 귀결됩니다. Node 오용의 99%는 직접적인 결과입니다.

기억하십시오: Node.js는 컴퓨팅 확장 문제를 해결하기 위해 생성된 것이 아닙니다. I/O 스케일링 문제를 해결하기 위해 만들어졌는데, 정말 잘합니다.

Node.js를 사용하는 이유 사용 사례에 CPU 집약적 작업이 포함되지 않고 차단 리소스에 액세스하지 않는 경우 Node.js의 이점을 활용하고 빠르고 확장 가능한 네트워크 애플리케이션을 즐길 수 있습니다. 실시간 웹에 오신 것을 환영합니다.