Microservizi autonomi, code di eventi e rilevazione di servizi

Ultimamente ho letto molto sui micro-servizi, ed ecco alcune delle conclusioni che ho ottenuto finora (per favore correggimi se sbaglio in qualsiasi momento).

1. L'architettura dei micro-servizi si sposa bene con la progettazione guidata dal dominio. Di solito un MS rappresenta un contesto limitato.
2. Se il micro-servizio A richiede funzionalità che risiede nel micro-servizio B , il mio modello è probabilmente sbagliato e A e B dovrebbero effettivamente essere un micro-servizio / BC.
3. La comunicazione sincrona tra i micro-servizi (richieste HTTP dirette) è errata, perché sfugge allo scopo dei micro-servizi e introduce l'accoppiamento tra i componenti.
4. È auspicabile una comunicazione asincrona tra servizi. I servizi dovrebbero pubblicare eventi nelle code dei messaggi, in modo che altri servizi possano iscriversi ed elaborare la loro parte dell'evento o utilizzarlo per replicare una parte dei dati necessari per il loro contesto. In questo modo, i servizi possono elaborare le richieste anche altri servizi sono inattivi, il che non sarebbe il caso della comunicazione sincrona.
5. Se il micro-servizio A pubblica un evento, il micro-servizio B si iscrive a quell'evento e produce un nuovo evento come risultato, il micro-servizio A non dovrebbe essere quello che elabora un evento appena creato, perché sarebbe una dipendenza circolare. In questo caso, dovremmo introdurre un terzo micro-servizio o combinare A e B nel micro-servizio AB .
6. Micro-servizio è in realtà un termine fuorviante. Dovremmo lottare per piccoli contesti, ma non è necessario che sia così. Il termine non dovrebbe essere "micro-servizio", ma " abbastanza grande per fare il servizio di lavoro ".
7. I micro-servizi ci consentono di introdurre nuove funzionalità con maggiore facilità e senza timore di rompere l'intero sistema. Può essere fatto introducendo un nuovo servizio o riformattando uno di quelli esistenti.
8. Ogni micro-servizio dovrebbe avere il proprio archivio dati. La replica / duplicazione dei dati è un comportamento desiderabile in questa architettura.

Oltre a confermare la mia comprensione di questa architettura, la mia altra parte della domanda è principalmente legata alla scoperta del servizio. Se i servizi comunicano in modo asincrono e utilizzano la coda degli eventi centrale come Amazon SQS, ciò significa che il rilevamento dei servizi non ha un posto in questa architettura?

I servizi non dovrebbero avere alcuna conoscenza di altri servizi nel sistema. Sono consapevoli solo del contesto e degli eventi a cui dovrebbero pubblicare o abbonarsi?

Le tue conclusioni sembrano per lo più fondate e riassumono molto bene la strada da percorrere per i microservizi.

Tuttavia, non supporterei completamente 2, 5 e 8:

• 2) Una semplice dipendenza non dovrebbe comportare automaticamente una fusione. Devi considerare la frequenza di tali chiamate dipendenti e anche la frequenza delle chiamate da altri servizi.

  Pertanto, se un microservizio A richiede funzionalità nel microservizio B molto frequentemente e il microservizio B è raramente necessario per altri microservizi, è necessario sfidare la struttura prevista e chiedere se non sarebbe più appropriato raggruppare entrambi i microservizi.

• 5) ovviamente, è necessario evitare il ciclismo senza fine nella gestione dei messaggi.

  Ma l'aggiunta di un intermediario non lo impedirà: A potrebbe lanciare un messaggio gestito da C che lancia un messaggio gestito da B, che lancia un messaggio gestito da A e qui sei intrappolato in un ciclo.

  Il problema non può essere valutato solo considerando il livello di microservizio: la domanda riguarda davvero il tipo di messaggio e il contenuto che potrebbe portare al ciclo. Il grafico che modella la distribuzione e l'elaborazione dei messaggi tra i servizi deve quindi essere analizzato nel suo insieme (in effetti questo può essere complesso, quindi si potrebbe immaginare un microservizio di monitoraggio che rileva tali cicli e li interrompe).

• 8) sì, ogni microservizio deve avere un proprio archivio / database dedicato.

  È necessario un minimo di replica per consentire ai servizi di essere indipendenti. Tuttavia, non vorrei andare così lontano per dire che la replica è desiderata: deve essere ridotta al minimo per evitare l'accoppiamento nascosto tramite i processi di replica.

  I microservizi riguardano l'accoppiamento lento. A volte ciò può essere ottenuto in modo più efficace chiamando un altro microservizio per recuperare i dati correlati, invece di replicare i dati.

Le ultime due affermazioni non numerate sono troppo ampie per essere risolte qui. Penso che il tuo suggerimento sia un buon punto di partenza, ma che dipende davvero dai requisiti e dai vincoli dell'architettura.

