Der er nogle problemer med krydspostering på grund af markdown-dialekten i det originale indlæg. Især diagrammerne er ikke vist, som findes i det originale indlæg. Så tjek også den originale, hvis du er interesseret. Jeg synes, den originale er mere forståelig

HBase-opgradering oven på Event Sourcing og CQRS-arkitektur om 3 uger

TL;DR

• Vi brugte en blå-grøn implementeringsstrategi til HBase-versionsopgraderingen oven på Event Sourcing og CQRS-arkitektursystemet.
• Implementeringstilgangen fungerede ganske godt og tog kun 3 uger i alt at nå projektets mål. Denne oplevelse var ny og spændende for os. Så jeg vil gerne dele det :)

Om databaseopgradering

En databaseopgradering er altid besværlig, og når du har at gøre med sådanne omstændigheder i produktionsscenarier, ville du være super nervøs (jeg vil sige 100 gange sammenlignet med andre produktionsoperationer, som du har at gøre med) .

Denne følelse er svær at dele med folk, der ikke har erfaringen eller eksponeringen i driften af ​​databasemiljøerne. Og jeg tror, ​​at 99,9% af folk ville være enige, hvis du har erfaringen og har gennemgået de hårde tider med at håndtere de databaserelaterede operationer. Det er risikabelt, og det koster meget, men selve opgraderingen betyder ikke, at det giver ny værdi til produktet, og selvom det i mange tilfælde ikke er prioriteret, medmindre der er en presserende grund.

Samtidig er det en enorm skjult risiko, hvis databasen bliver "urørlig", og hvordan man håndterer dette problem har været et emne på tværs, mange udviklere og operatører har kæmpet med sådanne situationer

Opgraderingstilgang

Generelt har du to valgmuligheder.

rullende opgradering

Den ene er en rullende opgradering. Opgradering af databaseversionen én efter én på en sekventiel måde.
Jeg fandt en god forklaring her. Læs venligst dette, hvis du ikke er bekendt med ordet.

Hvad menes der med en rullende opgradering i softwareudvikling?

• Fordele

  • Data er samlet ét sted. Så du behøver ikke tænke på, hvordan du synkroniserer data mellem forskellige klynger, og hvordan du garanterer, at synkroniseringen fungerer perfekt.

• Ulemper

  • Når opgraderingen er færdig, er der ingen nem måde at vende tilbage. Så hvis opgraderingen udløser ydeevneproblemer på en eller anden måde, ville du være i store problemer.
  • Den langvarige database har en eller anden uventet tilstand, som du ikke kan gengive i testmiljøet. Nogle gange har du brug for at håndtere problemet, når det kommer til produktion. Og den mulighed gør dig virkelig nervøs.

blå-grøn implementering

Den anden er en blå-grøn indsættelse. I dette tilfælde skal du klargøre den opgraderede databaseklynge separat og skifte applikationen til at bruge den nye på et tidspunkt.
Tjek venligst dette blogindlæg, hvis du ikke er bekendt med ordet "blå-grøn implementering".

BlueGreenDeployment

Jeg tror, ​​at denne tilgang er udbredt i webapplikationsimplementering, men hvis du erstatter ordet "router" til "applikation" og "webserver" til "database", kan den samme tilgang anvendes til databaseopgradering.

• Fordele

  • Du rører ikke den kørende produktionsdatabase, mens du opgraderer. Det gør dit liv meget nemt sammenlignet med en rullende opgraderingstilgang.
  • Du kan nemt vende tilbage til den gamle klynge, når der opstår et uventet problem. Og du kan også distribuere anmodningerne gradvist, så du kan minimere omfanget i tilfælde af, at du har nogle problemer (For at gøre dette, som i "Ideles", skal du dog synkronisere data fra ny klynge til gammel klynge)
  • På grund af faktoren ovenfor kan du forkorte belastningstesten på testmiljøet noget og kan hurtigt fortsætte med projektet.

• Ulemper

  • Du skal sikre dig, at data er synkroniseret mellem begge databaseklynger. Ikke kun fra gammel klynge til den nye klynge, men også fra ny klynge til gammel klynge, hvis du vil have en nem måde at vende tilbage efter opgraderingen. Men gensidig datareplikering er ret vanskelig i mange tilfælde. Det kan være muligt at skrive til to klynger ved hver operation, men du skal forberede dig, når kun én klynge er nede, og kun operationen til den klynge mislykkedes. Den håndtering ville være virkelig kompliceret.
  • Du skal have dobbeltstore servere, mens du kører begge klynger. Det vil koste nogle penge og kan være svært, hvis dit system ikke er på cloud-infrastruktur.

Vores tilgang

Grundlæggende er vores tilgang blå-grøn implementering. Og fordi vi har Kafka foran som event sourcing bus, var det meget nemmere at håndtere datasynkroniseringsproblemet i "Ideles" angivet ovenfor.

Nuværende arkitektur

Lad mig først introducere den grundlæggende arkitektur. Btw, vi kalder hele chatbesked-undersystemet "Falcon". Det er derfor, falkeikonet er i diagrammet.

1. når en slutbruger sender en chatbesked, lægger write-api beskeddata ind i Kafka
2. read-model-updater ("rmu" kort fortalt) henter data fra Kafka, konverterer dem til read-model og sætter dem i HBase
3. når en slutbruger læser chatbeskeder, læs-api trække beskeddata fra HBase

