Vòng lặp sự kiện Node.js - nginx/apache

Question

Cả nginx và Node.js đều có vòng lặp sự kiện để xử lý các yêu cầu. Tôi đặt nginx trước Node.js như đã được khuyến cáo ở đây

Using Node.js only vs. using Node.js with Apache/Nginx

với các thiết lập hiển thị ở đây

Node.js + Nginx - What now?

1. Làm thế nào để hai vòng kiện chơi với nhau? Có nguy cơ xung đột nào giữa hai người không? Tôi tự hỏi vì Nginx có thể không xử lý được nhiều sự kiện mỗi giây như Node.js hoặc ngược lại. Ví dụ: nếu Nginx có thể xử lý 1000 sự kiện mỗi giây nhưng node.js chỉ 500, điều đó có gây ra sự cố không? (Tôi không có ý tưởng nếu 1000.500 là các đơn đặt hàng hợp lý về độ lớn, bạn có thể sửa tôi trên đó.)

2. Điều gì về việc đặt Apache trước Node.js? Apache không có vòng lặp sự kiện. Chỉ chủ đề. Vì vậy, sẽ không đặt Apache trước Node.js đánh bại mục đích?

3. Trong this 2010 talk, người sáng tạo Node.js Ryan Dahl có tầm nhìn để loại bỏ nginx/apache/bất kỳ điều gì và làm cho nút trò chuyện trực tiếp với internet. Khi nào bạn nghĩ điều này sẽ là hiện thực?

Answer 1

1. Cả nginx và nút đều sử dụng phương pháp không đồng bộ và theo hướng sự kiện.Các thông tin liên lạc giữa họ sẽ đi nhiều hơn hoặc ít hơn như thế này:

   • nginx nhận được yêu cầu
   • nginx sẽ chuyển yêu cầu đến quá trình Node và ngay lập tức quay ngược lại để chờ đợi để biết thêm yêu cầu
   • Node nhận được yêu cầu từ nginx
   • Nút xử lý yêu cầu với mức sử dụng CPU tối thiểu, cho đến một lúc nào đó, nó cần phát hành một hoặc nhiều yêu cầu I/O (đọc từ cơ sở dữ liệu, viết phản hồi, v.v.). Tại thời điểm này, nó khởi chạy tất cả các yêu cầu I/O này và quay trở lại để chờ đợi thêm yêu cầu.
   • Điều trên có thể lặp lại nhiều lần. Bạn có thể có hàng trăm nghìn yêu cầu tất cả trong trạng thái chờ không chặn, trong đó nginx đang đợi Node và Node đang đợi I/O. Và trong khi điều này xảy ra cả nginx và Node đều sẵn sàng chấp nhận nhiều yêu cầu hơn nữa!
   • Cuối cùng, không đồng bộ I/O bắt đầu bằng quy trình Node sẽ hoàn thành và chức năng gọi lại sẽ được gọi.
   • Nếu vẫn còn các yêu cầu I/O chưa hoàn thành cho yêu cầu này, thì Node sẽ quay lại vòng lặp của nó một lần nữa. Nó cũng có thể xảy ra khi một hoạt động I/O hoàn thành dữ liệu này được gọi lại bởi Node callback và sau đó I/O mới cần phải xảy ra, vì vậy Node có thể bắt đầu các yêu cầu I/O không đồng bộ trước khi quay trở lại vòng lặp.
   • Cuối cùng, tất cả các hoạt động I/O bắt đầu bằng Nút cho một yêu cầu cụ thể sẽ được hoàn thành, bao gồm cả những hoạt động viết phản hồi lại cho nginx. Vì vậy, nút kết thúc yêu cầu này, và sau đó như mọi khi quay trở lại vòng lặp của nó.
   • nginx nhận được sự kiện cho biết rằng dữ liệu phản hồi đã đến cho một yêu cầu, do đó, dữ liệu đó sẽ lấy và ghi lại cho khách hàng, một lần nữa theo kiểu không bị chặn. Khi câu trả lời đã được viết cho khách hàng và sự kiện sẽ kích hoạt và nginx sau đó sẽ kết thúc yêu cầu.

   Bạn đang hỏi về điều gì sẽ xảy ra nếu nginx và Node có thể xử lý số lượng kết nối tối đa khác nhau. Họ thực sự không có tối đa, tối đa nói chung đến từ cấu hình hệ điều hành, ví dụ từ số lượng tối đa mở xử lý hệ thống có thể có tại một thời gian hoặc thông qua CPU. Vì vậy, câu hỏi của bạn không thực sự áp dụng. Nếu hệ thống được cấu hình đúng và tất cả các quy trình là I/O bị ràng buộc, cả nginx hoặc Node sẽ không bao giờ chặn.

