Neke kompanije, uključujući našeg kupca, razvijaju proizvod kroz partnersku mrežu. Na primjer, velike internetske trgovine integrirane su s uslugom dostave - naručite proizvod i uskoro dobijete broj za praćenje paketa. Drugi primjer je kada uz avionsku kartu kupite osiguranje ili kartu za Aeroexpress.
Za to se koristi jedan API, koji se mora izdati partnerima preko API Gateway-a. Rešili smo ovaj problem. U ovom članku ćemo vam reći detalje.
Dato: ekosistem i API portal sa interfejsom gde se korisnici registruju, primaju informacije itd. Moramo napraviti zgodan i pouzdan API Gateway. U tom procesu, morali smo da obezbedimo
- registracija,
- API kontrola veze,
- praćenje kako korisnici koriste krajnji sistem,
- obračunavanje pokazatelja poslovanja.
U članku ćemo govoriti o našem iskustvu u kreiranju API Gatewaya, tokom kojeg smo riješili sljedeće zadatke:
- autentikacija korisnika,
- autorizacija korisnika,
- izmjena prvobitnog zahtjeva,
- zatražiti proxy,
- postprocesiranje odgovora.
Postoje dvije vrste upravljanja API-jem:
1. Standard, koji radi na sljedeći način. Prije povezivanja, korisnik testira karakteristike, zatim plaća i ugrađuje na svoju stranicu. Najčešće se koriste u malim i srednjim preduzećima.
2. Veliki B2B API menadžment, kada kompanija prvo donese poslovnu odluku o povezivanju, postaje partner kompanije sa ugovornom obavezom, a zatim se povezuje na API. I nakon što su sve formalnosti riješene, kompanija dobija probni pristup, prolazi testiranje i kreće u proizvodnju. Ali to nije moguće bez odluke uprave o povezivanju.
Naše rešenje
U ovom dijelu ćemo govoriti o kreiranju API Gatewaya.
Krajnji korisnici kreiranog API gatewaya su partneri našeg kupca. Za svaku od njih već imamo potrebne ugovore. Trebat ćemo samo proširiti funkcionalnost označavanjem odobrenog pristupa pristupniku. U skladu s tim, potreban je kontrolirani proces povezivanja i upravljanja.
Naravno, bilo je moguće uzeti neko gotovo rješenje za rješavanje problema upravljanja API-jem i kreiranja API Gateway-a posebno. Na primjer, ovo bi moglo biti. Nije nam odgovaralo, jer smo u našem slučaju već imali API portal i oko njega izgrađen ogroman ekosistem. Svi korisnici su već registrovani, već su shvatili gdje i kako mogu dobiti potrebne informacije. Potrebna sučelja su već postojala na API portalu, trebao nam je samo API Gateway. Zapravo, mi smo angažovani na njegovom razvoju.
Ono što mi zovemo API Gateway je vrsta proxyja. Ovdje smo opet imali izbor - možete napisati svoj proxy, ili možete odabrati nešto spremno. U ovom slučaju, otišli smo na drugi način i odabrali nginx + Lua paket. Zašto? Trebao nam je pouzdan, testiran softver koji podržava skaliranje. Nakon implementacije nismo željeli provjeravati ni ispravnost poslovne logike ni ispravnost proxyja.
Svaki web server ima cjevovod za obradu zahtjeva. U slučaju nginx-a, to izgleda ovako:
(dijagram iz )
Naš cilj je bio da se uklopimo u ovaj cjevovod na mjestu gdje možemo modificirati originalni zahtjev.
Želimo kreirati transparentan proxy tako da zahtjev ostane funkcionalno isti kao što je i stigao. Mi samo kontroliramo pristup konačnom API-ju, pomažemo zahtjevu da dođe do njega. U slučaju da je zahtjev bio netačan, konačni API bi trebao pokazati grešku, ali ne i mi. Jedini razlog zbog kojeg možemo odbiti zahtjev je taj što klijent nema pristup.
Već postoji za nginx na . Lua je skriptni jezik, veoma je lagan i lak za učenje. Tako smo implementirali potrebnu logiku koristeći Lua.
Konfiguracija nginxa (analogija s rutom aplikacije), gdje se obavlja sav posao, sasvim je razumljiva. Ovdje je vrijedna pažnje posljednja direktiva - 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;
}
Razmotrite šta se dešava u ovoj konfiguraciji:
more_clear_input_headers — briše vrijednost zaglavlja navedenih nakon direktive.
lua_need_request_body - kontrolira da li se originalno tijelo zahtjeva treba pročitati prije izvršavanja direktiva rewrite/access/access_by_lua ili ne. Podrazumevano, nginx ne čita tijelo klijentskog zahtjeva, a ako mu treba pristupiti, onda bi ovu direktivu trebalo postaviti na uključeno.
rewrite_by_lua_file - putanja do skripte, koja opisuje logiku modifikacije zahtjeva
access_by_lua_file — putanja do skripte, koja opisuje logiku koja provjerava pristup resursu.
proxy_pass — url na koji će zahtjev biti proslijeđen.
body_filter_by_lua_file — putanja do skripte, koja opisuje logiku filtriranja zahtjeva prije nego što ga vrati klijentu.
I, konačno, post_action - službeno nedokumentovana direktiva s kojom možete izvršiti neke druge radnje nakon što odgovor dobijete klijentu.
Zatim ćemo opisati redom kako smo riješili naše probleme.
Autorizacija/autentifikacija i zahtjev za izmjenom
Autorizacija
Izgradili smo autorizaciju i autentifikaciju koristeći pristup certifikatima. Postoji root certifikat. Svaki novi klijent klijenta generiše njegov lični sertifikat, sa kojim može pristupiti API-ju. Ovaj sertifikat je konfigurisan u odeljku servera nginx postavki.
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;Modifikacija
Može se postaviti pošteno pitanje: šta da radimo sa sertifikovanim klijentom ako ga iznenada želimo da isključimo iz sistema? Nemojte ponovo izdavati certifikate za sve ostale klijente.
Tako smo glatko pristupili sljedećem zadatku - modificiranju originalnog zahtjeva. Inicijalni zahtjev klijenta, općenito govoreći, ne vrijedi za konačni sistem. Jedan od zadataka je dodavanje dijelova koji nedostaju u zahtjev kako bi on bio validan. Poenta je da su podaci koji nedostaju različiti za svakog klijenta. Znamo da nam klijent dolazi sa sertifikatom iz kojeg možemo uzeti otisak prsta i izvući potrebne podatke o klijentu iz baze podataka.
Ako u nekom trenutku trebate isključiti klijenta iz naše usluge, njegovi podaci će nestati iz baze podataka i on neće moći ništa učiniti.
Rad sa podacima o kupcima
Trebali smo učiniti rješenje visoko dostupnim, posebno načinom na koji dolazimo do podataka o kupcima. Poteškoća je u tome što je primarni izvor ovih podataka usluga treće strane koja ne garantuje neprekidnu i dovoljno veliku brzinu.
Stoga smo morali osigurati visoku dostupnost podataka o kupcima. Kao alat smo odabrali koji nam pruža:
- brz pristup podacima
- mogućnost organiziranja klastera od nekoliko čvorova s podacima repliciranim na različitim čvorovima.
Išli smo s najjednostavnijom strategijom za isporuku podataka u keš memoriju:
Rad sa krajnjim sistemom odvija se unutar sesija i postoji ograničenje maksimalnog broja. Ako klijent nije zatvorio sesiju, mi ćemo to morati učiniti.
Podaci otvorene sesije dolaze iz krajnjeg sistema i inicijalno se obrađuju na Lua strani. Odlučili smo koristiti Hazelcast za pohranu ovih podataka u .NET posao. Zatim, u određenim intervalima, proveravamo pravo na život otvorenih sednica i zatvaramo one pokvarene.
Pristup Hazelcastu iz Lua i .NET-a
Ne postoje Lua klijenti za rad sa Hazelcastom, ali Hazelcast ima REST API, koji smo odlučili da koristimo. Za .NET postoji , preko kojeg smo planirali pristupiti Hazelcast podacima na .NET strani. Ali nije ga bilo.
Prilikom pohranjivanja podataka putem REST-a i preuzimanja podataka putem .NET klijenta, koriste se različiti serijalizatori i deserijalizatori. Stoga je nemoguće staviti podatke kroz REST, već ih dobiti preko .NET klijenta i obrnuto.
Ako ima zainteresovanih, reći ćemo vam više o ovom problemu u posebnom članku. Spojler - na šemi.
Evidentiranje i praćenje
Naš korporativni standard za logovanje kroz .NET je Serilog, svi logovi završavaju u Elasticsearch-u, a mi ih analiziramo preko Kibane. Voleo bih da uradim nešto slično u ovom slučaju. Jedini rad sa Elastic-om na Lua-u, koji je pronađen, prekinuo je pri prvom zahtjevu. I koristili smo Fluentd.
- open source rješenje za pružanje jednog sloja prijavljivanja aplikacija. Omogućava vam da prikupljate zapise s različitih slojeva aplikacije, a zatim ih emitujete u jedan izvor.
API Gateway radi u K8S, pa smo odlučili da dodamo kontejner sa fluentd-om u istu podiju kako bismo pisali logove na postojeći otvoreni tcp port fluentd.
Također smo istražili kako bi se fluentd ponašao da nema veze s Elasticsearch-om. Dva dana, zahtjevi su se neprekidno slali na gateway, logovi su slani na fluentd, ali je fluentd-u zabranjen IP Elastic. Nakon što je veza obnovljena, fluentd je savršeno pretekao apsolutno sve logove u Elastic-u.
zaključak
Odabrani pristup implementaciji omogućio nam je da za samo 2.5 mjeseca isporučimo stvarno funkcionalan proizvod u borbeno okruženje.
Ako vam se jednog dana dogodi takve stvari, savjetujemo vam da prije svega jasno shvatite koji problem rješavate i koje resurse već imate. Budite svjesni složenosti integracije sa postojećim API sistemima upravljanja.
Shvatite sami šta ćete tačno razvijati - samo poslovnu logiku za obradu zahteva ili, kako bi to moglo biti u našem slučaju, ceo proxy. Ne zaboravite da sve što sami radite mora biti temeljno testirano nakon toga.
izvor: www.habr.com