Jeg forklarer ikke, hvorfor vi vælger CQRS i dette indlæg. Så tjek venligst slides nedenfor, hvis du vil vide mere detaljeret, eller hvis du ikke er bekendt med konceptet CQRS.
Kafka Summit SF 2017 - Verdensomspændende skalerbare og modstandsdygtige meddelelsestjenester med Kafka- og Kafka-streams
Worldwide Scalable and Resilient Messaging Services af CQRS og Event Sourcing ved hjælp af Akka, Kafka Streams og HBase

Databaseopgraderingsforløb

Nu vil jeg forklare, hvordan vi lavede databaseopgraderingen oven på denne arkitektur

Trin 1: Forbered nye klynger og foretag indledende gendannelse fra backup.

Trin 2: Forbered en anden forbruger (rmu2 i dette diagram) til at synkronisere data fra Kafka til en ny databaseklynge. Du vil genafspille gamle Kafka-begivenheder fra før den første gendannelse. Sørg for at implementere idempotens på din forbruger. Jeg mener, systemet skal fungere korrekt, selvom den samme hændelse forbruges mere end én gang.

Trin 3: Når den nye forbruger(rmu2) har indhentet de seneste Kafka-beskeder, skal du forberede endnu en read-api, der trækker data fra den nye databaseklynge. Og send anmodninger til nye læse-api gradvist.

Der ville være en vis tilstandsforskel mellem den gamle klynge og den nye klynge, selvom datasynkronisering er færdig på et par millisekunder. Vi havde et lille problem på grund af denne forskel, så du skal bekræfte og køre et vurderingstjek på forhånd for at se, hvilken slags problem der kan udløses gennem forskellen mellem klynger og din applikationslogik. Eller hvis du har nogle gode lag foran read-api til at distribuere anmodningen i henhold til brugerattribut eller noget (f.eks. routing via Nginx eller Envoy lignende proxy), kan du bare sætte den rigtige regel derinde, og forskellen kan håndteres effektivt og det vil ikke være et problem.

Og i retrospektiv af dette projekt bemærkede vi, at hvis du kan spejle anmodningerne fra eksisterende api til nye api, kan du udføre belastningstesten ved hjælp af produktionstrafik uden at påvirke slutbrugerne.

Trin 4: Skift til ny læse-API 100% og luk gamle klynger og applikationer ned, når du er sikker på, at alt fungerer perfekt.

Hvorfor jeg synes, denne tilgang er bedre

Lad mig forklare forskellen med den normale blå-grønne tilgang. Et problem i normal blå-grøn er, at du skal sikre dig, at data er synkroniseret på begge klynger, ideelt set ikke kun før opgraderingen, men også efter opgraderingen. I denne tilgang, i stedet for at bruge replikeringsfunktionalitet, som databasen tilbyder, anvendes databaseopdateringerne separat via den applikation, som vi skriver og forbereder. Denne tilgang giver os mange fordele.

For det første, fordi de arbejder separat, behøver du ikke at bekymre dig om, hvordan data synkroniseres på hver fase. Især har du brug for en ekstra (og ret hård i de fleste tilfælde) indsats for at synkronisere data fra den nye klynge til den gamle klynge, hvis du vil have en nem måde at vende tilbage efter opgraderingen. Men i denne tilgang arbejder de bare uafhængigt. Så du kan bare vende tilbage til at bruge gamle, hvis der opstår et uventet problem efter opgraderingen.

For det andet behøver du ikke bekymre dig om versionskompatibiliteten mellem gamle klynger og nye klynger. Hvis du bruger klyngedatasynkroniseringsfunktionalitet, som databasen tilbyder, ville der være nogle versionsbegrænsninger og kompatibilitetsproblemer, der kan opstå i nogle edge-tilfælde. Men i denne tilgang er alt hvad du skal gøre at forberede en uafhængig applikation, som lægger data ind i hver database. Jeg tror, ​​det er det problem, du kan løse meget nemmere i de fleste tilfælde. Og i teorien kan du ikke kun opdatere databaseversionen, men du kan også skifte den nye klynge til en helt anden (f.eks. DynamoDB) ved at bruge den samme tilgang. I så fald kan du ikke bruge sikkerhedskopieringsdataene til indledende opsætning og skal forberede et indledende datamigreringsprogram. Det vil tage noget tid, men jeg synes, det er en rimelig ting at tage sig af.

Konklusion

CQRS og event sourcing emner diskuteres ofte i softwarearkitektur. Fra et operationelt synspunkt øger det at have et lag mere som hændelsesbus infrastrukturens kompleksitet og driftsomkostninger. Ærligt talt kunne jeg ikke lide denne tilgang så meget fra det synspunkt før. Men vi bemærkede, at det også ændrer, hvordan vi driver infrastrukturen og giver os freden i databasedriften. Og ja, jeg er enormt sjov med CQRS og event sourcing nu :)

Næste udfordring

Du spekulerer måske på, hvad vi ville opgradere Kafka (event sourcing bus)? Ja, det bliver vores næste udfordring. Jeg håber, der findes en bedre tilgang end normal rullende opgradering og blå-grøn implementering. Ingeniørlivet fortsætter!