API Gateway: Užklausų maršrutizavimas ir apkrovos balansavimas globalioms architektūroms

Šiandieniniame tarpusavyje susijusiame skaitmeniniame kraštovaizdyje, kuriant patikimas ir mastelio keitimo programas, dažnai reikia pasinaudoti mikroservisais. Šios nepriklausomos paslaugos, nors ir siūlo lankstumą ir vikrumą, sukuria sudėtingumą valdant paslaugų sąveiką ir užtikrinant vientisą vartotojo patirtį. Šios sudėtingumo valdymo priešakyje yra API Gateway. Dvi jo svarbiausios ir kritiškiausios funkcijos yra užklausų maršrutizavimas ir apkrovos balansavimas. Šis įrašas gilinasi į šias sąvokas, paaiškindamas jų svarbą, kaip jos veikia ir jų nepakeičiamą vaidmenį šiuolaikinėse globaliose programinės įrangos architektūrose.

Pagrindinis API Gateway vaidmuo

Prieš gilindamiesi į maršrutizavimą ir apkrovos balansavimą, būtina suprasti, kas yra API Gateway ir kodėl ji yra mikroservisų pagrindas. API Gateway veikia kaip vienas įėjimo taškas visoms kliento užklausoms į jūsų užnugaros paslaugas. Užuot klientams tiesiogiai bendravus su atskiromis mikroservisais (o tai gali sukelti painų taškas-taškas jungčių rinkinį), jie sąveikauja su šliuzu. Tada šliuzas protingai persiunčia šias užklausas į atitinkamą užnugaros paslaugą.

Šis architektūrinis modelis siūlo keletą pagrindinių privalumų:

• Atjungimas: Klientai yra atjungti nuo užnugaros paslaugų, o tai leidžia paslaugas refaktoriuoti, atnaujinti arba pakeisti, nepaveikiant klientų.
• Abstrakcija: Ji slepia užnugario sudėtingumą, pateikdama vieningą API klientams.
• Centralizuotas rūpestis: Bendros funkcijos, tokios kaip autentifikavimas, autorizavimas, tarifų apribojimas, registravimas ir stebėjimas, gali būti tvarkomos šliuzo lygmeniu, sumažinant redundanciją tarp paslaugų.
• Patobulintas našumas: Šliuze gali būti įdiegtos tokios funkcijos kaip talpyklos ir užklausų apibendrinimas.

Šiame centriniame centre užklausų maršrutizavimas ir apkrovos balansavimas yra itin svarbūs efektyviam ir patikimam veikimui.

Užklausų maršrutizavimo supratimas

Užklausų maršrutizavimas yra procesas, kuriuo API Gateway nustato, kuri užnugario paslauga turėtų apdoroti gaunamą kliento užklausą. Tai kaip labai protingas eismo kontrolierius, nukreipiantis transporto priemones (užklausas) į teisingas paskirties vietas (paslaugas).

Kaip veikia užklausų maršrutizavimas?

API Gateway paprastai naudoja įvairias strategijas užklausoms maršrutizuoti:

• Maršrutizavimas pagal kelią: Tai vienas iš labiausiai paplitusių metodų. Šliuzas tikrina gaunamos užklausos URL kelią ir maršrutizuoja jį pagal iš anksto nustatytas taisykles. Pavyzdžiui:
• Užklausos į /users/ gali būti nukreiptos į Vartotojų paslaugą.
• Užklausos į /products/ gali būti nukreiptos į Produktų paslaugą.
• Užklausos į /orders/ gali būti nukreiptos į Užsakymų paslaugą.
• Maršrutizavimas pagal pagrindinį kompiuterį: Scenarijuose, kai vienas šliuzas gali aptarnauti kelias atskiras programas ar domenus, maršrutizavimas pagal pagrindinį kompiuterį leidžia šliuzui nukreipti užklausas pagal pagrindinio kompiuterio pavadinimą užklausos „Host“ antraštėje. Pavyzdžiui:
• Užklausos į api.example.com gali būti nukreiptos į vieną paslaugų rinkinį.
• Užklausos į admin.example.com gali būti nukreiptos į kitą.
• Maršrutizavimas pagal antraštę: Išplėstinis maršrutizavimas gali būti pagrįstas pasirinktinėmis antraštėmis, esančiomis užklausoje. Tai gali būti naudinga A/B testavimui, kanarėlių leidimams ar maršrutizavimui pagal konkrečius kliento atributus. Pavyzdžiui, „x-version“ antraštė galėtų nukreipti srautą į skirtingas paslaugos versijas.
• Maršrutizavimas pagal užklausos parametrą: Panašiai kaip ir maršrutizavimas pagal antraštę, tam tikri URL esantys užklausos parametrai taip pat gali diktuoti maršruto kelią.
• Maršrutizavimas pagal metodą: Nors ir ne taip dažnai naudojamas kaip pagrindinė maršrutizavimo strategija, HTTP metodas (GET, POST, PUT, DELETE) gali būti maršruto taisyklės dalis, ypač jei jis derinamas su maršrutizavimu pagal kelią.

