3.16 API-gateways och tjänstenät

Översikt och motivation

I samma stund du delar upp ett program i många tjänster dyker en ny fråga upp: vem ansvarar för trafiken mellan dem och för trafiken som kommer in utifrån? Du kan besvara frågan dåligt genom att strö samma frågor (autentisering, omförsök, tidsgränser, hastighetsgränser, loggning) för hand i varje tjänst, eller så kan du besvara den väl genom att skjuta in dessa frågor i ett gemensamt lager som varje tjänst ärver gratis. Det här kapitlet handlar om två sådana lager. En API-gateway sitter vid ytterdörren och hanterar trafik som kommer in från klienter. Ett tjänstenät sitter mellan dina tjänster och hanterar trafiken som flödar dem emellan. De löser besläktade problem på olika ställen, och att blanda ihop de två är ett vanligt och dyrt misstag.

Branschen namnger trafikens två riktningar med en kompassmetafor. Nord-sydlig trafik är trafiken som korsar ditt systems gräns: en mobilapp, en webbläsare eller en partner som ringer in. Öst-västlig trafik är trafiken som stannar inom ditt system: tjänst A anropar tjänst B som anropar tjänst C för att tillfredsställa en begäran. En API-gateway är specialisten på nord-syd. Ett tjänstenät är specialisten på öst-väst. Att hålla den distinktionen skarp är kapitlets enskilt mest användbara idé, eftersom den talar om vilket verktyg som äger vilken policy och hindrar dig från att göra samma arbete två gånger.

För stora team är dessa lager hur du upprätthåller en policy en gång i stället för hundra. När autentisering, kryptering under överföring och hastighetsbegränsning bor i ett gemensamt lager når en säkerhetsrättelse varje tjänst den dag du driftsätter lagret, i stället för att vänta på hundra eftersläpningar. I företags- och myndighetssammanhang är den centraliseringen ofta poängen: revisorer vill ha ett enda, bevisbart ställe där åtkomst kontrolleras och trafik krypteras, och en gemensam gateway eller ett tjänstenät ger dem precis den punkten för policyefterlevnad. Det här kapitlet bygger på arkitekturstilarna i kapitel 3.2, de distribuerade systemens verklighet i kapitel 3.3 och nätverksgrunderna i kapitel 3.13, och omvandlar dem till konkret vägledning om vem som hanterar din trafik.

Nyckelprinciper

Skilj nord-syd (gateway) från öst-väst (nät). Låt var och en äga sin riktning.
Skjut tvärgående frågor in i ett gemensamt lager så att du skriver dem en gång, inte per tjänst.
Anta ett tjänstenät först när antalet tjänster gör kablage per tjänst till den större kostnaden.
Definiera en punkt för policyefterlevnad per fråga. Låt aldrig gateway och nät göra samma jobb.
Håll tjänster tunna: plattformen hanterar transporten, tjänsten hanterar affärslogiken.
Föredra identitetsbaserat nolltillitsnätverkande framför tillit baserad på nätverksplats.
Köp ett näts driftkomplexitet med öppna ögon och mät om det lönar sig.

Rekommendationer

Förstå vad en API-gateway gör

En API-gateway är en enda ingångspunkt som sitter framför dina tjänster och förmedlar varje begäran från omvärlden. I sin enklaste form är den en smart omvänd proxy (en server som tar emot klientbegäranden och vidarebefordrar dem till rätt backend), men en gateway förtjänar sitt namn genom att göra långt mer än att vidarebefordra. Den dirigerar varje begäran till rätt tjänst baserat på sökväg, värd eller rubriker. Den autentiserar anroparen (verifierar vem de är) och auktoriserar begäran (kontrollerar vad de får göra), så att en tjänst bakom den kan lita på att en begäran redan passerat ytterdörren. Den upprätthåller hastighetsbegränsning (att kapa begäranden per klient över tid) och kvoter (att kapa total användning över ett längre fönster) så att en bullrig eller missbrukande klient inte kan svälta de andra.

En gateway omformar också trafik. Begäranstransformation skriver om rubriker, översätter mellan protokoll eller anpassar en gammal klients format till en ny tjänsts förväntningar. API-komposition låter gatewayn sprida en enda inkommande begäran till flera tjänster och sy ihop deras svar till ett, så att en klient gör ett anrop i stället för sex. Versionsstöd låter dig köra v1 och v2 av ett API sida vid sida och dirigera varje klient till den version den förväntar sig, vilket köper dig utrymme att utvecklas utan att bryta någon. Att koncentrera dessa frågor vid kanten håller dina tjänster fokuserade på affärslogik och ger dig ett ställe att observera, säkra och strypa allt som kommer in. Designen av de API:er gatewayn står framför är ämnet för kapitel 2.3, och de identitetskontroller den utför bygger på kapitel 4.7.

