26. februar holdt vi et Apache Ignite GreenSource-møte, hvor bidragsytere til åpen kildekode-prosjektet snakket . En viktig begivenhet i livet til dette samfunnet var omstruktureringen av komponenten , som lar deg distribuere tilpassede mikrotjenester direkte i en Ignite-klynge. Han snakket om denne vanskelige prosessen på møtet , programvareingeniør og Apache Ignite-bidragsyter i over to år.
La oss starte med hva Apache Ignite er generelt. Dette er en database som er en distribuert nøkkel/verdilagring med støtte for SQL, transaksjonalitet og caching. I tillegg lar Ignite deg distribuere tilpassede tjenester direkte inn i en Ignite-klynge. Utvikleren har tilgang til alle verktøyene som Ignite leverer – distribuerte datastrukturer, meldinger, streaming, Compute og Data Grid. For eksempel, når du bruker Data Grid, forsvinner problemet med å administrere en egen infrastruktur for datalagring og som en konsekvens de resulterende overheadkostnadene.
Ved å bruke Service Grid API kan du distribuere en tjeneste ved ganske enkelt å spesifisere distribusjonsskjemaet og følgelig selve tjenesten i konfigurasjonen.
Vanligvis er et distribusjonsskjema en indikasjon på antall forekomster som bør distribueres på klyngenoder. Det er to typiske distribusjonsordninger. Den første er Cluster Singleton: til enhver tid er en forekomst av en brukertjeneste garantert tilgjengelig i klyngen. Den andre er Node Singleton: én forekomst av tjenesten er distribuert på hver klyngennode.
Brukeren kan også spesifisere antall tjenesteforekomster i hele klyngen og definere et predikat for filtrering av egnede noder. I dette scenariet vil Service Grid selv beregne den optimale distribusjonen for distribusjon av tjenester.
I tillegg er det en funksjon som Affinity Service. Affinitet er en funksjon som definerer forholdet mellom nøkler til partisjoner og forholdet mellom partier og noder i topologien. Ved hjelp av nøkkelen kan du bestemme den primære noden som dataene er lagret på. På denne måten kan du knytte din egen tjeneste til en nøkkel- og affinitetsfunksjonsbuffer. Hvis affinitetsfunksjonen endres, vil automatisk omdistribuering skje. På denne måten vil tjenesten alltid være plassert i nærheten av dataene den trenger for å manipulere, og følgelig redusere kostnadene ved tilgang til informasjon. Denne ordningen kan kalles en slags samlokalisert databehandling.
Nå som vi har funnet ut hva skjønnheten med Service Grid er, la oss snakke om utviklingshistorien.
Hva skjedde før
Den forrige implementeringen av Service Grid var basert på Ignites transaksjonsreplikerte systembuffer. Ordet "cache" i Ignite refererer til lagring. Det vil si at dette ikke er noe midlertidig, som du kanskje tror. Til tross for at cachen er replikert og hver node inneholder hele datasettet, har den en partisjonert representasjon inne i cachen. Dette er på grunn av lagringsoptimalisering.
Hva skjedde da brukeren ønsket å distribuere tjenesten?
- Alle noder i klyngen abonnerte på å oppdatere data i lagringen ved hjelp av den innebygde mekanismen for kontinuerlig spørring.
- Den initierende noden, under en leseforpliktet transaksjon, laget en post i databasen som inneholdt tjenestekonfigurasjonen, inkludert den serialiserte forekomsten.
- Når det ble varslet om en ny oppføring, beregnet koordinator fordelingen basert på konfigurasjonen. Det resulterende objektet ble skrevet tilbake til databasen.
- Hvis en node var en del av distribusjonen, måtte koordinatoren distribuere den.
Det som ikke passet oss
På et tidspunkt kom vi til konklusjonen: dette er ikke måten å jobbe med tjenester på. Det var flere grunner.
Hvis det oppstod en feil under distribusjonen, kunne det bare bli funnet ut fra loggene til noden der alt skjedde. Det var kun asynkron utrulling, så etter å ha returnert kontroll til brukeren fra distribusjonsmetoden, måtte det litt ekstra tid til for å starte tjenesten – og i løpet av denne tiden kunne ikke brukeren kontrollere noe. For å videreutvikle Service Grid, skape nye funksjoner, tiltrekke seg nye brukere og gjøre livet til alles enklere, må noe endres.
Ved utformingen av det nye tjenestenettet ønsket vi først og fremst å gi en garanti for synkron distribusjon: så snart brukeren returnerte kontrollen fra API-en, kunne han umiddelbart bruke tjenestene. Jeg ønsket også å gi initiativtakeren muligheten til å håndtere distribusjonsfeil.
I tillegg ønsket jeg å forenkle implementeringen, nemlig komme unna transaksjoner og rebalansering. Til tross for at cachen er replikert og det ikke er noen balansering, oppsto det problemer under en stor distribusjon med mange noder. Når topologien endres, må noder utveksle informasjon, og med en stor distribusjon kan disse dataene veie mye.
Når topologien var ustabil, måtte koordinatoren beregne fordelingen av tjenester på nytt. Og generelt, når du må jobbe med transaksjoner på en ustabil topologi, kan dette føre til vanskelige å forutsi feil.
Problemer
Hva er globale endringer uten medfølgende problemer? Den første av disse var en endring i topologi. Du må forstå at når som helst, selv i øyeblikket av tjenestedistribusjon, kan en node gå inn eller ut av klyngen. Videre, hvis noden blir med i klyngen på tidspunktet for distribusjon, vil det være nødvendig å konsekvent overføre all informasjon om tjenestene til den nye noden. Og vi snakker ikke bare om det som allerede er utplassert, men også om nåværende og fremtidige utplasseringer.
Dette er bare ett av problemene som kan samles i en egen liste:
- Hvordan distribuere statisk konfigurerte tjenester ved nodeoppstart?
- Forlate en node fra klyngen - hva skal jeg gjøre hvis noden er vert for tjenester?
- Hva skal jeg gjøre hvis koordinatoren har endret seg?
- Hva skal jeg gjøre hvis klienten kobler til klyngen på nytt?
- Må forespørsler om aktivering/deaktivering behandles og hvordan?
- Hva om de ba om destruksjon av cache, og vi har tilknytningstjenester knyttet til det?
Og det er ikke alt.
beslutning
Som et mål valgte vi den hendelsesdrevne tilnærmingen med implementering av prosesskommunikasjon ved hjelp av meldinger. Ignite implementerer allerede to komponenter som lar noder videresende meldinger seg imellom - kommunikasjon-spi og oppdagelse-spi.
Communication-spi lar noder kommunisere direkte og videresende meldinger. Den egner seg godt til å sende store datamengder. Discovery-spi lar deg sende en melding til alle noder i klyngen. I standardimplementeringen gjøres dette ved hjelp av en ringtopologi. Det er også integrasjon med Zookeeper, i dette tilfellet brukes en stjernetopologi. Et annet viktig poeng som er verdt å merke seg er at discovery-spi gir garantier for at meldingen definitivt vil bli levert i riktig rekkefølge til alle noder.
La oss se på distribusjonsprotokollen. Alle brukerforespørsler om distribusjon og avinstallering sendes via discovery-spi. Dette gir følgende garanti:
- Forespørselen vil bli mottatt av alle noder i klyngen. Dette gjør at forespørselen kan fortsette behandlingen når koordinatoren endres. Dette betyr også at i én melding vil hver node ha alle nødvendige metadata, for eksempel tjenestekonfigurasjonen og dens serialiserte forekomst.
- Streng bestilling av meldingslevering hjelper til med å løse konfigurasjonskonflikter og konkurrerende forespørsler.
- Siden nodens inntreden i topologien også behandles via discovery-spi, vil den nye noden motta all data som er nødvendig for å jobbe med tjenester.
Når en forespørsel mottas, validerer noder i klyngen den og oppretter behandlingsoppgaver. Disse oppgavene settes i kø og behandles deretter i en annen tråd av en separat arbeider. Det implementeres på denne måten fordi distribusjon kan ta betydelig tid og forsinke den dyre oppdagelsesstrømmen på en utålelig måte.
Alle forespørsler fra køen behandles av distribusjonslederen. Den har en spesiell arbeider som henter en oppgave fra denne køen og initialiserer den for å starte distribusjonen. Etter dette skjer følgende handlinger:
- Hver node beregner distribusjonen uavhengig takket være en ny deterministisk tilordningsfunksjon.
- Noder genererer en melding med resultatene av distribusjonen og sender den til koordinatoren.
- Koordinatoren samler alle meldinger og genererer resultatet av hele distribusjonsprosessen, som sendes via discovery-spi til alle noder i klyngen.
- Når resultatet er mottatt, avsluttes distribusjonsprosessen, hvoretter oppgaven fjernes fra køen.
Ny hendelsesdrevet design: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Hvis det oppstår en feil under distribusjon, inkluderer noden umiddelbart denne feilen i en melding som den sender til koordinatoren. Etter aggregering av meldinger vil koordinatoren ha informasjon om alle feil under distribusjon og vil sende denne meldingen via discovery-spi. Feilinformasjon vil være tilgjengelig på alle noder i klyngen.
Alle viktige hendelser i tjenestenettet behandles ved hjelp av denne driftsalgoritmen. For eksempel er endring av topologi også en melding via discovery-spi. Og generelt sett, sammenlignet med det som var før, viste protokollen seg å være ganske lett og pålitelig. Nok til å håndtere enhver situasjon under distribusjon.
Hva vil skje videre
Nå om planene. Enhver større endring i Ignite-prosjektet fullføres som et Ignite-forbedringsinitiativ, kalt en IEP. Service Grid redesign har også en IEP - med den hånende tittelen «Oljeskifte i servicenettet». Men faktisk byttet vi ikke motoroljen, men hele motoren.
Vi delte opp oppgavene i IEP i 2 faser. Den første er en hovedfase, som består av omarbeiding av distribusjonsprotokollen. Det er allerede inkludert i masteren, du kan prøve det nye Service Grid, som vil vises i versjon 2.8. Den andre fasen inkluderer mange andre oppgaver:
- Hot omplassering
- Tjenesteversjon
- Økt feiltoleranse
- Tynn klient
- Verktøy for overvåking og beregning av ulike beregninger
Til slutt kan vi gi deg råd om Service Grid for å bygge feiltolerante systemer med høy tilgjengelighet. Vi inviterer deg også til å besøke oss kl и del din erfaring. Din erfaring er veldig viktig for fellesskapet; det vil hjelpe deg å forstå hvor du skal flytte videre, hvordan du kan utvikle komponenten i fremtiden.
Kilde: www.habr.com