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

Jag tyckte att den här artikeln var ganska intressant, och eftersom Envoy oftast används som en del av "istio" eller helt enkelt som en Kubernetes "ingress controller", har de flesta inte samma direkta interaktion med den som till exempel med typiska Nginx- eller Haproxy-installationer. Men om något går sönder vore det bra att förstå hur det fungerar inifrån. Jag försökte översätta så mycket text som möjligt till ryska, inklusive specialord. För er som tycker det är smärtsamt att titta på detta har jag lämnat originalen inom parentes. Välkommen under snittet.

Teknisk dokumentation på låg nivå för Envoy-kodbasen är för närvarande ganska gles. För att åtgärda detta planerar jag att göra en serie blogginlägg om de olika Envoy-delsystemen. Eftersom detta är den första artikeln, berätta gärna vad du tycker och vad du kan vara intresserad av i framtida artiklar.

En av de vanligaste tekniska frågorna jag får om Envoy är en begäran om en lågnivåbeskrivning av den trådmodell som används. I det här inlägget kommer jag att beskriva hur Envoy mappar kopplingar till trådar, och det Thread Local Storage-system som används internt för att göra kod mer parallell och effektiv.

Översikt över gängning

Envoy använder tre olika typer av strömmar:

Huvudsaklig: Den här tråden hanterar processstart och avstängning, all XDS (xDiscovery Service) API-bearbetning, inklusive DNS, hälsokontroll, allmän kluster- och runtime-hantering, statistikåterställning, administration och allmän processhantering. Linux Signaler, omstarter under drift, etc. Allt som händer i den här tråden är asynkront och blockerar inte. Sammantaget koordinerar huvudtråden alla kritiska processer som inte kräver en stor processor. Detta gör att det mesta av kontrollkoden kan skrivas som om den vore enkeltrådad.
Arbetstagare: Som standard skapar Envoy en arbetstråd för varje hårdvarutråd i systemet, detta kan styras med alternativet --concurrency. Varje arbetstråd kör en "icke-blockerande" händelseloop som ansvarar för att lyssna på varje lyssnare (det finns ingen lyssnarshardning i skrivande stund (29 juli 2017)), acceptera nya anslutningar, instansiera en filterstack för anslutningen och hantera all IO under anslutningens livslängd. Återigen, detta gör att det mesta av koden för anslutningshantering kan skrivas som om den vore enkeltrådad.
Filrensare: Varje fil som Envoy skriver, främst åtkomstloggar, har för närvarande en oberoende låstråd. Detta beror på att skrivning till filer som cachas av filsystemet även när man använder O_NONBLOCK ibland kan det bli blockerat (suck). När arbetstrådar behöver skriva till en fil flyttas data faktiskt till en buffert i minnet där de så småningom spolas genom tråden. filrensning. Detta är ett kodområde där tekniskt sett alla arbetstrådar kan blockera samma lås samtidigt som de försöker fylla en minnesbuffert.

Hantering av anslutningar

Som diskuterats kort ovan lyssnar alla arbetartrådar på alla lyssnare utan någon segmentering. På så sätt används kärnan för att intelligent skicka mottagna sockets till arbetstrådar. Moderna kärnor är generellt sett mycket bra på detta, och använder funktioner som IO-boosting för att försöka fylla en tråd med arbete innan andra trådar som också lyssnar på samma socket börjar använda den, och använder inte spinlock för att hantera varje förfrågan.
När en anslutning väl har accepterats i en arbetstråd lämnar den aldrig den tråden. All vidare bearbetning av anslutningen hanteras helt i arbetstråden, inklusive eventuellt vidarebefordringsbeteende.

Detta har flera viktiga konsekvenser:

Alla anslutningspooler i Envoy är associerade med en arbetstråd. Så, även om HTTP/2-anslutningspooler bara gör en anslutning till varje uppströmsvärd åt gången, om det finns fyra arbetstrådar, kommer det att finnas fyra HTTP/2-anslutningar per uppströmsvärd i stationärt tillstånd.
Anledningen till att Envoy fungerar på det här sättet är att genom att hålla allt på en enda arbetstråd kan nästan all kod skrivas låsfri och som om den vore enkeltrådad. Den här designen gör det enkelt att skriva stora mängder kod och skalar otroligt bra till ett nästan obegränsat antal arbetstrådar.
En av de viktigaste slutsatserna är dock att det, ur ett minnespool- och anslutningseffektivitetsperspektiv, faktiskt är mycket viktigt att finjustera parametern. --concurrency. Att ha fler arbetstrådar än nödvändigt kommer att resultera i slöseri med minne, fler inaktiva anslutningar och en långsammare anslutningshastighet för anslutningspoolen. På Lyft körs våra Envoy sidecar-containrar med mycket låg samtidighet, så prestandan är ungefär i linje med de tjänster de står bredvid. Vi kör endast Envoy som en edge-proxy vid maximal samtidighet.

