Er zijn wat problemen met cross-posten vanwege het dialect van afwaardering in de originele post. Vooral de diagrammen worden niet getoond die in de originele post bestaan. Dus controleer ook de originele als je geïnteresseerd bent. Ik denk dat de originele begrijpelijker is

HBase-upgrade bovenop Event Sourcing en CQRS-architectuur in 3 weken

TL;DR

We gebruikten een blauw-groene implementatiestrategie voor de HBase-versie-upgrade bovenop Event Sourcing en CQRS-architectuursysteem.
De implementatie-aanpak werkte redelijk goed en duurde in totaal slechts 3 weken om het projectdoel te bereiken. Deze ervaring was nieuw en spannend voor ons. Dus ik wil het delen :)

Over database-upgrade

Een database-upgrade is altijd lastig en wanneer je met dergelijke omstandigheden in productiescenario's te maken hebt, zou je super nerveus zijn (ik zou zeggen 100 keer vergeleken met andere productieactiviteiten waarmee je te maken hebt) .

Dit gevoel is moeilijk te delen met mensen die niet de ervaring of bekendheid hebben met het bedienen van de Database-omgevingen. En ik denk dat 99,9% van de mensen het ermee eens zou zijn als je de ervaring hebt en de moeilijke tijden hebt doorgemaakt in het omgaan met de database-gerelateerde operaties. Het is riskant en het kost veel, maar de upgrade zelf betekent niet dat het nieuwe waarde aan het product geeft en hoewel het in veel gevallen geen prioriteit krijgt, tenzij er een dringende reden is.

Tegelijkertijd is het een enorm verborgen risico als de database "onaantastbaar" wordt en hoe met dit probleem om te gaan is een onderwerp waarover veel ontwikkelaars en operators worstelen met dergelijke situaties

Upgrade-aanpak

Over het algemeen heb je twee keuzes.

rollende upgrade

Een daarvan is een rollende upgrade. De databaseversie één voor één op een sequentiële manier upgraden.
Ik heb hier een goede uitleg gevonden. Lees dit alstublieft als u het woord niet kent.

Wat wordt bedoeld met een voortschrijdende upgrade in softwareontwikkeling?

Voordelen
- Gegevens staan op één plek. U hoeft dus niet na te denken over hoe u de gegevens tussen verschillende clusters kunt synchroniseren en hoe u kunt garanderen dat de synchronisatie perfect werkt.
Nadelen
- Als de upgrade eenmaal is voltooid, is er geen gemakkelijke manier om terug te keren. Dus als de upgrade op de een of andere manier prestatieproblemen veroorzaakt, zou je in grote problemen komen.
- De langlopende database heeft een onverwachte status die je niet kunt reproduceren in de testomgeving. Soms moet je het probleem oplossen als het om productie gaat. En die mogelijkheid maakt je echt nerveus.

blauw-groene implementatie

De andere is een blauwgroene implementatie. In dit geval moet u het bijgewerkte databasecluster afzonderlijk inrichten en de toepassing op een bepaald moment overschakelen om de nieuwe te gebruiken.
Lees deze blogpost als je niet bekend bent met het woord "blauw-groene implementatie".

BlueGreenDeployment

Ik denk dat deze benadering wijdverbreid is in de implementatie van webapplicaties, maar als je het woord "router" vervangt door "applicatie" en "webserver" door "database", kan dezelfde benadering worden toegepast op database-upgrades.

Voordelen
- Je raakt de lopende productiedatabase niet aan tijdens het upgraden. Dat maakt je leven een stuk gemakkelijker in vergelijking met de doorlopende upgrade-aanpak.
- Je kunt gemakkelijk terugkeren naar het oude cluster als er een onverwacht probleem optreedt. En u kunt de verzoeken ook geleidelijk distribueren, zodat u het bereik kunt minimaliseren voor het geval u een probleem ondervindt (hiervoor moet u, zoals in "Nadelen", echter gegevens synchroniseren van een nieuw cluster naar een oud cluster)
- Vanwege de bovenstaande factor kunt u het testen van de belasting op de testomgeving enigszins verkorten en kunt u snel doorgaan met het project.
nadelen
- U moet ervoor zorgen dat de gegevens tussen beide databaseclusters worden gesynchroniseerd. Niet alleen van het oude cluster naar het nieuwe cluster, maar ook van het nieuwe cluster naar het oude cluster als je na de upgrade op een gemakkelijke manier terug wilt kunnen keren. Maar onderlinge gegevensreplicatie is in veel gevallen best lastig. Het kan mogelijk zijn om bij elke bewerking naar twee clusters te schrijven, maar u moet zich voorbereiden wanneer slechts één cluster niet beschikbaar is en de bewerking naar alleen dat cluster is mislukt. Die afhandeling zou heel ingewikkeld zijn.
- U moet servers met een dubbele grootte hebben terwijl u beide clusters uitvoert. Dat kost wat geld en kan lastig zijn als je systeem niet op een cloudinfrastructuur staat.

Onze aanpak

Kortom, onze aanpak is blauw-groen inzetten. En omdat we Kafka vooraan hebben als event sourcing-bus, was het veel gemakkelijker om het probleem met de gegevenssynchronisatie in "Nadelen" hierboven op te lossen.

Huidige architectuur

Laat me eerst de basisarchitectuur introduceren. Trouwens, we noemen het hele subsysteem voor chatberichten "Falcon". Daarom staat het valkpictogram in het diagram.

wanneer een eindgebruiker een chatbericht plaatst, plaatst write-api berichtgegevens in Kafka
read-model-updater ("rmu" in het kort) haalt gegevens op van Kafka, converteert deze naar read-model en zet deze in HBase
wanneer een eindgebruiker chatberichten leest, haalt read-api berichtgegevens uit HBase

