Disa kompani, pĂ«rfshirĂ« klientin tonĂ«, zhvillojnĂ« produktin nĂ«pĂ«rmjet 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 porosi pĂ«r njĂ« produkt dhe sĂ« shpejti merrni numrin e ndjekjes sĂ« parcelĂ«s. NjĂ« shembull tjetĂ«r â sĂ« bashku me biletĂ«n e avionit, ju blini sigurimin ose biletĂ«n pĂ«r aeroport.
Për këtë përdoret një API, i cili duhet t'i jepet partnerëve përmes API Gateway. Këtë detyrë ne e zgjidhëm. Në këtë artikull do të tregojmë detajet.
Dhe: ekosistemi dhe portali API me një ndërfaqe, ku përdoruesit janë të regjistruar, marrin informacion dhe të tjera. Na nevojitet të krijojmë një API Gateway të përshtatshëm dhe të besueshëm. Në proces, na nevojitet të sigurojmë
- regjistrimin,
- kontrollin e lidhjes me API,
- monitorimin e mënyrës se si përdoruesit përdorin sistemin përfundimtar,
- përllogaritjen e treguesve të biznesit.
Në artikull do të flasim për përvojën tonë në krijimin e API Gateway, gjatë së cilës ne zgjidhëm detyrat e mëposhtme:
- autorizimi i përdoruesit,
- identifikimi i përdoruesit,
- modifikimi i kërkesës fillestare,
- proksimi i kërkesës,
- pasprocesimi i përgjigjes.
Ka dy lloje të menaxhimit të API:
1. Standardi, i cili funksionon në këtë mënyrë. Para se të lidhet, përdoruesi provon mundësitë, pastaj paguan dhe e integrojnë në faqen e tij. Shumica e herëve, kjo përdoret në bizneset e vogla dhe të mesme.
2. Menaxhimi i API për B2B të madh, ku kompania fillimisht merr një vendim biznesi për t'u lidhur, bëhet partner me një kontratë obligative, dhe më pas lidhet me API. Vetëm pasi të zgjidhin të gjitha formalitetet, kompania merr akses provë, 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 përfundimtarë të këtij gateway-i për API janë partnerët e klientit tonë. Për çdo një prej tyre, ne tashmë kemi kontratat e nevojshme. Na nevojitet vetëm të zgjerrojmë funksionalitetin, duke shënuar aksesin e dhënë në gateway. Për rrjedhojë, nevojitet një proces i kontrolluar për lidhjen dhe menaxhimin.
Sigurisht, mund të ishte e mundur të merrnim ndonjë zgjidhje të gatshme për zgjidhjen e problemit të menaxhimit të API dhe krijimin e API Gateway në veçanti. Për shembull, një e tillë mund të ishte. Nuk s'na përshtati, sepse në rastin tonë ne kishim tashmë një portal API dhe një ekosistem të madh të ndërtuar rreth tij. Të gjithë përdoruesit tashmë ishin regjistruar, ata e dinin se ku dhe si mund të merrnin informacionin që u nevojitej. Në portalin API tashmë ekzistonin ndërfaqet e nevojshme, ne vetëm na nevojitej API Gateway. Në fakt, për këtë u angazhuam në zhvillim.
Ajo qĂ« ne e quajmĂ« API Gateway â Ă«shtĂ« njĂ« lloj proksi. Kemi pasur pĂ«rsĂ«ri njĂ« zgjedhje â mund tĂ« shkruajmĂ« proksin tonĂ« ose tĂ« zgjedhim diçka tĂ« gatshme. NĂ« kĂ«tĂ« rast, ne zgjodhĂ«m rrugĂ«n e dytĂ« dhe zgjodhĂ«m kombinimin nginx+Lua. Pse? Na nevojitej njĂ« softuer i besueshĂ«m, tĂ« testuar dhe qĂ« mbĂ«shtet shkallĂ«zimin. Nuk donim qĂ« pas pĂ«rfundimit tĂ« implementimit tĂ« verifikonim si saktĂ«sinĂ« e logjikĂ«s biznesore ashtu edhe funksionimin e proksit.
Ădo server web ka njĂ« pipeline tĂ« pĂ«rpunimit tĂ« kĂ«rkesĂ«s. NĂ« rastin e nginx, ai duket si mĂ« poshtĂ«:
(skema nga )
Qëllimi ynë ishte të ishim të integruar në këtë pipeline në momentin kur mund të modifikojmë kërkesën origjinale.
Ne duam të krijojmë një proksi transparent, që kërkesa të mbetet funksionalisht ashtu siç erdhi. Ne vetëm kontrollojmë qasjen në API-në përfundimtare, ndihmojmë kërkesën të arrijë atje. Në rastin kur kërkesa ishte e papërshtatshme, gabimin duhet ta tregojë API përfundimtar, por jo ne. Arsyet e vetme përse mund të refuzojmë një kërkesë janë mungesa e qasjes për klientin.
PĂ«r nginx tashmĂ« ekziston nĂ« . Lua â Ă«shtĂ« njĂ« gjuhĂ« skriptuese, Ă«shtĂ« shumĂ« e lehtĂ« dhe e thjeshtĂ« pĂ«r t'u mĂ«suar. NĂ« kĂ«tĂ« mĂ«nyrĂ«, logjikĂ«n e nevojshme e realizuam me ndihmĂ«n e Lua.
Konfigurimi i nginx (analogjia e aplikacionit route), ku zhvillohet gjithĂ« puna, Ă«shtĂ« mjaft e kuptueshme. E veçanta kĂ«tu Ă«shtĂ« 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;
}
Shikojmë se çfarë ndodh në këtë konfigurim:
more_clear_input_headers â pastron vlerĂ«n e kokave tĂ« specifikuara pas direktivĂ«s.
lua_need_request_body â rregullon nĂ«se duhet tĂ« lexohet trupi origjinal i kĂ«rkesĂ«s para se tĂ« ekzekutohen direktivat rewrite/access/access_by_lua ose jo. PĂ«r default, nginx nuk e lexon trupin e kĂ«rkesĂ«s sĂ« klientit, dhe nĂ«se ju nevojitet qasja nĂ« tĂ«, kjo direktivĂ« duhet tĂ« jetĂ« on.
rewrite_by_lua_file â rruga pĂ«r skriptin qĂ« pĂ«rshkruan logjikĂ«n pĂ«r modifikimin e kĂ«rkesĂ«s
access_by_lua_file â rruga pĂ«r skriptin qĂ« pĂ«rshkruan logjikĂ«n, e cila kontrollon pranueshmĂ«rinĂ« pĂ«r burimin.
proxy_pass â url, nga i cili do tĂ« proksohet kĂ«rkesa.
body_filter_by_lua_file â rruga pĂ«r skriptin qĂ« pĂ«rshkruan logjikĂ«n pĂ«r filtrimin e kĂ«rkesĂ«s para se t'i kthehet klientit.
Dhe, nĂ« fund, post_action â njĂ« direktivĂ« zyrtare e pa dokumentuar, me ndihmĂ«n e sĂ« cilĂ«s mund tĂ« kryhen veprime tĂ« tjera pas dorĂ«zimit tĂ« pĂ«rgjigjes pĂ«r klientin.
Më pas do të flasim hap pas hapi, si e zgjidhëm problemin tonë.
Autorizimi/identifikimi dhe modifikimi i kërkesës
Autorizimi
Ne krijuam autorizimin dhe identifikimin me ndihmĂ«n e qasjeve pĂ«rmes certifikatĂ«s. Ka njĂ« certifikatĂ« rrĂ«njĂ«sore. Ădo klient tĂ« ri i porositĂ«sit i gjenerohet njĂ« certifikatĂ« personale, me tĂ« cilĂ«n ai mund tĂ« ketĂ« qasje 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
Një pyetje e drejtë mund të jetë: çfarë të bëjmë me klientin e certifikuar, nëse papritur duam ta çaktivizojmë atë nga sistemi? A duhet të rishqetësojmë certifikatën për të gjithë klientët e tjerë?
KĂ«shtu kaluam nĂ« detyrĂ«n tjetĂ«r â modifikimi i kĂ«rkesĂ«s origjinale. KĂ«rkesa origjinale e klientit, nĂ« pĂ«rgjithĂ«si, nuk Ă«shtĂ« e vlefshme pĂ«r sistemin pĂ«rfundimtar. NjĂ« nga detyrat Ă«shtĂ« tĂ« shtoni nĂ« kĂ«rkesĂ« pjesĂ«t e mungueshme pĂ«r ta bĂ«rĂ« atĂ« tĂ« vlefshme. ĂĂ«shtja Ă«shtĂ« qĂ« tĂ« dhĂ«nat e munguara janĂ« tĂ« ndryshme pĂ«r çdo klient. Ne dimĂ« qĂ« klienti vjen te ne me njĂ« certifikatĂ«, me tĂ« cilĂ«n mund tĂ« marrim njĂ« gjurmĂ« dhe tĂ« nxjerrim nga baza tĂ« dhĂ«nat e nevojshme tĂ« klientit.
Nëse në ndonjë moment do të jetë e nevojshme të çaktivizohet klienti nga shërbimi ynë, të dhënat e tij do të fshihen nga baza dhe ai nuk do të mund të bëjë asgjë.
Puna me të dhënat e klientit
Na nevojitej të sigurojmë një disponueshmëri të lartë të zgjidhjes, veçanërisht për mënyrën se si marrim të dhënat e klientit. Vështirësia qëndron në faktin se burimi fillestar i këtyre të dhënave është një shërbim i jashtëm, i cili nuk garanton një funksionim të pandërprerë dhe një shpejtësi të mjaftueshme.
Prandaj na duhej të sigurojmë një disponueshmëri të lartë të të dhënave të klientëve. Si mjet zgjodhëm , i cili na ofron:
- qasje i shpejtë në të dhëna,
- mundësia për të organizuar një klaster nga disa node me të dhëna të replikueshme në node të ndryshme.
Ne zgjodhëm strategjinë më të thjeshtë për dërgimin e të dhënave në cache:
Bashkëpunimi me sistemin përfundimtar ndodh brenda sesioneve dhe ka një limit për numrin maksimal. Nëse klienti nuk e mbyll sesionin, këtë do ta bëjmë ne.
Të dhënat për sesionin e hapur vinë nga sistemi përfundimtar dhe fillimisht përpunohen anës Lua. Ne vendosëm të përdorim Hazelcast për të ruajtur këto të dhëna duke përdorur një job të shkruar në .NET. Më pas, me një periudhë të caktuar kontrollojmë të drejtën për jetë të sesioneve të hapura dhe mbyllim ato që janë skaduar.
Qasja në Hazelcast 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 e përdorëm. Për .NET gjithashtu ka , përmes të cilit planifikuam të merrnim qasje në të dhënat e Hazelcast në anën e .NET. Por nuk doli ashtu.
Kur ruajmë të dhënat përmes REST dhe nxjerrim përmes klientit .NET, përdoren serializues të ndryshëm. Prandaj, nuk është e mundur të vendosësh të dhëna përmes REST dhe të nxjerrësh përmes klientit .NET dhe anasjelltas.
NĂ«se do tĂ« ketĂ« interes, do tĂ« flasim mĂ« shumĂ« mbi kĂ«tĂ« problem nĂ« njĂ« artikull tĂ« veçantĂ«. SpoilerânĂ« diagram.
Logimi dhe monitorimi
Standarti ynë korporativ për logimin përmes .NET është Serilog, të gjitha loget përfundojnë në Elasticsearch, analizën e bëjmë përmes Kibanës. Disa gjëra të ngjashme dëshironim të bënim edhe në këtë rast. E vetmja për të punuar me Elastic në Lua, që u gjet, u prish në kërkesën e parë. Kështu përdorëm Fluentd.
â njĂ« zgjidhje open source pĂ«r tĂ« ofruar njĂ« shtresĂ« tĂ« integruar logimi tĂ« aplikacionit. Lejon mbledhjen e logeve nga shtresa tĂ« ndryshme tĂ« aplikacionit dhe mĂ« pas t'i translante ato nĂ« njĂ« burim tĂ« vetĂ«m.
API Gateway punon në K8S, prandaj vendosëm të shtonim një kontejner me fluentd në të njëjtin pod, për të shkruar loget në portin tcp të hapur të fluentd.
Ne gjithashtu hulumtuam se si do të veprojë fluentd nëse nuk do të kishte lidhje me Elasticsearch. Gjatë dy ditëve, kërkesat vazhdimisht përshkuan portin, loget dërgoheshin në fluentd, por IP Elastic ishte bllokuar nga fluentd. Pas rikthimit të lidhjes, fluentd transferoi gjithsej loget në Elastic.
PĂ«rfundim
Qasja e zgjedhur për realizimin na lejoi të dorëzojmë një produkt në funksionim në mjedisin e prodhimit brenda vetëm 2.5 muajve.
Nëse ndonjëherë do t'ju ndodhë të merret me këto gjëra, ne rekomandojmë që në radhë të parë të kuptoni qartë se çfarë problemi po zgjidhni dhe çfarë burimesh keni tashmë. Jini të kujdesshëm ndaj vështirësive të integrimit me sistemet ekzistuese të menaxhimit të API-ve.
Kuptoni pĂ«r vete se çfarĂ« saktĂ«sisht po planifikoni tĂ« zhvilloni â vetĂ«m logjikĂ«n e biznesit pĂ«r pĂ«rpunimin e kĂ«rkesave apo, siç mund tĂ« kishte ndodhur nĂ« rastin tonĂ«, njĂ« proxy tĂ« plotĂ«. Mos harroni se gjithçka qĂ« bĂ«ni vetĂ« duhet tĂ« testohet me kujdes mĂ« pas.
Burimi: habr.com
