Niektoré spoločnosti, vrátane našich klientov, rozvíjajú produkt prostredníctvom partnerskej siete. Napríklad veľké internetové obchody sú integrované so službou doručenia — objednávate si tovar a čoskoro dostanete sledovacie číslo zásielky. Ďalším príkladom je, že spolu s letenkou si zakúpite poistenie alebo lístok na aerotrain.
Na tento účel sa používa jeden API, ktorý je potrebné poskytnúť partnerom prostredníctvom API Gateway. Tento úkol sme sa rozhodli vyriešiť. V tomto článku sa podelíme o podrobnosti.
Máme: ekosystém a API portál s rozhraním, na ktorom sú zaregistrovaní používatelia, získavajú informácie atď. Potrebujeme urobiť pohodlný a spoľahlivý API Gateway. V procese musíme zabezpečiť
- registráciu,
- kontrolu pripojenia k API,
- monitorovanie toho, ako používatelia využívajú koncovú systém,
- sledovanie obchodných ukazovateľov.
V článku sa podelíme o naše skúsenosti s vytváraním API Gateway, pri ktorom sme riešili nasledujúce úlohy:
- autentifikáciu používateľa,
- autorizáciu používateľa,
- modifikáciu pôvodného dopytu,
- proxy dopytu,
- postprocessing odpovede.
Existujú dva typy správy API:
1. Štandardný, ktorý funguje nasledujúcim spôsobom. Pred pripojením si používateľ testuje možnosti, potom platí a integruje na svoju stránku. Najčastejšie sa používa v malom a strednom podnikaní.
2. Veľký B2B API Management, keď spoločnosť najskôr prijme obchodné rozhodnutie o pripojení, stane sa partnerom spoločnosti s zmluvnou povinnosťou, po čom sa pripojí k API. A až po vybavení všetkých formálností spoločnosť dostane testovací prístup, podstúpi testovanie a prejde do produkcie. Ale to nie je možné bez riadiaceho rozhodnutia o pripojení.
Naše riešenie
V tejto časti sa podelíme o vytváranie API Gateway.
Koneční používatelia vytváraného API Gateway sú partneri nášho klienta. Pre každého z nich už máme uložené potrebné zmluvy. Budeme musieť len rozšíriť funkcionalitu, pričom označíme poskytnutý prístup k gateway. To si vyžaduje kontrolovaný proces pripojenia a správy.
Samozrejme, bolo by možné vybrať nejaké hotové riešenie pre správu API a vytváranie API Gateway konkrétne. Napríklad to mohlo byťPre nás to nebolo vhodné, pretože v našom prípade sme už mali API portál a obrovský ekosystém vybudovaný okolo neho. Všetci používatelia boli už zaregistrovaní, vedeli, kde a ako môžu získať potrebné informácie. V API portáli už existovali potrebné rozhrania, potrebovali sme len API Gateway. Na jeho vývoji sme sa vlastne aj podieľali.
To, čo nazývame API Gateway, je akýsi proxy. Aj tu sme mali na výber — mohli sme napísať svoj vlastný proxy, alebo si vybrať niečo už hotové. V tomto prípade sme zvolili druhú cestu a vybrali kombináciu nginx+Lua. Prečo? Potrebovali sme spoľahlivý, testovaný softvér, ktorý podporuje škálovanie. Nechceli sme po implementácii testovať a overovať správnosť obchodnej logiky a správnosť fungovania proxy.
Každý webový server má potrubie na spracovanie požiadaviek. V prípade nginx vyzerá nasledovne:
(schéma z )
Naším cieľom bolo integrovať sa do tohto potrubia v momente, keď môžeme modifikovať pôvodnú požiadavku.
Chceme vytvoriť transparentný proxy, aby požiadavka zostala taká, aká prišla. Len kontrolujeme prístup k konečnému API, pomáhame požiadavke dostať sa k nemu. V prípade, že požiadavka bola nesprávna, chybu má nahlásiť konečné API, nie my. Jediným dôvodom, pre ktorý môžeme odmietnuť požiadavku, je nedostatok prístupu pre klienta.
Pre nginx už existuje na . Lua je skriptovací jazyk, je veľmi ľahký a jednoducho sa osvojiteľný. Takýmto spôsobom sme potrebnú logiku implementovali pomocou Lua.
Konfigurácia nginxu (analógia s routou aplikácie), kde sa vykonáva celá práca, je celkom zrozumiteľná. Pozoruhodná je posledná 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;
}
Pozrime sa, čo sa deje v tejto konfigurácii:
more_clear_input_headers — čistí hodnotu uvedených hlavičiek po direktíve.
lua_need_request_body — reguluje, či má byť pred vykonaním direktív rewrite/access/access_by_lua prečítané pôvodné telo požiadavky. Predvolene nginx nečíta telo požiadavky klienta a ak potrebujete k nemu získať prístup, táto direktíva by mala mať hodnotu on.
rewrite_by_lua_file — cesta k skriptu, kde je opísaná logika na modifikáciu požiadavky
access_by_lua_file — cesta k skriptu, kde je opísaná logika, ktorá kontroluje prístup k zdroju.
proxy_pass — url, na ktorý bude požiadavka proxyvaná.
body_filter_by_lua_file — cesta k skriptu, kde je opísaná logika na filtrovanie požiadavky pred jej vrátením klientovi.
A nakoniec, post_action — oficiálne nedokumentovaná direktíva, pomocou ktorej je možné vykonávať ešte ďalšie akcie po tom, ako je odpoveď odovzdaná klientovi.
Teraz sa postupne porozprávame, ako sme riešili svoje úlohy.
Autorizácia/audifikácia a modifikácia požiadavky
Autorizácia
Autorizáciu a autentifikáciu sme postavili pomocou prístupov na základe certifikátu. Existuje koreňový certifikát. Každému novému klientovi zákazníka je generovaný jeho osobný certifikát, s ktorým môže získať prístup k API. Tento certifikát je nastavený v sekcii server konfigurácií 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;Modifikácia
Môže sa objaviť spravodlivá otázka: čo robiť so certifikovaným klientom, ak sme náhle chceli jeho odpojenie zo systému? Predsa nebudeme znovu vydávať certifikáty pre všetkých ostatných klientov.
Tak sme pomaly prešli k ďalšej úlohe — modifikácii pôvodnej požiadavky. Pôvodná požiadavka klienta, celkom povedané, nie je platná pre konečný systém. Jednou z úloh je dopísať do požiadavky chýbajúce časti, aby bola platná. Základom je, že chýbajúce údaje sú rôzne pre každého klienta. Vieme, že klient k nám prichádza s certifikátom, z ktorého môžeme získať otlačok a vytiahnuť potrebné údaje o klientovi z databázy.
Ak by v nejakom momente bolo potrebné odpojiť klienta od našich služieb, jeho údaje zmiznú z databázy a nič nebude môcť robiť.
Práca s údajmi klienta
Museli sme zabezpečiť vysokú dostupnosť riešenia, najmä toho, ako získavame údaje klienta. Zložitosť spočíva v tom, že primárny zdroj týchto údajov je tretia strana, ktorá nezaručuje bezproblémovú a dostatočne vysokú rýchlosť práce.
Preto sme museli zabezpečiť vysokú dostupnosť údajov klientov. Ako nástroj sme vybrali , ktorý nám poskytuje:
- rýchly prístup k údajom,
- možnosť usporiadať klaster z viacerých uzlov s replikovanými na rôznych uzloch dátami.
Rozhodli sme sa pre najjednoduchšiu stratégiu dodávania dát do cache:
Práca s konečným systémom prebieha v rámci relácií a je tu limit na maximálny počet. Ak však klient neskončil reláciu, musíme to urobiť my.
Údaje o otvorenej relácii prichádzajú od konečného systému a spočiatku sa spracovávajú na strane Lua. Rozhodli sme sa použiť Hazelcast na uchovávanie týchto dát pomocou jobu naprogramovaného v .NET. Potom pravidelne kontrolujeme právo na život otvorených relácií a uzatvárame vypršané.
Prístup k Hazelcast je možný z Lua aj z .NET.
Klienti na Lua na prácu s Hazelcast neexistujú, ale Hazelcast má REST API, ktoré sme sa rozhodli využiť. Pre .NET je dostupný , cez ktorý sme plánovali získať prístup k dátam Hazelcast na strane .NET. Ale nebolo to také jednoduché.
Pri uchovávaní dát cez REST a ich získavaní cez .NET klienta sa používajú rôzne serializátory a deserializátory. Preto nie je možné uložiť dáta cez REST a získať ich cez .NET klienta a naopak.
Ak budú záujemcovia, podrobnejšie sa o tomto probléme dozviete v samostatnom článku. Spoiler — na schéme.
Logovanie a monitoring
Náš firemný štandard pre logovanie cez .NET — Serilog, všetky logy nakoniec končia v Elasticsearch, ich analýzu vykonávame cez Kibana. Niečo podobné sme chceli dosiahnuť aj v tomto prípade. Jediný nástroj na prácu s Elastic na Lua, ktorý bol nájdený, sa rozbil pri prvom require. A tak sme použili Fluentd.
— open source riešenie na zabezpečenie jednotnej vrstvy logovania aplikácie. Umožňuje zbierať logy z rôznych vrstiev aplikácie a následne ich prenášať do jedného zdroja.
API Gateway beží v K8S, preto sme sa rozhodli pridať kontajner s Fluentd do tej istej pody, aby sme mohli zapisovať logy do existujúceho otvoreného tcp portu Fluentd.
Rovnako sme skúmali, ako sa Fluentd správa, ak nemá spojenie s Elasticsearch. Počas dvoch dní do brány nepretržite prichádzali požiadavky, do Fluentd sa posielali logy, ale IP Elastic bol zablokovaný. Po obnovení spojenia Fluentd skvele preniesol všetky logy do Elastic.
Záver
Zvolený prístup k implementácii nám umožnil dodať skutočne funkčný produkt do prevádzky za pouhých 2,5 mesiaca.
Ak raz budete musieť riešiť podobné veci, odporúčame vám najprv jasne pochopiť, akú úlohu riešite a aké zdroje už máte k dispozícii. Buďte pozorní k zložitostiam integrácie s existujúcimi systémami správy API.
Ujasnite si, čo presne plánujete vyvinúť — iba obchodnú logiku spracovania požiadaviek alebo, ako to bolo v našom prípade, celý proxy server. Nezabúdajte, že všetko, čo si vytvoríte sami, by malo byť následne dôkladne otestované.
Zdroj: habr.com
