Den 26 februari höll vi ett Apache Ignite GreenSource-möte, där bidragsgivare till open source-projektet talade . En viktig händelse i samhällets liv var omstruktureringen av komponenten , som låter dig distribuera anpassade mikrotjänster direkt i ett Ignite-kluster. Han berättade om denna svåra process på mötet , mjukvaruingenjör och Apache Ignite-bidragsgivare i över två år.
Låt oss börja med vad Apache Ignite är i allmänhet. Detta är en databas som är en distribuerad nyckel/värdelagring med stöd för SQL, transaktionsförmåga och caching. Dessutom låter Ignite dig distribuera anpassade tjänster direkt i ett Ignite-kluster. Utvecklaren har tillgång till alla verktyg som Ignite tillhandahåller – distribuerade datastrukturer, Messaging, Streaming, Compute och Data Grid. Till exempel, när man använder Data Grid, försvinner problemet med att administrera en separat infrastruktur för datalagring och, som en följd av detta, de resulterande overheadkostnaderna.
Med hjälp av Service Grid API kan du distribuera en tjänst genom att helt enkelt ange distributionsschemat och följaktligen själva tjänsten i konfigurationen.
Vanligtvis är ett distributionsschema en indikation på antalet instanser som ska distribueras på klusternoder. Det finns två typiska distributionsscheman. Den första är Cluster Singleton: vid varje given tidpunkt är en instans av en användartjänst garanterat tillgänglig i klustret. Den andra är Node Singleton: en instans av tjänsten distribueras på varje klusternod.
Användaren kan också specificera antalet tjänsteinstanser i hela klustret och definiera ett predikat för filtrering av lämpliga noder. I det här scenariot kommer Service Grid själv att beräkna den optimala distributionen för att distribuera tjänster.
Dessutom finns det en sådan funktion som Affinity Service. Affinitet är en funktion som definierar förhållandet mellan nycklar till partitioner och förhållandet mellan partier och noder i topologin. Med hjälp av nyckeln kan du bestämma den primära noden där data lagras. På så sätt kan du associera din egen tjänst med en nyckel- och affinitetsfunktionscache. Om affinitetsfunktionen ändras kommer automatisk omdistribuering att ske. På så sätt kommer tjänsten alltid att vara placerad nära den data som den behöver för att manipulera, och följaktligen minska omkostnader för att komma åt information. Detta schema kan kallas en sorts samlokaliserad beräkning.
Nu när vi har tagit reda på vad skönheten med Service Grid är, låt oss prata om dess utvecklingshistoria.
Vad hände innan
Den tidigare implementeringen av Service Grid baserades på Ignites transaktionsreplikerade systemcache. Ordet "cache" i Ignite syftar på lagring. Det vill säga, det här är inget tillfälligt, som man kanske tror. Trots det faktum att cachen är replikerad och varje nod innehåller hela datamängden, har den inuti cachen en partitionerad representation. Detta beror på lagringsoptimering.
Vad hände när användaren ville distribuera tjänsten?
- Alla noder i klustret prenumererade på att uppdatera data i lagringen med den inbyggda mekanismen för kontinuerlig fråga.
- Den initierande noden, under en läsbeslutad transaktion, gjorde en post i databasen som innehöll tjänstekonfigurationen, inklusive den serialiserade instansen.
- Vid meddelande om en ny post beräknade samordnaren fördelningen baserat på konfigurationen. Det resulterande objektet skrevs tillbaka till databasen.
- Om en nod var en del av distributionen var koordinatorn tvungen att distribuera den.
Det som inte passade oss
Vid något tillfälle kom vi fram till slutsatsen: det är inte så man arbetar med tjänster. Det fanns flera skäl.
Om något fel inträffade under driftsättningen kunde det bara hittas från loggarna för den nod där allt hände. Det fanns bara asynkron driftsättning, så efter att ha återfört kontrollen till användaren från distributionsmetoden behövdes ytterligare tid för att starta tjänsten – och under denna tid kunde användaren inte kontrollera någonting. För att utveckla Service Grid ytterligare, skapa nya funktioner, attrahera nya användare och göra allas liv enklare behöver något förändras.
När vi designade det nya Service Grid ville vi först och främst ge en garanti för synkron distribution: så snart användaren återvände kontrollen från API:t kunde han omedelbart använda tjänsterna. Jag ville också ge initiativtagaren förmågan att hantera driftsättningsfel.
Dessutom ville jag förenkla implementeringen, nämligen komma bort från transaktioner och ombalansering. Trots att cachen är replikerad och det inte finns någon balansering uppstod problem under en stor utplacering med många noder. När topologin ändras behöver noder utbyta information, och med en stor utbyggnad kan denna data väga mycket.
När topologin var instabil behövde koordinatorn räkna om fördelningen av tjänster. Och i allmänhet, när du måste arbeta med transaktioner på en instabil topologi, kan detta leda till svårförutsägbara fel.
Problem
Vad är globala förändringar utan åtföljande problem? Den första av dessa var en förändring i topologi. Du måste förstå att när som helst, till och med vid tjänsteimplementeringen, kan en nod komma in i eller lämna klustret. Dessutom, om noden ansluter sig till klustret vid tidpunkten för driftsättning, kommer det att vara nödvändigt att konsekvent överföra all information om tjänsterna till den nya noden. Och vi talar inte bara om det som redan har satts in, utan också om nuvarande och framtida insatser.
Detta är bara ett av problemen som kan samlas i en separat lista:
- Hur distribuerar man statiskt konfigurerade tjänster vid nodstart?
- Lämna en nod från klustret - vad ska man göra om noden är värd för tjänster?
- Vad ska man göra om samordnaren har ändrats?
- Vad ska man göra om klienten återansluter till klustret?
- Behöver förfrågningar om aktivering/avaktivering behandlas och hur?
- Tänk om de uppmanade till förstörelse av cache och vi har affinitetstjänster kopplade till det?
Och det är inte allt.
beslutet
Som mål valde vi det händelsedrivna tillvägagångssättet med implementering av processkommunikation med hjälp av meddelanden. Ignite implementerar redan två komponenter som tillåter noder att vidarebefordra meddelanden sinsemellan - kommunikation-spi och upptäckt-spi.
Communication-spi tillåter noder att kommunicera direkt och vidarebefordra meddelanden. Den är väl lämpad för att skicka stora datamängder. Discovery-spi låter dig skicka ett meddelande till alla noder i klustret. I standardimplementeringen görs detta med en ringtopologi. Det finns även integration med Zookeeper, i detta fall används en stjärntopologi. En annan viktig punkt värd att notera är att discovery-spi ger garantier för att meddelandet definitivt kommer att levereras i rätt ordning till alla noder.
Låt oss titta på distributionsprotokollet. Alla användarförfrågningar för implementering och avinstallation skickas via Discovery-spi. Detta ger följande garantier:
- Begäran kommer att tas emot av alla noder i klustret. Detta gör att begäran kan fortsätta att behandlas när samordnaren ändras. Detta innebär också att i ett meddelande kommer varje nod att ha all nödvändig metadata, såsom tjänstens konfiguration och dess serialiserade instans.
- Strikt ordning på meddelandeleverans hjälper till att lösa konfigurationskonflikter och konkurrerande förfrågningar.
- Eftersom nodens inträde i topologin också bearbetas via discovery-spi, kommer den nya noden att ta emot all data som behövs för att arbeta med tjänster.
När en begäran tas emot validerar noder i klustret den och skapar bearbetningsuppgifter. Dessa uppgifter köas och bearbetas sedan i en annan tråd av en separat arbetare. Det implementeras på detta sätt eftersom implementeringen kan ta en betydande tid och försena det dyra upptäcktsflödet oacceptabelt.
Alla förfrågningar från kön behandlas av distributionshanteraren. Den har en speciell arbetare som hämtar en uppgift från den här kön och initierar den för att påbörja driftsättningen. Efter detta inträffar följande åtgärder:
- Varje nod beräknar fördelningen oberoende tack vare en ny deterministisk tilldelningsfunktion.
- Noder genererar ett meddelande med resultaten av driftsättningen och skickar det till samordnaren.
- Samordnaren aggregerar alla meddelanden och genererar resultatet av hela distributionsprocessen, som skickas via discovery-spi till alla noder i klustret.
- När resultatet tas emot avslutas distributionsprocessen, varefter uppgiften tas bort från kön.
Ny händelsedriven design: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Om ett fel uppstår under driftsättning, inkluderar noden omedelbart detta fel i ett meddelande som den skickar till koordinatorn. Efter meddelandeaggregering kommer samordnaren att ha information om alla fel under driftsättningen och skickar detta meddelande via discovery-spi. Felinformation kommer att finnas tillgänglig på alla noder i klustret.
Alla viktiga händelser i Service Grid bearbetas med denna driftalgoritm. Att ändra topologin är till exempel också ett meddelande via discovery-spi. Och i allmänhet, jämfört med vad som var tidigare, visade sig protokollet vara ganska lätt och pålitligt. Tillräckligt för att hantera alla situationer under driftsättning.
Vad kommer hända härnäst
Nu om planerna. Alla större förändringar av Ignite-projektet genomförs som ett Ignite-förbättringsinitiativ, kallat IEP. Service Grid redesign har också en IEP - med den hånfulla titeln "Oljebyte i servicenätet". Men i själva verket bytte vi inte motoroljan, utan hela motorn.
Vi delade in uppgifterna i IEP i 2 faser. Den första är en stor fas, som består av omarbetning av distributionsprotokollet. Det är redan inkluderat i mastern, du kan prova det nya Service Grid, som kommer att dyka upp i version 2.8. Den andra fasen innehåller många andra uppgifter:
- Hot omdistribuera
- Serviceversionering
- Ökad feltolerans
- Tunn klient
- Verktyg för att övervaka och beräkna olika mått
Slutligen kan vi ge dig råd om Service Grid för att bygga feltoleranta system med hög tillgänglighet. Vi inbjuder dig också att besöka oss kl и dela din erfarenhet. Din erfarenhet är verkligen viktig för samhället, det kommer att hjälpa dig att förstå var du ska flytta härnäst, hur du utvecklar komponenten i framtiden.
Källa: will.com