Använd mönstret backend-för-frontend för divergerande klienter

Ett enda allmänt API betjänar ofta en webbapp, en mobilapp och partnerintegrationer på en gång, och det betjänar dem alla lite dåligt. Mobilklienten vill ha små nyttolaster och få rundturer eftersom bandbredd och batteri är knappa. Webbklienten klarar pratsammare, rikare svar. Partnern vill ha ett stabilt kontrakt som aldrig överraskar dem. Mönstret backend för frontend (BFF) löser denna spänning genom att ge varje klientklass sin egen tunna gateway, skräddarsydd för den klientens behov, framför de gemensamma tjänsterna bakom.

En BFF är en gateway med en smalare publik. Mobil-BFF:en komponerar och trimmar svar så att appen gör ett effektivt anrop. Webb-BFF:en exponerar en fylligare form. Partner-BFF:en håller ett långsamt förändrat, noga versionerat kontrakt. Varje team kan utveckla sin egen BFF utan att vänta på de andra, vilket ofta är den verkliga vinsten, eftersom det frikopplar klientteam från varandra. Kostnaden är fler rörliga delar och viss duplicerad logik över BFF:er, så reservera mönstret för fall där klienternas behov verkligen divergerar. När varje klient vill ha samma sak är en gateway enklare och bättre.

Förstå vad ett tjänstenät gör

Ett tjänstenät hanterar den öst-västliga trafiken mellan dina tjänster, och det gör det utan att be dessa tjänster ändra sin kod. Det klassiska nätet fungerar genom att driftsätta en sidovagnsproxy (en liten proxyprocess som körs bredvid varje tjänsteinstans och fångar upp all dess nätverkstrafik). Din tjänst tror att den talar direkt med en annan tjänst. I verkligheten talar den med sin lokala sidovagn, som hanterar det verkliga nätverksanropet. Eftersom varje begäran nu flödar genom en proxy som plattformen kontrollerar kan nätet upprätthålla beteende enhetligt över varje tjänst, i varje språk, utan något gemensamt bibliotek att hålla synkroniserat.

Vad upprätthåller det? För det första ömsesidig TLS (mTLS), där båda sidor av varje anslutning presenterar certifikat och krypterar trafiken, så att anrop mellan tjänster är autentiserade och privata som standard. För det andra trafikhantering: nätet kan flytta en liten procentandel av trafiken till en ny version för en kanariesläppning, dela trafik efter rubrik för testning eller spegla trafik till en skuggtjänst. För det tredje motståndskraft: omförsök, tidsgränser och kretsbrytning (mönstren i kapitel 2.20) tillämpade på plattformsnivå, konfigurerade med policy snarare än kodade i varje tjänst. För det fjärde observerbarhet: eftersom varje begäran passerar en proxy sänder nätet konsekventa mått, loggar och distribuerade spår för all trafik mellan tjänster, vilket matar observerbarhetspraxis i kapitel 9.2. Tjänsteförfattaren skriver inget av detta och får allt.

Känn till sidovagnsmönstret och de sidovagnslösa alternativen

Sidovagnsmodellen är elegant men inte gratis. Varje tjänsteinstans kör nu en extra proxycontainer som förbrukar minne och CPU, och varje anrop gör två extra nätverkshopp (in i den lokala sidovagnen och ut ur den avlägsna), vilket lägger till lite latens. Vid en handfull tjänster är denna overhead osynlig. Över tusentals poddar blir den en verklig post i din beräkningsräkning och din latensbudget. Den kostnaden har drivit en våg av sidovagnslösa, eller proxylösa, ansatser.

Två riktningar spelar roll. Den ena flyttar nätfunktioner ut ur en sidovagn per pod och in i en proxy per nod, så att många tjänster på samma maskin delar en proxy i stället för att var och en kör sin egen. Det byter viss isolering mot en stor minskning av overhead. Den andra, proxylösa ansatsen bäddar in nätets logik direkt i tjänsten via ett tunt bibliotek eller körmiljön, vilket tar bort de extra hoppen helt till priset av ett beroende per språk. En nyare utveckling skjuter vissa nätfunktioner in i operativsystemets kärna med eBPF (en teknik för att köra isolerade program inuti Linuxkärnan), som kan upprätthålla policy och samla in telemetri med mindre overhead än en proxy i användarutrymmet. Du behöver inte satsa på en vinnare i dag. Du behöver veta att sidovagnsskatten är verklig, att alternativ finns och att dina plattformsval inte bör låsa ute dig från att anta dem senare. Dessa mönster vilar på containerorkestreringsgrunden i kapitel 8.3.

