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.