Să aruncăm o privire la acest scenariu.
Într-un model tradițional LB, am avea LB (fie că este un proxy invers sau nu) să obțină req/rep la serverele la nivel de aplicație. Acest model este bine pentru stilul de comunicare generic de solicitare/repetiție, dar ce se întâmplă atunci când avem conexiuni persistente.
Să ne uităm la un exemplu HTTP/2.
Aici nu avem o paradigmă simplă Req/Rep în care să pot pur și simplu să trimit cererea și să echilibrez sarcina respectivă și să primesc un răspuns. Întreaga arhitectură este apatridă (uitați de sesiunile sticky, deoarece asta are implicații care nu sunt relevante în acest exemplu). Ce se întâmplă, avem o conexiune persistentă, cum ar fi HTTP/2.
Nu pot conecta conexiunea HTTP/2 la LB, altfel acel LB se va satura extrem de repede și toate cererile clientului care nu au deja un soclu conectat cu acel LB vor avea ghinion. Dacă se bazează pe DNS pentru a indica acel LB, există o mulțime de probleme atunci când rămânem fără spațiu de socket.
Avem nevoie de ceva care să redirecționeze aproape cererea inițială SYN către un alt server care ar putea fi un alt LB sau nivelul aplicației însuși (uitați de atacurile de securitate/exterior).
Clientul trimite cererea s1.com --> (accesează DNS și returnează ip .123)
Clientul trimite apoi cererea de conexiune HTTP/2 la .123 (aceasta este un LB), dar în loc să se conecteze și să treacă la nivelul aplicației, trimite înapoi un răspuns la „redirecționare .. similar cu un 302 în HTTP” la ip .124 . IP .124 ar putea fi un alt tip de LB sau ar putea fi stratul de aplicație însuși, unde socket-ul real este legat pentru comunicarea HTTP/2.
Managementul .123 și nodurile către care indică ar putea fi gestionat cu o varietate de instrumente care există în prezent, dar în ceea ce privește această „redirecționare HTTP/2 pentru a echilibra problema încărcării socketului” nu am reușit să găsesc o soluție. .
Există o modalitate mai bună de a gestiona acest lucru (din nou, nu pentru serviciile interne, ci pentru solicitările externe) sau există un proxy/serviciu/sistem care să rezolve această problemă?
DSR este ușor diferit prin faptul că rezolvă problema la un nivel diferit și este cu adevărat relevant atunci când aveți mult trafic de retur, dar nu rezolvă problema dacă traficul este bidirecțional (nu funcționează, de asemenea, la mulți furnizori de cloud). ). DSR are o mulțime de sens pentru streaming media și trafic intens de răspuns pe server.
Vă mulțumim pentru orice informații sau ajutor pe care îl puteți oferi cu privire la acest subiect!
Cum
