Översättning av artikeln: Envoy-trådningsmodell — https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Den här artikeln verkade mig vara ganska intressant, och eftersom Envoy oftast används som en del av "istio" eller helt enkelt som "ingress controller" för Kubernetes, har de flesta människor inte samma direkta interaktion med den som med typiska installationer av Nginx eller Haproxy. Men om något går fel skulle det vara bra att förstå hur det fungerar inuti. Jag har försökt översätta så mycket text som möjligt till ryska, inklusive specialord, för dem som har svårt att se på sådant lämnade jag originalen inom parentes. Välkommen under kat.

Teknisk dokumentation av låg nivå om Envoys kodbas är för närvarande ganska sparsam. För att åtgärda detta planerar jag att göra en serie bloggartiklar om olika delsystem i Envoy. Eftersom detta är den första artikeln, vänligen låt mig veta vad du tycker och vad som skulle kunna intressera dig i de kommande artiklarna.

En av de vanligaste tekniska frågorna jag får om Envoy är begäran om en låg nivå beskrivning av den använda trådningsmodellen. I det här inlägget kommer jag att beskriva hur Envoy mappar anslutningar till trådar, samt en beskrivning av systemet för trådspecifik lagring (Thread Local Storage) som används internt för att göra koden mer parallell och högpresterande.

Översikt av trådar (Threading overview)

Envoy använder tre olika typer av trådar:

Huvudtråd (Main): Denna tråd hanterar starten och stoppningen av processen, all hantering av XDS (xDiscovery Service) API:erna, inklusive DNS, hälsokontroller (health checking), övergripande klusterhantering och tjänstehantering (runtime), återställande av statistik, administration och övergripande hantering av processer — Linux-signaler, varm omstart (hot restart) etc. Allt som händer i denna tråd är asynkront och "icke-blockerande". Generellt koordinerar huvudtråden alla kritiska funktionaliteter, vars utförande inte kräver en stor mängd CPU. Detta gör att större delen av styrningskoden kan skrivas som om den vore enkeltrådad.
Arbetstråd (Worker): Som standard skapar Envoy en arbetstråd (worker thread) för varje hårdvarutråd i systemet, detta kan kontrolleras med hjälp av alternativet --concurrency. Varje arbetstråd kör en "icke-blockerande" händelseschlepp (event loop) som ansvarar för att övervaka (listening) varje lyssnare (listener). Vid skrivande av denna artikel (29 juli 2017) finns ingen segmentering (sharding) av lyssnaren (listener), vilket inkluderar att ta emot nya kopplingar, skapa en instans av filterstacken för anslutningen och hantera alla in-och-utdataoperationer (IO) under anslutningens livslängd. Återigen gör detta att större delen av koden för hantering av anslutningar kan skrivas som om den vore en trådad (single-threaded) applikation.
Filskriver (File flusher): Varje fil som Envoy skriver, huvudsakligen åtkomstloggar (access logs), har för närvarande en oberoende blockerande tråd. Detta beror på att skrivning till filer, som är cachade av filsystemet även när det används O_NONBLOCK ibland kan blockera (suck). När arbetstrådar behöver skriva till en fil, flyttas data faktiskt till en buffer i minnet, där de så småningom spolas via strömmen file flush. Detta är ett av de områden i koden där tekniskt sett kan alla arbetstrådar (worker threads) blockera (block) samma lås (lock) när de försöker fylla bufferten i minnet.

Anslutningshantering (Connection handling)

Som kort nämnts ovan, övervakar alla arbetstrådar alla lyssnare (listeners) utan segmentering. Därför används kärnan för att effektivt skicka de mottagna sockets till arbetstrådarna. Moderna kärnor är i allmänhet mycket bra på detta, de använder funktioner som prioritering av in-och-utdata (IO) för att försöka fylla en ström med arbete innan de börjar använda andra strömmar som också lyssnar på samma socket, samt undvika cyklisk blockering (Spinlock) för att hantera varje begäran.
Så snart en anslutning accepteras på en arbetstråd (worker thread), lämnar den aldrig denna tråd (thread). All vidare behandling av anslutningen hanteras helt och hållet i arbetstråden (worker thread), inklusive eventuellt vidarebefordringsbeteende (forwarding behavior).

Detta har ett antal viktiga konsekvenser:

Alla anslutningspooler i Envoy tillhör arbetsflödet. Därför, även om HTTP/2 anslutningspooler endast upprättar en enda anslutning till varje överordnad värd åt gången, om det finns fyra arbetsflöden, kommer det att finnas fyra HTTP/2 anslutningar till den överordnade värden i ett stabilt tillstånd.
Anledningen till att Envoy fungerar på detta sätt är att genom att hålla allt i ett enda arbetsflöde kan nästan all kod skrivas utan blockeringar och som om den är entrådad. Denna design förenklar skrivandet av en stor mängd kod och skalas otroligt bra för nästan obegränsat antal arbetsflöden.
Men en av de viktigaste slutsatserna är att det i termer av effektivitet är mycket viktigt att justera parametern --concurrency. Att ha fler arbetsflöden än nödvändigt kommer att leda till minnesförlust, skapande av fler inaktiva anslutningar och lägre hastighet att nå anslutningspoolen. I Lyft arbetar våra envoy sidecar-containrar med mycket låg parallellism, så att prestandan ungefär motsvarar tjänsterna de sitter bredvid. Vi kör Envoy som en edge proxy endast vid maximal parallellism.