Avgör när ett nät förtjänar sin komplexitet

Ett tjänstenät är kraftfullt och genuint komplicerat att driva. Det lägger till ett kontrollplan att driva, proxyservrar att uppgradera, certifikat att rotera och ett nytt lager att felsöka när en begäran försvinner. Den komplexiteten är värd att köpa när du har tillräckligt många tjänster för att kablage av dessa frågor för hand, per tjänst och per språk, kostar mer än att driva nätet. Den grova signalen är skala och polyglott mångfald: dussintals eller hundratals tjänster, skrivna i flera språk, där ett gemensamt bibliotek för mTLS och omförsök vore en mardröm att hålla konsekvent. I den skalan betalar sig ett nät i enhetlighet och bevisbar säkerhet.

Nätet förtjänar inte sin komplexitet när du har en handfull tjänster, ett enda språk eller ett litet team. För ett måttligt system kan ett bra bibliotek eller ramverk ge dig mTLS, omförsök och mått med långt mindre driftbörda än ett fullständigt nät, och en vanlig gateway plus förnuftiga klientbibliotek täcker ofta allt du behöver. Att anta ett nät för att det är på modet, innan din skala kräver det, är ett vanligt sätt att tillbringa ett år med att driva infrastruktur som löser ett problem du inte har. Börja med gatewayn, lägg till motståndskraftsmönster i kod eller bibliotek och sträck dig efter ett nät när antalet tjänster och språk gör ansatsen per tjänst till den dyrare. Det är samma disciplin “förtjänar det sin komplexitet” som moln- och distribuerade system-kapitlen (3.11 och 3.3) återkommer till gång på gång.

Undvik dubbelhantering där gateway och nät överlappar

Gateways och nät överlappar, och överlappningen är där team skadar sig själva. Båda kan göra omförsök, båda kan upprätthålla tidsgränser, båda kan kontrollera identitet, båda kan samla telemetri. Om gatewayn gör omförsök av en begäran tre gånger och nätet också gör omförsök tre gånger vid varje internt hopp kan ett klientomförsök explodera till dussintals backendanrop och förvandla ett litet hickande till en omförsöksstorm. Om båda lagren upprätthåller en tidsgräns och den inre är längre än den yttre ger den yttre upp medan den inre fortsätter arbeta och slösar insats på ett svar ingen kommer att läsa.

Åtgärden är en tydlig arbetsfördelning, nedskriven och överenskommen. Tilldela varje fråga till exakt ett lager. Gatewayn äger nord-syd-frågor: slutanvändarautentisering, externa hastighetsgränser och kvoter, begäranstransformation och API-komposition för klienter. Nätet äger öst-väst-frågor: mTLS mellan tjänster, interna omförsök och kretsbrytning samt trafikflyttning mellan tjänsteversioner. Där en fråga skulle kunna bo i endera, välj en ägare och låt det andra lagret släppa igenom. Konfigurera omförsöksbudgetar och tidsgränshierarkier så att en yttre tidsgräns alltid är längre än det inre arbete den väntar på. Målet är att varje begäran har exakt ett ställe som hanterar varje fråga, och ingen begäran görs om, autentiseras eller loggas två gånger av misstag.

Behandla gateway och nät som punkter för policyefterlevnad för nolltillit

Det djupaste skälet att köra dessa lager är säkerhetsarkitektur. Nolltillit är principen att ingen begäran betros på grund av var den kom ifrån. Varje begäran måste bevisa sin identitet och sin behörighet, även inuti ditt eget nätverk. Den gamla modellen litade på allt som redan var innanför perimetern, vilket betydde att en komprometterad tjänst kunde röra sig fritt. Nolltillit ersätter tillit baserad på nätverksplats med identitetsbaserad tillit vid varje hopp, och gateways och nät är de naturliga punkter där den identiteten kontrolleras.

Gatewayn är punkten för policyefterlevnad för extern identitet: den verifierar slutanvändaren eller partnern innan något når dina tjänster. Nätet är punkten för policyefterlevnad för arbetslastidentitet: varje tjänst får en kryptografisk identitet, mTLS bevisar den vid varje anrop och policy avgör vilka tjänster som får tala med vilka. Tillsammans ger de dig försvar på djupet, där en begäran kontrolleras vid kanten och igen mellan tjänster, så att en komprometterad tjänst inte ger fri rörlighet åt resten. I driftsättningar över flera kluster och regioner kan ett nät utvidga detta identitetsväv över klustergränser, så att en tjänst i ett kluster autentiserar sig mot en tjänst i ett annat med samma mTLS-garantier som den använder lokalt, vilket ger konsekvent nolltillitsnätverkande även när fotavtrycket sprids. Identitetsgrunderna här hänger direkt ihop med kapitel 4.7.