Konfigūracija ir dinaminis maršrutizavimas

Maršruto taisyklės paprastai konfigūruojamos pačiame API Gateway. Ši konfigūracija gali būti statinė (apibrėžta konfigūracijos failuose) arba dinaminė (valdoma per API arba paslaugų atradimo mechanizmą).

Statinė konfigūracija: Paprastuose nustatymuose gali būti naudojami statiniai konfigūracijos failai. Tai lengva valdyti mažesniam diegimui, tačiau gali tapti sudėtinga, kai didėja paslaugų skaičius.

Dinaminis maršrutizavimas: Sudėtingesnėse debesų natūraliose aplinkose API Gateway integruojasi su paslaugų atradimo įrankiais (pvz., Consul, Eureka arba Kubernetes įmontuotas paslaugų atradimas). Kai paleidžiamas naujas paslaugos egzempliorius, jis užsiregistruoja paslaugų atradime. API Gateway užklausa paslaugų atradimui, kad gautų turimus tam tikros paslaugos egzempliorius, todėl jis gali dinamiškai nukreipti užklausas. Tai itin svarbu norint sklandžiai valdyti mastelio keitimo įvykius ir paslaugų gedimus.

Globalūs maršrutizavimo pavyzdžiai

• E. prekybos platformos: Toks globalus e. prekybos milžinas kaip Amazon arba Alibaba plačiai naudotų maršrutizavimą pagal kelią. Užklausos į /cart patenka į krepšelio paslaugą, /checkout į kasos paslaugą, o /user į vartotojo profilio paslaugą. Skirtingiems regionams gali būti naudojamas maršrutizavimas pagal pagrindinį kompiuterį (pvz., amazon.co.uk nukreipimas į JK specifines užnugario konfigūracijas).
• Važiavimo dalijimosi paslaugos: Tokios įmonės kaip Uber arba Grab naudoja maršrutizavimą užklausoms nukreipti į įvairius mikroservisus. Užklausa iš vairuotojo dėl netoliese esančių vairuotojų patektų į vairuotojų derinimo paslaugą, o užklausa peržiūrėti ankstesnes keliones patektų į kelionių istorijos paslaugą. Maršrutizavimas pagal antraštę gali būti naudojamas norint įdiegti naujas funkcijas tam tikram vartotojų pogrupiui konkrečiose geografinėse rinkose.
• Finansų įstaigos: Tarptautinis bankas gali naudoti maršrutizavimą užklausoms nukreipti į sąskaitų likučius į vieną paslaugą, pinigų pervedimus į kitą ir klientų aptarnavimą į dar vieną. Maršrutizavimas pagal pagrindinį kompiuterį gali būti naudojamas klientų užklausoms segmentuoti pagal jų bankininkystės skyrių (pvz., asmeninė bankininkystė ir verslo bankininkystė).

Apkrovos balansavimo supratimas

Nors užklausų maršrutizavimas nukreipia užklausą į *teisingo tipo* paslaugą, apkrovos balansavimas užtikrina, kad užklausa būtų išsiųsta į *sveiką ir prieinamą* tos paslaugos egzempliorių ir kad darbo krūvis būtų tolygiai paskirstytas tarp kelių egzempliorių. Be apkrovos balansavimo, vienas paslaugos egzempliorius gali būti perkrautas, o tai gali sumažinti našumą arba visiškai sugesti.

Apkrovos balansavimo poreikis

Mikroservisų architektūroje dažnai būna keli vienos paslaugos egzemplioriai, veikiantys siekiant valdyti didelius srauto kiekius ir užtikrinti redundanciją. Apkrovos balansavimas yra būtinas:

