Iuj kompanioj, inkluzive de nia kliento, disvolvas la produkton per partnera reto. Ekzemple, grandaj interretaj vendejoj estas integritaj kun la liverservo - vi mendas produkton kaj baldaŭ ricevas spuran numeron por la pako. Alia ekzemplo estas kiam vi aĉetas asekuron aŭ Aeroexpress-bileton kune kun via flugbileto.
Por tio, unu API estas uzata, kiu devas esti elsendita al partneroj per la API-Enirejo. Ni solvis ĉi tiun problemon. En ĉi tiu artikolo ni rakontos al vi la detalojn.
Donita: ekosistemo kaj API-portalo kun interfaco kie uzantoj estas registritaj, ricevas informojn, ktp. Ni devas fari oportunan kaj fidindan API-Enirejon. En la procezo, ni devis provizi
- registriĝo,
- API-konektokontrolo,
- monitorante kiel uzantoj uzas la finsistemon,
- kontado pri komercaj indikiloj.
En la artikolo ni parolos pri nia sperto pri kreado de API Gateway, dum kiu ni solvis la jenajn taskojn:
- uzantaŭtentigo,
- rajtigo de uzanto,
- modifo de la originala peto,
- peto prokurado,
- posttraktado de respondoj.
Estas du specoj de API-administrado:
1. Normo, kiu funkcias jene. Antaŭ ol konektiĝi, la uzanto testas la funkciojn, poste pagas kaj enigas sian retejon. Plej ofte ili estas uzataj en malgrandaj kaj mezgrandaj entreprenoj.
2. Granda B2B API-Administrado, kiam la kompanio unue faras komercan decidon konekti, fariĝas partnero de la kompanio kun kontrakta devo, kaj poste ligas al la API. Kaj post kiam ĉiuj formalaĵoj estas aranĝitaj, la kompanio ricevas testan aliron, trapasas provojn kaj ekproduktas. Sed ĉi tio ne eblas sen administra decido konektiĝi.
Nia solvo
En ĉi tiu parto, ni parolos pri kreado de API-Enirejo.
La finaj uzantoj de la kreita API-enirejo estas partneroj de nia kliento. Ni jam havas la necesajn kontraktojn por ĉiu el ili. Ni nur bezonos etendi la funkciecon markante la donitan aliron al la enirejo. Sekve, necesas kontrolita konekto kaj administradprocezo.
Kompreneble, eblis preni iun pretan solvon por solvi la problemon de API-Administrado kaj precipe krei API-Enirejon. Ekzemple, ĉi tio povus esti. Ĝi ne konvenis al ni, ĉar en nia kazo ni jam havis API-portalon kaj grandegan ekosistemon konstruitan ĉirkaŭ ĝi. Ĉiuj uzantoj jam estas registritaj, ili jam komprenis kie kaj kiel ili povas akiri la necesajn informojn. La necesaj interfacoj jam ekzistis en la API-portalo, ni nur bezonis la API-Enirejon. Efektive, ni okupiĝas pri ĝia evoluo.
Kion ni nomas la API Gateway estas speco de prokurilo. Ĉi tie ni denove havis elekton - vi povas skribi vian propran prokurilon, aŭ vi povas elekti ion pretan. En ĉi tiu kazo, ni iris la duan vojon kaj elektis la pakaĵon nginx + Lua. Kial? Ni bezonis fidindan, provitan programaron, kiu subtenas skaladon. Post la efektivigo, ni ne volis kontroli kaj la ĝustecon de la komerca logiko kaj la ĝustecon de la prokurilo.
Ĉiu retservilo havas pettraktan dukton. En la kazo de nginx, ĝi aspektas jene:
(diagramo el )
Nia celo estis kongrui en ĉi tiu dukto ĉe punkto kie ni povas modifi la originan peton.
Ni volas krei travideblan prokurilon por ke la peto restu funkcie sama kiel ĝi venis. Ni nur kontrolas aliron al la fina API, helpas la peton atingi ĝin. Se la peto estis malĝusta, la fina API devus montri la eraron, sed ne nin. La nura kialo, ke ni povas rifuzi peton, estas ĉar la kliento ne havas aliron.
Jam ekzistas por nginx sur . Lua estas skriptlingvo, ĝi estas tre malpeza kaj facile lernebla. Tiel, ni efektivigis la necesan logikon uzante Lua.
La agordo nginx (analogio al la itinero de la aplikaĵo), kie la tuta laboro estas farita, estas sufiĉe komprenebla. Rimarkinda ĉi tie estas la lasta direktivo - 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;
}
Konsideru kio okazas en ĉi tiu agordo:
pli_klaraj_enigaj_kapoj — forigas la valoron de la kaplinioj specifitaj post la direktivo.
lua_bezona_peto_korpo - kontrolas ĉu la originala petokorpo devus esti legita antaŭ ekzekuti la rewrite/access/access_by_lua direktivoj aŭ ne. Defaŭlte, nginx ne legas la korpon de kliento-peto, kaj se vi bezonas aliri ĝin, tiam ĉi tiu direktivo devus esti ŝaltita.
reverki_per_lua_dosiero - la vojo al la skripto, kiu priskribas la logikon por modifi la peton
aliro_per_lua_dosiero — la vojo al la skripto, kiu priskribas la logikon, kiu kontrolas por aliro al la rimedo.
prokura_paso — url al kiu la peto estos sendita.
korpo_filtrilo_per_lua_dosiero — la vojo al la skripto, kiu priskribas la logikon por filtri la peton antaŭ resendi ĝin al la kliento.
Kaj fine post_ago - oficiale nedokumentita direktivo per kiu vi povas fari iujn aliajn agojn post kiam la respondo estas donita al la kliento.
Poste, ni priskribos en ordo kiel ni solvis niajn problemojn.
Rajtigo/aŭtentikigo kaj peto modifo
Rajtigo
Ni konstruis rajtigon kaj aŭtentikigon per atestila aliro. Estas radika atestilo. Ĉiu nova kliento de la kliento estas generita sian personan atestilon, per kiu li povas aliri la API. Ĉi tiu atestilo estas agordita en la servila sekcio de la agordoj de 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;Modifo
Justa demando povas ekesti: kion fari kun atestita kliento se ni subite volas malkonekti ĝin de la sistemo? Ne reeldonu atestojn por ĉiuj aliaj klientoj.
Do ni glate alproksimiĝis al la sekva tasko - modifi la originan peton. La komenca peto de la kliento, ĝenerale, ne validas por la fina sistemo. Unu el la taskoj estas aldoni la mankantajn partojn al la peto por validigi ĝin. La punkto estas, ke la mankantaj datumoj estas malsamaj por ĉiu kliento. Ni scias, ke kliento venas al ni kun atestilo, el kiu ni povas preni fingrospuron kaj ĉerpi la necesajn klientajn datumojn el la datumbazo.
Se iam vi bezonas malkonekti la klienton de nia servo, liaj datumoj malaperos el la datumbazo kaj li nenion povos fari.
Laborante kun klientaj datumoj
Ni devis igi la solvon tre disponebla, precipe kiel ni ricevas klientajn datumojn. La malfacilaĵo estas, ke la ĉefa fonto de ĉi tiuj datumoj estas triaj servo, kiu ne garantias seninterrompan kaj sufiĉe altan rapidon.
Tial ni devis certigi altan haveblecon de klientdatenoj. Kiel ilon, ni elektis kiu provizas al ni:
- rapida aliro al datumoj
- la kapablo organizi areton de pluraj nodoj kun datenoj reproduktitaj sur malsamaj nodoj.
Ni iris kun la plej simpla strategio por liveri datumojn al la kaŝmemoro:
Laboro kun la finsistemo okazas ene de sesioj kaj ekzistas limo por la maksimuma nombro. Se la kliento ne fermis la sesion, ni devos fari tion.
La malfermaj sesiaj datumoj venas de la fina sistemo kaj estas komence prilaboritaj ĉe la Lua-flanko. Ni decidis uzi Hazelcast por konservi ĉi tiujn datumojn per .NET-laboro. Poste, je kelkaj intervaloj, ni kontrolas la rajton al vivo de malfermitaj kunsidoj kaj fermas la putrajn.
Alirante Hazelcast de kaj Lua kaj .NET
Ne estas Lua-klientoj por labori kun Hazelcast, sed Hazelcast havas REST API, kiun ni decidis uzi. Por .NET ekzistas , per kiu ni planis aliri Hazelcast-datumojn ĉe la .NET-flanko. Sed ĝi ne estis tie.
Dum konservado de datumoj per REST kaj reakiro de datumoj per .NET-kliento, malsamaj seriigiloj kaj deserialigiloj estas uzataj. Tial, estas neeble meti datumojn per REST, sed ricevi ĝin per la .NET-kliento kaj inverse.
Se interesiĝas, ni rakontos al vi pli pri ĉi tiu problemo en aparta artikolo. Spoiler - sur la skemo.
Registrado kaj monitorado
Nia kompania normo por registri per .NET estas Serilog, ĉiuj protokoloj finiĝas en Elasticsearch, kaj ni analizas ilin per Kibana. Mi ŝatus fari ion similan en ĉi tiu kazo. La sola labori kun Elastic sur Lua, kiu estis trovita, rompis sur la plej unua postulo. Kaj ni uzis Fluentd.
- Malfermfonta solvo por provizi ununuran tavolon de aplikaĵa registrado. Ebligas vin kolekti protokolojn de malsamaj tavoloj de la aplikaĵo, kaj poste dissendi ilin en ununuran fonton.
API Gateway funkcias en K8S, do ni decidis aldoni ujon kun fluentd en la sama pody por skribi protokolojn al la ekzistanta malfermita tcp-haveno fluentd.
Ni ankaŭ esploris kiel fluentd kondutus se ĝi ne havus rilaton al Elasticsearch. Dum du tagoj, petoj estis senĉese senditaj al la enirejo, protokoloj estis senditaj al fluentd, sed fluentd estis malpermesita de IP Elastic. Post kiam la konekto estis restarigita, fluentd perfekte preterpasis absolute ĉiujn ŝtipojn en Elastic.
konkludo
La elektita aliro al efektivigo permesis al ni liveri vere funkciantan produkton al la batalmedio en nur 2.5 monatoj.
Se iam vi faras tiajn aferojn, ni konsilas al vi unue klare kompreni, kian problemon vi solvas kaj kiajn rimedojn vi jam havas. Estu konscia pri la kompleksecoj de integriĝo kun ekzistantaj API-administradsistemoj.
Komprenu mem, kion precize vi disvolvos - nur la komercan logikon por prilabori petojn, aŭ, kiel ĝi povus esti en nia kazo, la tutan prokurilon. Ne forgesu, ke ĉio, kion vi faras mem, devas esti ĝisfunde provita poste.
fonto: www.habr.com
