Daži uzņēmumi, tostarp mūsu klienti, izstrādā produktu, izmantojot partneru tīklu. Piemēram, lielie interneta veikali ir integrēti piegādes servisā – pasūtāt preci un drīz vien saņemat pakas izsekošanas numuru. Vēl viens piemērs ir, kad kopā ar aviobiļeti iegādājaties apdrošināšanu vai Aeroexpress biļeti.
Šim nolūkam tiek izmantota viena API, kas ir jāizsniedz partneriem caur API vārteju. Mēs esam atrisinājuši šo problēmu. Šajā rakstā mēs jums pastāstīsim sīkāk.
Dota: ekosistēma un API portāls ar interfeisu, kur lietotāji tiek reģistrēti, saņem informāciju utt. Mums ir jāizveido ērta un uzticama API vārteja. Šajā procesā mums vajadzēja nodrošināt
- reģistrācija,
- API savienojuma kontrole,
- uzraudzīt, kā lietotāji izmanto gala sistēmu,
- uzņēmējdarbības rādītāju uzskaite.
Rakstā mēs runāsim par mūsu pieredzi API vārtejas izveidē, kuras laikā mēs atrisinājām šādus uzdevumus:
- lietotāja autentifikācija,
- lietotāja autorizācija,
- sākotnējā pieprasījuma izmaiņas,
- pieprasīt starpniekserveri,
- atbildes pēcapstrāde.
Ir divu veidu API pārvaldība:
1. Standarts, kas darbojas šādi. Pirms savienojuma izveides lietotājs pārbauda funkcijas, pēc tam maksā un ievieto savā vietnē. Visbiežāk tos izmanto mazos un vidējos uzņēmumos.
2. Liela B2B API pārvaldība, kad uzņēmums pirmo reizi pieņem biznesa lēmumu izveidot savienojumu, kļūst par uzņēmuma partneri ar līgumsaistībām un pēc tam pievienojas API. Un pēc visu formalitāšu nokārtošanas uzņēmums saņem testa piekļuvi, nokārto testēšanu un sāk ražošanu. Bet tas nav iespējams bez vadības lēmuma par savienojumu.
Mūsu risinājums
Šajā daļā mēs runāsim par API vārtejas izveidi.
Izveidotās API vārtejas galalietotāji ir mūsu klienta partneri. Mums jau katram ir nepieciešamie līgumi. Mums vajadzēs tikai paplašināt funkcionalitāti, atzīmējot piešķirto piekļuvi vārtejai. Attiecīgi ir nepieciešams kontrolēts savienojuma un pārvaldības process.
Protams, bija iespējams paņemt kādu gatavu risinājumu API pārvaldības problēmas risināšanai un jo īpaši API vārtejas izveidei. Piemēram, tas varētu būt. Tas mums nederēja, jo mūsu gadījumā mums jau bija API portāls un ap to izveidota milzīga ekosistēma. Visi lietotāji jau ir reģistrēti, viņi jau saprata, kur un kā var iegūt nepieciešamo informāciju. Nepieciešamās saskarnes jau bija API portālā, mums bija nepieciešama tikai API vārteja. Patiesībā mēs esam iesaistīti tās attīstībā.
Tas, ko mēs saucam par API vārteju, ir sava veida starpniekserveris. Šeit mums atkal bija izvēle - varat uzrakstīt savu starpniekserveri vai izvēlēties kaut ko gatavu. Šajā gadījumā mēs gājām otro ceļu un izvēlējāmies nginx + Lua komplektu. Kāpēc? Mums bija nepieciešama uzticama, pārbaudīta programmatūra, kas atbalsta mērogošanu. Pēc ieviešanas mēs nevēlējāmies pārbaudīt gan biznesa loģikas, gan starpniekservera pareizību.
Katram tīmekļa serverim ir pieprasījumu apstrādes cauruļvads. Nginx gadījumā tas izskatās šādi:
(diagramma no )
Mūsu mērķis bija iekļauties šajā konveijerā vietā, kur varam mainīt sākotnējo pieprasījumu.
Mēs vēlamies izveidot caurspīdīgu starpniekserveri, lai pieprasījums paliktu funkcionāli tāds pats, kāds tas tika saņemts. Mēs kontrolējam tikai piekļuvi galīgajam API, palīdzam pieprasījumam to nokļūt. Ja pieprasījums bija nepareizs, kļūda ir jāparāda galīgajam API, bet ne mums. Vienīgais iemesls, kāpēc mēs varam noraidīt pieprasījumu, ir tas, ka klientam nav piekļuves.
Jau pastāv nginx par . Lua ir skriptu valoda, tā ir ļoti viegla un viegli apgūstama. Tādējādi mēs ieviesām nepieciešamo loģiku, izmantojot Lua.
Nginx konfigurācija (analoģija lietojumprogrammas maršrutam), kurā tiek veikts viss darbs, ir diezgan saprotama. Ievērības cienīga šeit ir pēdējā direktīva - 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;
}
Apsveriet, kas notiek šajā konfigurācijā:
more_clear_input_headers — notīra pēc direktīvas norādīto galveņu vērtību.
lua_need_request_body - kontrolē, vai sākotnējā pieprasījuma pamatteksts ir jānolasa pirms pārrakstīšanas/access/access_by_lua direktīvu izpildes. Pēc noklusējuma nginx nelasa klienta pieprasījuma pamattekstu, un, ja jums ir nepieciešams tai piekļūt, šī direktīva ir jāieslēdz.
pārrakstīt_by_lua_file - ceļš uz skriptu, kas apraksta pieprasījuma modificēšanas loģiku
access_by_lua_file — ceļš uz skriptu, kas apraksta loģiku, kas pārbauda piekļuvi resursam.
starpniekserveris — url, uz kuru pieprasījums tiks nosūtīts.
body_filter_by_lua_file — ceļš uz skriptu, kas apraksta pieprasījuma filtrēšanas loģiku pirms tā atgriešanas klientam.
Un, visbeidzot, post_action - oficiāli nedokumentēta instrukcija, ar kuru jūs varat veikt dažas citas darbības pēc atbildes sniegšanas klientam.
Tālāk mēs secībā aprakstīsim, kā mēs atrisinājām savas problēmas.
Autorizācija/autentifikācija un izmaiņu pieprasīšana
Atļauja
Mēs izveidojām autorizāciju un autentifikāciju, izmantojot piekļuvi sertifikātam. Ir saknes sertifikāts. Katram jaunajam klienta klientam tiek ģenerēts personīgais sertifikāts, ar kuru viņš var piekļūt API. Šis sertifikāts ir konfigurēts nginx iestatījumu servera sadaļā.
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;Izmaiņas
Var rasties godīgs jautājums: ko darīt ar sertificētu klientu, ja pēkšņi vēlamies to atvienot no sistēmas? Neizsniedziet atkārtoti sertifikātus visiem citiem klientiem.
Tā nu raiti ķērāmies pie nākošā uzdevuma – sākotnējā pieprasījuma modificēšanas. Sākotnējais klienta pieprasījums, vispārīgi runājot, galīgajai sistēmai nav derīgs. Viens no uzdevumiem ir pievienot pieprasījumam trūkstošās daļas, lai tas būtu derīgs. Lieta tāda, ka trūkstošie dati katram klientam ir atšķirīgi. Mēs zinām, ka klients nāk pie mums ar sertifikātu, no kura mēs varam paņemt pirkstu nospiedumu un iegūt nepieciešamos klienta datus no datu bāzes.
Ja kādā brīdī vajadzēs atslēgt klientu no mūsu servisa, viņa dati pazudīs no datu bāzes un viņš neko nevarēs darīt.
Darbs ar klientu datiem
Mums bija jāpadara risinājums ļoti pieejams, jo īpaši tas, kā mēs iegūstam klientu datus. Grūtības rada tas, ka šo datu primārais avots ir trešās puses pakalpojums, kas negarantē nepārtrauktu un pietiekami lielu ātrumu.
Tāpēc mums bija jānodrošina augsta klientu datu pieejamība. Kā rīku mēs esam izvēlējušies kas mums nodrošina:
- ātra piekļuve datiem
- spēja organizēt vairāku mezglu kopu ar datiem, kas replicēti dažādos mezglos.
Mēs izmantojām vienkāršāko stratēģiju datu piegādei kešatmiņā:
Darbs ar beigu sistēmu notiek sesiju ietvaros un ir ierobežots maksimālais skaits. Ja klients nav slēdzis sesiju, mums tas būs jādara.
Atvērtās sesijas dati nāk no beigu sistēmas un sākotnēji tiek apstrādāti Lua pusē. Mēs nolēmām izmantot Hazelcast, lai saglabātu šos datus ar .NET darbu. Pēc tam ar dažiem intervāliem pārbaudām atklāto sesiju tiesības uz dzīvību un slēdzam sapuvušās.
Piekļuve Hazelcast gan no Lua, gan no .NET
Nav neviena Lua klienta, kas strādātu ar Hazelcast, taču Hazelcast ir REST API, kuru mēs nolēmām izmantot. .NET ir , caur kuru plānojām piekļūt Hazelcast datiem .NET pusē. Bet tā tur nebija.
Uzglabājot datus, izmantojot REST, un izgūstot datus, izmantojot .NET klientu, tiek izmantoti dažādi serializatori un deserializatori. Tāpēc nav iespējams ievietot datus caur REST, bet iegūt tos caur .NET klientu un otrādi.
Ja ir interese, sīkāk par šo problēmu pastāstīsim atsevišķā rakstā. Spoileris - uz shēmas.
Mežizstrāde un uzraudzība
Mūsu korporatīvais standarts reģistrēšanai, izmantojot .NET, ir Serilog, visi žurnāli nonāk Elasticsearch, un mēs tos analizējam, izmantojot Kibana. Es gribētu kaut ko līdzīgu darīt šajā gadījumā. Vienīgais lai strādātu ar Elastic uz Lua, kas tika atrasts, sabojājās jau pirmajā prasībā. Un mēs izmantojām Fluentd.
- atvērtā pirmkoda risinājums viena slāņa lietojumprogrammu reģistrēšanas nodrošināšanai. Ļauj apkopot žurnālus no dažādiem lietojumprogrammas slāņiem un pēc tam pārraidīt tos vienā avotā.
API vārteja darbojas K8S, tāpēc mēs nolēmām tajā pašā podā pievienot konteineru ar fluentd, lai rakstītu žurnālus esošajā atvērtajā tcp portā fluentd.
Mēs arī izpētījām, kā fluentd rīkotos, ja tam nebūtu savienojuma ar Elasticsearch. Divas dienas nepārtraukti tika sūtīti pieprasījumi uz vārteju, žurnāli tika sūtīti uz fluentd, bet fluentd tika aizliegts IP Elastic. Pēc savienojuma atjaunošanas fluentd lieliski apsteidza absolūti visus baļķus Elastic.
Secinājums
Izvēlētā ieviešanas pieeja ļāva mums kaujas vidē piegādāt patiešām funkcionējošu produktu tikai 2.5 mēnešos.
Ja jums kādreiz gadās darīt šādas lietas, mēs iesakām vispirms skaidri saprast, kādu problēmu jūs risinat un kādi resursi jums jau ir. Jāapzinās, cik sarežģīti ir integrācija ar esošajām API pārvaldības sistēmām.
Saprotiet paši, ko tieši jūs gatavojaties attīstīt - tikai pieprasījumu apstrādes biznesa loģiku vai, kā tas varētu būt mūsu gadījumā, visu starpniekserveri. Neaizmirstiet, ka viss, ko jūs darāt pats, pēc tam ir rūpīgi jāpārbauda.
Avots: www.habr.com
