Chỉ sử dụng Node.js so với sử dụng Node.js với Apache / Nginx


224

Trong trường hợp nào người ta chỉ nên sử dụng Node.js làm máy chủ khi triển khai thực sự?

Khi một người không muốn chỉ sử dụng Node.js, cái gì chơi tốt hơn với Node.js? Apache hay Nginx?

Câu trả lời:


207

Có một số lý do chính đáng để gắn một máy chủ web khác trước Node.js:

  • Không phải lo lắng về đặc quyền / setuid cho quy trình Node.js. Chỉ root mới có thể liên kết với cổng 80 thông thường. Nếu bạn để nginx / Apache lo lắng về việc bắt đầu với quyền root, liên kết với cổng 80 và sau đó từ bỏ các đặc quyền gốc của nó, điều đó có nghĩa là ứng dụng Node của bạn không phải lo lắng về điều đó.
  • Phục vụ các tệp tĩnh như hình ảnh, css, js và html. Nút có thể kém hiệu quả hơn so với việc sử dụng máy chủ web tệp tĩnh thích hợp (Nút cũng có thể nhanh hơn trong các tình huống được chọn, nhưng điều này không chắc là chuẩn mực). Ngoài các tệp phục vụ hiệu quả hơn, bạn sẽ không phải lo lắng về việc xử lý các tiêu đề eTags hoặc bộ điều khiển bộ đệm theo cách bạn sẽ làm nếu bạn phục vụ mọi thứ ngoài Node. Một số khung có thể xử lý việc này cho bạn, nhưng bạn sẽ muốn chắc chắn. Bất kể, có lẽ vẫn chậm hơn.
  • Như Matt Sergeant đã đề cập trong câu trả lời của anh ấy, bạn có thể dễ dàng hiển thị các trang lỗi có ý nghĩa hơn hoặc quay lại trang web tĩnh nếu dịch vụ nút của bạn gặp sự cố. Nếu không, người dùng có thể nhận được kết nối đã hết thời gian.
  • Chạy một máy chủ web khác trước Node có thể giúp giảm thiểu các lỗi bảo mật và các cuộc tấn công DoS chống lại Node. Đối với một ví dụ thực tế, bản tin CVE-2013-4450 được ngăn ngừa bằng cách chạy một cái gì đó giống như Nginx trước Node .

Tôi sẽ báo trước điểm đạn thứ hai bằng cách nói rằng có lẽ bạn nên phục vụ các tệp tĩnh của mình thông qua CDN hoặc từ phía sau máy chủ bộ đệm như Varnish. Nếu bạn đang làm điều này, điều đó không thực sự quan trọng nếu nguồn gốc là Node hoặc Nginx hoặc Apache.

Hãy cẩn thận với nginx cụ thể: nếu bạn đang sử dụng websockets, hãy đảm bảo sử dụng phiên bản nginx gần đây (> = 1.3.13), vì nó chỉ thêm hỗ trợ để nâng cấp kết nối để sử dụng websockets.


11
express.staticsẽ xử lý ETags và tiêu đề kiểm soát bộ đệm tốt.
robertklep


4
pauljz, bạn có điểm chuẩn để sao lưu chậm hơn? các bài viết @pawlakpp chỉ ra dường như nói Node.js nhanh hơn nhiều khi tải.
Samuel Neff

3
Có một số cuộc thảo luận liên quan ở đây: stackoverflow.com/questions/9967887/ trên với một số quan điểm bổ sung. Các điểm chuẩn ở đó (vì bạn đã yêu cầu điểm chuẩn bổ sung) hiển thị node.js / express, thậm chí được nhóm lại, hoạt động kém đáng chú ý. Tôi cảm thấy tốt nhất là giữ cho việc phục vụ tệp tĩnh và yêu cầu xử lý hoàn toàn khỏi vòng lặp sự kiện nút, lưu các chu trình đó cho công việc cần thực hiện trong Node. Nhưng thành thật mà nói, nếu bạn phục vụ các công cụ tĩnh ngoài Node, bạn cũng sẽ ổn thôi. Nó không phải là một việc lớn.
pauljz

4
Cần lưu ý rằng nếu bạn chỉ sử dụng nút trực tiếp, bạn vẫn có thể liên kết với các cổng dành riêng như :80không chạy nút gốc bằng cách sử dụng authbind: thomashunter.name/blog/USE-authbind-with-node-js
wyqydsyq

70

