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

Parliamo di aspetti positivi e negativi dell'approccio microservice.

Prime negazioni. Quando crei i microservizi, aggiungi complessità intrinseca nel codice. Stai aggiungendo overhead. Stai rendendo più difficile la replica dell'ambiente (ad esempio per gli sviluppatori). Stai rendendo più difficile il debug dei problemi intermittenti.

Lasciatemi illustrare un vero svantaggio. Considerare ipoteticamente il caso in cui si hanno 100 microservizi chiamati durante la generazione di una pagina, ognuno dei quali fa la cosa giusta il 99,9% delle volte. Ma lo 0,05% delle volte producono risultati sbagliati. E lo 0,05% delle volte c'è una richiesta di connessione lenta dove, per esempio, è necessario un timeout TCP / IP per la connessione 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% del tempo la tua pagina è lenta. E ogni errore 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 caos. Soprattutto quando un microservice chiama un altro che chiama un altro alcuni strati in profondità. E una volta che hai problemi, peggiorerà solo nel tempo.

OK, sembra un incubo (e più di una società ha creato enormi problemi andando da questa parte). Il successo è possibile solo se sei chiaramente consapevole del potenziale svantaggio e lavori costantemente per affrontarlo.

Che ne è dell'approccio monolitico?

Si scopre che un'applicazione monolitica è altrettanto facile da modulare come microservizi. E una chiamata di funzione è in pratica meno costosa e più affidabile di una chiamata RPC. Così puoi sviluppare la stessa cosa, tranne che è più affidabile, corre più veloce e coinvolge meno codice.

OK, allora perché le aziende passano all'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 vengono scalati, i server Web non possono conservare il codice in memoria e così via. Inoltre, gli approcci al microservizio consentono aggiornamenti indipendenti e incrementali della vostra applicazione. Pertanto, un'architettura di microservizi è una soluzione per ridimensionare l'applicazione.

La mia regola empirica personale è che passare dal codice in un linguaggio di scripting (ad es. Python) a C ++ ottimizzato generalmente può migliorare 1-2 ordini di grandezza sia sull'uso delle prestazioni che della memoria. Andare in un'altra direzione verso un'architettura distribuita aggiunge una grande importanza ai requisiti delle risorse, ma consente di ridimensionare indefinitamente. Puoi far funzionare un'architettura distribuita, ma farlo è più difficile.

Quindi direi che se stai iniziando un progetto personale, vai monolitico. Impara come farlo bene. Non essere distribuiti perché (Google | eBay | Amazon | etc) sono. Se arrivi in una grande azienda che viene distribuita, fai molta attenzione a come lo fanno funzionare e non rovinarlo. E se finisci di dover fare la transizione, sii molto, molto attento perché stai facendo qualcosa di difficile che è molto facile sbagliare molto.

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 di microservice distribuita è davvero qualcosa che fai perché è necessario, e non perché sia in qualche modo più pulito e migliore.

Sono pienamente d'accordo con la risposta di btilly, ma volevo solo aggiungere un altro positivo per Microservices, che penso sia un'ispirazione originale dietro di esso.

In un mondo Microservices, 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 la versione corretta ecc.).

Anche se può sembrare un beneficio banale, considera l'opposto 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 lavorano su di essa. Sarà quindi necessario introdurre pianificazione, recensioni, ecc. E l'intero processo rallenta.

Per quanto riguarda la tua scelta, oltre a considerare i tuoi requisiti di ridimensionamento, considera anche qualsiasi struttura di squadra richiesta. Sarei d'accordo con la raccomandazione di btilly di iniziare Monolithic e poi identificare in seguito dove i microservizi potrebbero diventare utili, ma bisogna essere consapevoli 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 ai quali i servizi web hanno avuto accesso. L'idea era che ogni servizio potesse accedere solo alla quantità minima di dati richiesta per svolgere il proprio lavoro.

Non era un sovraccarico rispetto a un database monolitico, ma immagino che questo fosse dovuto principalmente alla natura dei dati che erano già in gruppi isolati.

I webservices sono stati richiamati dal codice del server Web che ha generato una pagina, quindi è molto simile alla tua architettura di microservizi, anche se forse non così micro come suggerisce la parola e non distribuita, anche se avrebbero potuto essere (notare che una WS ha fatto call per ottenere dati da un servizio di terze parti, quindi c'era 1 istanza di un servizio di dati distribuiti lì). 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 con il suo concetto di strongzza del software (purtroppo le newsletter non sono più online, ma puoi acquistare il suo libro).