2. Đặt Apache ở phía trước Nút sẽ chỉ hoạt động tốt nếu bạn có thể đảm bảo rằng Apache của bạn không bao giờ chặn (tức là nó không bao giờ đạt đến giới hạn kết nối tối đa). Điều này là khó khăn/không thể đạt được cho số lượng lớn các kết nối, bởi vì Apache sử dụng một quá trình riêng lẻ hoặc luồng cho mỗi kết nối. nginx và Node thực sự tốt, Apache thì không.

3. Chạy nút mà không có máy chủ khác ở phía trước hoạt động tốt và sẽ không sao cho các trang web tải nhỏ/vừa. Lý do đặt một máy chủ web ở phía trước của nó là ưa thích là các máy chủ web như nginx đi kèm với các tính năng mà Node không có và bạn sẽ cần phải thực hiện chính mình. Những điều như bộ nhớ đệm, cân bằng tải, chạy nhiều ứng dụng từ cùng một máy chủ vv

Answer 2

1. Vòng sự kiện độc lập. Các vòng lặp sự kiện được thực hiện ở cấp ứng dụng, do đó, không quan tâm đến loại kiến ​​trúc nào khác sử dụng.

2. NodeJS rất tốt ở nhiều thứ, nhưng có một số nơi nó vẫn còn ngập ngừng. Khi ví dụ đang phân phát các tệp tĩnh. Hiện tại, nodejs thực hiện khá kém trong thử nghiệm này, vì vậy có một máy chủ web chuyên dụng cho các tệp tĩnh của bạn cải thiện đáng kể thời gian phản hồi. Ngoài ra, nodejs vẫn còn trong giai đoạn trứng nước, và đã không được "thử nghiệm và cứng" trong các vấn đề an ninh như Apache trên nginX.

3. Sẽ mất nhiều thời gian để mọi người tự xem xét các nút node. Các mô-đun cụm là một bước đi đúng hướng, nhưng nó sẽ mất một thời gian dài ngay cả sau khi nó đạt đến v1 trước khi nó xảy ra.

Answer 3

1. Cả hai vòng lặp sự kiện đều không liên quan. Họ không chơi cùng nhau.
2. Vâng, nó khá là vô ích. Apache không phải là một cân bằng tải.
3. Điều mà Ryan Dahl cho biết có thể áp dụng được. Giới hạn của người dùng đồng thời chắc chắn cao hơn so với Apache. Trước khi các trang web node.js có lượng người dùng đồng thời phải sử dụng nginx để cân bằng tải. Đối với các doanh nghiệp vừa và nhỏ, nó có thể được thực hiện chỉ với node.js. Nhưng loại trừ nginx hoàn toàn sẽ mất thời gian. Hãy để node.js ổn định trước khi nó có thể theo đuổi ước mơ đầy tham vọng này.

Answer 4

Tôi nghĩ rằng câu hỏi của bạn đã được phần lớn được bao phủ bởi một số người khác câu trả lời, nhưng có một vài mảnh còn thiếu, và một số Tôi không đồng ý với, vì vậy, đây là của tôi:

1. Các vòng lặp sự kiện được phân lập với nhau ở cấp quy trình, nhưng tương tác. Các vấn đề bạn có nhiều khả năng gặp phải nhất là xung quanh cấu hình bộ đệm phản hồi nginx, dữ liệu chunked, v.v.nhưng đây là tối ưu hóa hơn là giải quyết lỗi.

2. Khi bạn chỉ ra, nếu bạn sử dụng Apache, bạn đang vô hiệu hóa lợi ích của việc sử dụng Node.js, tức là đồng thời lớn và ổ cắm web. Tôi sẽ không khuyên bạn nên làm điều đó.

3. Mọi người đã sử dụng Node.js ở phía trước ngăn xếp của họ. Việc tìm kiếm điểm chuẩn trả về một số lợi ích của Node là reasonable-looking results, vì vậy hiệu suất cho tâm trí của tôi không phải là vấn đề. Tuy nhiên, vẫn còn có lý do để đưa Nginx trước mặt Node.

   1. an - Node đã được trao tăng giám sát, nhưng nó vẫn còn trẻ. Bạn có thể không có vấn đề ở đây, nhưng thận trọng thường là bạn của bạn.

   2. Đào tạo - Nhân viên Ops mà bạn thuê sẽ biết cách quản lý Nginx, nhưng cấu hình và quản lý ứng dụng Nút tùy chỉnh của bạn sẽ chỉ được những người phát triển của bạn hiểu thành công. Ở một số công ty, đây là không ai.

   3. Tính linh hoạt hoạt động - Nếu bạn đạt đến quy mô, bạn có thể muốn tách phân phối nội dung tĩnh, hoàn toàn là giảm tải trên máy chủ ứng dụng của bạn. Bạn có thể muốn chia nhỏ nội dung giữa các miền khác nhau và được quản lý riêng biệt hoặc có hành vi SSL hoặc proxy khác nhau cho các miền hoặc mẫu URL khác nhau. Đây là những thứ dễ dàng cho những người dùng Ops cấu hình trong Nginx, nhưng bạn phải viết mã bằng tay trong ứng dụng Node.