Avvägningar: för- och nackdelar

Tillvägagångssätt	Fördelar	Nackdelar
API-gateway	Ett ställe för autentisering, hastighetsgränser, komposition, versionering	En enda trång passage att skala och hålla högtillgänglig
Backend för frontend	Varje klient får ett skräddarsytt, oberoende utvecklande API	Fler gateways att driva. Logik duplicerad över BFF:er
Tjänstenät (sidovagn)	Enhetlig mTLS, omförsök, observerbarhet utan kodändring	Proxyoverhead, latens och ett kontrollplan att driva
Sidovagnslöst / proxylöst nät	Lägre overhead och latens än sidovagnar per pod	Mindre moget. Svagare isolering eller beroende per språk
Biblioteksbaserad motståndskraft	Enkelt att driva. Ingen extra infrastruktur	Duplicering per språk. Svårt att hålla konsekvent i skala
Nät över kluster	Konsekvent nolltillitsidentitet överallt	Betydande drift- och nätverkskomplexitet

Den centrala spänningen är enhetlighet mot driftkostnad. Ett gemensamt lager köper dig konsekvens, bevisbar säkerhet och policy du skriver en gång, men det är ett verkligt system du måste driva, skala, säkra och felsöka, och det för in sig själv i vägen för varje begäran. Lös spänningen efter skala och behov. En gateway lönar sig nästan alltid i samma stund du har externa klienter, eftersom de frågor den centraliserar är sådana du inte kan undvika. Ett nät lönar sig senare, när antalet tjänster och språk gör kablage per tjänst till den dyrare vägen. Under den tröskeln ger bibliotek och en vanlig gateway det mesta av nyttan till en bråkdel av kostnaden. Över den är nätets enhetlighet värd sin vikt. Misstaget åt båda håll är att anta av mode snarare än av behov: ett nät för tidigt är ett år av onödigt tillrättaläggande, och ett nät som hoppas över för sent är hundra inkonsekventa, handrullade implementationer av mTLS.

Frågor att diskutera med ditt team

