คำนำ
อัปเดตในปี 2559 สิ่งต่าง ๆ กำลังพัฒนาเซิร์ฟเวอร์ทั้งหมดเริ่มดีขึ้นพวกเขาทุกคนรองรับ SSL และเว็บน่าทึ่งกว่าที่เคย
เว้นแต่จะมีการกล่าวต่อไปนี้จะถูกกำหนดเป้าหมายไปยังมืออาชีพในธุรกิจและเริ่มต้นธุรกิจรองรับผู้ใช้หลายพันถึงล้านคน
เครื่องมือและสถาปัตยกรรมเหล่านี้ต้องการผู้ใช้ / ฮาร์ดแวร์ / เงินจำนวนมาก คุณสามารถลองทำสิ่งนี้ได้ที่ห้องแล็บที่บ้านหรือเรียกใช้บล็อก แต่มันก็ไม่สมเหตุสมผล
ตามกฎทั่วไปจำไว้ว่าคุณต้องการที่จะให้มันง่าย มิดเดิ้ลแวร์ทุกตัวที่ต่อท้ายเป็นอีกหนึ่งชิ้นส่วนที่สำคัญของมิดเดิลแวร์ที่ต้องดูแล ความสมบูรณ์แบบไม่สามารถทำได้เมื่อไม่มีสิ่งใดที่จะเพิ่ม แต่เมื่อไม่มีสิ่งใดที่จะลบ
การปรับใช้ทั่วไปและน่าสนใจบางอย่าง
HAProxy (ปรับสมดุล) + nginx (แอปพลิเคชัน php + การแคช)
เว็บเซิร์ฟเวอร์กำลังทำงาน nginx php เมื่อ nginx มีอยู่แล้วก็อาจจัดการกับแคชและการเปลี่ยนเส้นทาง
HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
HAProxy (ปรับสมดุล) + วานิช (แคช) + Tomcat (แอปพลิเคชัน Java)
HAProxy สามารถเปลี่ยนเส้นทางไปยัง Varnish ตามคำขอ URI (* .jpg * .css * .js)
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
HAProxy (ปรับสมดุล) + nginx (SSL ไปยังโฮสต์และแคช) + เว็บเซิร์ฟเวอร์ (แอปพลิเคชัน)
เว็บเซิร์ฟเวอร์ไม่ได้พูด SSL แม้ว่าทุกคนจะต้องพูด SSL ( โดยเฉพาะการเชื่อมโยง HAProxy-WebServer นี้พร้อมข้อมูลผู้ใช้ส่วนตัวที่กำลังจะผ่าน EC2 ) การเพิ่ม local nginx อนุญาตให้นำ SSL ขึ้นไปยังโฮสต์ เมื่อ nginx อยู่ที่นั่นแล้วก็อาจทำการแคชและการเขียน URL อีกครั้ง
หมายเหตุ : การเปลี่ยนเส้นทางพอร์ต 443: 8080 กำลังเกิดขึ้น แต่ไม่ได้เป็นส่วนหนึ่งของคุณสมบัติ ไม่มีจุดในการทำการเปลี่ยนเส้นทางพอร์ต ตัวโหลดบาลานซ์สามารถพูดโดยตรงกับเว็บเซิร์ฟเวอร์: 8080
(nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A ---> nginx:443 -> webserver:8080
P ---> nginx:443 -> webserver:8080
r ---> nginx:443 -> webserver:8080
o ---> nginx:443 -> webserver:8080
x ---> nginx:443 -> webserver:8080
y ---> nginx:443 -> webserver:8080
มิดเดิ้ล
HAProxy: โหลดบาลานเซอร์
คุณสมบัติหลัก :
- โหลดบาลานซ์ (TCP, HTTP, HTTPS)
- อัลกอริธึมหลายอย่าง (round robin, source ip, header)
- การคงอยู่ของเซสชัน
- การยกเลิก SSL
ทางเลือกที่คล้ายกัน : nginx (เว็บเซิร์ฟเวอร์อเนกประสงค์สามารถกำหนดเป็น load balancer)
ทางเลือกที่แตกต่าง : Cloud (Amazon ELB, Google load balancer), ฮาร์ดแวร์ (F5, Fortinet, citrix netscaler), อื่น ๆ & ทั่วโลก (DNS, anycast, CloudFlare)
HAProxy ทำอะไรและเมื่อไหร่ที่คุณต้องใช้มัน?
เมื่อใดก็ตามที่คุณต้องการสมดุลภาระ HAProxy เป็นทางแก้ปัญหา
ยกเว้นเมื่อคุณต้องการราคาถูกมากหรือเร็ว & สกปรกหรือคุณไม่มีทักษะที่มีอยู่คุณอาจใช้ ELB: D
ยกเว้นเมื่อคุณอยู่ในธนาคาร / รัฐบาล / ที่คล้ายกันที่ต้องการใช้ดาต้าเซ็นเตอร์ของคุณเองด้วยข้อกำหนดที่เข้มงวด (โครงสร้างพื้นฐานเฉพาะ, failover ที่เชื่อถือได้, ไฟร์วอลล์ 2 ชั้น, การตรวจสอบข้อมูล, SLA จ่าย x% ต่อนาทีของการหยุดทำงานทั้งหมด) คุณอาจวาง 2 F5 ไว้ด้านบนสุดของชั้นวางที่มีเซิร์ฟเวอร์แอปพลิเคชัน 30 เครื่องของคุณ
ยกเว้นเมื่อคุณต้องการผ่าน 100k HTTP (S) [และหลายไซต์] คุณต้องมีHAProxy ทวีคูณด้วยเลเยอร์ของ [โลก] โหลดบาลานซ์ที่อยู่ตรงหน้า (cloudflare, DNS, anycast) ในทางทฤษฎีบาลานเซอร์ระดับโลกสามารถพูดคุยกับเว็บเซิร์ฟเวอร์ได้โดยตรงเพื่อให้สามารถแฮ็ป HAProxy ได้ อย่างไรก็ตามโดยปกติคุณควรเก็บ HAProxy เป็นจุดเข้าสู่ศูนย์ข้อมูลของคุณและปรับตัวเลือกขั้นสูงเพื่อสร้างความสมดุลให้กับโฮสต์อย่างเป็นธรรมและลดความแปรปรวน
ความคิดเห็นส่วนตัว : โครงการโอเพนซอร์ซขนาดเล็กที่บรรจุอยู่ทั้งหมดทุ่มเทให้กับวัตถุประสงค์ของ ONE TRUE ท่ามกลางการกำหนดค่าที่ง่ายที่สุด (ไฟล์เดียว) ซอฟต์แวร์โอเพ่นซอร์สที่มีประโยชน์และน่าเชื่อถือที่สุดที่ฉันเคยเจอในชีวิตของฉัน
Nginx: Apache ที่ไม่ดูด
คุณสมบัติหลัก :
- WebServer HTTP หรือ HTTPS
- เรียกใช้แอปพลิเคชั่นใน CGI / PHP / อื่น ๆ
- การเปลี่ยนเส้นทาง URL / เขียนใหม่
- การควบคุมการเข้าถึง
- การจัดการส่วนหัว HTTP
- เก็บเอาไว้
- Reverse Proxy
ทางเลือกที่คล้ายกัน : Apache, Lighttpd, Tomcat, Gunicorn ...
Apache เป็นเว็บเซิร์ฟเวอร์แบบพฤตินัยหรือที่รู้จักกันว่าเป็นคลัสเตอร์ขนาดใหญ่ของโมดูลจำนวนมากและหลายร้อยบรรทัดhttpd.confบนสถาปัตยกรรมการประมวลผลคำขอที่ไม่สมบูรณ์ nginx ทำซ้ำทั้งหมดด้วยโมดูลที่น้อยกว่า (เล็กน้อย) การกำหนดค่าที่ง่ายขึ้นและสถาปัตยกรรมแกนที่ดีกว่า
nginx ทำอะไรและเมื่อไหร่ที่คุณจะต้องใช้มัน?
เว็บเซิร์ฟเวอร์มีวัตถุประสงค์เพื่อเรียกใช้แอปพลิเคชัน เมื่อแอปพลิเคชันของคุณถูกพัฒนาให้ทำงานบน nginx คุณมี nginx อยู่แล้วและคุณอาจใช้ฟีเจอร์ทั้งหมดของมันเช่นกัน
ยกเว้นเมื่อแอปพลิเคชันของคุณไม่ได้ตั้งใจให้เรียกใช้บน nginx และ nginx ไม่พบในสแต็กของคุณ คุณลักษณะ webservers มีอยู่ในเว็บเซิร์ฟเวอร์ปัจจุบันของคุณและงานอื่น ๆ จะได้รับการจัดการที่ดีขึ้นโดยเครื่องมือเฉพาะที่เหมาะสม (HAProxy / Varnish / CDN)
ยกเว้นเมื่อเว็บเซิร์ฟเวอร์ / แอปพลิเคชันของคุณขาดฟีเจอร์ยากที่จะกำหนดค่าและ / หรือคุณอยากตายมากกว่ามอง (Gunicorn ใคร?) คุณอาจวาง nginx ไว้ด้านหน้า (เช่นในแต่ละโหนด) เพื่อดำเนินการ URL เขียนใหม่ส่งการเปลี่ยนเส้นทาง 301 บังคับใช้การควบคุมการเข้าถึงจัดให้มีการเข้ารหัส SSL และแก้ไขส่วนหัว HTTP แบบทันที [นี่คือคุณสมบัติที่คาดหวังจากเว็บเซิร์ฟเวอร์]
วานิช: เซิร์ฟเวอร์แคช
คุณสมบัติหลัก :
- เก็บเอาไว้
- การแคชขั้นสูง
- แคชเม็ดเล็ก ๆ
- เก็บเอาไว้
ทางเลือกที่คล้ายกัน : nginx (เว็บเซิร์ฟเวอร์อเนกประสงค์ที่สามารถกำหนดค่าเป็นเซิร์ฟเวอร์แคช)
ทางเลือกอื่น : CDN (Akamai, Amazon CloudFront, CloudFlare), ฮาร์ดแวร์ (F5, Fortinet, Citrix Netscaler)
วานิชทำอะไรและเมื่อไหร่ที่คุณต้องใช้?
มันแคชเพียงแคช มันมักจะไม่คุ้มค่ากับความพยายามและเสียเวลา ลอง CDN แทน โปรดทราบว่าการแคชเป็นสิ่งสุดท้ายที่คุณควรใส่ใจเมื่อใช้งานเว็บไซต์
ยกเว้นเมื่อคุณใช้งานเว็บไซต์เกี่ยวกับรูปภาพหรือวิดีโอโดยเฉพาะคุณควรตรวจสอบ CDN อย่างละเอียดและคิดถึงการแคชอย่างจริงจัง
ยกเว้นเมื่อคุณถูกบังคับให้ใช้ฮาร์ดแวร์ของคุณเองในดาต้าเซ็นเตอร์ของคุณเอง (CDN ไม่มีตัวเลือก) และเว็บเซิร์ฟเวอร์ของคุณแย่มากในการส่งไฟล์สแตติก
ยกเว้นเมื่อคุณมีเว็บไซต์ที่มีเนื้อหาที่สร้างขึ้นแบบคงที่ แต่ซับซ้อนส่วนใหญ่แบบไดนามิก (ดูย่อหน้าต่อไปนี้) วานิชสามารถประหยัดพลังงานในการประมวลผลจำนวนมากบนเว็บเซิร์ฟเวอร์ของคุณ
การแคชแบบคงที่ถูกประเมินค่าเกินจริงในปี 2559
การแคชเกือบฟรีแล้วไม่มีค่าใช้จ่ายและไม่มีเวลา เพียงสมัครสมาชิก CloudFlare หรือ CloudFront หรือ Akamai หรือ MaxCDN เวลาที่ฉันจะเขียนบรรทัดนี้จะนานกว่านั้นเวลาที่ใช้ในการตั้งค่าแคชและเบียร์ที่ฉันถืออยู่ในมือของฉันนั้นแพงกว่าการสมัครสมาชิก CloudFlare เฉลี่ย
บริการทั้งหมดนี้ทำงานนอกกรอบสำหรับ static * .css * .js * .png และอื่น ๆ ในความเป็นจริงพวกเขาส่วนใหญ่ให้เกียรติCache-Controlคำสั่งในส่วนหัว HTTP ขั้นตอนแรกของการแคชคือการกำหนดค่าเว็บเซิร์ฟเวอร์ของคุณเพื่อส่งคำสั่งแคชที่เหมาะสม ไม่สำคัญว่า CDN คืออะไร Varnish เบราว์เซอร์ใดอยู่ตรงกลาง
ข้อควรพิจารณาด้านประสิทธิภาพ
วานิชถูกสร้างขึ้นในเวลาที่เว็บเซิร์ฟเวอร์โดยเฉลี่ยสำลักเพื่อให้บริการภาพแมวในบล็อก ทุกวันนี้อินสแตนซ์เดียวของเว็บเซิร์ฟเวอร์ที่ทำงานด้วย buzzword ซึ่งทำงานด้วย buzzword โดยเฉลี่ยนั้นสามารถส่งลูกแมวไปทั่วประเทศได้อย่างน่าเชื่อถือ sendfile()มารยาทของ
ฉันทำการทดสอบประสิทธิภาพอย่างรวดเร็วสำหรับโปรเจ็กต์สุดท้ายที่ฉันทำงาน อินสแตนซ์ tomcat เดียวสามารถให้บริการ 21,000 ถึง 33,000 ไฟล์คงที่ต่อวินาทีผ่านทาง HTTP (การทดสอบไฟล์จาก 20B ถึง 12kB โดยนับรวมการเชื่อมต่อ HTTP / ไคลเอนต์ที่แตกต่างกัน) ปริมาณการใช้ข้อมูลขาออกที่ยั่งยืนเกินกว่า 2.4 Gb / s การผลิตจะมีเพียง 1 Gb / s อินเตอร์เฟส ไม่สามารถทำได้ดีกว่าฮาร์ดแวร์ไม่มีจุดลองใช้วานิช
แคชที่ซับซ้อนการเปลี่ยนแปลงเนื้อหาแบบไดนามิก
CDN และแคชเซิร์ฟเวอร์มักจะไม่สนใจ URL ที่มีพารามิเตอร์เช่น?article=1843พวกเขาไม่สนใจคำขอกับคุกกี้ประชุมหรือผู้ใช้สิทธิ์ใด ๆ และพวกเขาไม่สนใจชนิด MIME มากที่สุดรวมทั้งจากapplication/json /api/article/1843/infoมีตัวเลือกการกำหนดค่าที่ใช้ได้ แต่โดยปกติจะไม่เป็นเม็ดเล็กแทนที่จะเป็น "all or nothing"
สารเคลือบเงาสามารถมีกฎที่ซับซ้อนที่กำหนดเอง (ดู VCL) เพื่อกำหนดสิ่งที่สามารถเข้าถึงได้และสิ่งที่ไม่ กฎเหล่านี้สามารถแคชเนื้อหาที่เฉพาะเจาะจงโดย URI ส่วนหัวและคุกกี้เซสชันผู้ใช้ปัจจุบันและประเภทและเนื้อหา MIME ALL TOGETHER ที่สามารถประหยัดพลังงานการประมวลผลจำนวนมากบนเว็บเซิร์ฟเวอร์สำหรับรูปแบบการโหลดที่เฉพาะเจาะจง นั่นคือเมื่อวานิชมีประโยชน์และน่ากลัว
ข้อสรุป
ฉันใช้เวลาสักครู่เพื่อทำความเข้าใจชิ้นส่วนเหล่านี้ทั้งหมดเมื่อใช้พวกเขาและวิธีที่พวกเขาเข้าด้วยกัน หวังว่านี่จะช่วยคุณได้
มันค่อนข้างยาว (เขียนได้ 6 ชั่วโมง OMG!: O) บางทีฉันควรเริ่มต้นบล็อกหรือหนังสือเกี่ยวกับเรื่องนั้น สนุกจริง: ดูเหมือนจะไม่จำกัดความยาวของคำตอบ