ฉันตั้งใจจะใช้ VPS เดียวเพื่อปรับใช้แอป CherryPy ที่มีปริมาณการใช้งานต่ำเป็นไดเรกทอรีย่อย เช่นexample.com/app1, example.com/app2ฯลฯ

หลังจากทำการค้นคว้าเกี่ยวกับการปรับใช้ WSGI ดูเหมือนว่าวิธีที่ต้องการสำหรับการปรับใช้แอพคือการใช้เซิร์ฟเวอร์ WSGI (Gunicorn, uWSGI, ฯลฯ ) และ NGinx ในการตั้งค่า reverse-proxy ดูเหมือนว่า overkill การใช้สองเว็บเซิร์ฟเวอร์ควบคู่ - โดยเฉพาะอย่างยิ่งนับตั้งแต่แอป CherryPy ของฉันตัวเองเป็นเว็บเซิร์ฟเวอร์ - แต่ฉันไม่ต้องการที่จะยกเลิกความคิดตามที่ปรากฏทุกที่ ฉันไม่ได้เป็นผู้เชี่ยวชาญแน่นอนดังนั้นฉันต้องการที่จะหารือ

ฉันเห็นสามตัวเลือก:

• ปรับใช้ CherryPy ด้วยตัวเอง
• ปรับใช้ภายใต้ Gunicorn หรือเซิร์ฟเวอร์ WSGI อื่น
• ปรับใช้ภายใต้เซิร์ฟเวอร์ WSGI และ reverse-proxy กับ NGinx ซึ่งดูเหมือนจะเป็นทางออกของทุกคน

คำถามของฉัน:

• เหตุผลหลักที่ฉันเห็นรูปแบบนี้ทุกที่คืออะไร Nginx เป็นเพียงที่ดีหรือไม่?
• สำหรับแอปที่มีปริมาณการใช้งานต่ำเซิร์ฟเวอร์ CherryPy ดั้งเดิมดีพอหรือฉันควรลองด้วยซ้ำ

คำแนะนำใด ๆ และทั้งหมดได้รับการชื่นชมขอบคุณ

เหตุผลที่ทุกคนใส่ nginx (หรือเซิร์ฟเวอร์อื่นเช่น Apache) ไว้ข้างหน้าเซิร์ฟเวอร์แอปของพวกเขาคือทุกคนมีเนื้อหาแบบคงที่เช่นรูปภาพ, CSS และ JavaScript และข้อกำหนดแปลก ๆ ซึ่งเป็นเอกลักษณ์ของแอปพลิเคชันของพวกเขา

เซิร์ฟเวอร์แอปของคุณ (CherryPy, gunicorn หรืออะไรก็ตาม) ได้รับการปรับแต่งเพื่อให้แอพของคุณทำงานได้ดีที่สุด แม้ว่าแอพเซิร์ฟเวอร์จะสามารถให้บริการเนื้อหาแบบคงที่ได้ แต่ก็ไม่เหมาะสำหรับงานนี้เนื่องจากเป็นงานรองสำหรับวัตถุประสงค์หลักของแอปเซิร์ฟเวอร์ (เซิร์ฟเวอร์แอปบางตัวจะช่วยด้วยการย่อและบีบอัด CSS และ JS ของคุณเพื่อให้เว็บเซิร์ฟเวอร์ด้านหน้าสามารถให้บริการทรัพยากรเหล่านี้ได้เร็วขึ้น)

นอกจากนี้เว็บเซิร์ฟเวอร์จริงสามารถทำได้มากกว่าการให้บริการเนื้อหาที่มีประสิทธิภาพสูง สิ่งต่างๆเช่นแคชการจัดการส่วนหัวการเขียน URL ใหม่การระบุตำแหน่งทางภูมิศาสตร์และคุณสมบัติอื่น ๆ ที่จะทำให้เซิร์ฟเวอร์แอปพลิเคชันไม่ดี

โดยทั่วไปแล้วคุณจะเรียกใช้เซิร์ฟเวอร์แอปเพียงอย่างเดียวเมื่อพัฒนาแอปพลิเคชันเมื่อคุณเป็นผู้ใช้คนเดียวและประสิทธิภาพการทำงานไม่ได้เป็นปัญหา แม้ว่าเว็บไซต์ของคุณจะมีปริมาณการใช้งานต่ำ แต่คุณต้องการให้เว็บไซต์ทำงานเร็วขึ้นใช่มั้ย ไซต์ที่มีปริมาณการใช้งานต่ำซึ่งโดยปกติจะไม่เติบโตเป็นไซต์ที่มีปริมาณการใช้งานสูง ...