Vad icke-blockerande betyder

Termen "icke-blockerande" har använts flera gånger i diskussioner om hur huvud- och arbetsflöden fungerar. All kod är skriven med förutsättningen att ingenting någonsin blockeras. Dock är detta inte helt sant.

Envoy använder flera långvariga lås i processen:

Som tidigare nämnts, när loggar för åtkomst skrivs, får alla arbetsflöden samma lås innan de fyller loggbufferten i minnet. Hålltiden för låsen bör vara mycket låg, men det är möjligt att denna lås kan ifrågasättas vid hög parallellism och hög genomströmning.
Envoy använder ett mycket komplext system för att hantera statistik som är lokal för strömmen. Detta kommer att vara ämnet för ett separat inlägg. Jag nämner dock kort att som en del av lokal statistikbehandling av strömmen, krävs det ibland en lås för det centrala "statistiklagret". Detta lås ska aldrig behövas.
Huvudströmmen behöver periodiskt samordnas med alla arbetströmmar. Detta görs genom att "publicera" från huvudströmmen till arbetströmmarna, och ibland från arbetströmmarna tillbaka till huvudströmmen. För att skicka krävs det en lås så att det publicerade meddelandet kan placeras i kö för senare leverans. Dessa lås bör aldrig utsättas för allvarlig konkurrens, men de kan tekniskt sett fortfarande blockeras.
När Envoy skriver loggar till systemströmmens felström (standardfel), får den en lås på hela processen. Generellt sett betraktas lokal loggning i Envoy som dålig för prestandan, så det läggs inte mycket vikt vid att förbättra den.
Det finns några andra tillfälliga lås, men ingen av dem är kritisk för prestanda och bör aldrig ifrågasättas.

Tråd-lokalt lagring (Thread local storage)

På grund av sättet som Envoy separerar huvudströmmens ansvar från arbetströmmens ansvar, finns det ett krav på att komplex bearbetning kan utföras i huvudströmmen och sedan ges till varje arbetström med hög grad av parallellism. I detta avsnitt beskrivs systemet för Envoy Thread Local Storage (TLS) på en hög nivå. I nästa avsnitt kommer jag att beskriva hur det används för att hantera klustret.

Som redan nämnts, hanterar huvudströmmen nästan alla funktioner för hantering och funktionalitet för kontrollplanet i Envoy-processen. Kontrollplanet är här något överbelastat, men om man ser på det i ramen för selve Envoy-processen och jämför med vidarebefordran som utförs av arbetströmmarna, verkar det rimligt. Som en allmän regel utför huvudströmsprocessen en viss arbetsuppgift och sedan måste den uppdatera varje arbetström i enlighet med resultatet av detta arbete. I det här fallet behöver inte arbetstråden sätta en lås vid varje åtkomst.

TLS-systemet (Tråd-lokal lagring) Envoy fungerar på följande sätt:

Koden som körs i huvudtråden kan allokera en TLS-plats för hela processen. Även om detta är abstrakt, är det i praktiken ett index i en vektor som tillhandahåller O(1) åtkomst.
Huvudtråden kan sätta godtyckliga data i sin slot. När detta görs publiceras data i varje arbetstråd som en vanlig händelse i händelsecykeln.
Arbetstrådarna kan läsa från sin TLS-slot och hämta alla lokala tråddatan som finns tillgänglig där.

Även om detta är en mycket enkel och otroligt kraftfull paradigm som liknar RCU-konceptet (Read-Copy-Update). I grunden ser arbetstrådarna aldrig några förändringar i data i TLS-slotarna under arbetets gång. Ändringar sker endast under vila mellan arbetshändelser.

Envoy använder detta på två olika sätt:

Genom att spara olika data på varje arbetstråd görs åtkomsten till dessa data utan någon låsning.
Genom att spara en gemensam pekare på globala data i läsläge på varje arbetstråd. Därmed har varje arbetstråd en referensräknare på data som inte kan minskas under arbetets gång. Endast när alla arbetare har vilat och laddat nya gemensamma data, kommer de gamla data att förstöras. Detta är identiskt med RCU.

Klusteruppdateringstrådning (Cluster update threading)

I det här avsnittet kommer jag att beskriva hur TLS (Thread local storage) används för att hantera klustret. Hantering av klustret inkluderar behandling av API xDS och / eller DNS samt hälsokontroller (health checking).

Klustertrådhantering omfattar följande komponenter och steg:

Klusterhanteraren är en komponent inom Envoy som hanterar alla kända upstream i klustret, API-gränssnittet CDS (Cluster Discovery Service), API-gränssnitten SDS (Secret Discovery Service) och EDS (Endpoint Discovery Service), DNS och aktiva externa hälsokontroller (health checking). Den ansvarar för att skapa en "eventuellt konsekvent" (eventually consistent) bild av varje upstream i klustret, vilket inkluderar upptäckta värdar samt hälsostatus (health status).
Hälsokontrollverktyget (health checker) utför aktiv hälsokontroll och rapporterar förändringar i tillståndet till klusterchefen.
CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS används för att avgöra klustertillhörighet. Tillståndsändringar returneras till klusterchefen.
Varje arbetstråd utför ständigt en cykel av händelsebehandling.
När klusterchefen fastställer att tillståndet för klustret har förändrats skapas en ny tillståndsbild som är skrivskyddad och skickas till varje arbetstråd.
Under nästa viloperiod kommer arbetstråden att uppdatera bilden i den tilldelade TLS-platsen.
Under en in- och utflödeshändelse som ska avgöra värden för belastningsbalansering kommer belastningsbalanseraren att begära TLS-platsen (trådspecifik lagring) för att hämta värdinformation. Inga lås krävs för detta. Observera också att TLS även kan initiera händelser vid uppdateringar, så att belastningsbalanseringens subsystem och andra komponenter kan omberäkna cacheminnen, datakonstruktioner etc. Detta går utanför ramen för detta inlägg, men används på olika ställen i koden.

Genom att använda den ovan beskrivna proceduren kan Envoy hantera varje begäran utan några lås (förutom de som tidigare beskrivits). Utöver komplexiteten i själva TLS-koden behöver den största delen av koden inte förstå hur flertrådighet fungerar, och den kan skrivas i en enkeltrådig stil. Detta underlättar skrivandet av större delen av koden utöver utmärkt prestanda.

Andra subsystem som använder TLS

TLS (trådspecifik lagring) och RCU (Read Copy Update) används allmänt i Envoy.

Användningsexempel:

Mekanism för att ändra funktionalitet under körning: Den aktuella listan över aktiverade funktioner beräknas i huvudtråden. Därefter tilldelas varje arbetstråd en skrivskyddad bild med hjälp av RCU-semantik.
Ersättning av routingtavlor: för rutnät som tillhandahålls av RDS (Route Discovery Service) skapas rutnät i huvudtråden. En skrivskyddad ögonblicksbild kommer sedan att tillhandahållas varje arbetstråd med hjälp av RCU-semantik (Read Copy Update). Detta gör ändringar i rutnät atomärt effektiva.
Caching av HTTP-huvuden: Det visar sig att beräkningen av HTTP-huvudet för varje förfrågan (vid körning av ~25K+ RPS per kärna) är ganska kostsam. Envoy beräknar centralt huvudet ungefär varannan sekund och förser varje arbetare via TLS och RCU.

Det finns andra fall, men de tidigare exemplen bör ge en bra förståelse för vad TLS används till.

Kända prestandafällor (Known performance pitfalls)

Även om Envoy överlag fungerar ganska bra finns det några kända områden som kräver uppmärksamhet när det används med mycket hög parallellism och kapacitet:

Som redan beskrivits i denna artikel, får för närvarande alla arbetstrådar en låsning vid skrivning till minnesbufferten för loggåtkomst. Vid hög parallellism och hög kapacitet kommer det att krävas en samling av loggar för varje arbetstråd till priset av oordnad leverans vid skrivning till den slutliga filen. Som ett alternativ kan varje arbetstråd upprätta en separat logg för åtkomst.
Även om statistiken är starkt optimerad, kommer det troligen att ske atomär konkurrens om individuell statistik vid mycket hög parallellism och kapacitet. Lösningen på detta problem är att ha räknare för en arbetstråd med periodiska återställningar av centrala räknare. Detta kommer att diskuteras i ett kommande inlägg.
Den befintliga arkitekturen kommer inte att fungera bra om Envoy distribueras i ett scenario där det finns mycket få anslutningar som kräver betydande resurser för bearbetning. Det finns ingen garanti för att anslutningarna kommer att fördelas jämnt mellan arbetstrådarna. Detta kan lösas genom att implementera lastbalansering av arbetstrådar, där en funktion för att dela anslutningar mellan arbetstrådar implementeras.

Slutsats (Conclusion)

Envoys trådbaserade modell är utformad för att underlätta programmering och massiv parallellism genom potentiellt kostsamma användningar av minne och anslutningar om de inte konfigureras korrekt. Denna modell gör att den fungerar mycket bra vid ett mycket stort antal trådar och hög genomströmning.
Som jag kort nämnde på Twitter kan designen också fungera ovanpå en fullfjädrad nätverksstack i användarläge, som DPDK (Data Plane Development Kit), vilket kan leda till att vanliga servrar hanterar miljoner förfrågningar per sekund med fullständig L7-behandling. Det ska bli mycket intressant att se vad som byggs under de kommande åren.
En sista snabb kommentar: Jag har fått frågan flera gånger om varför vi valde C++ för Envoy. Anledningen är fortfarande att det är det enda allmänt förekommande språk på industristandard, som kan bygga den arkitektur som beskrivs i det här inlägget. C++ är definitivt inte lämpligt för alla eller ens många projekt, men för vissa användningsfall är det fortfarande det enda verktyget som får jobbet gjort.