Ci sono alcuni problemi nel post incrociato a causa del dialetto di markdown nel post originale. Soprattutto non vengono mostrati i diagrammi che esiste nel post originale. Quindi per favore controlla anche quello originale se sei interessato. Penso che quello originale sia più comprensibile

Upgrade di HBase su Event Sourcing e architettura CQRS in 3 settimane

TL;DR

• Abbiamo utilizzato una strategia di implementazione blu-verde per l'aggiornamento della versione HBase su Event Sourcing e sistema di architettura CQRS.
• L'approccio di distribuzione ha funzionato abbastanza bene e ha richiesto solo 3 settimane in totale per raggiungere l'obiettivo del progetto. Questa esperienza è stata nuova ed emozionante per noi. Quindi voglio condividerlo :)

Informazioni sull'aggiornamento del database

Un aggiornamento del database è sempre problematico e ogni volta che hai a che fare con tali circostanze in scenari di produzione saresti super nervoso (direi 100 volte rispetto ad altre operazioni di produzione con cui hai a che fare) .

Questa sensazione è difficile da condividere con persone che non hanno l'esperienza o l'esposizione nell'utilizzo degli ambienti di database. E penso che il 99,9% delle persone sarebbe d'accordo se hai l'esperienza e hai attraversato momenti difficili nell'affrontare le operazioni relative al database. È rischioso e costa molto, ma l'aggiornamento in sé non significa che fornisca nuovo valore al prodotto e anche se in molti casi non ha la priorità, a meno che non ci sia un motivo urgente.

Allo stesso tempo, è un enorme rischio nascosto se il database diventa "intoccabile" e come affrontare questo problema è stato un argomento diffuso, molti sviluppatori e operatori hanno lottato con tali situazioni

Approccio all'aggiornamento

In generale, avresti due scelte.

aggiornamento continuo

Uno è un aggiornamento continuo. Aggiornamento della versione del database uno per uno in modo sequenziale.
Ho trovato una buona spiegazione qui. Si prega di leggere questo se non si ha familiarità con la parola.

Cosa si intende per aggiornamento in sequenza nello sviluppo del software?

• Pro

  • I dati sono in un unico posto. Quindi non devi pensare a come sincronizzare i dati tra diversi cluster e come garantire che la sincronizzazione funzioni perfettamente.

• Contro

  • Una volta terminato l'aggiornamento, non esiste un modo semplice per ripristinarlo. Quindi, se l'aggiornamento provoca in qualche modo problemi di prestazioni, saresti nei guai.
  • Il database di lunga durata presenta uno stato imprevisto che non è possibile riprodurre nell'ambiente di test. A volte è necessario affrontare il problema per quanto riguarda la produzione. E questa possibilità ti rende davvero nervoso.

schieramento blu-verde

L'altro è uno schieramento blu-verde. In questo caso, è necessario eseguire il provisioning del cluster di database aggiornato separatamente e cambiare l'applicazione per utilizzare quello nuovo a un certo punto.
Controlla questo post del blog se non hai familiarità con la parola "distribuzione blu-verde".

BlueGreenDeployment

Penso che questo approccio sia diffuso nella distribuzione di applicazioni web, ma se sostituisci la parola "router" con "applicazione" e "server web" con "database", lo stesso approccio può essere applicato all'aggiornamento del database.

• Pro

  • Non si tocca il database di produzione in esecuzione durante l'aggiornamento. Ciò ti semplifica la vita rispetto all'approccio di aggiornamento progressivo.
  • Puoi ripristinare facilmente il vecchio cluster quando si verifica un problema imprevisto. E puoi anche distribuire le richieste gradualmente in modo da ridurre al minimo l'ambito in caso di problemi (per farlo, come in "Contro", devi sincronizzare i dati dal nuovo cluster al vecchio cluster)
  • Grazie al fattore di cui sopra, puoi abbreviare in qualche modo il test di carico nell'ambiente di test e puoi procedere rapidamente con il progetto.

• Contro

  • È necessario assicurarsi che i dati siano sincronizzati tra entrambi i cluster di database. Non solo dal vecchio cluster al nuovo cluster, ma anche dal nuovo cluster al vecchio cluster se si desidera avere un modo semplice per ripristinare dopo l'aggiornamento. Ma la replica reciproca dei dati è piuttosto difficile in molti casi. Può essere possibile scrivere su due cluster per ogni operazione, ma è necessario prepararsi quando un solo cluster è inattivo e l'operazione solo su quel cluster non riesce. Questa gestione sarebbe davvero complicata.
  • È necessario disporre di server di dimensioni doppie durante l'esecuzione di entrambi i cluster. Ciò costerà del denaro e può essere difficile se il tuo sistema non è su un'infrastruttura cloud.

Il nostro approccio

Fondamentalmente, il nostro approccio è la distribuzione blu-verde. E poiché abbiamo Kafka in primo piano come bus di sourcing di eventi, è stato molto più facile affrontare il problema di sincronizzazione dei dati nei "Contro" sopra elencati.

Architettura attuale

Per prima cosa, vorrei introdurre l'architettura di base. A proposito, chiamiamo l'intero sottosistema dei messaggi di chat "Falcon". Ecco perché l'icona del falco è nel diagramma.

1. quando un utente finale pubblica un messaggio di chat, write-api inserisce i dati del messaggio in Kafka
2. read-model-updater ("rmu" in breve) recupera i dati da Kafka, li converte in read-model e li inserisce in HBase
3. Quando un utente finale legge i messaggi di chat, read-api estrae i dati dei messaggi da HBase

