Disa kompani, pĂ«rfshirĂ« edhe klientin tonĂ«, zhvillojnĂ« produktin pĂ«rmes njĂ« rrjeti partnerĂ«sh. PĂ«r shembull, dyqanet e mĂ«dha online janĂ« tĂ« integruara me shĂ«rbimin e dĂ«rgesĂ«s â ju bĂ«ni porosinĂ« dhe sĂ« shpejti merrni numrin e ndjekjes sĂ« paketĂ«s. NjĂ« shembull tjetĂ«r â sĂ« bashku me biletĂ«n tuaj tĂ« fluturimit blini sigurimin ose biletĂ«n pĂ«r aeropĂ«rtin.
Për këtë përdoret një API, i cili duhet të jepet partnerëve përmes API Gateway. Këtë detyrë e zgjodhëm ne. Në këtë artikull do të tregojmë detajet.
Dhe: ekosistemi dhe portali i API-ve me një ndërfaqe, ku përdoruesit janë regjistruar, marrin informacion etj. Na nevojitet të bëjmë një API Gateway të përshtatshëm dhe të besueshëm. Në procesin e krijimit na duhej të siguronim
- regjistrimin,
- kontrollin e lidhjes me API,
- monitorimin e mënyrës si përdoruesit përdorin sistemin përfundimtar,
- raportimin e treguesve të biznesit.
Në këtë artikull do të flasim për përvojën tonë në krijimin e API Gateway, gjatë së cilës ne zgjodhëm detyrat e mëposhtme:
- autentifikimi i përdoruesit,
- autorizimi i përdoruesit,
- modifikimi i kërkesës origjinale,
- proksimi i kërkesës,
- pasprocesimi i përgjigjes.
Ka dy lloje menaxhimi të API-ve:
1. Standard, i cili funksionon si më poshtë. Para lidhjes, përdoruesi teston kapacitetet, pastaj paguan dhe e integrojnë në faqen e tij. Në përgjithësi, ato përdoren nga bizneset e vogla dhe të mesme.
2. B2B i madh për Menaxhimin e API-ve, kur një kompani fillimisht merr një vendim të biznesit për lidhjen, bëhet partner me kompaninë me një detyrim kontraktual, pas së cilës lidhet me API-në. Dhe vetëm pasi të zgjidhen të gjitha formalitetet, kompania merr qasje testuese, kalon testimin dhe del në prodhim. Por kjo nuk është e mundur pa një vendim menaxherial për lidhjen.
Zgjidhja jonë
Në këtë pjesë do të flasim për krijimin e API Gateway.
PĂ«rdoruesit e fundit tĂ« portĂ«s sĂ« krijuar pĂ«r API â partnerĂ«t e klientit tonĂ«. PĂ«r secilin prej tyre, ne tashmĂ« mbajmĂ« kontratat e nevojshme. Na nevojitet vetĂ«m tĂ« zgjeroni funksionalitetin, duke shĂ«nuar qasjen e dhĂ«nĂ« nĂ« portal. PĂ«rkatĂ«sisht, nevojitet njĂ« proces i kontrolluar pĂ«r lidhjen dhe menaxhimin.
Sigurisht, mund të ishte marrë ndonjë zgjidhje të gatshme për të zgjidhur detyrën e Menaxhimit të API-ve dhe krijimin e API Gateway, në veçanti. Për shembull, një mundësi e tillë mund të ishte. Na nuk e zgjodhëm, sepse në rastin tonë ne kishim tashmë një portal API dhe një ekosistem të madh të ndërtuar rreth tij. Të gjithë përdoruesit ishin regjistruar, ata e dinin tashmë se ku dhe si mund të merrnin informacionin e nevojshëm. Në portalin API ishin të pranishme ndërfaqet e nevojshme, na duhej vetëm një API Gateway. Në fakt, këtë ne e filluam të zhvillonim.
Ajo qĂ« ne e quajmĂ« API Gateway Ă«shtĂ« njĂ« lloj proxy. KĂ«tu sĂ«rish kishim zgjedhjen â mund tĂ« shkruanim njĂ« proxy tonin ose tĂ« zgjidhnim diçka qĂ« tashmĂ« ekzistonte. NĂ« kĂ«tĂ« rast, ne e zgjodhĂ«m rrugĂ«n e dytĂ« dhe zgjodhĂ«m kombinimin nginx+Lua. Pse? Na nevojitej njĂ« software i besueshĂ«m, i testuar, qĂ« mbĂ«shtetej pĂ«r shkallĂ«zim. Nuk donim tĂ« kontrollonim pas realizimit as korrektĂ«sinĂ« e logjikĂ«s sĂ« biznesit dhe as korrektĂ«sinĂ« e funksionimit tĂ« proxy-tĂ«.
Ădo server web ka njĂ« tubacione pĂ«r trajtimin e kĂ«rkesave. NĂ« rastin e nginx, ai duket si mĂ« poshtĂ«:
(schema nga )
Qëllimi ynë ishte të integronim në këtë tubacion në momentin kur mund të modifikonim kërkesën origjinale.
Ne duam të krijojmë një proxy transparent, për të siguruar që kërkesa funksionale të mbetet ashtu siç ka ardhur. Ne vetëm kontrollojmë aksesin në API-në përfundimtare, duke ndihmuar kërkesën të arrijë aty. Në rast se kërkesa ka qenë e papërshtatshme, gabimin duhet ta tregojë API-ja përfundimtare, jo ne. Arsyet e vetme pse mund të refuzojmë një kërkesë janë për shkak të mungesës së aksesit nga ana e klientit.
Për nginx tashmë ekziston në . Lua është një gjuhë skenari, shumë e lehtë dhe e thjeshtë për t'u mësuar. Kështu, logjikën e nevojshme e kemi realizuar me ndihmën e Lua.
Konfigurimi i nginx (analoge me aplikacionin route), ku ndodh e gjithĂ« puna, Ă«shtĂ« mjaft e qartĂ«. ĂshtĂ« e rĂ«ndĂ«sishme kĂ«tu direktiva e fundit â 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;
}
Le të shqyrtojmë çfarë ndodh në këtë konfigurim:
more_clear_input_headers â pastron vlerĂ«n e header-eve tĂ« specifikuara pas direktivĂ«s.
lua_need_request_body â rregullon nĂ«se duhet lexuar trupi origjinal i kĂ«rkesĂ«s para se tĂ« ekzekutohen direktivat rewrite/access/access_by_lua ose jo. NĂ« mĂ«nyrĂ« default, nginx nuk e lexon trupin e kĂ«rkesĂ«s sĂ« klientit, dhe nĂ«se keni nevojĂ« tĂ« keni akses nĂ« tĂ«, kjo direktivĂ« duhet tĂ« ketĂ« vlerĂ«n on.
rewrite_by_lua_file â rruga deri te skripti, ku pĂ«rshkruhet logjika pĂ«r modifikimin e kĂ«rkesĂ«s
access_by_lua_file â rruga deri te skripti, ku pĂ«rshkruhet logjika qĂ« kontrollon nĂ«se ka akses nĂ« burim.
proxy_pass â url, nĂ« tĂ« cilin do tĂ« proxizohet kĂ«rkesa.
body_filter_by_lua_file â rruga deri te skripti, ku pĂ«rshkruhet logjika pĂ«r filtrimin e kĂ«rkesĂ«s pĂ«rpara se t'i kthehet klientit.
Dhe, pĂ«rfundimisht, post_action â njĂ« direktivĂ« zyrtarisht e pa dokumentuar, me tĂ« cilĂ«n mund tĂ« kryhen edhe disa veprime tĂ« tjera pasi pĂ«rgjigjja t'i jepet klientit.
Më pas do të flasim në rend, se si ne e zgjidhëm problemin tonë.
Autorizimi/autentifikimi dhe modifikimi i kërkesës
Autorizimi
Autorizimin dhe autentifikimin e kemi ndĂ«rtuar me anĂ« tĂ« qasjes pĂ«rmes certifikatave. Ekziston njĂ« certifikatĂ« rrĂ«njĂ«sore. Ădo klient i ri i porositĂ«sit i gjenerohet njĂ« certifikatĂ« personale, me tĂ« cilĂ«n ai mund tĂ« qaset nĂ« API. Kjo certifikatĂ« konfigurohet nĂ« seksionin server tĂ« cilĂ«simeve tĂ« nginx.
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;Modifikimi
Mund të lindë një pyetje e drejtë: çfarë të bëjmë me klientin e certifikuar, nëse papritur dëshirojmë ta shkëputim atë nga sistemi? A do të rishpemë certifikatat për të gjithë klientët e tjerë?
KĂ«shtu, ne kaluam natyrshĂ«m nĂ« detyrĂ«n tjetĂ«r â modifikimin e kĂ«rkesĂ«s origjinale. KĂ«rkesa origjinale e klientit, nĂ« fakt, nuk Ă«shtĂ« valide pĂ«r sistemin pĂ«rfundimtar. NjĂ« nga detyrat Ă«shtĂ« tĂ« plotĂ«sojmĂ« nĂ« kĂ«rkesĂ« pjesĂ«t e nevojshme pĂ«r ta bĂ«rĂ« atĂ« tĂ« zakonshme. Solucioni Ă«shtĂ« se tĂ« dhĂ«nat e duhura janĂ« tĂ« ndryshme pĂ«r çdo klient. Ne e dimĂ« se klienti vjen tek ne me njĂ« certifikatĂ«, nga e cila mund tĂ« marrim njĂ« gjurmĂ« dhe tĂ« nxjerrim nga baza tĂ« dhĂ«nat e nevojshme tĂ« klientit.
Nëse në një moment ndiheni të nevojshëm të çaktivizoni klientin nga shërbimi ynë, të dhënat e tij do të humbasin nga baza dhe ai nuk do të mund të bëjë asgjë.
Puna me të dhënat e klientit
Na duhej të siguronim një disponueshmëri të lartë të zgjidhjes, sidomos për mënyrën si marrim të dhënat e klientit. Komplikimi është se burimi i parë i këtyre të dhënave është një shërbim i jashtëm, i cili nuk garanton disponueshmëri të pandërprerë dhe një shpejtësi mjaft të lartë pune.
Për këtë arsye, na duhej të siguronim një disponueshmëri të lartë të të dhënave të klientëve. Si mjet zgjodhëm , i cili na ofron:
- akses të shpejtë në të dhëna,
- mundësinë për të organizuar një klaster prej disa nodave me të dhëna të replikura në nod të ndryshëm.
Ne shkuam me strategjinë më të thjeshtë për dërgimin e të dhënave në kësh:
Puna me sistemin përfundimtar ndodh brenda seancave dhe ka një limit në numrin maksimal. Nëse klienti nuk e mbyll seancën, këtë do të duhet ta bëjmë ne.
Të dhënat për sesionin e hapur vijnë nga sistemi përfundimtar dhe fillimisht përpunohen në anën e Lua. Ne vendosëm të përdorim Hazelcast për të ruajtur këto të dhëna me një punë që është shkruar në .NET. Më pas, me një periudhë të caktuar, ne kontrollojmë të drejtën për jetën e sesioneve të hapura dhe mbyllim ato që janë skaduar.
Qasja në Hazelcast është e mundur si nga Lua ashtu edhe nga .NET
Nuk ka klientë për Lua për të punuar me Hazelcast, por Hazelcast ka një REST API, të cilin ne vendosëm ta përdorim. Për .NET ka , përmes të cilit ne planifikonim të merrnim qasje në të dhënat e Hazelcast në anën e .NET. Por gjërat nuk shkuan kështu.
Kur ruhet të dhëna përmes REST dhe nxirren përmes klientit .NET, përdoren serializues dhe deserializues të ndryshëm. Prandaj, nuk është e mundur të ruhen të dhënat përmes REST dhe të dalin përmes klientit .NET dhe anasjelltas.
NĂ«se ka interes tĂ« shqyrtohet kjo, ne do tĂ« flasim mĂ« shumĂ« pĂ«r kĂ«tĂ« problem nĂ« njĂ« artikull tĂ« veçantĂ«. Spoiler â nĂ« skemĂ«n.
Logimi dhe monitorimi
Standarti ynë korporativ për logimin nëpërmjet .NET është Serilog, të gjitha loget përfundojnë në Elasticsearch, dhe analizohemi ato nëpërmjet Kibana. Dëshironim të bënim diçka të ngjashme edhe në këtë rast. Vetëm për të punuar me Elastic në Lua, i cili u gjet, u prish gjatë kërkesës së parë. Ne përdorëm Fluentd.
â njĂ« zgjidhje open source pĂ«r tĂ« siguruar njĂ« shtresĂ« unike pĂ«r logimin e aplikacioneve. Lejon mbledhjen e logeve nga nivele tĂ« ndryshme tĂ« aplikacionit dhe mĂ« pas t'i transmetojĂ« ato nĂ« njĂ« burim tĂ« vetĂ«m.
API Gateway funksionon në K8S, prandaj vendosëm të shtojmë një kontejner me fluentd në të njëjtën pod për të shkruar logët në portin tcp të hapur të fluentd.
Ne gjithashtu hulumtuam se si do të sillet fluentd nëse nuk do të kishte lidhje me Elasticsearch. gjatë dy ditëve të vazhdueshme, në gateway vazhdonin të vijnë kërkesa, logët dërgoheshin në fluentd, por IP-ja e Elastic ishte e bllokuar. Pas rikthimit të lidhjes, fluentd kaloi të gjitha logët në Elastic.
PĂ«rfundimi
Qasja e zgjedhur për implementim na lejoi të ofronim një produkt në funksion në ambientin e prodhimit brenda vetëm 2.5 muajsh.
Nëse ndonjëherë do të angazhoheni me gjëra të tilla, rekomandojmë që së pari të kuptoni qartë se çfarë detyre po zgjidhni dhe çfarë burimesh keni tashmë. Bëni kujdes me vështirësitë e integrimit me sistemet ekzistuese të menaxhimit të API-ve.
PĂ«rpiquni tĂ« kuptoni çfarĂ« saktĂ«sisht do tĂ« zhvilloni â vetĂ«m logjikĂ«n e biznesit pĂ«r trajtimin e kĂ«rkesave, ose, siç mund tĂ« ishte rasti ynĂ«, njĂ« proxy tĂ« plotĂ«. Mos harroni, gjithçka qĂ« do tĂ« bĂ«ni vetĂ« duhet tĂ« testohet me kujdes mĂ« pas.
Burimi: habr.com