I micro-servizi riguardano il disaccoppiamento di diversi domini di funzionalità. Ogni servizio può essere sviluppato a un ritmo diverso, da un team diverso, utilizzando un diverso stack tecnologico. Questo crea flessibilità organizzativa. Il compromesso è la complessità operativa, in cui ogni servizio aggiuntivo crea un'altra cosa che deve essere gestita in un ambiente operativo. Quindi, il fondamentale compromesso tra monolite e micro-servizio non riguarda l'evitare le dipendenze, si tratta di evitare lo sviluppo e lo spiegamento di blocchi in cui tutto deve essere spedito tutto in una volta, ma a costo di dover spedire più spesso perché ci sono più parti in movimento.

I servizi non dovrebbero avere alcuna conoscenza di altri servizi nel sistema. Sono consapevoli solo del contesto e degli eventi a cui dovrebbero pubblicare o abbonarsi?

Il problema di evitare le dipendenze è un'aringa rossa. Avrai sempre dipendenze tra i pezzi del tuo prodotto e se si trovano in un servizio separato o parte dello stesso codice non altera il fatto che le dipendenze possano rompersi. Possono rompersi a livello operativo, perché un server chiave si interrompe e lo gestisci attraverso pratiche operative di ridondanza e failover. Possono anche rompersi a livello di integrazione, poiché le parti cambiano in modi incompatibili, rilevabili attraverso i test di integrazione. Mischiare il codice tra i servizi non risolve il problema delle dipendenze potenzialmente interrotte. Le soluzioni per evitare dipendenze interrotte sono la ridondanza operativa e i test di integrazione, che non hanno nulla a che fare con la dimensione dei servizi.

Se i servizi comunicano in modo asincrono e utilizzano la coda degli eventi centrale come Amazon SQS, ciò significa che il rilevamento dei servizi non ha un posto in questa architettura?

Per rispondere a questa domanda, prima rispondi a questa: perché desideri comunicare in modo asincrono? È per facilitare lo sviluppo indipendente di componenti separati? Migliorare la disponibilità operativa per un sistema 24/7? Diciamo che è quest'ultimo e si desidera utilizzare le code per replicare i dati nei database locali. Bene, ora i tuoi dati possono essere obsoleti. Ad un certo punto sarà troppo stantio. Come lo affronti? Inoltre, come si garantisce la disponibilità operativa della coda, che è un altro componente di runtime? E come garantite la disponibilità di quei database locali? Invece di gestire un cluster di database, ora ne hai diversi. Il tuo team operativo può gestire questo carico di lavoro? E davvero, ne vale la pena, quando forse i tuoi utenti sarebbero più felici con più funzionalità e poche ore di inattività ogni mese se costruissi un semplice monolite?

Penso che tu veda il mio punto. La progettazione del sistema non riguarda il giusto e lo sbagliato, si tratta di scegliere tra un'ampia varietà di compromessi. Tutto ciò che è sbagliato può essere giusto e viceversa, se solo lo vedi nel giusto contesto. Il tuo contesto è unico per te, quindi mentre possiamo darti una risposta, non sarà la risposta. Ricorda chi è il tuo pubblico, quali sono le sue esigenze e il design giusto si rivelerà.

1. L'architettura dei micro-servizi si sposa bene con la progettazione guidata dal dominio. Di solito un MS rappresenta un contesto limitato.

Disaccordo. DDD tende ad essere molto OO. un ordine viene consegnato? Order.Deliver () mentre i micro-servizi avrebbero DeliveryService.Deliver (ordine)

2. Se il micro-servizio A richiede funzionalità che risiede nel micro-servizio B, il mio modello è probabilmente sbagliato e A e B dovrebbero effettivamente essere un micro-servizio / BC.

In disaccordo, dovresti provare a mantenere micro servizi micro. dividerli ancora più piccoli!

3. La comunicazione sincrona tra i micro-servizi (richieste HTTP dirette) è errata, perché sfugge allo scopo dei micro-servizi e introduce l'accoppiamento tra i componenti.

Disaccordo. i servizi non dovrebbero preoccuparsi di chi li sta chiamando e ai chiamanti non dovrebbe interessarsi che la logica sia implementata in un microservizio.

4. È auspicabile una comunicazione asincrona tra servizi. I servizi dovrebbero pubblicare eventi nelle code dei messaggi, in modo che altri servizi possano iscriversi ed elaborare la loro parte dell'evento o utilizzarlo per replicare una parte dei dati necessari per il loro contesto. In questo modo, i servizi possono elaborare le richieste anche altri servizi sono inattivi, il che non sarebbe il caso della comunicazione sincrona.

Le code sono buone. Ma il tuo ragionamento è sbagliato. l'unica differenza tra le risposte di sincronizzazione e asincrone è che aspetti la sincronizzazione. È possibile implementare chiamate in stile RPC con code e più lavoratori senza problemi.

