Meie kogemus API Gateway loomisel

Mõned ettevõtted, sealhulgas meie klient, arendavad toodet partnervõrgustiku kaudu. Näiteks on suured internetipoodid integreeritud tarnehaldussüsteemiga – tellite toote ja saad peagi jälgimisnumbriga paki. Teine näide on see, et koos lennupiletiga ostetakse kindlustus või pilet aeroekspressile.

Selleks kasutatakse ühte API-d, mille peame partneritele API Gateway kaudu esitama. Selle ülesande me lahendasime. Selles artiklis räägime üksikasjadest.

Antud: ökosüsteem ja API-portaal koos liidese ning registreeritud kasutajatega, kes saavad teavet jne. Me peame looma mugava ja usaldusväärse API Gateway. Protsessi käigus pidime tagama

• registreerimise,
• ühenduse kontrolli API-ga,
• kasutajate tegevuse jälgimise lõpp-süsteemis,
• ärinäitajate arvestuse.

Artiklis räägime oma kogemustest API Gateway loomisel, mille käigus lahendasime järgmised ülesanded:

• kasutaja autentimine,
• kasutaja volitamine,
• algse päringu modifitseerimine,
• päringu edastamine,
• vastuse järel töötlemine.

On kaks tüüpi API haldust:

1. Standardne, mis töötab järgmiselt. Enne ühendamist testib kasutaja võimalusi, seejärel maksab ja integreerib oma veebisaidile. Seda kasutavad kõige sagedamini väike ja keskmine äri.

2. Suur B2B API haldus, kus ettevõte teeb esmalt ärilise otsuse ühendamiseks, becomes partner of the company with a contractual obligation, pärast mida liitub API-ga. Ja alles pärast kõigi formaalsuste lahendamist saab ettevõte testimisõiguse, läbib testimise ja jõuab tootmisse. Kuid see pole võimalik ilma juhtimisotsuseta ühendamiseks.

Meie lahendus

Selles osas räägime API Gateway loomise protsessist.

API-käideldava lõppkasutaja sihtgrupp on meie kliendi partnerid. Igaühe jaoks on meil juba vajalikud lepingud olemas. Peame lihtsalt laiendama funktsionaalsust, märkides juurdepääsu väravas. Seega on vaja kontrollitud protsessi ühendamiseks ja haldamiseks.

Muidugi oleks olnud võimalik võtta mõni valmis lahendus API haldamise ja API Gateway loomise ülesande täitmiseks. Näiteks võiks see olla Azure API Management. Meile see ei sobinud, sest meie olukorras oli meil juba olemas API-portaal ja hiiglaslik ökosüsteem selle ümber. Kõik kasutajad olid juba registreeritud, nad mõistsid, kust ja kuidas nad saavad vajalikku teavet. API-portaalis olid juba olemas vajalikud liidesed, me vajasime vaid API Gatewayd. Selle arendusega me tegelikult tegelesime.

Seda, mida me nimetame API Gatewayks — on omamoodi proks. Siin oli meil taas valik — kas kirjutada oma proks või valida juba midagi valmiskujul. Sellel juhul läksime teist teed ja valisime kombinatsiooni nginx+Lua. Miks? Me vajasime usaldusväärset, testitud tarkvara, mis toetaks skaleerimist. Me ei soovinud pärast rakendamist kontrollida ei äri loogika õigsust ega proksi töö õigsust.

Igal veebiserveril on päringu töötlemise konveier. Nginxi puhul näeb see välja järgmiselt:

(skeem on GitHub Lua Nginx)

Meie eesmärk oli integreeruda sellesse konveierisse sel hetkel, kus me saame algset päringut modifitseerida.

Me tahame luua läbipaistva proksi, et funktsionaalselt jääks päring selliseks, nagu ta tuli. Me lihtsalt kontrollime juurdepääsu lõplikule API-le, aitame päringul sinna jõuda. Juhul, kui päring oli vale, peaks vea näitama lõplik API, mitte meie. Ainus põhjus, miks me saame päringu tagasi lükata, on põhjendamatud kliendi juurdepääsuõigused.

