Gestione dei dati decentralizzata - incapsulamento dei database in microservizi [chiuso]

Di recente ho seguito un corso sulla progettazione del software e una recente discussione / raccomandazione sull'utilizzo di un modello di "microservizi" in cui i componenti di un servizio sono separati in sottocomponenti di microservizi il più indipendenti possibile.

Una parte che è stata menzionata era invece di seguire il modello molto spesso visto di avere un singolo database con cui parlano tutti i microservizi, avresti un database separato in esecuzione per ciascuno dei microservizi.

Una spiegazione migliore e più dettagliata di ciò può essere trovata qui: http://martinfowler.com/articles/microservices.html nella sezione Gestione decentralizzata dei dati

la parte più saliente che dice questo:

I microservizi preferiscono consentire a ciascun servizio di gestire il proprio database, sia istanze diverse della stessa tecnologia di database, sia sistemi di database completamente diversi, un approccio chiamato Polyglot Persistence. È possibile utilizzare la persistenza dei poliglotti in un monolite, ma appare più frequentemente con i microservizi.

Figura 4

Mi piace questo concetto e, tra le altre cose, lo vedo come un forte miglioramento per la manutenzione e avere progetti con più persone che ci lavorano. Detto questo, non sono affatto un architetto del software di esperienza. Qualcuno ha mai provato a implementarlo? Quali vantaggi e ostacoli hai incontrato?

Parliamo di aspetti positivi e negativi dell'approccio microservizio.

Primi negativi. Quando si creano microservizi, si aggiunge complessità intrinseca al codice. Stai aggiungendo spese generali. Stai rendendo più difficile replicare l'ambiente (ad esempio per gli sviluppatori). Stai rendendo più difficile il debug di problemi intermittenti.

Permettetemi di illustrare un vero aspetto negativo. Prendi in considerazione ipoteticamente il caso in cui hai chiamato 100 microservizi durante la generazione di una pagina, ognuno dei quali fa la cosa giusta il 99,9% delle volte. Ma lo 0,05% delle volte produce risultati errati. E lo 0,05% delle volte c'è una richiesta di connessione lenta in cui, per esempio, è necessario un timeout TCP / IP per connettersi e che richiede 5 secondi. Circa il 90,5% delle volte la tua richiesta funziona perfettamente. Ma circa il 5% delle volte hai risultati errati e circa il 5% delle volte la tua pagina è lenta. E ogni fallimento non riproducibile ha una causa diversa.

A meno che non si pensi molto agli strumenti per il monitoraggio, la riproduzione e così via, questo si trasformerà in un casino. Soprattutto quando un microservizio chiama un altro che ne chiama un altro a pochi strati di profondità. E una volta che hai problemi, peggiorerà nel tempo.

OK, sembra un incubo (e più di una società ha creato enormi problemi per se stessa andando su questa strada). Il successo è possibile solo se si è chiaramente consapevoli del potenziale svantaggio e si lavora costantemente per affrontarlo.

E che dire di questo approccio monolitico?

Si scopre che un'applicazione monolitica è altrettanto semplice da modulare quanto i microservizi. E una chiamata di funzione è più economica e più affidabile in pratica di una chiamata RPC. Quindi puoi sviluppare la stessa cosa tranne che è più affidabile, funziona più velocemente e comporta meno codice.

OK, allora perché le aziende adottano l'approccio dei microservizi?

La risposta è perché quando si scala, c'è un limite a ciò che si può fare con un'applicazione monolitica. Dopo così tanti utenti, così tante richieste e così via, si raggiunge un punto in cui i database non si ridimensionano, i server web non possono mantenere il codice in memoria e così via. Inoltre, gli approcci di microservizio consentono aggiornamenti indipendenti e incrementali dell'applicazione. Pertanto un'architettura di microservizi è una soluzione per ridimensionare l'applicazione.

La mia regola personale è che passare dal codice in un linguaggio di scripting (ad esempio Python) al C ++ ottimizzato in generale può migliorare 1-2 ordini di grandezza sia sulle prestazioni che sull'utilizzo della memoria. Passare dall'altra parte a un'architettura distribuita aggiunge una grandezza ai requisiti delle risorse ma consente di ridimensionare indefinitamente. È possibile far funzionare un'architettura distribuita, ma farlo è più difficile.

Pertanto, direi che se stai avviando un progetto personale, diventa monolitico. Scopri come farlo bene. Non essere distribuito perché (Google | eBay | Amazon | ecc.) Lo sono. Se atterri in una grande azienda che è distribuita, presta molta attenzione a come la fanno funzionare e non rovinarla. E se finisci per fare la transizione, stai molto, molto attento perché stai facendo qualcosa di difficile che è molto facile sbagliare.

Divulgazione, ho quasi 20 anni di esperienza in aziende di tutte le dimensioni. E sì, ho visto architetture monolitiche e distribuite da vicino e personali. È basato su quell'esperienza che ti sto dicendo che un'architettura a microservizi distribuiti è davvero qualcosa che fai perché è necessario e non perché è in qualche modo più pulita e migliore.

Sono pienamente d'accordo con la risposta di Btilly, ma volevo solo aggiungere un altro aspetto positivo per Microservices, che ritengo sia una fonte d'ispirazione originale.

In un mondo di microservizi, i servizi sono allineati ai domini e sono gestiti da team separati (un team può gestire più servizi). Ciò significa che ogni team può rilasciare servizi completamente separatamente e indipendentemente da qualsiasi altro servizio (presupponendo che il controllo delle versioni sia corretto, ecc.).

Mentre quello può sembrare un vantaggio banale, considera il contrario in un mondo monolitico. Qui, dove una parte dell'applicazione deve essere aggiornata frequentemente, avrà un impatto sull'intero progetto e su tutti gli altri team che vi lavorano. Sarà quindi necessario introdurre la pianificazione, le revisioni ecc. Ecc. E l'intero processo rallenta.

Per quanto riguarda la tua scelta, oltre a considerare i requisiti di ridimensionamento, considera anche le strutture del team richieste. Concordo con la raccomandazione di Btilly di iniziare il monolitico e di identificare in seguito dove i microservizi potrebbero diventare utili, ma sii consapevole che la scalabilità non è l'unico vantaggio.

Ho lavorato in un luogo che aveva una discreta quantità di fonti di dati indipendenti. Li hanno messi tutti in un unico database, ma in diversi schemi a cui hanno avuto accesso i servizi web. L'idea era che ogni servizio potesse accedere solo alla quantità minima di dati richiesta per svolgere il proprio lavoro.

Non è stato un sovraccarico rispetto a un database monolitico, ma immagino che ciò sia dovuto principalmente alla natura dei dati che erano già in gruppi isolati.

I servizi web sono stati chiamati dal codice del server web che ha generato una pagina, quindi è molto simile all'architettura dei microservizi, anche se probabilmente non è micro come suggerisce la parola e non è stato distribuito, anche se avrebbe potuto essere (nota che un WS ha chiamato per ottenere dati da un servizio di terze parti, quindi vi era 1 istanza di un servizio dati distribuito). La società che lo ha fatto era più interessata alla sicurezza che alla scala, tuttavia, questi servizi e i servizi dati fornivano una superficie di attacco più sicura in quanto un difetto sfruttabile in uno non avrebbe dato pieno accesso all'intero sistema.

Roger Sessions nelle sue eccellenti newsletter di Objectwatch ha descritto qualcosa di simile al suo concetto di Software Fortresses (sfortunatamente le newsletter non sono più online, ma è possibile acquistare il suo libro).