Sawetara perusahaan, kalebu pelanggan, ngembangake produk kasebut liwat jaringan mitra. Contone, toko online gedhe digabungake karo layanan pangiriman - sampeyan supaya produk lan enggal nampa nomer nelusuri paket. Conto liyane yaiku nalika sampeyan tuku asuransi utawa tiket Aeroexpress bebarengan karo tiket pesawat sampeyan.
Kanggo iki, siji API digunakake, sing kudu ditanggepi kanggo mitra liwat Gateway API. Kita wis ngrampungake masalah iki. Ing artikel iki kita bakal pitutur marang kowe rincian.
Diwenehi: ekosistem lan portal API kanthi antarmuka pangguna pangguna, nampa informasi, lsp. Kita kudu nggawe Gateway API sing trep lan dipercaya. Ing proses, kita kudu nyedhiyani
- pendaftaran,
- kontrol sambungan API,
- ngawasi cara pangguna nggunakake sistem pungkasan,
- akuntansi kanggo indikator bisnis.
Ing artikel kasebut, kita bakal ngomong babagan pengalaman nggawe API Gateway, nalika kita ngrampungake tugas ing ngisor iki:
- otentikasi pangguna,
- wewenang pangguna,
- modifikasi saka panjalukan asli,
- njaluk proxy,
- respon postprocessing.
Ana rong jinis manajemen API:
1. Standar, sing dianggo kaya ing ngisor iki. Sadurunge nyambungake, pangguna nguji fitur kasebut, banjur mbayar lan nyelehake ing situs kasebut. Paling asring digunakake ing bisnis cilik lan menengah.
2. Manajemen API B2B gedhe, nalika perusahaan pisanan nggawe keputusan bisnis kanggo nyambungake, dadi mitra perusahaan kanthi kewajiban kontrak, banjur nyambung menyang API. Lan sawise kabeh formalitas dirampungake, perusahaan entuk akses tes, lulus tes lan mlebu produksi. Nanging iki ora bisa ditindakake tanpa keputusan manajemen kanggo nyambung.
Solusi kita
Ing bagean iki, kita bakal ngomong babagan nggawe Gateway API.
Pangguna pungkasan saka gateway API sing digawe minangka mitra pelanggan. Kita wis duwe kontrak sing dibutuhake kanggo saben wong. Kita mung kudu nggedhekake fungsi kasebut kanthi menehi tandha akses sing diwenehake menyang gateway. Mulane, sambungan sing dikontrol lan proses manajemen dibutuhake.
Mesthi, iku bisa kanggo njupuk sawetara solusi siap kanggo mecahaken masalah Manajemen API lan nggawe API Gateway ing tartamtu. Contone, iki bisa uga. Ora cocog karo kita, amarga ing kasus kita, kita wis duwe portal API lan ekosistem gedhe sing dibangun ing saubengé. Kabeh pangguna wis ndhaptar, dheweke wis ngerti ngendi lan kepiye entuk informasi sing dibutuhake. Antarmuka sing dibutuhake wis ana ing portal API, kita mung butuh API Gateway. Bener, kita melu pembangunan.
Apa sing diarani API Gateway minangka jinis proxy. Ing kene maneh duwe pilihan - sampeyan bisa nulis proxy dhewe, utawa sampeyan bisa milih sing wis siap. Ing kasus iki, kita lunga kanthi cara liya lan milih bundle nginx + Lua. Kenging punapa? Kita butuh piranti lunak sing dipercaya lan diuji sing ndhukung skala. Sawise implementasine, kita ora pengin mriksa kabeneran logika bisnis lan kebeneran proxy.
Saben server web duwe pipa pangolahan panjaluk. Ing kasus nginx, katon kaya iki:
(diagram saka )
Tujuane yaiku pas karo pipa iki ing titik sing bisa ngowahi panjaluk asli.
Kita pengin nggawe proxy transparan supaya panjalukan tetep fungsional kaya sing teka. Kita mung ngontrol akses menyang API pungkasan, nulungi panyuwunan kasebut. Yen panjaluk kasebut ora bener, API pungkasan kudu nuduhake kesalahan kasebut, nanging dudu kita. Alesan mung kita bisa nolak panjalukan amarga klien ora duwe akses.
Wis ana kanggo nginx ing . Lua minangka basa skrip, entheng banget lan gampang disinaoni. Mangkono, kita ngetrapake logika sing dibutuhake nggunakake Lua.
Konfigurasi nginx (analogi karo rute aplikasi), ing ngendi kabeh karya wis rampung, cukup dingerteni. Wigati ing kene yaiku arahan pungkasan - 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;
}
Coba apa sing kedadeyan ing konfigurasi iki:
more_clear_input_headers - mbusak nilai header sing ditemtokake sawise arahan kasebut.
lua_need_request_body - ngontrol apa awak panjalukan asli kudu diwaca sadurunge nglakokake nulis ulang / akses / akses_by_lua arahan utawa ora. Kanthi gawan, nginx ora maca awak panjalukan klien, lan yen sampeyan kudu ngakses, banjur arahan iki kudu disetel.
rewrite_by_lua_file - path kanggo script, kang njlèntrèhaké logika kanggo ngowahi request
akses_by_lua_file - path kanggo script, kang njlèntrèhaké logika sing mriksa kanggo akses kanggo sumber.
proxy_pass - url sing panjaluk bakal diproksi.
body_filter_by_lua_file — path kanggo script, kang njlèntrèhaké logika kanggo nyaring request sadurunge bali menyang klien.
Lan, pungkasanipun, post_action - arahan sing ora resmi resmi sing sampeyan bisa nindakake sawetara tumindak liyane sawise respon diwenehake marang klien.
Sabanjure, kita bakal nerangake carane ngatasi masalah kita.
Wewenang / otentikasi lan modifikasi panyuwunan
Wewenang
Kita mbangun wewenang lan otentikasi nggunakake akses sertifikat. Ana sertifikat root. Saben klien anyar pelanggan digawe sertifikat pribadhi, sing bisa ngakses API. Sertifikat iki dikonfigurasi ing bagean server setelan 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;Modifikasi
Pitakonan sing adil bisa uga muncul: apa sing kudu ditindakake karo klien sing disertifikasi yen tiba-tiba pengin medhot saka sistem? Aja nerbitake maneh sertifikat kanggo kabeh klien liyane.
Dadi kanthi lancar nyedhaki tugas sabanjure - ngowahi panjaluk asli. Panjaluk awal saka klien, umume, ora sah kanggo sistem pungkasan. Salah sawijining tugas yaiku nambahake bagean sing ilang menyang panyuwunan supaya sah. Intine yaiku data sing ilang beda kanggo saben klien. Kita ngerti manawa klien teka karo sertifikat sing bisa njupuk sidik jari lan ngekstrak data klien sing dibutuhake saka database.
Yen ing sawetara titik sampeyan kudu medhot klien saka layanan kita, data bakal ilang saka database lan ora bakal bisa nindakake apa-apa.
Nggarap data pelanggan
Kita kudu nggawe solusi kasebut kasedhiya banget, utamane carane entuk data pelanggan. Kangelan iku sumber utami data iki layanan pihak katelu sing ora njamin uninterrupted lan kacepetan cukup dhuwur.
Mulane, kita kudu njamin kasedhiyan data pelanggan sing dhuwur. Minangka alat, kita wis milih sing menehi kita:
- akses cepet menyang data
- kemampuan kanggo ngatur kluster saka sawetara kelenjar karo data replicated ing macem-macem kelenjar.
Kita nganggo strategi paling gampang kanggo ngirim data menyang cache:
Bisa karo sistem pungkasan njupuk Panggonan ing sesi lan ana watesan ing jumlah maksimum. Yen klien durung nutup sesi kasebut, kita kudu nindakake iki.
Data sesi mbukak asalé saka sistem pungkasan lan wiwitane diproses ing sisih Lua. Kita mutusaké kanggo nggunakake Hazelcast kanggo nyimpen data iki karo proyek .NET. Banjur, ing sawetara interval, kita mriksa hak urip sesi mbukak lan nutup sing bosok.
Ngakses Hazelcast saka Lua lan .NET
Ora ana klien Lua kanggo nggarap Hazelcast, nanging Hazelcast duwe API REST, sing kita mutusake kanggo nggunakake. Kanggo .NET ana , liwat kang kita ngrancang kanggo ngakses data Hazelcast ing sisih .NET. Nanging ora ana.
Nalika nyimpen data liwat REST lan njupuk data liwat klien .NET, serializers beda lan deserializers digunakake. Mulane, iku mokal kanggo sijine data liwat REST, nanging njaluk liwat klien .NET lan kosok balene.
Yen ana sing kasengsem, kita bakal ngandhani luwih lengkap babagan masalah iki ing artikel sing kapisah. Spoiler - ing skema.
Logging lan ngawasi
Standar perusahaan kita kanggo mlebu liwat .NET yaiku Serilog, kabeh log rampung ing Elasticsearch, lan kita nganalisa liwat Kibana. Aku pengin nindakake sing padha ing kasus iki. mung siji kanggo bisa karo Elastis ing Lua, kang ketemu, nyuwil ing mbutuhake banget pisanan. Lan kita nggunakake Fluentd.
- solusi open source kanggo nyediakake lapisan siji saka logging aplikasi. Ngidini sampeyan ngumpulake log saka macem-macem lapisan aplikasi, banjur nyebarake menyang sumber siji.
API Gateway dianggo ing K8S, supaya kita mutusaké kanggo nambah wadhah karo fluentd ing pody padha kanggo nulis log menyang ana mbukak tcp port fluentd.
Kita uga njelajah carane fluentd bakal nindakake yen ora ana sambungan kanggo Elasticsearch. Kanggo rong dina, panjalukan terus dikirim menyang gateway, log dikirim menyang fluentd, nanging fluentd dilarang saka IP Elastic. Sawise sambungan dibalèkaké, fluentd sampurna overtook pancen kabeh log ing Elastis.
kesimpulan
Pendekatan sing dipilih kanggo implementasine ngidini kita ngirim produk sing bisa digunakake ing lingkungan pertempuran mung sajrone 2.5 wulan.
Yen sampeyan nate nindakake perkara kasebut, mula disaranake supaya ngerti kanthi jelas apa masalah sing sampeyan rampungake lan sumber daya apa sing wis ana. Waca kerumitan integrasi karo sistem manajemen API sing ana.
Ngerti dhewe apa persis sing bakal dikembangake - mung logika bisnis kanggo ngolah panjalukan, utawa, kaya ing kasus kita, kabeh proxy. Aja lali yen kabeh sing sampeyan lakoni dhewe kudu diuji kanthi lengkap.
Source: www.habr.com
