Strategia di migrazione dei DB per i container docker in AWS ECS

Question

Strategia di migrazione dei DB per i container docker in AWS ECS

#1 da (3 voti)
#2 da (1 voti)

7

Sto lavorando alla creazione di un set di microservizi in Docker (utilizzando .net core e AWS RDS come backbone, ma non è rilevante).

Come parte della distribuzione, il vecchio contenitore e il nuovo contenitore coesistono per un breve periodo di tempo (in genere meno di 30 secondi) per garantire che non vi siano tempi di inattività.

Tuttavia, questo significa che se il mio schema non è compatibile con la versione precedente del microservice (o il vecchio schema non è compatibile con la nuova versione), un set di contenitori non funzionerà correttamente.

I miei pensieri sono:

Solo migrazioni compatibili con le versioni precedenti. Significa che non ci sono% di migrazioni% co_de. Non sono impressionato da questo approccio in quanto porterebbe ad accumulare un po 'di confusione (garantito, con la dimensione del microservizio non sarà troppo male, ma sarà uno schema sgradevole in un paio di anni)
Obsoleto: rimuove le distribuzioni in due passaggi. Il significato in v2 rimuove il codice che consuma lo schema, ma non lo schema stesso e in v3 rimuoviamo lo schema. Il problema qui è che dobbiamo eseguire due distribuzioni consecutivi di fila, il che sembra stupido, o assicurarci che gli sviluppatori ricordino di effettuare il check-in di quelle rimozioni nella prossima versione, che è potenzialmente soggetta ad errori umani e si ripercuoterà in altro modo
Sono disponibili due tipi di distribuzione: interruzione e interruzione; con la rottura dello schieramento facendo il vecchio servizio di stop della scuola, migrare, portare un nuovo servizio. Il problema qui è che ci sono tempi di inattività per gli utenti finali.

Con cosa andresti e perché? (o, se hai già qualcos'altro, per favore dillo).

database microservices aws

posta zaitsman 24.09.2017 - 01:27

fonte

2 risposte

1

Qual è il tuo "budget di errore"? cioè quanto tempo di fermo puoi permetterti di avere e rimanere nello SLA concordato? Se il tempo di attività del tuo SLA è del 99,95% e il tuo servizio è al 99,999%, puoi farlo.
Se ci sono 30 secondi di inattività, quanto di SLA si riduce? Se si riduce in modo significativo, non ci possono essere rilasci costanti, ma se stai pianificando un rilascio mensile, 30 secondi di inattività su 30 giorni non danneggeranno i numeri concordati.
Sono davvero 30 secondi? Se l'applicazione è errata, quanto tempo ci vuole per il rollback? Esiste una strategia di distribuzione blu-verde?
Dall'alto, è necessario zero tempi di inattività? In tal caso, è necessario il passaggio "obsoleto-rimozione". La cosa buona è che stai separando le preoccupazioni ad ogni passaggio in modo da poter gestire ogni caso di errore (vale a dire strategia di rollback)

Il concetto di SLA e il budget di errore provengono da questo libro SRE di Google

Nella mia esperienza, questo è un modo per farlo:

Crea la tua API in modo che tu possa deprecare / rimuovere quel codice - quindi puoi CANCELLARE le colonne
Ogni serie di codici ha una versione minima della migrazione in modo tale che il codice non possa essere distribuito a meno che non venga distribuita la versione minima della migrazione.
La migrazione è sempre compatibile con le versioni precedenti. Comprendo le tue preoccupazioni in merito a "passaggi twp obsoleti rimossi" ma la maggior parte dei software non gestisce la compatibilità con le versioni precedenti (ad esempio deprecato, rimozione)?

risposta data 28.04.2018 - 03:22

fonte

Leggi altre domande sui tag database microservices aws

OOD - Il singolo principio di responsabilità dipende dal contesto? Esistono alternative all'iniezione delle dipendenze per le classi stateless?

score 3 · Accepted Answer

Una modifica dovrebbe solo cambiare ciò che è necessario. La rimozione di colonne non utilizzate in uno schema DB non è una modifica necessaria, è una sorta di modifica di manutenzione non funzionale. Quindi non c'è motivo di bloccare queste modifiche affinché si verifichino nella stessa iterazione di qualsiasi servizio (o, peraltro, essere parte di una distribuzione del servizio).

Mentre è certamente possibile elaborare un sistema che impone una migrazione a ogni distribuzione dopo un determinato tipo di distribuzione "break change", questo mi sembra un po 'di ottimizzazione eccessiva o YAGNI.

Il modo in cui lo gestisco in una delle mie app è semplicemente aggiungere il passaggio al mio processo di controllo delle modifiche, in cui qualsiasi implementazione di microservizi deve essere non interruzione come nel tuo # 1, ma terrei il conto di quali colonne sono candidate alla rimozione e effettuare una pulizia trimestrale (con buy-in dagli utenti aziendali), possibilmente su una pianificazione progressiva in modo tale che qualsiasi colonna proposta deve passare un po 'di tempo prima che effettivamente rimuovilo, b / c sai che in molte impostazioni aziendali la cosa che sicuramente non avremo mai più bisogno è in realtà una funzionalità che vediamo richiesta in sei mesi circa.