Meie kogemus API Gateway loomisel.

Mõned ettevõtted, sealhulgas meie klient, arendavad toodet partnerite võrgustiku kaudu. Näiteks on suured veebipoed integreeritud kohaletoimetamisteenustega — te tellite toote ja saate varsti jälgimisnumber. Teine näide — koos lennupiletiga ostate ka kindlustuse või pileti lennujaamabussile.

Selleks kasutatakse ühte API-t, mille tuleb partneritele anda läbi API Gateway. Selle ülesande lahendamisega me tegelesime. Selles artiklis jagame üksikasju.

Kontekst: ökosüsteem ja API-portaal, kus kasutajad on registreeritud, saavad teavet jne. Me peame looma mugava ja usaldusväärse API Gateway. Protsessi käigus pidime tagama

• registreerimise,
• API-ühenduse kontrollimise,
• kasutajate tegevuse jälgimise lõpp-süsteemis,
• äri näitajate jälgimise.

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

• kasutaja autentimine,
• kasutaja autoriseerimine,
• algse päringu muutmine,
• päringu edastamine,
• vastuse töötlemine.

API haldamise on kahte tüüpi:

1. Standardlahendus, mis töötab järgmiselt. Enne ühenduse loomist testib kasutaja võimalusi, seejärel maksab ja integreerib oma saidile. Enim kasutavad seda väike- ja keskmiselt ettevõtted.

2. Suur B2B API haldamine, kus ettevõte teeb esmalt äriotsuse ühenduse loomise kohta, saab ettevõtte partneriks lepinguliste kohustustega, pärast mida ühildub API-ga. Ja pärast kõigi vormistamiste lõpetamist saab ettevõte testimisjuurdepääsu, läbib testimise ja läheb tootmisse. Kuid see ei ole võimalik ilma juhtimisotsuseta ühenduse loomiseks.

Meie lahendus

Selles osas räägime API Gateway loomise protsessist.

API looja lõppkasutajad on meie kliendi partnerid. Igaühe jaoks on meil juba vajalikud lepingud olemas. Peame lihtsalt laiendama funktsionaalsust, märkides antud juurde pääsu väravale. Seega on vajalik kontrollitud ühendamise ja haldamise protsess.

Ilmselgelt oleks olnud võimalik võtta mõni valmis lahendus API haldamise ja eriti API Gateway loomiseks. Näiteks võiks selliseks olla Azure API Management. Meie puhul see ei sobinud, sest meil oli juba API-portaal ja sellele rajatud suur ökosüsteem. Kõik kasutajad olid juba registreeritud ning nad mõistsid juba, kus ja kuidas nad saavad vajalikku teavet. API-portaalis olid juba olemas vajalikud liidesed, me vajasime vaid API Gateway’d. Just selle arendamisega me kokkuvõttes tegelema hakkasime.

Seda, mida me nimetame API Gateway’ks, võib pidada omamoodi pöördeliseks. Ka siin seisis meil taas ees valik — kirjutada oma pöördel või valida juba midagi valmisolevat. Antud juhul läksime teist teed ja valisime kombinatsiooni nginx+Lua. Miks? Me vajasime usaldusväärset, testitud tarkvara, mis toetaks skaleerimist. Me ei tahtnud pärast elluviimist kontrollida mitte ainult äri loogika õigsust, vaid ka pöördeliidestuse töö korrektset toimimist.

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

(skeem GitHub Lua Nginx)

Meie eesmärk oli siseneda sellesse konveierisse hetkel, kus me saaksime algset päringut muuta.

Soovime luua läbipaistva proxy, et funktsionaalne päring jääks selliseks, nagu ta on. Kontrollime vaid juurdepääsu lõpp-API-le ja aitame päringul sinna jõuda. Kui päring oli vale, peab vea näitama lõpp-API, mitte meie. Ainus põhjus, miks me päringu tagasi võime lükata, on kliendi juurdepääsu puudumine.

Nginx jaoks on juba olemas laiendust järgnevaga Lua. Lua on skriptikeel, mis on väga kerge ja hõlpsasti omandatav. Seega rakendasime vajalikku loogikat Lua abil.

Nginxi konfiguratsioon (analoogia rakenduse marsruudiga), kus kogu töö toimub, on täiesti arusaadav. Siin on märkimisvää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 toimub selles konfiguratsioonis:
more_clear_input_headers — puhastab direktiivi järel nimetatud päiste väärtuse.
lua_need_request_body — reguleerib, kas tuleb lugeda päritud päringu keha enne rewrite/access/access_by_lua direktiivide täitmist või mitte. Vaikimisi ei loe nginx kliendi päringu keha, ja kui on vajalik sellele juurde pääseda, peab see direktiiv olema seatud väärtusele on.
rewrite_by_lua_file — tee skripti, mis määratleb päringu muutmise loogika
access_by_lua_file — tee skripti, mis määratleb loogika, mis kontrollib juurdepääsu olemasolu ressursile.
proxy_pass — url, kuhu päring edastatakse.
body_filter_by_lua_file — tee skripti, mis määratleb loogika päringu filtreerimiseks enne selle tagastamist kliendile.
Ja lõpuks, post_action — ametlikult dokumenteerimata direktiiv, mis võimaldab teha muid toiminguid pärast vastuse andmist kliendile.

Edasi räägime samm-sammult, kuidas me oma ülesandeid lahendasime.