Vad icke-blockerande betyder

Termen "icke-blockerande" har använts flera gånger hittills när man diskuterar hur huvud- och arbetstrådarna fungerar. All kod skrivs med antagandet att ingenting någonsin låser sig. Detta är dock inte helt sant (vad är inte helt sant?).

Envoy använder flera långa processlås:

Som nämnts, när man skriver åtkomstloggar, får alla arbetstrådar samma lås innan de fyller loggbufferten i minnet. Låsets hålltid bör vara mycket låg, men det är möjligt att detta lås kommer att ifrågasättas vid hög samtidighet och hög dataflöde.
Envoy använder ett mycket sofistikerat system för att hantera statistik som är lokal för en tråd. Detta blir ämnet för ett separat inlägg. Jag vill dock kort nämna att det som en del av den lokala bearbetningen av trådstatistik ibland är nödvändigt att skaffa ett lås på det centrala "statistiklagret". Detta lås borde aldrig vara nödvändigt.
Huvudtråden behöver regelbundet koordineras med alla arbetartrådar. Detta görs genom att "publicera" från huvudtråden till arbetstrådarna, och ibland från arbetstrådarna tillbaka till huvudtråden. Skicka kräver ett lås så att det publicerade meddelandet kan placeras i kö för senare leverans. Dessa block borde aldrig utsättas för allvarlig konkurrens, men de kan tekniskt sett fortfarande blockeras.
När Envoy skriver en logg till systemfelsströmmen (standardfel) får den ett processomfattande lås. Generellt sett anses Envoys lokala loggning vara fruktansvärd prestandamässigt, så det finns inte mycket fokus på att förbättra den.
Det finns några andra slumpmässiga lås, men ingen av dem är prestandakritiska och bör aldrig ifrågasättas.

Tråd lokal lagring

På grund av hur Envoy separerar huvudtrådens ansvarsområden från arbetstrådens ansvarsområden finns det ett krav att komplex bearbetning kan utföras på huvudtråden och sedan levereras till varje arbetstråd med en hög grad av parallellitet. Det här avsnittet beskriver Envoy Thread Local Storage (TLS)-systemet på en övergripande nivå. I nästa avsnitt kommer jag att beskriva hur det används för att hantera ett kluster.

Som beskrivits tidigare hanterar huvudtråden i stort sett all hanterings- och kontrollplansfunktionalitet i Envoy-processen. Kontrollplanet här är lite överbelastat, men när det ses inom själva Envoy-processen och jämförs med den vidarebefordran som arbetstrådar gör, är det vettigt. Den allmänna regeln är att huvudtrådsprocessen gör ett visst arbete och sedan behöver den uppdatera varje arbetstråd med resultatet av det arbetet, på så sätt behöver inte arbetstråden ställa in ett lås för varje åtkomst.

Envoys TLS-system (Thread local storage) fungerar enligt följande:

Kod som körs på 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, vilket ger O(1)-åtkomst.
Huvudtråden kan lägga in godtyckliga data i sin plats. När detta är klart publiceras data till varje arbetstråd som en vanlig händelseloop.
Arbetartrådar kan läsa från sin TLS-plats och hämta all trådlokal data som finns tillgänglig där.

Även om det är ett mycket enkelt och otroligt kraftfullt paradigm, är det mycket likt RCU (Read-Copy-Update) låskonceptet. I huvudsak ser arbetstrådar aldrig några ändringar av data i TLS-platser medan de utför arbete. Förändring sker endast under viloperioden mellan arbetshändelser.

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

Genom att lagra olika data på varje arbetstråd kan dessa data nås utan någon låsning.
Håller en delad pekare till globala data i skrivskyddat läge på varje arbetstråd. Således har varje arbetstråd ett datareferensantal som inte kan minskas medan arbetet pågår. Först när alla arbetare har lugnat ner sig och laddat upp den nya delade datan kommer den gamla datan att förstöras. Detta är identiskt med RCU.

Trådning för klusteruppdatering

I det här avsnittet kommer jag att beskriva hur TLS (Thread local storage) används för att hantera klustret. Klusterhantering inkluderar xDS- och/eller DNS API-bearbetning, samt hälsokontroll.

Klusterflödeshantering omfattar följande komponenter och steg:

Klusterhanteraren är en komponent i Envoy som hanterar alla kända klusteruppströmsenheter, Cluster Discovery Service (CDS) API, Secret Discovery Service (SDS) och Endpoint Discovery Service (EDS) API:er, DNS och aktiv extern hälsokontroll. Den ansvarar för att skapa en "så småningom konsekvent" vy över varje uppströms kluster, vilket inkluderar upptäckta värdar samt hälsostatus.
Hälsokontrollen utför aktiv hälsokontroll och rapporterar hälsotillståndsändringar till klusterhanteraren.
CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS utförs för att fastställa klustermedlemskap. Tillståndsändringen returneras till klusterhanteraren.
Varje arbetstråd kör kontinuerligt en händelsebearbetningsslinga.
När klusterhanteraren fastställer att klustrets tillstånd har ändrats skapar den en ny skrivskyddad ögonblicksbild av klustertillståndet och skickar den till varje arbetstråd.
Under nästa tysta period kommer arbetstråden att uppdatera ögonblicksbilden i den allokerade TLS-platsen.
Under en I/O-händelse som behöver identifiera en värd för lastbalansering, kommer lastbalanseraren att fråga TLS-platsen (Thread local storage) för att hämta information om värden. Detta kräver inga lås. Observera också att TLS också kan utlösa händelser när den uppdateras, så att lastbalanserare och andra komponenter kan beräkna om cacher, datastrukturer etc. Detta ligger utanför ramen för det här inlägget, men används på olika ställen i koden.

Med hjälp av ovanstående procedur kan Envoy behandla alla förfrågningar utan någon blockering (förutom de som beskrivits tidigare). Bortsett från komplexiteten i själva TLS-koden behöver den mesta delen av kod inte förstå hur multitrådning fungerar och kan skrivas i enkeltrådat läge. Detta gör det mesta av koden enklare att skriva, förutom att det ger överlägsen prestanda.

Andra delsystem som använder TLS

TLS (Thread local storage) och RCU (Read Copy Update) används flitigt i Envoy.

Exempel på användning:

Mekanism för att ändra funktionalitet under körning: Den aktuella listan över aktiverade funktioner beräknas i huvudtråden. Varje arbetstråd får sedan en skrivskyddad ögonblicksbild med hjälp av RCU-semantik.
Ersätta routtabellerFör routtabeller som tillhandahålls av RDS (Route Discovery Service) skapas routtabeller i huvudtråden. Den skrivskyddade ögonblicksbilden kommer sedan att tillhandahållas varje arbetstråd med hjälp av RCU-semantik (Read Copy Update). Detta gör att ändringar av routningstabeller är atomärt effektiva.
HTTP-header-cachning: Det visar sig att det är ganska dyrt att beräkna HTTP-headern för varje begäran (medan man kör ~25K+ RPS per kärna). Envoy beräknar centralt headern ungefär var halva sekund och skickar den till varje arbetare via TLS och RCU.

Det finns andra fall, men de föregående exemplen borde ge en god förståelse för vad TLS används till.

Kända prestandafallgropar

Även om Envoy generellt sett presterar ganska bra, finns det några kända områden som kräver uppmärksamhet när de används med mycket hög samtidighet och dataflöde:

Som beskrivs i den här artikeln låses för närvarande alla arbetstrådar när de skriver till åtkomstloggens minnesbuffert. Vid hög samtidighet och högt dataflöde måste du batcha åtkomstloggarna för varje arbetstråd på bekostnad av leverans i fel ordning när du skriver till den slutliga filen. Alternativt kan du skapa en separat åtkomstlogg för varje arbetsflöde.
Även om statistiken är starkt optimerad, kommer det vid mycket hög parallellitet och genomströmning sannolikt att finnas atomär konkurrens om individuell statistik. Lösningen på detta problem är räknare per arbetartråd med periodisk återställning av centrala räknare. Detta kommer att diskuteras i ett senare inlägg.
Den befintliga arkitekturen kommer inte att fungera bra om Envoy distribueras i ett scenario där det finns väldigt få anslutningar som kräver betydande resurser för att bearbeta. Det finns ingen garanti för att anslutningar kommer att vara jämnt fördelade mellan arbetstrådar. Detta kan lösas genom att implementera balansering av arbetaransslutningar, vilket möjliggör utbyte av anslutningar mellan arbetartrådar.

Slutsats

Envoys trådmodell är utformad för att ge enkel programmering och massiv parallellitet, på bekostnad av potentiellt slöseri med minne och anslutningar om den inte konfigureras korrekt. Denna modell gör att den presterar mycket bra vid mycket höga trådantal och genomströmning.
Som jag kort nämnde på Twitter kan designen också köras ovanpå en fullfjädrad användarlägesnätverksstack som DPDK (Data Plane Development Kit), vilket kan resultera i att vanliga servrar hanterar miljontals förfrågningar per sekund med full L7-bearbetning. Det ska bli väldigt intressant att se vad som byggs under de närmaste åren.
En sista snabb kommentar: Jag har blivit frågad många gånger varför vi valde C++ för Envoy. Anledningen är fortfarande att det fortfarande är det enda allmänt använda språket i produktionskvalitet där arkitekturen som beskrivs i det här inlägget kan byggas. C++ är definitivt inte rätt för alla eller ens många projekt, men för vissa användningsfall är det fortfarande det enda verktyget för att få jobbet gjort.