För varje tvärgående fråga (autentisering, omförsök, tidsgränser, hastighetsbegränsning, kryptering, telemetri), vilket enskilt lager äger den, och kan alla namnge ägaren utan att gissa? Det här är frågan som förhindrar dubbelhantering, och de flesta team har aldrig besvarat den uttryckligen, vilket betyder att svaret skiljer sig per tjänst och per författare. Ta med en konkret lista över frågor nedför vänster sida och era lager (klientbibliotek, gateway, nät, enskild tjänst) tvärs över toppen och fyll i rutnätet tillsammans. Platserna där två celler kryssas för en fråga är era omförsöksstormar och tidsgränsinversioner som väntar på att hända. De tomma raderna är de frågor ingen hanterar alls. Leveransen är en enda överenskommen tabell, publicerad där varje team kan se den, som säger att exakt ett lager äger varje fråga och de andra släpper igenom. Den tabellen är värd mer än någon mängd gateway- eller nätkonfiguration, eftersom den är det som hindrar de två lagren från att bråka med varandra.
Har vi faktiskt tillräckligt många tjänster och språkmångfald för att motivera ett tjänstenät, eller håller vi på att köpa ett kontrollplan för att lösa ett problem vi inte har? Ett nät är ett allvarligt driftåtagande, och det ärliga svaret för många team är att ett bra bibliotek plus en gateway skulle tjäna dem bättre i dag. Ta med det verkliga antalet tjänster, antalet språk de är skrivna i och en ärlig bedömning av hur mycket duplicerad nätverkslogik faktiskt skadar er just nu. Ta sedan med den andra sidan: vem ska driva nätet, uppgradera dess proxyservrar, rotera dess certifikat och larmas när det felroutar en begäran. Om smärtan med kablage per tjänst är mindre än kostnaden för att driva nätet har ni ert svar, och det är att vänta. Om ni drunknar i inkonsekvent mTLS- och omförsökskod över dussintals polyglotta tjänster förtjänar nätet sin plats. Poängen är att avgöra på belägg, inte på hur en konferensföreläsning fick nätet att se ut.
Var går vår nolltillitsgräns i dag, och vad händer om en intern tjänst komprometteras? Många system litar fortfarande på allt som redan är innanför nätverket, vilket betyder att en enda komprometterad tjänst kan röra sig i sidled och nå allt annat, och team upptäcker ofta detta först under en incident. Gå igenom sprängradien ärligt: om en angripare äger en av era tjänster, vad kan den anropa, vad kan den läsa och vad stoppar den? Ta med ert nuvarande svar på hur anrop mellan tjänster autentiseras och krypteras, och var specifika med vilka anrop som skyddas av mTLS och vilka som är klartextstillit baserad på att vara på samma nätverk. Åtgärden som följer är en medveten plan för identitetsbaserad åtkomst vid varje hopp, med gatewayn som kontrollerar extern identitet och nätet eller motsvarande som kontrollerar arbetslastidentitet, så att ett intrång begränsas snarare än katastrofalt. Även om ni inte är redo att köra ett fullständigt nät är det första ärliga steget att namnge var tillitsgränsen verkligen sitter.
Om vårt gatewaylager föll just nu, hur mycket av systemet går svart, och har vi testat det felet i stället för att anta bort det? Gatewayn centraliserar så mycket att dess avbrott tar allt bakom den offline, och stora team tenderar att underinvestera i dess redundans just för att den fungerar tyst tills den inte gör det. Väg de konkurrerande dragen: en enda enkel gateway är lätt att resonera om och billig att driva, medan ett horisontellt skalat lager över flera zoner kostar mer och lägger till sin egen redundanskonfiguration och komplexitet. Ta med verkliga siffror till diskussionen, inklusive hur många instanser som körs i dag, över hur många tillgänglighetszoner, vad redundansväxlingstiden är och när ni senast körde en spelövning som medvetet dödade gatewayn. För företags- och myndighetsplattformar med åtaganden om drifttid eller lagstadgade servicenivåer, lägg till den avtalsenliga eller regulatoriska påföljden för ett avbrott, eftersom en ytterdörr utan redundans är en tillgänglighetsrisk ni i tysthet accepterat å varje tjänsts och varje medborgares vägnar bakom den.
Har vi mätt den sidovagnsskatt vårt nät faktiskt tar ut, och har vi en plan för de sidovagnslösa och eBPF-alternativen, eller betalar vi den blint? I skala slutar overheaden för proxyn per pod i beräkning och latens att vara osynlig och blir en verklig post i budgeten, men många team kör tusentals sidovagnar utan att någonsin mäta kostnaden. Spänningen är mellan sidovagnsmodellens mognad och isolering å ena sidan och den lägre overheaden hos proxyservrar per nod, proxylösa bibliotek eller eBPF-ansatser i kärnan å den andra, som är nyare och byter bort viss isolering eller lägger till ett beroende per språk. Ta med de uppmätta siffrorna: minne och CPU som proxyservrar förbrukar över flottan, den tillagda svanslatensen per hopp och vilken andel av er beräkningsräkning nätet utgör. För ett stort företag som kör nätet över tusentals poddar, eller en myndighetsplattform under budgetgranskning, är detta ett utgiftsbeslut tillsynen så småningom kommer att fråga om, så att känna till skatten och om era plattformsval håller de billigare alternativen öppna är grundläggande aktsamhet.
Behöver varje klientklass verkligen sin egen backend för frontend, eller håller vi på att duplicera logik över gateways för klienter som egentligen vill ha samma sak? BFF-mönstret frikopplar klientteam och låter var och en utveckla ett skräddarsytt kontrakt, men varje ny BFF är ytterligare en gateway att driva, säkra och hålla synkroniserad, och den duplicerade logiken över dem blir i tysthet en underhållsskatt. De konkurrerande hänsynen är teamautonomi och klientspecifik effektivitet mot driftkostnaden och driften hos många nästan identiska gateways. Ta med belägg för hur mycket klienternas behov verkligen divergerar: nyttolaststorlekar, antal rundturer, versioneringstakt och hur ofta en klients ändring skulle ha blockerat en annan under en enda gemensam gateway. I en stor organisation med många klientteam, eller en myndighetsplattform som betjänar en publik webbapp, en mobilapp och partnerintegrationer på en gång, är den ärliga frågan om divergensen motiverar spridningen, eftersom en BFF per klient som alla vill ha samma form är en utbredning ni kommer att betala för att underhålla i åratal.

Sektorsperspektiv

Startup. Leverera en API-gateway och hoppa över nätet. Med en handfull tjänster och ett pyttelitet team hanterar en enda gateway autentisering, hastighetsgränser och komposition, medan ett gemensamt klientbibliotek ger dig mTLS och omförsök till en bråkdel av ett kontrollplans kostnad. Din knappaste resurs är utvecklingsuppmärksamhet, så ett nät du inte kan driva är en skuld, inte en vallgrav. Håll gatewayn tillräckligt redundant för att överleva att en nod dör och ompröva nätet först när tjänsteantal och språkmångfald faktiskt tvingar fram frågan.

