Microservizi autonomi, code di eventi e individuazione di servizi

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 portare automaticamente a una fusione. È necessario considerare la frequenza di tali chiamate dipendenti e anche la frequenza delle chiamate da altri servizi.

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

• 5) naturalmente, è necessario evitare cicli infiniti nella gestione dei messaggi.

  Ma aggiungere 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 attraverso i servizi deve quindi essere analizzato nel suo insieme (in realtà ciò può essere complesso, quindi è possibile immaginare un microservizio di monitoraggio che rileva tali cicli e li interrompe).

• 8) sì, ogni microservizio deve avere il suo archivio / database dedicato.

  È richiesto un minimo di replica per consentire ai servizi di essere indipendenti. Tuttavia non andrei così lontano per dire che la replica è desiderata: deve essere mantenuta al minimo per evitare l'accoppiamento nascosto tramite processi di replica.

  I microservizi sono incoerenti. 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 poter rispondere con fermezza qui. Penso che il tuo suggerimento sia un buon punto di partenza, ma che in realtà dipende da requisiti e vincoli architettonici.

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

Services should not have any knowledge about other services in the system. They are only aware of their context and events they should publish or subscribe to?

Il problema dell'elusione della dipendenza è una falsa pista. Avrai sempre delle 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 possono rompere. Possono interrompersi a livello operativo, perché un server chiave si interrompe e lo gestisci attraverso procedure operative di ridondanza e failover. Possono anche rompersi a livello di integrazione, perché le parti cambiano in modi incompatibili, che vengono rilevati tramite test di integrazione. Il mischiare il codice tra i servizi non risolve il problema delle dipendenze potenzialmente interrotte. Le soluzioni per evitare dipendenze non funzionanti sono ridondanza operativa e test di integrazione, che non hanno nulla a che fare con la dimensione dei servizi.

If the services are communicating asynchronously, and using central event queue like amazon SQS, does that mean that service discovery does not have its place in architecture like that?

Per rispondere a questa domanda, rispondi prima a questa domanda: 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 fai a farcela? Inoltre, come si garantisce la disponibilità operativa della coda, che è un altro componente di runtime? E come assicurate la disponibilità di quei database locali? Invece di gestire un cluster di database, ora ne hai diversi. Il tuo team ops può gestire questo carico di lavoro? E davvero, la complessità vale la pena, quando forse i tuoi utenti sarebbero più felici con più funzioni e qualche ora di inattività ogni mese se hai costruito un monolite semplice?

Penso che tu veda il mio punto. La progettazione del sistema non è giusta e sbagliata, si tratta di scegliere tra una vasta gamma di compromessi. Tutto ciò che è sbagliato può essere giusto, e viceversa, se solo lo si vede 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 i loro bisogni e il design giusto si rivelerà da solo.

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

E per la tua altra domanda, l'individuazione dei servizi non è richiesta per le comunicazioni in coda.

1. L'architettura di micro-servizi si sposa bene con la progettazione basata sul dominio. Di solito una MS rappresenta un contesto limitato.

Non sono d'accordo. DDD tende ad essere molto OO. un ordine viene consegnato? Order.Deliver () considerando che Micro-services avrebbe DeliveryService.Deliver (ordine)

2. Se il micro-servizio A richiede funzionalità che risiedono nel micro-service B, il mio modello è probabilmente sbagliato e A e B dovrebbero in realtà è un micro-servizio / BC.

Non sono d'accordo, dovresti provare a mantenere i tuoi micro servizi micro. dividerli ancora più piccoli!

3. Comunicazione sincrona tra microservizi (diretta HTTP richieste) è negativo, perché sfugge allo scopo dei micro-servizi e introduce l'accoppiamento tra i componenti.

Non sono d'accordo. i servizi non dovrebbero preoccuparsi di chi li chiama e ai chiamanti non dovrebbe importare che la logica sia implementata in un microservizio.

4. È auspicabile la comunicazione asincrona tra servizi. Servizi dovrebbe pubblicare eventi sulle code dei messaggi, quindi altri servizi possono iscriversi e elaborare la propria parte dell'evento o utilizzarla per replicare una porzione di dati necessari per il loro contesto. Per di qua, i servizi possono elaborare le richieste anche se altri servizi non sono disponibili, quali non sarebbe il caso nella comunicazione sincrona.

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

