Den 26. februar holdt vi et Apache Ignite GreenSource-møde, hvor bidragydere til open source-projektet talte . En vigtig begivenhed i dette samfunds liv var omstruktureringen af komponenten , som giver dig mulighed for at implementere tilpassede mikrotjenester direkte i en Ignite-klynge. Han fortalte om denne vanskelige proces ved mødet , softwareingeniør og Apache Ignite-bidragyder i over to år.
Lad os starte med, hvad Apache Ignite er generelt. Dette er en database, der er et distribueret nøgle/værdilager med understøttelse af SQL, transaktionsevne og caching. Derudover giver Ignite dig mulighed for at implementere tilpassede tjenester direkte i en Ignite-klynge. Udvikleren har adgang til alle de værktøjer, som Ignite leverer – distribuerede datastrukturer, Messaging, Streaming, Compute og Data Grid. For eksempel, når du bruger Data Grid, forsvinder problemet med at administrere en separat infrastruktur til datalagring og som følge heraf de deraf følgende overheadomkostninger.
Ved at bruge Service Grid API kan du implementere en tjeneste ved blot at angive implementeringsskemaet og dermed selve tjenesten i konfigurationen.
Typisk er en implementeringsordning en indikation af antallet af forekomster, der skal implementeres på klynge noder. Der er to typiske implementeringsordninger. Den første er Cluster Singleton: til enhver tid er én forekomst af en brugertjeneste garanteret tilgængelig i klyngen. Den anden er Node Singleton: en forekomst af tjenesten er implementeret på hver klynge node.
Brugeren kan også angive antallet af tjenesteforekomster i hele klyngen og definere et prædikat til filtrering af egnede noder. I dette scenarie vil Service Grid selv beregne den optimale fordeling til implementering af tjenester.
Derudover er der sådan en funktion som Affinity Service. Affinitet er en funktion, der definerer forholdet mellem nøgler til partitioner og forholdet mellem parter til noder i topologien. Ved hjælp af nøglen kan du bestemme den primære node, hvorpå dataene er gemt. På denne måde kan du knytte din egen tjeneste til en nøgle- og affinitetsfunktionscache. Hvis affinitetsfunktionen ændres, vil der ske automatisk omfordeling. På denne måde vil tjenesten altid være placeret tæt på de data, den skal manipulere, og dermed reducere omkostningerne ved at få adgang til information. Denne ordning kan kaldes en slags samlokaliseret computing.
Nu hvor vi har fundet ud af, hvad skønheden ved Service Grid er, lad os tale om dets udviklingshistorie.
Hvad skete der før
Den tidligere implementering af Service Grid var baseret på Ignites transaktionelle replikerede systemcache. Ordet "cache" i Ignite refererer til opbevaring. Det vil sige, at dette ikke er noget midlertidigt, som du måske tror. På trods af at cachen er replikeret, og hver node indeholder hele datasættet, har den inde i cachen en partitioneret repræsentation. Dette skyldes lageroptimering.
Hvad skete der, da brugeren ønskede at implementere tjenesten?
- Alle noder i klyngen abonnerede på at opdatere data i lageret ved hjælp af den indbyggede Continuous Query-mekanisme.
- Den initierende node lavede under en læseforpligtet transaktion en registrering i databasen, der indeholdt tjenestekonfigurationen, inklusive den serialiserede forekomst.
- Ved besked om en ny post, beregnede koordinatoren fordelingen ud fra konfigurationen. Det resulterende objekt blev skrevet tilbage til databasen.
- Hvis en node var en del af distributionen, skulle koordinatoren implementere den.
Hvad passede os ikke
På et tidspunkt kom vi til den konklusion: det er ikke måden at arbejde med tjenester på. Der var flere grunde.
Hvis der opstod en fejl under implementeringen, kunne den kun findes ud af logfilerne på den node, hvor alting skete. Der var kun asynkron udrulning, så efter at have returneret kontrol til brugeren fra udrulningsmetoden, skulle der noget ekstra tid til at starte tjenesten – og i løbet af denne tid kunne brugeren ikke kontrollere noget. For at udvikle Service Grid yderligere, skabe nye funktioner, tiltrække nye brugere og gøre alles liv lettere, skal noget ændres.
Da vi designet det nye Service Grid, ønskede vi først og fremmest at give en garanti for synkron implementering: Så snart brugeren returnerede kontrol fra API'en, kunne han straks bruge tjenesterne. Jeg ønskede også at give initiativtageren mulighed for at håndtere implementeringsfejl.
Derudover ville jeg forenkle implementeringen, nemlig komme væk fra transaktioner og rebalancering. På trods af at cachen er replikeret, og der ikke er nogen balancering, opstod der problemer under en stor udrulning med mange noder. Når topologien ændres, skal noder udveksle information, og med en stor udrulning kan disse data veje meget.
Når topologien var ustabil, skulle koordinatoren genberegne fordelingen af tjenester. Og generelt, når du skal arbejde med transaktioner på en ustabil topologi, kan dette føre til svære at forudsige fejl.
Problemer
Hvad er globale ændringer uden medfølgende problemer? Den første af disse var en ændring i topologi. Du skal forstå, at et knudepunkt kan komme ind i eller forlade klyngen på et hvilket som helst tidspunkt, selv på tidspunktet for tjenesteimplementering. Desuden, hvis knudepunktet på tidspunktet for implementeringen slutter sig til klyngen, vil det være nødvendigt konsekvent at overføre al information om tjenesterne til den nye knude. Og vi taler ikke kun om det, der allerede er indsat, men også om nuværende og fremtidige indsættelser.
Dette er blot et af de problemer, der kan samles i en separat liste:
- Hvordan implementerer man statisk konfigurerede tjenester ved nodestart?
- At forlade en node fra klyngen - hvad skal man gøre, hvis noden hostede tjenester?
- Hvad skal man gøre, hvis koordinatoren har ændret sig?
- Hvad skal man gøre, hvis klienten genopretter forbindelse til klyngen?
- Skal aktiverings-/deaktiveringsanmodninger behandles og hvordan?
- Hvad hvis de opfordrede til destruktion af cache, og vi har affinitetstjenester knyttet til det?
Og det er ikke alt.
beslutning
Som mål valgte vi den Event Driven tilgang med implementering af proceskommunikation ved hjælp af budskaber. Ignite implementerer allerede to komponenter, der gør det muligt for noder at videresende beskeder indbyrdes - kommunikation-spi og discovery-spi.
Communication-spi tillader noder at kommunikere direkte og videresende beskeder. Den er velegnet til at sende store mængder data. Discovery-spi giver dig mulighed for at sende en besked til alle noder i klyngen. I standardimplementeringen sker dette ved hjælp af en ringtopologi. Der er også integration med Zookeeper, i dette tilfælde bruges en stjernetopologi. En anden vigtig pointe, der er værd at bemærke, er, at discovery-spi giver garantier for, at beskeden helt sikkert vil blive leveret i den rigtige rækkefølge til alle noder.
Lad os se på implementeringsprotokollen. Alle brugeranmodninger om implementering og udrulning sendes via discovery-spi. Dette giver følgende garanti:
- Anmodningen vil blive modtaget af alle noder i klyngen. Dette vil gøre det muligt for anmodningen at fortsætte behandlingen, når koordinatoren skifter. Dette betyder også, at hver node i én besked vil have alle de nødvendige metadata, såsom tjenestekonfigurationen og dens serialiserede instans.
- Streng bestilling af meddelelseslevering hjælper med at løse konfigurationskonflikter og konkurrerende anmodninger.
- Da nodens indtræden i topologien også behandles via discovery-spi, vil den nye node modtage alle de data, der er nødvendige for at arbejde med tjenester.
Når en anmodning modtages, validerer noder i klyngen den og opretter behandlingsopgaver. Disse opgaver sættes i kø og behandles derefter i en anden tråd af en separat arbejder. Det er implementeret på denne måde, fordi implementering kan tage en betydelig mængde tid og forsinke det dyre opdagelsesflow utåleligt.
Alle anmodninger fra køen behandles af implementeringsadministratoren. Den har en speciel arbejder, der trækker en opgave fra denne kø og initialiserer den for at begynde implementeringen. Herefter sker følgende handlinger:
- Hver node beregner uafhængigt fordelingen takket være en ny deterministisk tildelingsfunktion.
- Noder genererer en besked med resultaterne af implementeringen og sender den til koordinatoren.
- Koordinatoren samler alle beskeder og genererer resultatet af hele implementeringsprocessen, som sendes via discovery-spi til alle noder i klyngen.
- Når resultatet er modtaget, afsluttes implementeringsprocessen, hvorefter opgaven fjernes fra køen.
Nyt hændelsesdrevet design: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Hvis der opstår en fejl under implementeringen, inkluderer noden denne fejl straks i en meddelelse, som den sender til koordinatoren. Efter meddelelsesaggregation vil koordinatoren have information om alle fejl under implementeringen og vil sende denne meddelelse via discovery-spi. Fejloplysninger vil være tilgængelige på enhver node i klyngen.
Alle vigtige hændelser i Service Grid behandles ved hjælp af denne driftsalgoritme. For eksempel er ændring af topologi også et budskab via discovery-spi. Og generelt, sammenlignet med hvad der var før, viste protokollen sig at være ret let og pålidelig. Nok til at håndtere enhver situation under implementering.
Hvad sker der nu
Nu om planerne. Enhver større ændring af Ignite-projektet gennemføres som et Ignite-forbedringsinitiativ, kaldet en IEP. Service Grid-redesignet har også en IEP - med den hånende titel "Olieskift i servicenettet". Men faktisk skiftede vi ikke motorolien, men hele motoren.
Vi delte opgaverne i IEP op i 2 faser. Den første er en større fase, som består i at omarbejde implementeringsprotokollen. Det er allerede inkluderet i masteren, du kan prøve det nye Service Grid, som vises i version 2.8. Anden fase omfatter mange andre opgaver:
- Hot omfordeling
- Serviceversionering
- Øget fejltolerance
- Tynd klient
- Værktøjer til overvågning og beregning af forskellige metrikker
Endelig kan vi rådgive dig om Service Grid til at bygge fejltolerante systemer med høj tilgængelighed. Vi inviterer dig også til at besøge os kl и del din oplevelse. Din oplevelse er virkelig vigtig for fællesskabet; den vil hjælpe dig med at forstå, hvor du skal flytte videre, hvordan du udvikler komponenten i fremtiden.
Kilde: www.habr.com