Autoriseerimine/autentimine ja päringu modifitseerimine

Autoriseerimine

Oleme autoriseerimise ja autentimise loonud sertifikaatide põhjal. On juursertifikaat. Iga uue kliendi jaoks genereeritakse isiklik sertifikaat, mille kaudu saab ta ligipääsu API-le. Selle sertifikaadi seadistamine toimub nginx serveri seadete jaotises.

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

Võib küsida, mida teha sertifitseeritud kliendiga, kui me äkki otsustame ta süsteemist välja lülitada? Kas tõesti, et kõigi teiste klientide sertifikaate uuesti välja anda.

Nii oleme sujuvalt jõudnud järgmise ülesandeni — sisendpäringu muutmine. Klientide algne päring ei ole põhjapanevalt kehtiv lõpp-süsteemi jaoks. Üks ülesanne on lisada päringusse puuduvaid osi, et muuta see kehtivaks. Asi on selles, et puuduvaid andmeid on igale kliendile erinevalt. Me teame, et klient tuleb meile sertifikaadiga, mille põhjal saame võtta sõrmejälje ja tõmmata andmebaasist vajalikud kliendi andmed.

Kui mingil hetkel on vajalik klient meie teenusest eemaldada, siis tema andmed kaovad andmebaasist ja ta ei saa midagi teha.

Kliendiandmetega töötamine

Me pidime tagama lahenduse kõrge kätte saadavuse, eriti selle osas, kuidas me kliendiandmeid saame. Probleemiks on see, et nende andmete algallikaks on kolmanda osapoole teenus, mis ei garanteeri katkematut ja piisavalt kõrget töökiirus.

Seetõttu pidime tagama klientide andmete kõrge kätte saadavuse. Tööriistana valisime Hazelcast, mis pakub meile:

• kiiret juurdepääsu andmetele,
• võimalust organiseerida klaster mitmest nodist, millel on replikatsioon erinevates nodides.

Me valisime kõige lihtsama strateegia andmete edastamiseks vahemällu:

Lõpp-süsteemiga töötamine toimub sessioonide raames ja on maksimaalne piir. Kui klient ei ole sessiooni lõpetanud, peame seda tegema meie.

Avasessiooni andmed saavad lõpp-süsteemist ja töödeldakse alguses Lua poolel. Otsustasime kasutada Hazelcast'i nende andmete salvestamiseks .NET keeles kirjutatud tööjuhtmoodulis. Seejärel kontrollime perioodiliselt avatud sessioonide elujõudlust ja sulgeme aegunud sessioonid.

Pääs Hazelcasti juurde on nii Lua kui ka .NET kaudu.

Hazelcasti jaoks ei ole Lua kliente, kuid Hazelcast'il on REST API, mida me otsustasime kasutada. .NET'i puhul on olemas kliendi, mille kaudu plaanisime pääseda andmetele Hazelcasti poolt .NET poolel. Kuid mitte nii kiiresti.

REST kaudu andmete salvestamisel ja .NET kliendi kaudu nende täiustamisel kasutatakse erinevaid serialiseerijaid/deserialiseerijaid. Seetõttu ei ole võimalik andmeid RESTi kaudu sisestada ja seejärel .NET kliendi kaudu välja võtta ja vastupidi.

Kui on huvilisi, saame sellest probleemist üksikasjalikumalt rääkida eraldi artiklis. Spoileri jaoks — skeemil.

Logimine ja jälgimine

Meie ettevõtte standard logimise jaoks .NET'is on Serilog, kõik logid jõuavad viimaks Elasticsearch'i ja nende analüüsi teeme Kibanaga. Midagi sarnast soovisime ka sel juhul teha. Ainult et kliendi Elasticiga töötamiseks mõeldud Lua, mis leiti, purunes juba esimeses require'is. Ja me kasutasime Fluentd-d.

Fluentd — avatud lähtekoodiga lahendus, mis tagab rakenduse logimise ühtse kihi. See võimaldab koguda logisid erinevatest rakenduse kihtidest ja seejärel edastada need ühte allikasse.

API Gateway töötab K8S-is, seetõttu otsustasime lisada konteineri Fluentd sama pod'i, et kirjutada logisid olemasolevasse avatud tcp porti Fluentd.

Uurime ka, kuidas käitub Fluentd, kui tal pole ühendust Elasticsearchiga. Kaks päeva ajal suunati pidevalt päringud väravasse, Fluentd'le saadeti logisid, kuid Fluentd IP Elasticust blokeeriti. Pärast ühenduse taastamist edastas Fluentd kõik logid Elasticsearchi täielikult.

Kokkuvõte

Valitud rakenduse lähenemine võimaldas meil toimetada reaalselt töötava toote tootmiskeskkonda vaid 2,5 kuuga.

Kui kunagi satute tegelema sarnaste asjadega, soovitame esmalt selgelt mõista, millist ülesannet te lahendate ja milliseid ressursse teil juba on. Olge ettevaatlikud API haldamise olemasolevate süsteemidega integreerimise keerukuste suhtes.

Mõistke ise, mida te kavatsete arendada — kas ainult äriloogikat, mis käsitleb päringute töötlemist, või, nagu see oli meie puhul, terve proksi. Ärge unustage, et kõik, mida te ise teete, peab hiljem olema põhjalikult testitud.

Allikas: habr.com