5. Se il micro-servizio A pubblica un evento, il micro-servizio B sottoscrive quell'evento e produce un nuovo evento come risultato, micro-servizio A non dovrebbe essere l'unico evento di elaborazione creato, perché questo sarebbe una dipendenza circolare. In questo caso, dovremmo introdurre terzo micro-servizio, o combinare A e B nel micro-servizio AB.

Non sono d'accordo. Non è una dipendenza circolare perché i tuoi micro-servizi non sono accoppiati. Anche tu vuoi provvedere a inviare nuovamente senari, SendEmail, EmailFailed, SendAgain non ha bisogno di 3 micro-servizi

6. Il micro-servizio è in realtà un termine fuorviante. Dovremmo lottare per piccoli contesti, ma non è necessario. Termine dovrebbe non essere "micro-service", ma "abbastanza grande da fare il servizio di lavoro".

Non sono d'accordo. Scopri i nano-servizi.

7. I micro-servizi ci permettono di introdurre nuove funzionalità con altro facilità e senza timore che interromperemo l'intero sistema. Può essere fatto introducendo un nuovo servizio, o refactoring uno dei esistente.

Non sono d'accordo. Sì, ti stai disaccoppiando, ma l'orchestrazione dei micro-servizi può essere scoraggiante come qualsiasi progetto di monolite

8. Ogni micro-servizio dovrebbe avere il proprio archivio dati. Dati la replica / duplicazione è un comportamento auspicabile in questa architettura.

Non sono d'accordo. Sebbene non si debba condividere lo storage, i micro-servizi dovrebbero cercare di essere apolidi laddove possibile. non duplicare i dati a meno che non siano a bordo

Um, stai solo parlando di programmazione orientata agli oggetti. O almeno, quello che originariamente era concepito per essere: pezzi indipendenti di codice in esecuzione che comunicano tra loro usando i messaggi.

Alan Kay ha concepito l'OOP come modello dopo i sistemi biologici, in cui le cellule sono relativamente indipendenti l'una dall'altra e comunicano semplicemente attraverso messaggi che si collegano a interfacce esterne su altre celle.

Quindi perché smettere di pensarlo come OOP solo perché tutti gli oggetti non sono in esecuzione sullo stesso computer? Se mai, questo è ancor più orientato agli oggetti che se si trovano sullo stesso computer e fanno parte della stessa applicazione, perché se tutti gli oggetti si trovano nella stessa app, gli sviluppatori spesso interrompono l'OOP utilizzando variabili globali condivise da tutte le classi e includendo le stesse intestazioni in ogni file, ecc. Quando tutti gli oggetti dipendono dalla stessa roba, non sono incapsulati come se fossero completamente indipendenti l'uno dall'altro, e l'incapsulamento è l'intero OOP.

Ad esempio, quasi tutto ciò che viene detto nelle altre risposte sono dichiarazioni di un libro di testo su OOP.

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

Ho trovato estremamente proficuo pensare a sottodomini a partire dalle funzionalità di business. La capacità aziendale è qualcosa che fa la tua organizzazione. È una delle sue funzioni aziendali. Poiché il nostro obiettivo è allineamento business-IT , li voglio decisamente avere rapporto 1: 1 con i miei servizi tecnici .

Quindi questo processo si riduce a quanto segue. Innanzitutto, definisco le capacità di business di livello superiore. Dovrebbe assumere la forma di sostantivo e verbo (o qualche forma derivativa). Di solito ci sono meno di 10 capacità di business. Quindi immenso capacità nidificate più profonde e identificative. E così via, finché non c'è nulla da dividere. Le capacità con cui sei arrivato a utilizzare questo approccio riflettono il vero dominio, il modo reale in cui funziona la tua organizzazione. Queste funzionalità saranno innatamente accoppiate liberamente, quindi se si mappano i servizi tecnici a queste funzionalità, saranno autonomi e basati sugli eventi. Questo processo si chiama Mappatura delle capacità aziendali , ma ci sono altri modi per trovare i tuoi servizi, il il più importante dei quali è probabilmente Analisi della catena del valore .

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