5. Se il micro-servizio A pubblica un evento, il micro-servizio B si iscrive a quell'evento e produce un nuovo evento come risultato, il micro-servizio A non dovrebbe essere quello che elabora un evento appena creato, perché sarebbe una dipendenza circolare. In questo caso, dovremmo introdurre un terzo micro-servizio o combinare A e B nel micro-servizio AB.

Disaccordo. Non è una dipendenza circolare perché i tuoi micro-servizi non sono accoppiati. Inoltre vuoi provvedere a rinviare i senari, SendEmail, EmailFailed, SendAgain non ha bisogno di 3 micro-servizi

6. Micro-servizio è in realtà un termine fuorviante. Dovremmo lottare per piccoli contesti, ma non è necessario che sia così. Il termine non dovrebbe essere "micro-servizio", ma "abbastanza grande per fare il servizio di lavoro".

Disaccordo. Dai un'occhiata ai nano-servizi.

7. I micro-servizi ci consentono di introdurre nuove funzionalità con maggiore facilità e senza timore di rompere l'intero sistema. Può essere fatto introducendo un nuovo servizio o riformattando uno di quelli esistenti.

Disaccordo. Sì, si ottiene il disaccoppiamento, ma l'orchestrazione dei micro-servizi può essere scoraggiante come qualsiasi progetto monolitico

8. Ogni micro-servizio dovrebbe avere il proprio archivio dati. La replica / duplicazione dei dati è un comportamento desiderabile in questa architettura.

Disaccordo. Anche se non dovresti condividere l'archiviazione, i tuoi micro-servizi dovrebbero cercare di essere apolidi dove possibile. non duplicare i dati a meno che non siano a bordo

Le tue conclusioni sono buone regole empiriche, ma non universali. Ci saranno casi in cui l'opzione migliore è infrangere queste regole, anche in un progetto greenfield. In alcuni casi la comunicazione sincrona è l'opzione migliore. In alcuni casi non è bene unire due servizi in uno anche se sono accoppiati da una comunicazione sincrona.

E per l'altra domanda, il rilevamento del servizio non è richiesto per la comunicazione basata sulla coda.

Uhm, stai solo parlando di programmazione orientata agli oggetti. O almeno, ciò che originariamente era concepito: pezzi indipendenti di codice in esecuzione che comunicavano tra loro usando i messaggi.

Alan Kay ha concepito OOP come modellato su sistemi biologici, in cui le cellule sono relativamente indipendenti le une dalle altre e comunicano semplicemente attraverso messaggi che si collegano a interfacce esterne su altre celle.

Quindi perché smettiamo di pensarlo come OOP solo perché tutti gli oggetti non sono in esecuzione sullo stesso computer? Semmai, questo è ancora più orientato agli oggetti che se sono sullo stesso computer e parte della stessa applicazione, perché se tutti gli oggetti si trovano nella stessa applicazione, quindi gli sviluppatori di rompere spesso OOP utilizzando le variabili globali condivise da tutte le classi e comprese le stesse intestazioni in ogni file, ecc. Quando tutti gli oggetti dipendono dalle stesse cose, non sono incapsulati come se fossero completamente indipendenti l'uno dall'altro e l'incapsulamento è il punto centrale di OOP.

Ad esempio, quasi tutto quanto detto nelle altre risposte sono dichiarazioni di un libro di testo su OOP.

Dal momento che incontro spesso una comprensione errata di un concetto così importante come Bounded Context e Core Domain, mi piacerebbe approfondire un po 'su di esso.

Ho trovato estremamente redditizio pensare ai sottodomini come alle capacità aziendali. La capacità aziendale è qualcosa che fa la tua organizzazione. È una delle sue funzioni aziendali. Poiché il nostro obiettivo è l' allineamento business-IT , desidero sicuramente che abbiano una relazione 1: 1 con i miei servizi tecnici .

Quindi questo processo si riduce a quanto segue. Innanzitutto, definisco le capacità aziendali di livello superiore. Dovrebbe assumere la forma di nome e verbo (o qualche forma derivata). Di solito ci sono meno di 10 capacità aziendali. Quindi mi immergo sempre più in profondità, identificando le capacità annidate. E così via, fino a quando non c'è nulla da dividere. Le capacità che hai acquisito utilizzando questo approccio riflettono il dominio reale, il modo reale in cui lavora la tua organizzazione. Queste capacità saranno accoppiate in modo innato, quindi se si mappano i servizi tecnici su tali capacità, saranno autonomi e guidati dagli eventi. Questo processo è chiamato Mappatura delle capacità aziendali , ma ci sono altri modi per trovare i tuoi servizi, il più importante dei quali è probabilmente analisi della catena del valore .

Ecco un esempio di identificazione dei confini del servizio utilizzando questo approccio.