Score:1

Load Balancing HTTP/2 GRPC การเชื่อมต่อแบบถาวร

ธง in
Sam

ลองมาดูสถานการณ์นี้กัน

ในโมเดล 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 เหมาะสมอย่างยิ่งสำหรับการสตรีมสื่อและทราฟฟิกการตอบสนองของเซิร์ฟเวอร์จำนวนมาก

ขอบคุณสำหรับข้อมูลเชิงลึกหรือความช่วยเหลือที่คุณสามารถให้ได้ในหัวข้อนี้!

ยังไง

in flag
Sam
ฉันเกือบจะคิดเกี่ยวกับการสร้างบางอย่างในสนิมหรือ erlang ที่ยอมรับคำขอ HTTP1.x โดยทั่วไป (คำขอนี้มาจากเบราว์เซอร์) ที่ยอมรับซ็อกเก็ตและส่งคืนโทเค็น dnsname + และจากการตอบสนองนั้นตั้งค่าการเชื่อมต่อ HTTP/2 ด้วยชื่อ DNS และข้อมูลโทเค็นนั้น (สำหรับการรับรองความถูกต้องบนเซิร์ฟเวอร์อื่น)

โพสต์คำตอบ

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