Puncte:0

Când ar trebui să adaug mai multe grupuri de puncte finale de rețea la un serviciu backend?

drapel vn

Când configurez un Google Cloud Load Balancer, mi se prezintă opțiunea de a adăuga mai multe Grupuri de puncte finale de rețea pentru a mea Servicii de backend.

O mare parte din literatura despre Cloud Load Balancing se concentrează pe distribuția geografică a cererilor servicii identice reprezentând o singură limită implementate în diferite locații.

Documentație Google Cloud mențiuni că grupurile de puncte terminale de rețea fără server sunt „Un serviciu Cloud Run sau un grup de servicii care partajează același model de adrese URL.” Nu sunt 100% sigur la ce se înțelege „același model de adresă URL”, dar dacă asta înseamnă ceva de genul „sunt aceeași aplicație” sau „au aceleași rute”, s-ar aplica această regulă și pentru serviciile de backend sau serviciile de backend pot fi compuse din grupuri de puncte terminale de rețea cu diferite „Modele URL”?

În cazul aplicațiilor mele, folosim mai multe regiuni pentru respectarea cerințelor de rezidență a datelor în cazul în care fiecare regiune reprezintă o limită separată cu date diferite. Aceasta înseamnă că logica aplicației noastre comută DNS (api-ca, api-us) a bazat utilizatorul selectând în mod conștient care regiune pentru a-și stoca datele în.

Cu acest lucru stabilit, întrebările mele specifice sunt:

  • Având în vedere că nu sunt interschimbabile, mai are sens să-mi configurez grupurile de puncte finale de rețea pentru toate regiuni sub un singur serviciu de backend?
  • Rețineți că lucrez și sub constrângerea că Google Cloud pare să aibă o cotă strânsă pentru serviciile de backend.

Vă rugăm să rețineți:

  • Motivul pentru care trebuie să folosesc echilibrarea încărcăturii în cloud este că cel puțin una dintre regiunile în care implementăm un serviciu Google Cloud Run nu acceptă mapările de domenii personalizate.
Puncte:0
drapel gh

A începe cu -

Un model URL conține un domeniu plus un model care se poate potrivi cu o cale URL, de exemplu: example.com/*/animals/** . Oricare dintre următoarele solicitări URL ar putea corespunde exemplului de model de URL: exemplu.com/singapore/animals exemplu.com/australia/animals/spiders exemplu.com/australia/animals/marsupials/koala.png

Înțeleg că utilizați Cloud Run pentru a vă găzdui aplicația și, prin urmare, încercați să utilizați NEG fără server și

a) Da, este bine să configurați mai multe NEG-uri (1 NEG per regiune) pentru același serviciu backend, dar are puține limitări, așa cum este descris în Descriere

b) De asemenea, utilizarea combinației de echilibrare a încărcăturii Cloud Run și HTTP(e) vă ajută să mapați adresa URL unică la mai multe aplicații identice fără server care rulează în regiuni diferite, așa cum este descris în doc ceea ce ar putea fi benefic în scenariul dvs.

Cred că încercați să configurați Cloud Run într-una dintre regiunile menționate în âLimitări de mapare a domeniului Cloud Runâ și, prin urmare, vă confruntați cu problema în utilizarea mapării personalizate a domeniilor. Dacă încercați să configurați în orice altă regiune, vă rugăm să distribuiți mesajul de eroare.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.