Tôi dự định sử dụng một VPS duy nhất để triển khai nhiều ứng dụng CherryPy lưu lượng truy cập thấp làm thư mục con; ví dụ như: example.com/app1, example.com/app2vv

Sau khi nghiên cứu về triển khai WSGI, có vẻ như phương pháp ưa thích để triển khai các ứng dụng là sử dụng máy chủ WSGI (Gunicorn, uWSGI, v.v.) và NGinx trong thiết lập proxy ngược. Có vẻ như quá mức cần thiết để sử dụng hai máy chủ web song song - đặc biệt là vì ứng dụng CherryPy của tôi tự nó là một máy chủ web - nhưng tôi không muốn loại bỏ ý tưởng này khi nó xuất hiện ở mọi nơi . Tôi chắc chắn không phải là một chuyên gia vì vậy tôi muốn thảo luận về nó.

Tôi thấy ba lựa chọn:

• Tự triển khai CherryPy.
• Triển khai bên dưới Gunicorn hoặc máy chủ WSGI khác.
• Triển khai bên dưới máy chủ WSGI và ủy quyền ngược lại NGinx, đây dường như là giải pháp của mọi người.

Những câu hỏi của tôi:

• Lý do chính tôi thấy mô hình này ở khắp mọi nơi là gì? NGinx có tốt không?
• Đối với các ứng dụng có lưu lượng truy cập thấp, máy chủ CherryPy bản địa có đủ tốt hay tôi thậm chí không nên thử?

Bất kỳ và tất cả các lời khuyên được đánh giá cao, cảm ơn bạn.

Lý do mọi người đặt nginx (hoặc máy chủ khác như Apache) trước máy chủ ứng dụng của họ là vì mọi người đều có nội dung tĩnh như hình ảnh, CSS và JavaScript và các yêu cầu lạ đối với ứng dụng của họ.

Máy chủ ứng dụng của bạn (CherryPy, gunicorn, bất cứ điều gì) được tối ưu hóa để chạy ứng dụng của bạn và phục vụ đầu ra của nó. Mặc dù máy chủ ứng dụng cũng có thể phục vụ nội dung tĩnh, nhưng chúng hầu như không được tối ưu hóa tốt cho nhiệm vụ này, vì nó là mục đích chính của máy chủ ứng dụng. (Một số máy chủ ứng dụng cũng sẽ trợ giúp bằng cách thu nhỏ và nén CSS và JS của bạn, để máy chủ web phía trước có thể phục vụ các tài nguyên này nhanh hơn nữa.)

Ngoài ra, máy chủ web thực tế có thể làm nhiều hơn việc phục vụ nội dung hiệu suất cao. Những thứ như bộ nhớ đệm, thao tác tiêu đề, viết lại URL, định vị địa lý và nhiều tính năng khác sẽ làm cho máy chủ ứng dụng không có mục đích tốt.

Thông thường, bạn sẽ chỉ chạy máy chủ ứng dụng khi phát triển ứng dụng, khi bạn là người dùng duy nhất và hiệu suất không phải là vấn đề. Ngay cả khi trang web của bạn có lưu lượng truy cập thấp, bạn muốn nó nhanh hơn, phải không? Các trang web có lưu lượng truy cập thấp, thường không phát triển thành các trang có lưu lượng truy cập cao ...

Tại sao người ta lại đặt Nginx ở phía trước?

1. Nginx là một web-sever không đồng bộ. Nó có nghĩa là nó không dành một luồng hoặc một quá trình cho mỗi kết nối. Thay vào đó, nó sử dụng thư viện bỏ phiếu ưa thích của hệ điều hành và do đó có thể xử lý hàng trăm nghìn kết nối. Tại sao bạn, như một nhà phát triển ứng dụng, quan tâm? Bởi vì Nginx đệm kết nối và chỉ chuyển yêu cầu đến phiên bản ngược dòng CherryPy của bạn khi yêu cầu được đọc đầy đủ. Tương tự cho câu trả lời. Bằng cách này, ứng dụng CherryPy của bạn, một máy chủ có luồng, đứng sau Nginx theo nhiều nghĩa, trở nên không đồng bộ. Cụ thể, bạn vẫy tay với một vấn đề máy khách chậm và các cuộc tấn công DOS chậm.
2. Nginx có tốc độ kết nối giới hạn ra khỏi hộp. Giả sử, tôi không muốn có nhiều hơn 8 kết nối đồng thời từ cùng một IP.
3. CherryPy có vấn đề về SSL . Nginx không.
4. Python có thể gửi byte qua lại gần như tốt như C. Python zlibchỉ là một trình bao bọc xung quanh thư viện C. Nhưng vì Nginx xử lý kết nối một cách hiệu quả, nên giảm các luồng công nhân CherryPy của bạn khỏi việc phục vụ nội dung tĩnh trong sản xuất và chỉ dành cho nội dung động.
5. Ghép kênh một số phiên bản CherryPy trên cùng một cổng, tên miền, đường dẫn, v.v ... Nói chung tính linh hoạt bổ sung của cấp độ cấu hình khác.

Có an toàn khi sử dụng CherryPy không?

Theo một trong những tác giả ban đầu, vâng . Hầu hết những điều liên quan đến web mà bạn có thể tự làm với CherryPy.

CherryPy có khái niệm về một ứng dụng và bạn có thể phục vụ một số ứng dụng với một ví dụ CherryPy. CherryPy cũng có thể phục vụ các ứng dụng WSGI khác .

Triển khai CherryPy

Trong một triển khai kiểu * nix truyền thống, bạn viết tập lệnh init, trình bày bạn xử lý, bỏ các đặc quyền của nó, viết PID của nó, v.v. Nó không phải là vấn đề lớn khi bạn có một vài phiên bản CherryPy. Khi bạn có hàng tá, việc này trở nên tẻ nhạt và thật hợp lý khi bàn giao quản lý quy trình cho Gunicorn hoặc uWGSI và chuyển các phiên bản CherryPy của bạn từ HTTP sang WSGI.

Tôi đã viết một bộ xương hướng dẫn / dự án, cherrypy-webapp-skeleton , mục tiêu là lấp đầy các khoảng trống để triển khai (truyền thống) một ứng dụng CherryPy trong thế giới thực trên Debian cho một nhà phát triển web.

Gói (lại

1. Lưu lượng truy cập thấp, không có yêu cầu đặc biệt → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Lưu lượng truy cập cao, yêu cầu đặc biệt → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Hàng chục trường hợp CherryPy riêng biệt trên cùng một máy chủ, mong muốn giải quyết quá mức giải pháp của mọi người → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.