Sababaraha pausahaan, kaasup konsumén urang, ngamekarkeun produk ngaliwatan jaringan afiliasi. Salaku conto, toko online ageung dihijikeun sareng jasa pangiriman - anjeun mesen produk sareng enggal nampi nomer tracking parsél. Conto sanésna nyaéta anjeun mésér asuransi atanapi tikét Aeroexpress sareng tikét udara.
Jang ngalampahkeun ieu, hiji API dipaké, nu kudu dikaluarkeun pikeun mitra ngaliwatan Gateway API. Urang direngsekeun masalah ieu. Dina artikel ieu kami bakal ngabejaan Anjeun detil.
Dibikeun: ékosistem sareng portal API kalayan antarmuka dimana pangguna ngadaptar, nampi inpormasi, jsb. Urang kudu nyieun gateway API merenah tur dipercaya. Dina prosés urang diperlukeun pikeun mastikeun
- pendaptaran,
- kontrol sambungan API,
- mantau kumaha pamaké ngagunakeun sistem tungtung,
- akuntansi tina indikator bisnis.
Dina artikel ieu kami bakal ngobrol ngeunaan pangalaman urang dina nyieun API Gateway, salila urang ngajawab masalah ieu:
- auténtikasi pamaké,
- otorisasi pamaké,
- modifikasi tina pamundut aslina,
- proxying pamundut,
- pos-processing tina respon.
Aya dua jinis manajemén API:
1. Standar, anu jalanna kieu. Sateuacan nyambungkeun, pangguna nguji kamampuan, teras mayar sareng nyelapkeun kana halaman wéb na. Seringna dianggo dina usaha leutik sareng sedeng.
2. Manajemén API B2B ageung, nalika perusahaan mimiti nyandak kaputusan bisnis pikeun nyambungkeun, janten mitra perusahaan sareng kawajiban kontrak, teras nyambung ka API. Sareng saatos sadaya formalitas parantos netep, perusahaan nampi aksés tés, ngajalanan tés sareng janten produksi. Tapi ieu teu mungkin tanpa kaputusan manajemén on sambungan.
Solusi urang
Dina bagian ieu urang bakal ngobrol ngeunaan nyieun hiji gateway API.
Pamaké ahir gateway API anu didamel mangrupikeun mitra palanggan kami. Pikeun masing-masingna, kami parantos ngagaduhan kontrak anu diperyogikeun disimpen. Urang ngan bakal perlu manjangkeun pungsionalitasna ku nyirian aksés dibikeun ka gateway nu. Sasuai, sambungan anu dikontrol sareng prosés manajemén diperyogikeun.
Tangtu, ieu mungkin nyandak sababaraha solusi siap-dijieun pikeun ngajawab masalah Manajemén API tur nyieun hiji gateway API hususna. Contona, ieu bisa jadi. Éta henteu cocog sareng kami sabab dina hal urang kami parantos ngagaduhan portal API sareng ékosistem anu ageung diwangun di sabudeureun éta. Sadaya pangguna parantos didaptarkeun, aranjeunna parantos ngartos dimana sareng kumaha aranjeunna tiasa nampi inpormasi anu diperyogikeun. Antarbeungeut anu diperyogikeun parantos aya dina portal API; kami ngan ukur peryogi Gateway API. Sabenerna, urang mimiti ngembangkeun éta.
Anu kami sebut gateway API mangrupikeun jinis proxy. Di dieu deui kami ngagaduhan pilihan - anjeun tiasa nyerat proxy anjeun nyalira, atanapi anjeun tiasa milih anu siap-dijieun. Dina hal ieu, urang nyandak jalur kadua sareng milih kombinasi nginx + Lua. Naha? Kami peryogi parangkat lunak anu tiasa dipercaya, diuji anu tiasa skala. Kami henteu hoyong pariksa leresna logika bisnis sareng operasi anu leres tina proxy saatos palaksanaan.
Sakur pangladén wéb ngagaduhan saluran pamrosésan pamundut. Dina kasus nginx sigana kieu:
(diagram ti )
Tujuanana kami nyaéta ngalebetkeun diri kana pipa ieu dina titik dimana urang tiasa ngarobih pamundut asli.
Kami hoyong ngadamel proxy transparan supados sacara fungsional pamundut tetep sami sareng anu sumping. Urang ukur ngadalikeun aksés ka API final sarta mantuan pamundut meunang ka dinya. Upami pamundut éta lepat, API final kedah nunjukkeun kasalahan, tapi sanés kami. Hiji-hijina alesan urang bisa mungkir pamundut hiji sabab klien nu teu boga aksés.
Geus aya pikeun nginx dina . Lua mangrupikeun basa skrip, hampang pisan sareng gampang diajar. Ku kituna, urang nerapkeun logika perlu ngagunakeun Lua.
Konfigurasi nginx (analog sareng aplikasi rute), dimana sadaya padamelan parantos réngsé, cukup jelas. The diréktif panungtungan nyaéta noteworthy dieu - 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;
}
Hayu urang tingali naon anu lumangsung dina konfigurasi ieu:
more_clear_input_headers - mupus nilai tina headers dieusian sanggeus diréktif.
lua_need_request_body - ngadalikeun naha badan pamundut aslina kudu dibaca saméméh executing rewrite / aksés / access_by_lua directives atanapi henteu. Sacara standar, nginx henteu maca badan pamundut klien, sareng upami anjeun kedah ngaksés éta, maka diréktif ieu kedah disetel ka on.
rewrite_by_lua_file - jalur ka naskah, nu ngajelaskeun logika pikeun ngaropéa pamundut nu
access_by_lua_file - jalur ka naskah, nu ngajelaskeun logika nu cek pikeun aksés ka sumberdaya nu.
proxy_pass - url dimana pamundut bakal diproksi.
body_filter_by_lua_file - jalur ka naskah, nu ngajelaskeun logika pikeun nyaring pamundut saméméh balik deui ka klien nu.
Sarta pamustunganana post_action - hiji diréktif resmi undocumented nu bisa dipaké pikeun ngalakukeun tindakan séjén sanggeus respon dibikeun ka klien.
Salajengna, kami bakal ngabejaan ka maneh dina urutan kumaha urang ngajawab masalah urang.
Otorisasina / auténtikasi sareng modifikasi pamundut
mieun kuwasa
Kami ngawangun otorisasi sareng auténtikasi nganggo aksés sertipikat. Aya sertipikat akar. Unggal klien anyar konsumén dihasilkeun ku sertipikat pribadi-Na, jeung nu bisa ngakses API. Sertipikat ieu dikonpigurasi dina bagian server tina setélan 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;modipikasi
Patarosan anu adil tiasa timbul: naon anu kudu dilakukeun ku klien anu disertipikasi upami urang ujug-ujug hoyong pegatkeun sambunganna tina sistem? Ulah reissue sertipikat pikeun sakabéh klien séjén.
Janten urang lancar ngadeukeutan tugas salajengna - ngarobih pamundut asli. Paménta asli klien, sacara umum, henteu sah pikeun sistem tungtung. Salah sahiji pancén nyaéta pikeun nambihan bagian anu leungit kana pamundut pikeun ngajantenkeun éta sah. Intina nyaéta yén data anu leungit béda pikeun unggal klien. Urang terang yén klien datang ka kami kalayan sertipikat ti mana urang tiasa nyandak sidik sareng narik data klien anu diperyogikeun tina pangkalan data.
Lamun di sawatara titik anjeun kudu megatkeun sambungan klien tina layanan kami, data na bakal ngaleungit tina database sarta anjeunna moal bisa ngalakukeun nanaon.
Gawe sareng data klien
Urang diperlukeun pikeun mastikeun kasadiaan tinggi sahiji solusi, utamana kumaha urang ménta data customer. Kasusahna nyaéta yén sumber utama data ieu mangrupikeun jasa pihak katilu, anu henteu ngajamin kacepetan anu teu diganggu sareng cekap.
Kituna, urang diperlukeun pikeun mastikeun kasadiaan tinggi data customer. Urang milih salaku alat anu masihan urang:
- aksés gancang kana data,
- kamampuhan pikeun ngatur gugusan sababaraha titik kalawan data replicated on titik béda.
Kami nuturkeun strategi pangbasajanna pikeun ngirim data ka cache:
Gawe sareng sistem final lumangsung dina sesi sarta aya wates dina jumlah maksimum. Upami klien henteu nutup sési, urang kedah ngalakukeun ieu.
Data sési kabuka asalna tina sistem tungtung sareng mimitina diolah di sisi Lua. Urang mutuskeun ngagunakeun Hazelcast pikeun nyimpen data ieu kalawan pakasaban ditulis dina .NET. Teras, kalayan sababaraha frékuénsi, urang pariksa hak hirup tina sesi kabuka sareng nutup anu rusak.
Aksés Hazelcast ti Lua sareng .NET
Henteu aya klien Lua pikeun damel sareng Hazelcast, tapi Hazelcast gaduh REST API, anu kami mutuskeun pikeun dianggo. Pikeun .NET aya , ngaliwatan nu urang rencanana ngakses data Hazelcast dina sisi .NET. Tapi teu aya.
Nalika nyimpen data via REST sarta retrieving eta via klien .NET, serializers béda jeung deserializers dipaké. Ku alatan éta, teu mungkin pikeun nyimpen data ngaliwatan REST tur meunangkeun deui ngaliwatan klien .NET sarta sabalikna.
Upami aya anu kabetot, kami bakal nyarios langkung seueur ngeunaan masalah ieu dina tulisan anu misah. Spoiler - dina diagram.
Logging jeung monitoring
Standar perusahaan kami pikeun logging via .NET nyaéta Serilog, sadaya log pamustunganana ditungtungan dina Elasticsearch, sareng kami nganalisisna ngalangkungan Kibana. Abdi hoyong ngalakukeun hal anu sami dina hal ieu. Hiji-hijina pikeun gawé bareng elastis on Lua, nu kapanggih, peupeus di pisan munggaran merlukeun. Sareng kami nganggo Fluentd.
- solusi open source pikeun nyadiakeun hiji lapisan logging aplikasi. Ngidinan anjeun pikeun ngumpulkeun log tina lapisan aplikasi anu béda, teras disiarkeun kana hiji sumber.
API gateway dijalankeun dina K8S, sangkan mutuskeun pikeun nambahkeun wadahna kalawan fluentd ka pod sarua guna nulis log kana port tcp kabuka aya tina fluentd.
Urang ogé neuleuman kumaha fluentd bakal kalakuanana lamun teu boga sambungan kana Elasticsearch. Pikeun dua poé, requests anu terus dikirim ka gateway nu, log dikirim ka fluentd, tapi fluentd urang IP elastis dilarang. Saatos sambungan dibalikeun, fluentd sampurna ditransfer pancen sadayana log ka Elastis.
kacindekan
Pendekatan anu dipilih pikeun palaksanaan ngamungkinkeun urang pikeun nganteurkeun produk anu leres-leres damel kana lingkungan tempur dina ngan 2.5 bulan.
Upami anjeun kantos mendakan diri ngalakukeun hal sapertos kieu, kami mamatahan anjeun ngartos heula naon masalah anu anjeun rengsekeun sareng sumber daya naon anu anjeun gaduh. Waspada kana kompleksitas ngahijikeun sareng sistem manajemen API anu tos aya.
Ngartos pikeun diri naon anu anjeun badé kembangkeun - ngan ukur logika bisnis pikeun ngolah pamundut atanapi, sapertos anu tiasa janten kasus urang, sadayana proxy. Tong hilap yén sadaya anu anjeun laksanakeun nyalira kedah diuji sacara saksama saatosna.
sumber: www.habr.com