Småföretag. Du har inget plattformsteam som kan driva ett nät, så lita på det din hostingplattform eller gatewayprodukt ger direkt: hanterad TLS, inbyggd hastighetsbegränsning och en hostad gateway snarare än en du patchar själv. Rama in valet som köp mot bygg, och köp, eftersom en hanterad API-gateway kostar mindre än ingenjörstimmarna för att driva din egen. Behandla intern kryptering mellan tjänster som en funktion din plattform tillhandahåller, inte ett projekt du bemannar.

Storföretag. Med hundratals tjänster över många team och språk förtjänar ett nät sin komplexitet, och det verkliga arbetet är styrning: en nedskriven arbetsfördelning så att gateway och nät aldrig dubbelhanterar en fråga, enhetlig mTLS och telemetri samt ett plattformsteam som äger proxyuppgraderingar och certifikatrotation. Revisorer vill ha en enda bevisbar punkt för efterlevnad av åtkomst och kryptering, så standardisera gränssnittet och gör policy till något team ärver snarare än implementerar på nytt. Hantera sidovagnsskatten som en verklig budgetpost och håll sidovagnslösa alternativ öppna så att ni inte låses ute från billigare ansatser senare.

Offentlig sektor. Upphandlingsregler, transparens och offentlig ansvarsskyldighet formar arkitekturen. Behandla gateway och nät som den nolltillitsstomme tillsynsmyndigheter förväntar sig: varje medborgare och partner autentiserad vid ytterdörren, varje internt anrop autentiserat och krypterat via arbetslastidentitet och ett revisionsspår vid varje punkt för efterlevnad som bevisar var åtkomst kontrollerades och var trafik krypterades. Föredra öppna standarder och portabel konfiguration framför proprietär inlåsning som upphandlingsregler kan förbjuda, och publicera, där det är lämpligt, hur plattformen skyddar medborgardata när den korsar varje gräns.

Exempel

Startup. En startup på tolv personer kör åtta tjänster bakom en enda API-gateway. Gatewayn hanterar allt nord-syd-arbete: den autentiserar användare med en tokenkontroll, upprätthåller hastighetsgränser per plan så att användare på gratisnivån inte kan svämma över systemet och komponerar ett par pratsamma ändpunkter till enskilda mobilvänliga anrop. För öst-väst-trafik hoppar de medvetet över ett tjänstenät, eftersom åtta tjänster på två språk inte motiverar ett kontrollplan. I stället får de mTLS och omförsök från ett gemensamt klientbibliotek och sin plattforms inbyggda certifikathantering, och de samlar in spår med en lättviktsagent. När de senare lägger till en dedikerad mobilklient med snävare nyttolastbehov inför de en backend för frontend för mobil bredvid den befintliga webbgatewayn. De ompröva nätfrågan varje år och fortsätter besluta, med rätta, att de ännu inte passerat tröskeln där det skulle löna sig.

Storföretag. En multinationell bank kör flera hundra tjänster över många team och språk, och här förtjänar ett tjänstenät sin komplexitet. Varje tjänst får en arbetslastidentitet och mTLS som standard, så att all intern trafik är autentiserad och krypterad utan att något team skriver kryptokod, vilket tillfredsställer både säkerhetsorganisationen och revisorerna som vill ha en enda bevisbar punkt för efterlevnad. Nätet tillämpar enhetliga omförsök, tidsgränser och kretsbrytning med policy, och det flyttar trafik gradvis för kanariesläppningar så att en dålig driftsättning berör en procent av användarna innan den berör alla. Ett lager av API-gateways står framför extern trafik och partnertrafik och äger autentisering, kvoter och versionering, med en fast nedskriven regel att interna omförsök bor bara i nätet och externa hastighetsgränser bor bara i gateways, så att de två lagren aldrig dubbelhanterar en begäran. Konsekvent telemetri från varje proxy matar en central observerbarhetsplattform som låter en jourhavande ingenjör spåra en begäran över dussintals tjänstehopp.

