Vår erfarenhet av att skapa en API Gateway

Vissa företag, inklusive vår kund, utvecklar produkter genom ett partnernätverk. Till exempel, stora e-handelsföretag är integrerade med leveranstjänster – du beställer en vara och får snart ett spårningsnummer för paketet. Ett annat exempel är att du köper en reseförsäkring eller en biljett till expressflyget tillsammans med din flygbiljett.

För detta används ett API som måste tillhandahållas till partnerna via API Gateway. Denna uppgift har vi löst. I denna artikel kommer vi att berätta mer.

Givet: en ekosystem och en API-portal med ett gränssnitt där användare är registrerade, får information osv. Vi behöver skapa en användarvänlig och pålitlig API Gateway. Under processen behöver vi säkerställa

• registrering,
• kontroll av anslutning till API,
• övervakning av hur användare använder det slutliga systemet,
• redovisning av affärsindikatorer.

I artikeln kommer vi att dela med oss av vår erfarenhet av att skapa en API Gateway, under vilken vi löste följande uppgifter:

• användarautentisering,
• användarautorisering,
• modifiering av den ursprungliga begäran,
• proxyservering av begäran,
• efterbehandling av svaret.

Det finns två typer av API-hantering:

1. Standard, som fungerar på följande sätt. Innan anslutning testar användaren funktionerna, betalar och integrerar på sin webbplats. Oftast används detta av små och medelstora företag.

2. Stora B2B API Management, där företaget först fattar ett affärsbeslut om att ansluta, blir en partner till företaget med kontraktsförpliktelser, och ansluter sig sedan till API. Efter att alla formaliteter har lösts får företaget teståtkomst, genomgår tester och går i produktion. Men detta är omöjligt utan en ledningsbeslut om anslutningen.

Vår lösning

I denna del kommer vi att berätta om skapandet av API Gateway.

Slutanvändarna av den skapade API-gatewayen är partner till vår kund. För varje av dem har vi redan de nödvändiga kontrakten. Vi behöver bara utöka funktionaliteten, vilket markerar den tillhandahållna tillgången till gatewayen. Därför behövs en kontrollerad process för anslutning och hantering.

Självklart hade vi kunnat ta en färdig lösning för att lösa uppgiften med API-hantering och skapandet av API Gateway i synnerhet. Till exempel hade det kunnat vara Azure API Management. Det passade inte oss eftersom vi redan hade en API-portal och en stor ekosystem byggd runt den. Alla användare var redan registrerade och visste var och hur de kunde få den information de behövde. I API-portalen fanns redan de nödvändiga gränssnitten, vi behövde bara en API Gateway. Det var just utvecklingen av den vi tog oss an.

Det som vi kallar en API Gateway är en slags proxy. Här hade vi återigen ett val — vi kunde skriva vår egen proxy eller använda något färdigt. I det här fallet valde vi den andra vägen och valde en kombination av nginx+Lua. Varför? Vi behövde pålitlig, testad programvara som stödjer skalning. Vi ville inte behöva kontrollera både affärslogikens korrekthet och proxyens funktionalitet efter implementeringen.

Varje webbserver har en pipeline för begärningsbehandling. I fallet med nginx ser den ut som följande:

(schema från GitHub Lua Nginx)

Vårt mål var att integrera oss i denna pipeline vid den punkt där vi kan modifiera den ursprungliga begäran.

Vi vill skapa en transparent proxy, så att begäran förblir funktionellt oförändrad från det ögonblick den anländer. Vi kontrollerar bara åtkomsten till den slutliga API:en och hjälper begäran att nå dit. Om begäran är felaktig ska det bara visas ett fel av den slutliga API:en, inte av oss. Den enda anledningen till att vi kan avvisa en begäran är om klienten saknar åtkomst.

För nginx finns det redan ett tillägg till Lua. Lua är ett skriptspråk, det är mycket lättviktigt och enkelt att lära sig. På så sätt implementerade vi den nödvändiga logiken med hjälp av Lua.

Konfigurationen av nginx (analog till routen i en applikation), där allt arbete utförs, är ganska tydlig. Den sista direktiven — post_action — är anmärkningsvärd.

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;
}

Låt oss titta på vad som händer i denna konfiguration:
more_clear_input_headers — rensar värdet av de angivna huvudena efter direktiven.
lua_need_request_body — reglerar om det ska läsas det ursprungliga begärans kropp innan direktiven rewrite/access/access_by_lua utförs eller inte. Som standard läser nginx inte klientens begärans kropp, och om du behöver få åtkomst till den måste denna direktiv sättas till on.
rewrite_by_lua_file — sökvägen till skriptet som beskriver logiken för modifieringen av förfrågan
access_by_lua_file — sökvägen till skriptet som beskriver logiken som kontrollerar tillgången till resursen.
proxy_pass — url:en som förfrågan kommer att proxas till.
body_filter_by_lua_file — sökvägen till skriptet som beskriver logiken för filtrering av förfrågan innan den returneras till klienten.
Och slutligen, post_action — en officiellt odokumenterad direktiv som kan användas för att utföra andra åtgärder efter att svaret har getts till klienten.