Nginxi jaoks on juba olemas laiendamine . Tundub, et Lua. Lua on skriptimiskeel, see on väga kerge ja lihtne õppida. Seega, vajalik loogika teostati Lua abiga.

Nginxi konfiguratsioon (analoogia rakenduse marsruudiga), kus kogu töö toimub, on üsna arusaadav. Siin on tähelepanuväärne viimane direktiiv — post_action.

location /middleware {
      more_clear_input_headers Accept-Encoding;
      lua_need_request_body on;
      rewrite_by_lua_file 'middleware/rewrite.lua';
      access_by_lua_file 'middleware/access.lua';
      proxy_pass https://someurl.com;
      body_filter_by_lua_file 'middleware/body_filter.lua';
      post_action /process_session;
}

Vaatame, mis juhtus selle konfiguratsiooniga:
more_clear_input_headers — puhastab direktiivide järel märgitud päiste väärtused.
lua_need_request_body — reguleerib, kas tuleks lugeda algne päringu keha enne direktiivide rewrite/access/access_by_lua täitmist või mitte. Vaikimisi ei loe nginx kliendi päringu keha ning kui teil on sellele juurdepääs vajalik, peab see direktiiv olema väärtusega on.
rewrite_by_lua_file — tee skripti, kus on kirjeldatud päringu muutmise loogika
access_by_lua_file — tee skripti, kus on kirjeldatud loogika, mis kontrollib juurdepääsu olemasolu ressursile.
proxy_pass — url, kuhu päring edastatakse.
body_filter_by_lua_file — tee skripti, kus on kirjeldatud loogika päringu filtreerimiseks enne, kui see klientidele tagastatakse.
Ja lõpuks, post_action — ametlikult dokumenteerimata direktiiv, millega saab teha muid toiminguid pärast seda, kui vastus on kliendile antud.

Järgnevalt räägime järjestikku, kuidas me oma ülesandeid lahendasime.

Autoriseerimine/ autentimine ja päringu muutmine

Autoriseerimine

Autoriseerimist ja autentimist teostasime sertifikaatide kaudu. On olemas juursertifikaat. Iga uue kliendi jaoks genereeritakse oma isiklik sertifikaat, millega ta saab API-le juurde pääseda. See sertifikaat seadistatakse nginx'i serveri seadete lõigus.

ssl on;
ssl_certificate /usr/local/openresty/nginx/ssl/cert.pem;
ssl_certificate_key /usr/local/openresty/nginx/ssl/cert.pem;
ssl_client_certificate /usr/local/openresty/nginx/ssl/ca.crt;
ssl_verify_client on;

Muutmine

Tõstatub õigustatud küsimus: mida teha sertifitseeritud kliendiga, kui me äkki soovime ta süsteemist välja lülitada? Ei ole ju mõistlik sertifikaate kõigi teiste klientide jaoks uuesti välja anda.

Nii jõudsime sujuvalt järgmise ülesande juurde — algse päringu muutmine. Kliendi algne päring ei ole üldiselt lõpp-süsteemi jaoks kehtiv. Üks ülesandeid on lisada päringusse puuduolevaid osi, et muuta see kehtivaks. Probleem on selles, et puuduolevad andmed on igale kliendile erinevad. Me teame, et klient tuleb meile sertifikaadiga, millest saame võtta jälje ja välja tõmmata kliendi vajalikud andmed andmebaasist.

Kui mingil hetkel on vajalik klient meie teenusest välja lülitada, kaovad tema andmed andmebaasist ja ta ei saa enam midagi teha.

Töötamine kliendi andmetega