• Didelis prieinamumas: Jei vienas paslaugos egzempliorius sugenda, apkrovos balansavimo priemonė gali automatiškai peradresuoti srautą į sveikus egzempliorius, užkertant kelią paslaugos nutraukimui.
• Skalė: Didėjant srautui, galima pridėti naujų paslaugos egzempliorių, o apkrovos balansavimo priemonė pradės paskirstyti užklausas į juos, leidžiant programai keisti mastelį horizontaliai.
• Našumas: ToLygiu srauto paskirstymu užkertamas kelias tam, kad kuris nors vienas egzempliorius taptų kliūtimi, o tai lemia geresnį bendrą programos našumą ir sumažėjusį delsą.
• Išteklių panaudojimas: Užtikrina, kad visi turimi paslaugų egzemplioriai būtų naudojami efektyviai.

Bendrieji apkrovos balansavimo algoritmai

API Gateway arba tam skirti apkrovos balansavimo įrenginiai, su kuriais gali sąveikauti šliuzas, naudoja įvairius algoritmus srautui paskirstyti:

• Round Robin: Užklausos paskirstomos nuosekliai kiekvienam serveriui sąraše. Pasiekus sąrašo pabaigą, jis prasideda iš naujo nuo pradžios. Tai paprasta, bet neatsižvelgia į serverio apkrovą.
• Weighted Round Robin: Panašus į „Round Robin“, bet serveriams priskiriami svoriai. Serveriai, turintys didesnį svorį, gauna daugiau jungčių. Tai naudinga, kai serveriai turi skirtingus pajėgumus.
• Mažiausiai jungčių: Užklausos siunčiamos serveriui, kuriame yra mažiausiai aktyvių jungčių. Tai geras pasirinkimas ilgalaikėms jungtims.
• Svertinės mažiausios jungtys: Sujungia svorius su mažiausios jungtys algoritmu. Serveriai, turintys didesnį svorį, labiau linkę gauti naujų jungčių, tačiau sprendimas vis dar pagrįstas esamu aktyvių jungčių skaičiumi.
• IP Hash: Serveris pasirenkamas pagal kliento IP adreso maišą. Tai užtikrina, kad užklausos iš to paties kliento IP adreso visada pateks į tą patį serverį, o tai gali būti naudinga palaikant seanso būseną be specialios seanso saugyklos.
• Mažiausias atsako laikas: Nukreipia srautą į serverį, kuriame yra mažiausias vidutinis atsako laikas ir mažiausiai aktyvių jungčių. Šis algoritmas orientuotas į greičiausio atsakymo vartotojams pateikimą.
• Atsitiktinis: Iš turimo telkinio pasirenkamas atsitiktinis serveris. Paprasta, bet gali lemti netolygų pasiskirstymą per trumpą laiką.

Sveikatos patikrinimai

Svarbus apkrovos balansavimo komponentas yra sveikatos tikrinimas. API Gateway arba apkrovos balansavimo priemonė periodiškai tikrina užnugaros paslaugų egzempliorių būklę. Šie patikrinimai gali būti:

• Aktyvūs sveikatos patikrinimai: Apkrovos balansavimo priemonė aktyviai siunčia užklausas (pvz., pingus, HTTP užklausas į `/health` galutinį tašką) į užnugaros egzempliorius. Jei egzempliorius neatsako per nustatytą laiką arba grąžina klaidą, jis pažymimas kaip nesveikas ir pašalinamas iš turimų serverių telkinio, kol nebus atstatytas.
• Pasyvūs sveikatos patikrinimai: Apkrovos balansavimo priemonė stebi atsakymus iš užnugaros serverių. Jei ji pastebi didelį klaidų skaičių iš konkretaus serverio, ji gali daryti išvadą, kad serveris nesveikas.

Šis sveikatos tikrinimo mechanizmas yra gyvybiškai svarbus siekiant užtikrinti, kad srautas būtų siunčiamas tik į sveikus paslaugų egzempliorius, taip išlaikant programos stabilumą ir patikimumą.

Globalūs apkrovos balansavimo pavyzdžiai