ทำไมคนถึงใส่ Nginx ไว้ข้างหน้า?

1. Nginx เป็นเว็บแบบอะซิงโครนัส มันหมายความว่ามันไม่ได้อุทิศเธรดหรือกระบวนการต่อการเชื่อมต่อ แต่จะใช้ไลบรารีโพลซ็อกเก็ตที่ต้องการของระบบปฏิบัติการแทนดังนั้นจึงสามารถจัดการการเชื่อมต่อแสนแสน เหตุใดคุณในฐานะผู้พัฒนาแอปพลิเคชันจึงควรใส่ใจ? เนื่องจากการเชื่อมต่อบัฟเฟอร์ Nginx และส่งผ่านการร้องขอไปยังอินสแตนซ์ CherryPy upstream ของคุณเท่านั้นเมื่อการร้องขอถูกอ่านอย่างสมบูรณ์ เช่นเดียวกันสำหรับการตอบสนอง วิธีนี้ทำให้แอปพลิเคชัน CherryPy ของคุณซึ่งเป็นเซิร์ฟเวอร์เธรดที่อยู่ด้านหลัง Nginx ในหลาย ๆ ด้านกลายเป็นอะซิงโครนัส โดยเฉพาะอย่างยิ่งคุณโบกมือให้กับปัญหาไคลเอนต์ช้าและโจมตีช้า loris DOS
2. Nginx มีอัตราการเชื่อมต่อที่ จำกัด นอกกรอบ บอกว่าฉันไม่ต้องการการเชื่อมต่อมากกว่า 8 พร้อมกันจาก IP เดียวกัน
3. CherryPy มีปัญหา SSL Nginx ไม่ได้
4. Python สามารถส่งไบต์ไปมาได้เกือบจะดีเท่ากับ C. Python zlibเป็นเพียง wrapper รอบ ๆ C library แต่เนื่องจาก Nginx จัดการกับการเชื่อมต่อได้อย่างมีประสิทธิภาพจึงเป็นความคิดที่ดีที่จะบรรเทา CherryPy คนทำงานเธรดของคุณจากการให้บริการเนื้อหาคงที่ในการผลิตและอุทิศเฉพาะเนื้อหาแบบไดนามิก
5. มัลติเพล็กซ์ CherryPy หลาย ๆ อินสแตนซ์บนพอร์ตโดเมนพา ธ และอื่น ๆ โดยทั่วไปแล้วความยืดหยุ่นเพิ่มเติมของระดับการกำหนดค่าอื่น

การใช้ CherryPy ปลอดภัยหรือไม่?

ตามหนึ่งของผู้เขียนต้นฉบับใช่ สิ่งที่เกี่ยวข้องกับเว็บส่วนใหญ่ที่คุณสามารถทำได้กับ CherryPy ด้วยตัวเอง

CherryPy มีแนวคิดเกี่ยวกับแอปพลิเคชันและคุณสามารถให้บริการแอปพลิเคชั่นได้หลายอย่างด้วย CherryPy หนึ่งอินสแตนซ์ ยัง CherryPy สามารถให้บริการอื่น ๆการใช้งาน WSGI

กำลังปรับใช้ CherryPy

ในการปรับใช้สไตล์ * nix แบบดั้งเดิมที่คุณเขียนสคริปต์ init ให้ทำการ daemon ประมวลผลวางสิทธิ์เขียน PID ฯลฯ ไม่ใช่เรื่องใหญ่เมื่อคุณมีอินสแตนซ์ CherryPy สองสามตัว เมื่อคุณมีหลายสิบมันน่าเบื่อและเหมาะสมที่จะมอบการจัดการกระบวนการเป็น Gunicorn หรือ uWGSI และสลับอินสแตนซ์ CherryPy ของคุณจาก HTTP เป็น WSGI

ฉันเขียนโครงกระดูก tutorial / project, cherrypy-webapp-skeletonซึ่งเป้าหมายคือการเติมช่องว่างสำหรับการปรับใช้ (ดั้งเดิม) แอปพลิเคชัน CherryPy ในโลกแห่งความจริงบน Debian สำหรับนักพัฒนาเว็บ

สรุป

1. CherryPy * 1 ⇐ HTTP ⇒ Clientต่ำจราจรไม่มีข้อกำหนดพิเศษ→
2. CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Clientการจราจรสูงความต้องการพิเศษ→
3. หลายสิบกรณี CherryPy แยกต่างหากบนเซิร์ฟเวอร์เดียวกันอยากให้ overkill ของการแก้ปัญหาของทุกคนCherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client →