Microservices - Usa caso per database condiviso

2

Siamo in giro con l'idea di rompere la nostra applicazione monolitica in microservizi. Il problema che stiamo affrontando è che ci sono parti dell'applicazione che l'azienda non è disposta ad accettare l'idea di coerenza finale. Il nostro pensiero è di avere un database condiviso, ma ogni microservizio otterrebbe il proprio schema. I microservizi saranno autorizzati a leggere da tutti gli schemi, ma solo a scrivere al proprio, applicando così ancora un certo livello di contesto limitato. Ho visto alcuni riferirsi a questo come un monolite distribuito. Tuttavia, la scalabilità non è un problema per noi, non abbiamo una quantità elevata di traffico / carico, dobbiamo essere in grado di spostarci più velocemente e implementare le funzionalità in modo indipendente.

L'app: abbiamo un sistema ERP monolitico che invecchia. L'applicazione gestisce le informazioni sulle risorse umane, le informazioni sulle assicurazioni, le tariffe, la fatturazione, la scheda attività (tempo di tracciamento), la rendicontazione (compresi i salari), la pianificazione delle ferie, i clienti e i progetti, l'assegnazione dei dipendenti ai progetti (tutti utilizzati per la scheda attività e la fatturazione). p>

I problemi:

A: Il codice base è grande, disorganizzato e pieno di codice legacy. (Non proprio un problema di monolito, più un risultato di non aver mai refactoring e solo funzioni di horning horning in)

B: lunghi cicli di sviluppo e grandi sforzi di test.

C: la distribuzione è una situazione del tutto nulla. Se qualcosa non funziona come previsto, viene annullata l'intera distribuzione.

Al primo passaggio abbiamo pensato di rompere il sistema nei seguenti componenti:

  • Risorse umane (informazioni personali, tasso di pagamento, note / incidenti delle risorse umane, stato di cittadinanza, ecc.)
  • Scheda attività (clienti, progetti, assegnazione del progetto, ore / schede, tariffa per progetto / dipendente)
  • Servizio di segnalazione
  • Servizio vacanze

Il problema più grande che stiamo affrontando con il passaggio a un sistema distribuito riguarda infine la coerenza quando l'azienda non è disposta ad accettare la coerenza finale. Poiché il sistema viene utilizzato per la generazione di buste paga e fatturazione deve essere in tempo reale. Ad esempio, se il tasso di retribuzione Employee A è cambiato da $ 20 a $ 30 all'ora, un amministratore dovrebbe essere in grado di eseguire immediatamente un rapporto sulle buste paga e dovrebbe riflettere il cambiamento.

Un altro esempio è il sistema che blocca automaticamente tutti i fogli di lavoro e esegue il libro paga in un giorno / ora specifici una volta alla settimana. Se qualcuno ha aggiornato la propria scheda attività 2 minuti prima del blocco, ma non si è propagato tramite il bus dei messaggi, o qualunque meccanismo e retribuzione riflettessero valori più vecchi sarebbe molto negativo.

Come progettare microservizi quando hai bisogno di coerenza in tempo reale senza un databsae condiviso? Dovresti inserire tutto ciò che deve essere coerente all'interno dello stesso contesto microservice / limitato? Temo che questo ci ricondurrà a un monolite.

    
posta jkratz55 17.10.2018 - 20:05
fonte

1 risposta

1

Dato che non hai incluso un esempio concreto di un caso in cui potrebbe apparire un'incongruenza, immagino due situazioni.

Prima situazione

Supponiamo che un servizio gestisca i dipendenti e un altro gestisca i libri paga. Se si chiama il servizio di gestione stipendi per un nuovo dipendente che deve ancora essere creato, si teme che i dati potrebbero diventare incoerenti: verrà creato un libro paga per una persona che non esiste ancora.

In questo caso, passare da un'applicazione monolitica a un singolo database a un gruppo di servizi, ognuno dei quali è proprietario dei propri dati, non costituirebbe un problema, poiché il servizio di gestione stipendi potrebbe sempre contattare il servizio dipendenti per garantire che il dipendente esista. In caso contrario, la busta paga non dovrebbe essere creata.

Naturalmente, non si dispone del meccanismo di sicurezza in termini di vincoli del database. Tuttavia, il controllo simile può esistere a livello di applicazione.

Seconda situazione

Un servizio gestisce i libri paga e un altro gestisce le informazioni sull'assicurazione. Il servizio buste paga possiede un indirizzo postale della persona, utilizzato per inviare la busta paga. Allo stesso modo, il servizio di assicurazione ha anche gli indirizzi postali dei dipendenti per le proprie esigenze specifiche. Quando un indirizzo viene modificato in uno dei servizi, cosa garantisce che verrà modificato anche nell'altro?

In questo caso, di solito utilizzi un terzo servizio, ad esempio un servizio per i dipendenti, a cui altri due servizi delegheranno la responsabilità di mantenere gli indirizzi postali. In questo modo, le informazioni vengono archiviate solo una volta e non possono diventare incoerenti.

Ci possono essere situazioni che non sono chiare. Ad esempio, cosa succede se una persona è allo stesso tempo il tuo dipendente e il tuo cliente? Dovresti creare un altro servizio per gestire le persone in generale? O dovresti consentire qualche incoerenza (la maggior parte delle aziende sceglierebbe la seconda soluzione, che porta a molte situazioni, alcune divertenti, altre particolarmente fastidiose)? Non c'è scelta giusta per questo: spetta al tuo architetto decidere.

Database condiviso

Se considerate queste due situazioni, il database condiviso non porta alcun vantaggio. In entrambe le situazioni, poiché ciascuno dei due servizi non è (secondo te) non autorizzato a scrivere nello schema dell'altro servizio, non ci sarebbero altre soluzioni per chiamare l'altro servizio (prima situazione) o per avere un terzo servizio ( seconda situazione).

    
risposta data 17.10.2018 - 20:28
fonte

Leggi altre domande sui tag