• Srautinių paslaugų teikėjai: Tokios įmonės kaip Netflix arba Disney+ patiria didžiulį, svyruojantį srautą. Jų API Gateway ir pagrindinė apkrovos balansavimo infrastruktūra paskirsto užklausas tarp tūkstančių serverių egzempliorių visame pasaulyje. Kai išleidžiamas naujas serijos epizodas, apkrovos balansavimo priemonės užtikrina, kad užklausų padidėjimas būtų apdorotas neperkraunant nė vienos paslaugos. Jie taip pat naudoja sudėtingus algoritmus, kad nukreiptų vartotojus į artimiausius ir efektyviausius turinio pristatymo tinklo (CDN) kraštinius serverius.
• Socialinės žiniasklaidos platformos: Meta (Facebook, Instagram) kasdien apdoroja milijardus užklausų. Apkrovos balansavimas yra pagrindinis, kad šios platformos būtų prieinamos. Kai vartotojas įkelia nuotrauką, užklausa nukreipiama į atitinkamą įkėlimo paslaugą, o apkrovos balansavimas užtikrina, kad ši intensyvi užduotis būtų paskirstyta per daugelį turimų egzempliorių ir kad vartotojo kanalas būtų greitai užpildytas.
• Internetiniai žaidimai: Žaidimuose su daugybe žaidėjų (MMO) maža delsą ir didelis prieinamumas yra svarbiausia. API Gateway su patikimu apkrovos balansavimu nukreipia žaidėjus į žaidimų serverius, kurie yra geografiškai arčiausiai ir turi mažiausią apkrovą, užtikrindami sklandų žaidimo patyrimą milijonams vienu metu prisijungusių vartotojų visame pasaulyje.

Maršrutizavimo ir apkrovos balansavimo integravimas

Užklausų maršrutizavimas ir apkrovos balansavimas nėra nepriklausomos funkcijos; jie veikia kartu. Procesas paprastai atrodo taip:

1. Klientas siunčia užklausą į API Gateway.
2. API Gateway tikrina užklausą (pvz., jos URL kelią, antraštes).
3. Pagal iš anksto nustatytas taisykles šliuzas identifikuoja tikslinę mikroservisą (pvz., Vartotojų paslaugą).
4. Tada šliuzas konsultuojasi su turimų, sveikų to konkretaus Vartotojų paslaugos egzempliorių sąrašu.
5. Naudodama pasirinktą apkrovos balansavimo algoritmą (pvz., Mažiausiai jungčių), šliuzas parenka vieną sveiką Vartotojų paslaugos egzempliorių.
6. Užklausa persiunčiama į pasirinktą egzempliorių.

Šis integruotas metodas užtikrina, kad užklausos būtų nukreipiamos ne tik į tinkamą paslaugą, bet ir į prieinamą ir veikiantį tos paslaugos egzempliorių.

Išplėstinės nuostatos globalioms architektūroms

Globalinėms programoms maršrutizavimo ir apkrovos balansavimo sąveika tampa dar niuansiškesnė:

• Geografinis maršrutizavimas: Užklausos iš vartotojų skirtinguose geografiniuose regionuose gali būti nukreiptos į užnugaros paslaugas, įdiegtas duomenų centruose, kurie yra arčiausiai jų. Tai sumažina delsą ir pagerina vartotojo patirtį. Tai galima pasiekti turint regioninius API Gateway, kurie vėliau nukreipia užklausas į vietinius paslaugų egzempliorius.
• Geo-DNS apkrovos balansavimas: Dažnai DNS skiriamoji geba naudojama vartotojams nukreipti į artimiausią API Gateway egzempliorių.
• Global Server Load Balancing (GSLB): Ši pažangi technika paskirsto srautą tarp kelių duomenų centrų arba regionų. API Gateway tada gali atlikti vietinį apkrovos balansavimą konkrečiame regione.
• Paslaugos atradimo integravimas: Kaip minėta, patikima integracija su paslaugų atradimu yra būtina. Globaliame sąrankoje paslaugų atradimas turi žinoti apie paslaugų egzempliorius skirtinguose regionuose ir jų būklę.
• Kanarėlių leidimai ir Blue/Green diegimai: Šios diegimo strategijos labai priklauso nuo sudėtingo maršrutizavimo ir apkrovos balansavimo. Kanarėlių leidimai apima laipsnišką nedidelio srauto procento perkėlimą į naują paslaugos versiją, leidžiantį testuoti gamyboje. Blue/Green diegimai apima dviejų identiškų aplinkų paleidimą ir srauto perjungimą tarp jų. Abiems reikia, kad API Gateway dinamiškai valdytų srauto srautą pagal konkrečias taisykles (pvz., maršrutizavimą pagal antraštę kanarėlės atveju).

Tinkamo API Gateway sprendimo pasirinkimas

API Gateway sprendimo pasirinkimas yra kritinis ir priklauso nuo jūsų specifinių poreikių, masto ir esamos infrastruktūros. Populiarios parinktys apima:

