ลองมาดูสถานการณ์นี้กัน
ในโมเดล LB แบบดั้งเดิม เราจะให้ LB (ไม่ว่าจะเป็นพร็อกซีแบบย้อนกลับหรือไม่ก็ตาม) ฟาร์มเอาต์ req/rep ไปยังเซิร์ฟเวอร์ระดับแอปพลิเคชัน โมเดลนี้ใช้ได้กับรูปแบบการสื่อสารแบบ req/rep ทั่วไป แต่จะเกิดอะไรขึ้นเมื่อเรามีการเชื่อมต่ออย่างต่อเนื่อง
ลองดูตัวอย่าง HTTP/2
ที่นี่เราไม่มีกระบวนทัศน์ Req/Rep ง่ายๆ ที่ฉันสามารถส่งคำขอและโหลดบาลานซ์คำขอนั้นและรับการตอบกลับได้ สถาปัตยกรรมทั้งหมดนั้นไร้สัญชาติ (ลืมเซสชันที่เหนียวเนื่องจากมีความหมายที่ไม่เกี่ยวข้องในตัวอย่างนี้) เกิดอะไรขึ้นที่เรามีการเชื่อมต่ออย่างต่อเนื่องเช่นกับ HTTP/2
ฉันไม่สามารถเชื่อมต่อการเชื่อมต่อ HTTP/2 กับ LB ไม่เช่นนั้น LB จะอิ่มตัวเร็วมาก และคำขอของไคลเอ็นต์ทั้งหมดที่ไม่มีซ็อกเก็ตที่เชื่อมต่อกับ LB นั้นจะโชคไม่ดี หากพวกเขาใช้ DNS เพื่อชี้ไปที่ LB ปัญหามากมายจะเกิดขึ้นเมื่อเราไม่มีที่ว่างในซ็อกเก็ต
เราต้องการบางสิ่งที่เกือบจะเปลี่ยนเส้นทางคำขอ SYN เริ่มต้นไปยังเซิร์ฟเวอร์อื่นที่อาจเป็น LB อื่นหรือชั้นของแอปพลิเคชันเอง (ลืมเรื่องความปลอดภัย/การโจมตีจากภายนอกไปได้เลย)
ลูกค้าส่งคำขอ s1.com --> (กด DNS และส่งคืน ip .123)
จากนั้นไคลเอนต์ส่งคำขอเชื่อมต่อ HTTP/2 ไปที่ .123 (นี่คือ LB) แต่แทนที่จะเชื่อมต่อและส่งต่อไปยังเลเยอร์แอปพลิเคชัน มันกลับตอบกลับไปยัง "เปลี่ยนเส้นทาง .. คล้ายกับ 302 ใน HTTP" ไปที่ ip .124 IP .124 อาจเป็น LB ชนิดอื่นหรืออาจเป็นเลเยอร์ของแอปพลิเคชันเอง โดยที่ซ็อกเก็ตจริงถูกผูกไว้สำหรับการสื่อสาร HTTP/2
การจัดการ .123 และโหนดใดที่ชี้ไปสามารถจัดการได้ด้วยเครื่องมือที่มีอยู่มากมายในปัจจุบัน แต่ในแง่ของ "การเปลี่ยนเส้นทาง HTTP/2 เพื่อให้สมดุลกับปัญหาการโหลดซ็อกเก็ต" ฉันไม่สามารถหาวิธีแก้ไขได้ .
มีวิธีที่ดีกว่าในการจัดการสิ่งนี้ (อีกครั้งไม่ใช่สำหรับบริการภายใน แต่สำหรับคำขอภายนอก) หรือมีพร็อกซี/บริการ/ระบบที่มีอยู่เพื่อแก้ปัญหานี้หรือไม่
DSR แตกต่างกันเล็กน้อยตรงที่จะแก้ปัญหาที่เลเยอร์อื่น และมีความเกี่ยวข้องจริงๆ เมื่อคุณมีปริมาณการรับส่งข้อมูลกลับจำนวนมาก แต่ไม่สามารถแก้ปัญหาได้หากปริมาณการใช้ข้อมูลเป็นแบบสองทิศทาง (ไม่สามารถใช้ได้กับผู้ให้บริการระบบคลาวด์จำนวนมาก ). DSR เหมาะสมอย่างยิ่งสำหรับการสตรีมสื่อและทราฟฟิกการตอบสนองของเซิร์ฟเวอร์จำนวนมาก
ขอบคุณสำหรับข้อมูลเชิงลึกหรือความช่วยเหลือที่คุณสามารถให้ได้ในหัวข้อนี้!
ยังไง