Non spiego perché abbiamo scelto CQRS in questo post. Quindi, controlla le diapositive seguenti se vuoi sapere in dettaglio o se non hai familiarità con il concetto di CQRS.
Kafka Summit SF 2017 - Servizi di messaggistica scalabili e resilienti in tutto il mondo con Kafka e Kafka Streams
Servizi di messaggistica scalabili e resilienti in tutto il mondo di CQRS ed Event Sourcing tramite Akka, Kafka Streams e HBase

Flusso di aggiornamento del database

Ora spiegherò come abbiamo eseguito l'aggiornamento del database su questa architettura

Passaggio 1: Prepara nuovi cluster ed esegui il ripristino iniziale dal backup.

Fase 2: Preparare un altro consumatore (rmu2 in questo diagramma) per sincronizzare i dati da Kafka al nuovo cluster di database. Potrai riprodurre i vecchi eventi di Kafka a partire da prima del ripristino iniziale. Assicurati di implementare l'idempotenza sul tuo consumatore. Voglio dire, il sistema deve funzionare correttamente anche se lo stesso evento viene consumato più di una volta.

Fase 3: Quando il nuovo consumatore (rmu2) ha raggiunto gli ultimi messaggi Kafka, prepara un'altra API di lettura che estrae i dati dal nuovo cluster di database. E invia gradualmente le richieste alla nuova read-api.

Ci sarebbe una certa differenza di stato tra il vecchio cluster e il nuovo cluster anche se la sincronizzazione dei dati viene completata in un paio di millisecondi. Si è verificato un piccolo problema a causa di questa differenza, quindi è necessario confermare ed eseguire un controllo di valutazione per vedere in anticipo quale tipo di problema può essere attivato attraverso la differenza tra i cluster e la logica dell'applicazione. Oppure, se hai dei buoni livelli davanti a read-api per distribuire la richiesta in base all'attributo utente o qualcosa del genere (ad es. Routing tramite Nginx o Envoy come proxy), puoi semplicemente impostare la regola corretta lì e la differenza può essere gestita in modo efficiente e non sarà un problema.

E nella retrospettiva di questo progetto, abbiamo notato che se puoi eseguire il mirroring delle richieste dall'API esistente alla nuova API, puoi eseguire il test di carico utilizzando il traffico di produzione senza influire sugli utenti finali.

Fase 4: Passa alla nuova API di lettura al 100% e spegni i vecchi cluster e applicazioni quando sei sicuro che tutto funzioni perfettamente.

Perché penso che questo approccio sia migliore

Lascia che ti spieghi la differenza con il normale approccio blu-verde. Un problema nel normale blu-verde è che è necessario assicurarsi che i dati siano sincronizzati su entrambi i cluster, idealmente non solo prima dell'aggiornamento ma anche dopo l'aggiornamento. In questo approccio, invece di utilizzare la funzionalità di replica fornita dal database, gli aggiornamenti del database vengono applicati separatamente tramite l'applicazione che scriviamo e prepariamo. Questo approccio ci porta molti meriti.

Innanzitutto, poiché funzionano separatamente, non è necessario preoccuparsi di come i dati vengono sincronizzati in ciascuna fase. In particolare, avrai bisogno di uno sforzo aggiuntivo (e piuttosto difficile nella maggior parte dei casi) nella sincronizzazione dei dati dal nuovo cluster al vecchio cluster se desideri avere un modo semplice per ripristinare dopo l'aggiornamento. Ma in questo approccio, stanno solo lavorando in modo indipendente. Quindi puoi semplicemente tornare a utilizzare quelli vecchi nel caso in cui si verifichino problemi imprevisti dopo l'aggiornamento.

In secondo luogo, non è necessario preoccuparsi della compatibilità della versione tra i vecchi cluster e i nuovi cluster. Se si utilizza la funzionalità di sincronizzazione dei dati del cluster fornita dal database, potrebbero verificarsi alcune limitazioni di versione e problemi di compatibilità in alcuni casi limite. Ma in questo approccio, tutto ciò che devi fare è preparare un'applicazione indipendente che inserisca i dati in ogni database. Penso che sia il problema che puoi risolvere molto più facilmente nella maggior parte dei casi. E in teoria, non solo aggiornando la versione del database, ma puoi anche cambiare il nuovo cluster con uno completamente diverso (es. DynamoDB) usando lo stesso approccio. In tal caso, non è possibile utilizzare i dati di backup per la configurazione iniziale ed è necessario preparare il programma di migrazione dei dati iniziale. Ci vorrà del tempo, ma penso che sia l'elemento ragionevole da affrontare.

Conclusione

CQRS e argomenti di sourcing di eventi sono spesso discussi nell'architettura del software. Da un punto di vista operativo, avere un livello in più come bus di eventi aumenta la complessità dell'infrastruttura e i costi operativi. Onestamente parlando, non mi piaceva molto questo approccio da quel punto di vista prima. Ma abbiamo notato che cambia anche il modo in cui gestiamo l'infrastruttura e ci porta la tranquillità nel funzionamento del database. E sì, ora sono un grande divertimento di CQRS e di event sourcing :)

Prossima sfida

Potresti chiederti cosa aggiorneremmo Kafka (bus di approvvigionamento di eventi)? Sì, quella sarà la nostra prossima sfida. Spero che esista un approccio migliore rispetto al normale aggiornamento progressivo e alla distribuzione blu-verde. La vita dell'ingegnere continua!