Här nedan kommer vi att berätta i ordning hur vi löste våra uppgifter.

Autentisering/auktorisering och modifiering av förfrågan

Behörighet

Vi byggde autentisering och auktorisering med hjälp av certifikatsåtkomst. Det finns ett rotcertifikat. För varje ny klient skapas ett personligt certifikat som ger tillgång till API:t. Detta certifikat konfigureras i serversektionen av nginx-inställningarna.

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;

Modifiering

Det kan uppstå en rimlig fråga: vad gör vi med en certifierad klient om vi plötsligt vill koppla bort denne från systemet? Ska vi verkligen återutfärda certifikat för alla andra klienter?

Så vi kom smidigt till nästa uppgift — modifiering av den ursprungliga förfrågan. Den ursprungliga förfrågan från klienten är egentligen inte giltig för det slutliga systemet. En av uppgifterna är att fylla i de saknade delarna i förfrågan för att göra den giltig. Grejen är att de saknade uppgifterna är olika för varje klient. Vi vet att klienten kommer till oss med ett certifikat, från vilket vi kan ta ett fingeravtryck och extrahera de nödvändiga klientdata från databasen.

Om det skulle krävas att koppla bort klienten från vår service, kommer deras data att försvinna från databasen och de kan inte göra något.

Arbete med klientdata

Vi behövde säkerställa hög tillgänglighet för lösningen, särskilt hur vi får klientdata. Svårigheten ligger i att den ursprungliga källan till dessa data är en extern tjänst som inte garanterar en oavbruten och tillräckligt hög arbetshastighet.

Därför behövde vi säkerställa hög tillgänglighet för klientdata. Som verktyg valde vi Hazelcast, vilket ger oss:

• snabb åtkomst till data,
• möjlighet att organisera ett kluster av flera noder med replikerade data på olika noder.

Vi valde den enklaste strategin för att leverera data till cachen:

Arbetet med det slutliga systemet sker inom ramarna för sessioner och det finns en gräns för det maximala antalet. Om kunden inte stänger sessionen, måste vi göra det.

Information om den öppna sessionen kommer från det slutliga systemet och bearbetas först på Lua-sidan. Vi valde att använda Hazelcast för att spara dessa data med en job som är skriven i .NET. Sedan kontrollerar vi med viss regelbundenhet rättigheten att fortsätta med öppna sessioner och stänger de som har gått ut.

Åtkomst till Hazelcast både från Lua och .NET

Det finns ingen Lua-klient för att arbeta med Hazelcast, men Hazelcast har ett REST API, vilket vi valde att använda. För .NET finns det klient, genom vilket vi planerade att få åtkomst till Hazelcast-data på .NET-sidan. Men så enkelt var det inte.

Vid datalagring via REST och hämtning via .NET-klienten används olika serialiserare/deserialiserare. Därför är det omöjligt att lägga in data via REST och hämta dem via .NET-klienten och vice versa.

Om det finns intresserade, kommer vi att berätta mer om detta problem i en separat artikel. Spoiler - se diagrammet.

Loggning och övervakning

Vår företagsstandard för loggning via .NET är Serilog, alla loggar hamnar till slut i Elasticsearch, och vi analyserar dem via Kibana. Något liknande ville vi göra i det här fallet. Den enda klient klienten för att arbeta med Elastic på Lua, som hittades, kraschade vid första require. Så vi använde Fluentd.

Fluentd är en open source-lösning för att säkerställa ett enhetligt loggningsskikt för applikationen. Den gör det möjligt att samla loggar från olika nivåer i applikationen och sedan översätta dem till en enhetlig källa.

API-gatewayen körs i K8S, så vi beslutade att lägga till en behållare med Fluentd i samma pod för att skriva loggar till den befintliga öppna tcp-porten för Fluentd.

Vi undersökte också hur Fluentd skulle fungera om den inte hade kontakt med Elasticsearch. Under två dagar fick gatewayen kontinuerligt förfrågningar, loggar skickades till Fluentd, men Fluentd blockerades av Elastic IP. Efter att kontakten återställts skickade Fluentd över alla loggar till Elastic utan problem.

Slutsats

Den valda implementationen gjorde det möjligt för oss att leverera en riktigt fungerande produkt till produktionsmiljön på bara 2,5 månader.

Om du någonsin får möjlighet att arbeta med sådana saker, rekommenderar vi att du först tydligt förstår vilket problem du ska lösa och vilka resurser du redan har. Var uppmärksam på integrationsutmaningar med befintliga API-hanteringssystem.

Förstå vad du egentligen avser att utveckla – endast affärslogiken för att hantera förfrågningar eller, som i vårt fall, hela proxy-lösningen. Kom ihåg att allt du gör själv måste testas noggrant i efterhand.

Källa: habr.com