Offentlig sektor. En nationell skattemyndighet moderniserar en medborgarvänd deklarationsplattform och behandlar gateway och nät som stommen i en nolltillitsarkitektur som tillsynsmyndigheter kräver. En API-gateway är den kontrollerade ytterdörren: varje medborgare och varje partner autentiseras och auktoriseras där, externa hastighetsgränser skyddar systemet under deklarationsdeadlinens ökning och gamla klientformat transformeras vid kanten så att äldre integrationer fortsätter fungera. Bakom den ger ett tjänstenät varje intern tjänst en kryptografisk identitet och upprätthåller mTLS vid varje anrop, så att ingen tjänst betros bara för att den är inne i nätverket, och åtkomstpolicyn listar uttryckligen vilka tjänster som får anropa vilka. Eftersom plattformen spänner över flera datacenter för motståndskraft utvidgar nätet samma identitets- och krypteringsgarantier över kluster och ger konsekvent nolltillitsnätverkande över hela landet. Varje punkt för efterlevnad sänder ett revisionsspår, så att myndigheten kan bevisa för tillsynsorgan exakt var åtkomst kontrollerades och var trafik krypterades.

Affärsnytta: motiv, ROI och TCO

Avkastningen på en gateway är lätt att se och vanligen stor. I stället för att varje tjänst implementerar autentisering, hastighetsbegränsning och begäranloggning på nytt bygger du dem en gång vid kanten och varje tjänst ärver dem. En säkerhetsrättelse eller en ny hastighetsbegränsningspolicy levereras i en driftsättning i stället för hundra, vilket förkortar tiden att stänga en sårbarhet och sänker kostnaden för varje revision, eftersom det finns ett enda ställe att inspektera. Kompositions- och versioneringsfunktionerna skär ner klientrundturer och låter dig utveckla API:er utan att bryta anropare, vilket minskar både latenskostnader och samordningsskatten mellan team. För nästan vilket system som helst med externa klienter betalar sig en gateway snabbt.

Tjänstenätet har ett subtilare affärsärende, eftersom dess totala ägandekostnad är verklig och löpande. Du betalar för proxyservrarnas beräkning och latens, för ingenjörerna som driver kontrollplanet och för inlärningskurvan i att felsöka ett nytt lager. Den kostnaden är motiverad när alternativet (implementationer av mTLS, omförsök och telemetri per tjänst och per språk) skulle vara större och, värre, inkonsekvent på sätt som skapar säkerhetsluckor och avbrott. Vid hög skala omvandlar nätet hundra sköra handrullade lösningar till en enhetlig, bevisbar, och avkastningen syns som färre säkerhetsincidenter, snabbare säkra driftsättningar genom trafikflyttning och dramatiskt bättre observerbarhet. Under den skalan gynnar den ärliga kalkylen ofta bibliotek och en gateway, och det disciplinerade draget är att vänta. För att driva ärendet inför ledningen, koppla gatewayn till de mått de redan följer (tid att åtgärda sårbarheter, revisionskostnad, API-samordningsoverhead) och koppla nätet till begränsning av säkerhetsincidenter, driftsättningssäkerhet och kostnaden för den polyglotta duplicering det ersätter.

Antimönster och fallgropar

Nät innan du behöver det: att anta ett fullständigt tjänstenät vid en handfull tjänster och köpa ett kontrollplan för att lösa ett problem du ännu inte har.
Dubbla omförsök: gatewayn och nätet gör båda omförsök, så att ett klientanrop multipliceras till en omförsöksstorm i backend som förstärker ett avbrott.
Tidsgränsinversion: en inre tidsgräns längre än den yttre, så att anroparen ger upp medan den anropade fortsätter arbeta på ett svar ingen kommer att läsa.
Gateway som monolit: att stoppa affärslogik i gatewayn tills den blir en gemensam flaskhals som varje team måste samordna sig för att ändra.
Enskild felpunkt: att köra en gatewayinstans utan redundans, så att ytterdörrens fall tar ner varje tjänst bakom den.
Att lita på nätverket: att behandla allt innanför perimetern som säkert, så att en komprometterad tjänst kan röra sig i sidled och nå allt.
Överlappande ägarskap: ingen nedskriven arbetsfördelning, så att samma fråga hanteras i båda lagren av misstag och ingen vet vilket som är auktoritativt.
BFF-spridning: att starta en backend för frontend per klient när klienterna vill ha samma sak och multiplicera gateways och duplicera logik utan nytta.
Att ignorera sidovagnsskatten: att driftsätta tusentals sidovagnar utan att mäta beräknings- och latensoverheaden och sedan undra vart budgeten tog vägen.

Mognadsmodell