Chỉ cần thêm một lý do nữa cho câu trả lời của pauljz, tôi sử dụng máy chủ ngoại vi để nó có thể phục vụ 502 trang lỗi khi tôi khởi động lại máy chủ phụ trợ hoặc vì lý do nào đó. Điều này cho phép người dùng của bạn không bao giờ gặp lỗi về việc không thể thiết lập kết nối.


28

Tôi tin rằng việc sử dụng Node để phục vụ các tệp tĩnh là tốt trong mọi trường hợp miễn là bạn biết bạn đang làm gì . Đây chắc chắn là một mô hình mới để sử dụng máy chủ ứng dụng để phục vụ các tệp tĩnh vì rất nhiều công nghệ cạnh tranh (mọi?) (PHP, Ruby, Python, v.v.) yêu cầu máy chủ web như HTTPD hoặc Nginx trước máy chủ ứng dụng .

Mọi lý do khách quan mà tôi từng đọc chống lại việc phục vụ các tệp tĩnh với Node đều xoay quanh ý tưởng sử dụng những gì bạn biết rõ nhất hoặc sử dụng những gì được coi là được kiểm tra tốt hơn / ổn định hơn. Đây là những lý do rất hợp lệ trên thực tế, nhưng ít liên quan đến kỹ thuật.

Trừ khi bạn tìm thấy một tính năng có thể có với một máy chủ web cổ điển không thể có với Node (và tôi nghi ngờ bạn sẽ làm thế), hãy chọn những gì bạn biết rõ nhất hoặc những gì bạn thích làm việc với cả hai cách tiếp cận đều tốt.

Đối với Nginx vs Apache - họ sẽ "chơi" với Node giống nhau. Bạn nên so sánh chúng mà không cần quan tâm đến Node.


2
Quan điểm tốt về so sánh kỹ thuật nói chung: "Mọi lý do khách quan tôi từng đọc khi phục vụ các tệp tĩnh với Node đều xoay quanh ý tưởng sử dụng những gì bạn biết rõ nhất hoặc sử dụng những gì được coi là được kiểm tra tốt hơn / ổn định hơn. Đây là những lý do rất hợp lệ. thực tế mà nói, nhưng có chút liên quan thuần túy về mặt kỹ thuật. " Quá nhiều so sánh ngày nay là sai lệch và dựa trên hành lý của kinh nghiệm và mức độ thoải mái về các công nghệ kém hơn nhưng được thử nghiệm theo thời gian.
Nắng

Có nhưng họ thực sự / chủ quan / lý do. Một ví dụ tuyệt vời về lý do khách quan sẽ là điểm chuẩn - hầu hết trong số đó tôi thấy chỉ ra nginx> nodejs (mặc dù tôi thực sự nên tự làm ....)
Nick

@Nick Bạn hoàn toàn đúng. Và có một vài cái ở ngoài đó mặc dù tôi không phải là chuyên gia về chấm điểm khoa học nên tôi sẽ cho phép mọi người tìm kiếm trên web. Những gì tôi sẽ nói mặc dù tôi nghĩ rằng có một lợi ích cho sự đơn giản của việc sử dụng một máy chủ thay vì hai. Chỉ có ít tiềm năng cho một cái gì đó đi sai. Mặt khác, Nginx thường có một gói trên tất cả các Unix như hệ thống với cấu hình tốt trong khi với Node bạn cần phải tìm ra tích hợp với systemd, pm2vv Vì vậy, có mặt được, chưa và người dùng nên chọn chất độc của họ, có thể nói .

Tôi nghĩ đó là điều ngược lại - nút sẽ hoạt động tốt hơn khi tải (có lẽ không phải ở tốc độ không tải thuần túy) bởi vì nó không phải xử lý một quá trình phục vụ một tệp theo yêu cầu, mà có thể đẩy dữ liệu khi đĩa cục bộ hoặc máy khách từ xa đã sẵn sàng trên cùng một luồng mà tất cả hàng ngàn máy khách khác đang bật. Điều này tất nhiên bị hỏng khi bạn có nhiều bộ xử lý .. Trừ khi nút biết cách sử dụng chúng ngay bây giờ. Hoặc máy chủ web có thể sử dụng đa nhiệm hợp tác để lưu trữ các trang tĩnh ngay bây giờ ..
Gerard ONeill

1

Một bổ sung: Điều quan trọng nữa là nếu bạn cần Reverse Proxy, ví dụ để thực thi Máy chủ Websocket trên cùng một cổng hoặc có thể trộn một số techonlogies (trả lời với NodeJS một số yêu cầu và với PHP một số yêu cầu khác hoặc bất cứ điều gì khác)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.