Tại sao tôi cần Nginx và một cái gì đó như Gunicorn?


219

Tôi đang tìm kiếm một câu trả lời quá đơn giản cho câu hỏi sau đây. Tôi đang cố gắng xây dựng một sự hiểu biết nền tảng về cách Nginx hoạt động cùng với thứ gì đó như Gunicorn.

Tôi có cần cả Nginx và thứ gì đó như Gunicorn để triển khai ứng dụng Django trên Nginx không?

Nếu vậy, những gì thực sự xử lý các yêu cầu HTTP?

Thi thiên Tôi không muốn sử dụng Apache và mod_wsgi!


Apache và mod_wsgi là cách đơn giản nhất để thực hiện cầu nối giữa ứng dụng django của bạn và các yêu cầu http cũng rất có khả năng trong môi trường sản xuất. Đối với nhiều nhà phát triển, điều này có nghĩa là 'Apache tốt hơn nginx' nếu họ biết nhưng vì 'betamax tốt hơn VHS', than ôi, quy tắc Dogma
MagicLAMP

Câu trả lời:


314

Quá đơn giản: Bạn cần một cái gì đó thực thi Python nhưng Python không phải là tốt nhất để xử lý tất cả các loại yêu cầu.

[từ chối trách nhiệm: Tôi là nhà phát triển Gunicorn]

Ít đơn giản hơn: Bất kể máy chủ ứng dụng nào bạn sử dụng (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy), bất kỳ loại triển khai không tầm thường nào cũng sẽ có thứ gì đó ngược dòng sẽ xử lý các yêu cầu mà ứng dụng Django của bạn không nên xử lý. Các ví dụ tầm thường của các yêu cầu như vậy đang phục vụ các tài sản tĩnh (hình ảnh / css / js).

Điều này dẫn đến hai tầng đầu tiên của "kiến trúc ba tầng" cổ điển. Tức là, máy chủ web (Nginx trong trường hợp của bạn) sẽ xử lý nhiều yêu cầu cho hình ảnh và tài nguyên tĩnh. Các yêu cầu cần được tạo động sau đó sẽ được chuyển đến máy chủ ứng dụng (Gunicorn trong ví dụ của bạn). (Như một bên, thứ ba trong ba tầng là cơ sở dữ liệu)

Về mặt lịch sử, mỗi tầng này sẽ được lưu trữ trên các máy riêng biệt (và rất có thể sẽ có nhiều máy trong hai tầng đầu tiên, tức là: 5 máy chủ web gửi yêu cầu đến hai máy chủ ứng dụng lần lượt truy vấn một cơ sở dữ liệu).

Trong thời kỳ hiện đại, chúng ta có các ứng dụng của tất cả các hình dạng và kích cỡ. Không phải mọi dự án cuối tuần hoặc trang web kinh doanh nhỏ thực sự cần mã lực của nhiều máy và sẽ chạy khá vui vẻ trên một hộp. Điều này đã sinh ra các mục mới vào mảng các giải pháp lưu trữ. Một số giải pháp sẽ kết hôn máy chủ ứng dụng với máy chủ web (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, v.v.). Và không có gì lạ khi lưu trữ cơ sở dữ liệu trên cùng một máy như một trong những kết hợp máy chủ web / ứng dụng này.

Bây giờ trong trường hợp của Gunicorn, chúng tôi đã đưa ra một quyết định cụ thể (sao chép từ Kỳ lân của Ruby) để giữ mọi thứ tách biệt với Nginx trong khi dựa vào hành vi ủy quyền của Nginx. Cụ thể, nếu chúng ta có thể cho rằng Gunicorn sẽ không bao giờ đọc các kết nối trực tiếp từ internet, thì chúng ta không phải lo lắng về các khách hàng chậm. Điều này có nghĩa là mô hình xử lý cho Gunicorn rất đơn giản.

Việc phân tách cũng cho phép Gunicorn được viết bằng Python thuần giúp giảm thiểu chi phí phát triển trong khi không ảnh hưởng đáng kể đến hiệu suất. Nó cũng cho phép người dùng khả năng sử dụng các proxy khác (giả sử họ đệm chính xác).

Đối với câu hỏi thứ hai của bạn về những gì thực sự xử lý yêu cầu HTTP, câu trả lời đơn giản là Gunicorn. Câu trả lời đầy đủ là cả Nginx và Gunicorn đều xử lý yêu cầu. Về cơ bản, Nginx sẽ nhận được yêu cầu và nếu đó là một yêu cầu động (thường dựa trên các mẫu URL) thì nó sẽ gửi yêu cầu đó cho Gunicorn, sẽ xử lý nó và sau đó trả lại phản hồi cho Nginx, sau đó chuyển phản hồi trở lại ban đầu khách hàng

Vì vậy, trong đóng cửa, có. Bạn cần cả Nginx và Gunicorn (hoặc một cái gì đó tương tự) để triển khai Django thích hợp. Nếu bạn đặc biệt muốn tổ chức Django với Nginx, thì tôi sẽ điều tra Gunicorn, mod_uwsgi và có thể CherryPy là ứng cử viên cho phe Django.