• Debesų natūralūs sprendimai: AWS API Gateway, Azure API Management, Google Cloud API Gateway. Šios paslaugos yra valdomos ir siūlo gilų integravimą su atitinkamomis debesų ekosistemomis.
• Atvirojo kodo sprendimai:
• Kong Gateway: Labai išplečiamas, dažnai diegiamas su Kubernetes.
• Apache APISIX: Dinamiškas, realaus laiko, didelio našumo API šliuzas.
• Envoy Proxy: Dažnai naudojamas kaip duomenų lėktuvas paslaugų tinkle architektūroje (pvz., Istio), bet taip pat gali veikti kaip atskiras API Gateway.
• Nginx/Nginx Plus: Labai populiarus žiniatinklio serveris, kuris gali būti sukonfigūruotas kaip API Gateway su pažangiomis apkrovos balansavimo funkcijomis.
• Komerciniai sprendimai: Apigee (Google), Mulesoft, Tibco. Jie dažnai siūlo išsamesnes įmonės funkcijas ir palaikymą.

Vertindami sprendimus, atsižvelkite į jų galimybes:

• Maršrutizavimo lankstumas: Kaip lengvai galite apibrėžti sudėtingas maršruto taisykles?
• Apkrovos balansavimo algoritmai: Ar jis palaiko jums reikalingus algoritmus?
• Sveikatos tikrinimo mechanizmai: Ar jie yra patikimi ir konfigūruojami?
• Paslaugų atradimo integravimas: Ar jis integruojasi su pasirinktais paslaugų atradimo įrankiais?
• Našumas ir skalė: Ar jis gali valdyti numatomą srauto apkrovą?
• Stebėjimas: Ar jis suteikia gerą registravimą, stebėjimą ir atsekamumo galimybes?
• Išplėtimas: Ar galite pridėti pasirinktinės logikos ar papildinių?

Išvada

Užklausų maršrutizavimas ir apkrovos balansavimas yra ne tik techninės API Gateway funkcijos; jie yra pagrindiniai ramsčiai kuriant atsparias, mastelio keičiamas ir didelio našumo mikroservisų architektūras. Protingai nukreipdami gaunamas užklausas į atitinkamas užnugaros paslaugas ir tolygiai paskirstydami srautą per sveikus paslaugų egzempliorius, API Gateway užtikrina, kad programos išliktų prieinamos, našios ir galėtų valdyti dinamines apkrovas.

Globalioms programoms sudėtingas šių koncepcijų taikymas, dažnai derinamas su geografiniu suvokimu ir pažangiomis diegimo strategijomis, yra būtinas nuosekliai ir aukštesnei vartotojo patirčiai visame pasaulyje. Augant jūsų mikroservisų ekosistemai, gerai sukonfigūruota ir patikima API Gateway su efektyviu užklausų maršrutizavimu ir apkrovos balansavimu bus jūsų vertingiausias sąjungininkas, naršant sudėtingumą ir užtikrinant veiklos kompetenciją.

Naudingos įžvalgos:

• Apibrėžkite aiškias maršruto taisykles: Dokumentuokite ir standartizuokite savo maršrutizavimo strategijas, pagrįstas paslaugų atsakomybe.
• Pasinaudokite paslaugų atradimu: Integruokite savo API Gateway su paslaugų atradimo mechanizmu dinamiškam maršrutizavimui ir klaidų perėjimui.
• Įdiekite išsamius sveikatos patikrinimus: Užtikrinkite, kad jūsų šliuzas arba apkrovos balansavimo priemonė tiksliai stebėtų jūsų paslaugų egzempliorių būklę.
• Pasirinkite atitinkamus apkrovos balansavimo algoritmus: Pasirinkite algoritmus, kurie geriausiai atitinka jūsų paslaugos srauto modelius ir užnugaros galimybes.
• Stebėkite našumą: Nuolat stebėkite užklausų delsą, klaidų dažnį ir išteklių panaudojimą šliuzo lygmeniu, kad nustatytumėte kliūtis ir optimizuotumėte našumą.
• Apsvarstykite geografinį pasiskirstymą: Globalioms programoms planuokite savo API Gateway diegimą ir maršrutizavimo strategijas, kad galėtumėte aptarnauti vartotojus iš artimiausių buvimo taškų.

Įvaldę užklausų maršrutizavimą ir apkrovos balansavimą savo API Gateway, jūs padedate pagrindą patikimai ir ateičiai pritaikytai globalinei programos architektūrai.