Ik leg in dit bericht niet uit waarom we voor CQRS kiezen. Bekijk daarom onderstaande slides als je hier meer over wilt weten of als je niet bekend bent met het concept van CQRS.
Kafka Summit SF 2017 - Wereldwijd schaalbare en veerkrachtige berichtenservices met Kafka- en Kafka-streams
Wereldwijd schaalbare en veerkrachtige berichtenservices door CQRS en Event Sourcing met behulp van Akka, Kafka Streams en HBase

Database-upgradestroom

Nu ga ik uitleggen hoe we de database-upgrade hebben uitgevoerd bovenop deze architectuur

Stap1: Bereid nieuwe clusters voor en voer een eerste herstel uit vanaf een back-up.

Stap 2: Bereid een andere consument (rmu2 in dit diagram) voor om gegevens van Kafka naar een nieuw databasecluster te synchroniseren. Je speelt oude Kafka-gebeurtenissen opnieuw vanaf vóór de oorspronkelijke herstelperiode. Zorg ervoor dat u idempotency implementeert op uw consument. Ik bedoel, het systeem moet goed werken, zelfs als hetzelfde evenement meer dan eens wordt gebruikt.

Stap 3: Wanneer de nieuwe consument (rmu2) de laatste Kafka-berichten heeft ingehaald, bereidt u nog een read-api voor om gegevens uit het nieuwe databasecluster te halen. En stuur verzoeken geleidelijk naar nieuwe read-api.

Er zou een staatsverschil zijn tussen het oude cluster en het nieuwe cluster, zelfs als de gegevenssynchronisatie binnen een paar milliseconden is voltooid. We hadden een klein probleem vanwege dit verschil, dus u moet vooraf bevestigen en een beoordelingscontrole uitvoeren om te zien welk soort probleem kan worden veroorzaakt door het verschil tussen clusters en uw toepassingslogica. Of als je een aantal goede lagen voor read-api hebt om het verzoek te distribueren volgens gebruikersattribuut of zoiets (bijvoorbeeld routering via Nginx of Envoy zoals proxy), kun je daar gewoon de juiste regel instellen en het verschil kan efficiënt worden afgehandeld en het zal geen probleem zijn.

En in de terugblik op dit project merkten we dat als je de verzoeken van de bestaande api naar de nieuwe api kunt spiegelen, je de belastingstest kunt doen met productieverkeer zonder dat dit gevolgen heeft voor de eindgebruikers.

Stap4: Schakel over naar de nieuwe read-api 100% en sluit oude clusters en applicaties af als je zeker weet dat alles perfect werkt.

Waarom ik denk dat deze aanpak beter is

Laat me het verschil uitleggen met de normale blauw-groene benadering. Een probleem in normaal blauw-groen is dat je ervoor moet zorgen dat gegevens op beide clusters worden gesynchroniseerd, idealiter niet alleen vóór de upgrade, maar ook na de upgrade. In deze benadering worden de database-updates, in plaats van replicatiefunctionaliteit die de database biedt, afzonderlijk toegepast via de applicatie die we schrijven en voorbereiden. Deze aanpak levert ons veel voordelen op.

Ten eerste, omdat ze afzonderlijk werken, hoeft u zich er geen zorgen over te maken hoe gegevens in elke fase worden gesynchroniseerd. Vooral, je zult wat extra (en in de meeste gevallen behoorlijk zware) inspanningen nodig hebben bij het synchroniseren van gegevens van een nieuw cluster naar het oude cluster als je een gemakkelijke manier wilt hebben om terug te keren na de upgrade. Maar in deze benadering werken ze gewoon onafhankelijk. U kunt dus gewoon teruggaan naar het gebruik van oude voor het geval er een onverwacht probleem optreedt na de upgrade.

Ten tweede hoeft u zich geen zorgen te maken over de versiecompatibiliteit tussen oude clusters en nieuwe clusters. Als u de functionaliteit voor clustergegevenssynchronisatie gebruikt die de database biedt, kan er in sommige edge-gevallen een versiebeperking en compatibiliteitsprobleem optreden. Maar bij deze benadering hoeft u alleen maar een onafhankelijke toepassing voor te bereiden die gegevens in elke database plaatst. Ik denk dat dit het probleem is dat je in de meeste gevallen veel gemakkelijker kunt oplossen. En in theorie, niet alleen het bijwerken van de databaseversie, maar u kunt het nieuwe cluster ook overschakelen naar een geheel ander (bijv. DynamoDB) met dezelfde aanpak. In dat geval kunt u de back-upgegevens niet gebruiken voor de eerste configuratie en moet u het eerste gegevensmigratieprogramma voorbereiden. Dat zal wat tijd kosten, maar ik denk dat dit het redelijke punt is om mee om te gaan.

Conclusie

CQRS en event sourcing onderwerpen worden vaak besproken in software architectuur. Vanuit operationeel oogpunt verhoogt het hebben van een extra laag als evenementenbus de complexiteit van de infrastructuur en de operationele kosten. Eerlijk gezegd vond ik deze aanpak voorheen niet zo leuk vanuit die optiek. Maar we merkten dat het ook de manier waarop we de infrastructuur exploiteren verandert en ons de rust brengt in het databasebeheer. En ja, ik ben nu een groot plezier in CQRS en event sourcing :)

Volgende uitdaging

Je vraagt je misschien af wat we Kafka (event sourcing bus) zouden upgraden? Ja, dat wordt onze volgende uitdaging. Ik hoop dat er een betere aanpak bestaat dan de normale voortschrijdende upgrade en blauwgroene implementatie. Het leven van een ingenieur gaat door!