14
Cảm ơn đã dành thời gian để viết một câu trả lời chi tiết như vậy! Bất kỳ đề nghị đọc trên "kiến trúc 3 tầng" này?
sáng

5
Câu trả lời tuyệt vời, tuy nhiên tôi không hiểu vấn đề với khách hàng chậm.
Mads Skjern

3
@MadsSkjern Tôi đoán ở đây, nhưng nếu bạn cho rằng tất cả các máy khách đều nhanh, thì bạn có thể sử dụng một nhóm quy trình công nhân cố định và không phải mã hóa cho trường hợp nhiều hoặc tất cả chúng bị chặn chờ khách hàng.
Jonathan Hartley


7
Ứng dụng django của tôi chỉ phục vụ json không có nội dung tĩnh. Tôi chỉ có thể đi với gunicorn và không nginx
Sar009

27

Tôi thích cách giải thích này trong sự đơn giản của nó:

Nginx sẽ đối mặt với thế giới bên ngoài. Nó sẽ phục vụ các tệp phương tiện (hình ảnh, CSS, v.v.) trực tiếp từ hệ thống tệp. Tuy nhiên, nó không thể nói chuyện trực tiếp với các ứng dụng Django; nó cần một cái gì đó sẽ chạy ứng dụng, cung cấp cho nó yêu cầu từ web và trả lời phản hồi.

Đó là công việc của Gunicorn. Gunicorn sẽ tạo ra một ổ cắm Unix và phục vụ các phản hồi cho nginx thông qua giao thức wsgi - ổ cắm truyền dữ liệu theo cả hai hướng:

The outside world <-> Nginx <-> The socket <-> Gunicorn

https://gist.github.com/Atem18/4696071


Nó không phải là ổ cắm, chỉ trong trường hợp những người khác đang tự hỏi.
akshay

0

Tôi đang tìm kiếm một câu trả lời quá đơn giản ...

Tôi có cần cả Nginx và thứ gì đó như Gunicorn để triển khai ứng dụng Django trên Nginx không?

Nếu vậy, những gì thực sự xử lý các yêu cầu HTTP?

Câu trả lời quá đơn giản:

ĐÚNG.

Cả Nginx và Gunicorn.

Vì bạn đang triển khai trên Nginx, tất nhiên bạn cần Nginx.

Vì bạn đang triển khai Django, là một khung web, bạn cần một cái gì đó bắc cầu cuộc nói chuyện giữa máy chủ web (Nginx) và khung web (Django). Trong thế giới Python, một thứ như vậy được gọi là máy chủ WSGI (nhưng nghĩ rằng nó giống như một kho trung gian), các ví dụ bao gồm Gunicorn và uWSGI. Khi xử lý một yêu cầu, Nginx ủy quyền yêu cầu cho Gunicorn hoặc uWSGI, lần lượt gọi mã Django và trả về phản hồi.

Tài liệu này và câu trả lời của Paul sẽ giúp bạn tìm hiểu nó tốt hơn.


0

Gunicorn là một sự lãng phí tài nguyên. Bạn có thể đơn giản chuyển proxy để nghe django trên một cổng thay vì chạy gunicorn trên django hàng đầu và một lần nữa nginx trên tất cả điều đó. Trong điểm chuẩn, tôi đã thấy tốc độ tăng rất đáng chú ý. Nginx có thể dễ dàng xử lý các yêu cầu trực tiếp đến django. Gunicorn không gì khác hơn là một cầu vượt (thực ra là cầu vượt chậm hơn) trên con đường bình thường. Nó chỉ ngồi và ăn tài nguyên của bạn và cố gắng tuyên bố sẽ cung cấp năng lượng cho trang web của bạn.

Về cơ bản, nginx đệm tất cả các yêu cầu và tự xử lý các yêu cầu tệp tĩnh (nếu bạn đã cấu hình nó như thế). Và ủy quyền tất cả các nội dung động cho một máy chủ khác. (Gunicorn / django).

Gunicorn không có cách sử dụng nào khác ngoài việc chuyển yêu cầu đến ứng dụng. Nó giống như ống hút bạn có thể uống trực tiếp từ ly hoặc uống từ ống hút với tốc độ hạn chế (ở đây người uống là django). Và nginx là người phục vụ mang cho bạn ly nước trái cây.

Tôi đã điểm chuẩn và tìm thấy điều này - với gunicorn: 22k req / s không có gunicorn: 34k req / s

Trang web của bạn sẽ cần thêm req / s trong tải nặng.


1
Bạn đang nói về việc chạy máy chủ phát triển trong sản xuất?!
Michael Hampton

Máy chủ phát triển có thể được chạy phía sau một máy chủ sản xuất (như nginx). Bởi vì nó sẽ nhận được yêu cầu ở vị trí chính xác và bảo mật và hiệu quả sẽ được xử lý bởi máy chủ sản xuất. Nó giống như chỉ sử dụng bình WSGI +. Thay vào đó, bạn có thể sử dụng chỉ nginx + django (không có bất kỳ phần mềm trung gian nào, như gunicorn). Vui lòng kiểm tra thiết lập trên tải nặng và bạn sẽ hiểu.
ShadowDoom

1
github.com/django/channels/issues/142 (TLDR: đó là một ý tưởng tồi)
igor
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.