Nivå 1, Initiera: Tjänster talar direkt med varandra utan något gemensamt lager. Autentisering, omförsök och tidsgränser är handkodade per tjänst och inkonsekventa. Intern trafik är ofta klartext och betrodd för att den är på nätverket, och det finns inget enskilt ställe att upprätthålla policy eller observera trafik. Beslut är reaktiva, fattade tjänst för tjänst när problem visar sig.
Nivå 2, Utveckla: En API-gateway står framför extern trafik och centraliserar autentisering, hastighetsbegränsning och routing, men öst-väst-frågor hanteras av gemensamma bibliotek med ojämn användning. Vissa tjänster har mTLS, många har det inte. Team känner till distinktionen mellan nord-syd och öst-väst, men ägarskapet är informellt och praxis skiljer sig från team till team.
Nivå 3, Standardisera: Nord-syd- och öst-väst-frågor är rent åtskilda med en nedskriven arbetsfördelning tillämpad i hela organisationen. Gatewayn äger extern identitet, kvoter och komposition. Ett nät eller ett konsekvent biblioteksskikt äger intern mTLS, omförsök och telemetri. Överlappningar är lösta så att ingen fråga dubbelhanteras, intern trafik är krypterad och identitetskontrollerad som standard och standarden är dokumenterad och upprätthållen snarare än överlåten åt varje teams gottfinnande.
Nivå 4, Hantera: Trafiklagret mäts och styrs mot utgångslägen. Ni följer sidovagnsskatten i beräkning och svanslatens per hopp, gateway- och nättillgänglighet mot felbudgetar, incidenter med omförsöksförstärkning och tidsgränsinversion, mTLS-täckning som andel av interna anrop och tiden att driva en policyändring över flottan. Mått grindar beslut: en proxyuppgradering, en ny omförsöksbudget eller en kanarieregel bedöms på data mot ett utgångsläge snarare än på intuition, och varje avvikelse från standarden utlöser en rättelse.
Nivå 5, Orkestrera: Gateway och nät är punkter för policyefterlevnad för en mogen nolltillitsarkitektur, med identitet kontrollerad vid varje hopp över kluster och regioner. Trafikflyttning driver säker progressiv leverans, observerbarheten är enhetlig och rik och organisationen utvärderar och antar kontinuerligt sidovagnslösa, proxylösa och eBPF-ansatser där de lönar sig. Trafiklagret är integrerat med säkerhet, leverans och kapacitetsplanering och anpassas när skala, språk och riskbilden skiftar.

Idéer för diskussion

Om er enda API-gateway föll just nu, hur många tjänster skulle bli onåbara, och vad är er plan för att göra ytterdörren redundant?
Vilken fråga i ert system hanteras för närvarande i både gatewayn och en tjänst (eller ett bibliotek), och hur skulle ni bevisa att den inte dubbelhanteras?
Vid vilket antal tjänster och språk skulle ert team vara överens om att ett nät slutligen förtjänat sin komplexitet, och hur långt är ni från den linjen?
Om en angripare komprometterade en intern tjänst i morgon, vilka andra tjänster kunde den nå, och vilken identitetskontroll skulle stoppa den?
Är de sidovagnslösa eller eBPF-baserade näten mogna nog för er plattform ännu, och vad skulle ni mäta för att avgöra det?
Behöver var och en av era divergerande klienter verkligen sin egen backend för frontend, eller håller ni på att duplicera logik som kunde förbli gemensam?

Viktigaste punkter

Skilj nord-sydlig trafik (hanteras av en API-gateway) från öst-västlig trafik (hanteras av ett tjänstenät). Var och en äger sin riktning, och att blanda ihop dem orsakar dubbelhantering.
En gateway centraliserar routing, autentisering, auktorisering, hastighetsbegränsning, kvoter, begäranstransformation, komposition och versionering, så att tjänster förblir tunna och policy bor på ett ställe.
Ett tjänstenät ger dig mTLS, trafikflyttning, omförsök och kretsbrytning på plattformsnivå och enhetlig observerbarhet utan att ändra tjänstekod, klassiskt genom sidovagnsproxyservrar.
Anta ett nät först när antalet tjänster och språk gör kablage per tjänst till den dyrare vägen. Under det vinner bibliotek plus en gateway, och sidovagnsskatten är verklig nog att bevaka.
Behandla gateway och nät som punkterna för policyefterlevnad i en nolltillitsarkitektur, tilldela varje tvärgående fråga till exakt ett lager och kontrollera identitet vid varje hopp över kluster.

Referenser och vidare läsning

Sam Newman, Building Microservices: Designing Fine-Grained Systems
Chris Richardson, Microservices Patterns: With Examples in Java
Lee Calcote and Zack Butcher, Istio: Up and Running
Ken Owens, Alois Reitbauer, and others; the CNCF Cloud Native Landscape and service mesh documentation
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
Susan Fowler, Production-Ready Microservices