Meil oli vaja tagada lahenduse kõrge kättesaadavus, eriti nende andmete saamise osas. Probleem seisneb selles, et andmete esmasteks allikateks on kolmandate osapoolte teenused, mis ei garanteeri katkestusteta ja piisavalt kõrget töökiirust.

Seetõttu pidi meil tagama kliendiandmete kõrge kättesaadavus. Tööriistaks valisime Hazelcast, mis pakub meile:

• kiire juurdepääs andmetele,
• võimalus korraldada kluster mitmest sõlmest replitseeritud andmetega eri sõlmedes.

Me järgnesime kõige lihtsamale andmeedastamise strateegiale vahemälusse:

Töötamine lõppkasutaja süsteemiga toimub sessioonide raames ja on piirang maksimaalsete sessioonide arvu osas. Kui klient ei ole sessiooni suletud, peame me selle lõpetama.

Teave avatud sessiooni kohta tuleb lõppkasutaja süsteemist ja see töödeldakse esmalt Lua poolel. Otsustasime kasutada Hazelcasti nende andmete salvestamiseks töötaskuga, mis on kirjutatud .NET-is. Seejärel kontrollime teatud aja jooksul avatud sessioonide elujõulisust ja sulgeme aegunud sessioonid.

Juurdepääs Hazelcastile nii Lua-st kui ka .NET-ist

Lua-le, mis töötaks Hazelcastiga, kliente ei ole, kuid Hazelcastil on REST API, mida me otsustasime kasutada. .NET-i jaoks on olemas sattus tausta, mille kaudu kavatsesime saada juurdepääsu Hazelcasti andmetele .NET poolel. Kuid sellega oli probleeme.

REST-i kaudu andmete salvestamisel ja .NET kliendi kaudu väljavõttel kasutatakse erinevaid serialiseerijat/dserialiseringut. Seetõttu ei ole võimalik andmeid salvestada REST-i kaudu ja neid välja võtta .NET kliendi kaudu ning vastupidi.

Kui kedagi huvitab, saame sellest probleemist rääkida põhjalikumalt eraldi artiklis. Spoiler — joonisel.

Logimine ja monitooring

Meie ettevõtte standard logimiseks .NET-is on Serilog, kõik logid jõuavad lõpuks Elasticsearchi, me analüüsime neid Kibana kaudu. Soovisime midagi sarnast teha ka sel juhul. Ainus sattus tausta Lua-le tööks Elasticus, mis leiti, katkes esimesel require-l. Ja me kasutasime Fluentd-d.

Fluentd — avatud lähtekoodiga lahendus, et tagada rakenduse logimise ühtne kiht. See võimaldab koguda logisid erinevatest rakenduse kihtidest ja seejärel edastada need ühte allikasse.

API Gateway töötab K8S-is, seega otsustasime lisada konteineri fluentd samasse podi, et kirjutada logisid olemasolevasse avatud tcp porti fluentd.

Uurisime ka, kuidas käitub fluentd, kui tal pole ühendust Elasticsearchiga. Kaks päeva järjest edastati pidevalt päringuid väravasse, fluentd-sse saadeti logisid, kuid fluentd-l oli Elasticu IP blokeeritud. Pärast ühenduse taastamist edastas fluentd kõik logid sujuvalt Elasticisse.

Kokkuvõte

Valitud lähenemisviis võimaldas meil tuua tõeliselt töötava toote tootmisse vaid 2,5 kuu jooksul.

Kui kunagi peaksite tegelema selliste asjadega, soovitame kõigepealt selgelt mõista, millist ülesannet te lahendada püüdlete ja millised ressursid teil juba on. Olge tähelepanelik API haldussüsteemide integreerimise raskuste suhtes.

Mõistke, mida te tegelikult arendama asute — ainult äriloogikat päringute töötlemiseks või, nagu meie puhul, kogu proksi. Ära unusta, et kõik, mida te ise teete, peab hiljem olema põhjalikult testitud.

Allikas: habr.com