L'architettura applicativa monolitica convenzionale per le app server ha recentemente subito un cambio di paradigma nell'industria del software e l'architettura dei microservizi sta attualmente prendendo il suo posto. L'idea di una raccolta di moduli leggeri e vagamente connessi, ciascuno dei quali rappresenta una singola funzionalità ed esegue nei propri processi, è stata piuttosto popolare, e per una buona ragione. Scalabilità, affidabilità e disponibilità elevata sono rese possibili dall'architettura dei microservizi poiché ogni servizio separato viene creato, gestito e testato in modo indipendente senza dipendenze.
Poiché i microservizi sono debolmente accoppiati, ha senso che un broker di messaggi si inserisca in questa infrastruttura per consentire la comunicazione asincrona dei microservizi, pur mantenendo il disaccoppiamento. La comunicazione asincrona significa che uno dei due servizi non deve attendere l'altro. Per questo, il modello di pubblicazione-sottoscrizione è stato ampiamente adottato come mezzo per la comunicazione tra microservizi.
NCache è un archivio dati distribuito in memoria per .NET e fornisce pub/sub in memoria ricchi di funzionalità per la comunicazione guidata dagli eventi. Quindi, NCache può essere facilmente configurato come broker di messaggistica per comunicazioni asincrone tra microservizi usando il modello Pub/Sub.
NCache Dettagli Messaggistica Pub/Sub ed Eventi Pub / Sub NCache Docs
utilizzando NCache Pub/Sub in memoria per microservizi
Pub/Sub è abilitato in NCache definendo un argomento su cui i microservizi (integrati in .NET/.NET Core) possono pubblicare eventi e iscriversi a loro. Gli eventi vengono pubblicati all'esterno del microservizio, in NCache mediatore di messaggi. Ogni microservizio sottoscrittore contiene un gestore eventi per gestire l'evento appropriato una volta che il microservizio publisher lo ha pubblicato. Un semplice diagramma logico di questa architettura è evidenziato nella Figura 1:
Per .NET/.NET Core microservizi, NCache funge da bus di eventi o broker di messaggi attraverso il quale i messaggi vengono inoltrati a uno o più abbonati. Per maggiori dettagli sul NCache Modello Pub/Sub, fare riferimento a NCache documentazione o il nostro blog su utilizzando NCache come Pub/Sub in memoria.
Questo post del blog utilizza il eShopOnContainers applicazione di esempio estesa con NCache ed caricato su GitHub. Il progetto inietta NCache come bus di eventi per il coordinamento delle app tra i microservizi .NET. NCacheIl ruolo di ' in questa applicazione è mostrato nella Figura 2.
NCache Dettagli Messaggistica Pub/Sub ed Eventi Pub / Sub NCache Docs
Esempio rapido di utilizzo NCache Pub/Sub in memoria
Usando il eShopOnContainers applicazione, NCache funge da broker di messaggi in più scenari. Uno scenario evidenziato qui è l'evento di checkout dell'utente in cui si trovano i dettagli del carrello pubblicato Vai all’email NCache bus dell'evento e l'applicazione dell'ordine potrebbe avere sottoscritto a tutti i cestini in entrata al momento del pagamento dell'utente per elaborare l'ordine.
- Di pubblicazione: Questo frammento di codice semplificato mostra una parte della logica di checkout del carrello nel microservizio Basket.API in cui l'ID utente e tutti i dettagli del carrello come indirizzo, numero di carta e altro vengono aggiunti come payload del messaggio e pubblicati sul bus degli eventi. Il codice Basket.API può essere trovato in BasketController.cs classe su GitHub.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[Route("checkout")] [HttpPost] public async Task<ActionResult> CheckoutAsync([FromBody]BasketCheckout basketCheckout, [FromHeader(Name = "x-requestid")] string requestId) { var userId = GetUserIdentity(); basketCheckout.RequestId = GetRequestID(); var basket = await GetBasketAsync(userId); var userName = User.FindFirst(x => x.Type == "unique_name").Value; var eventMessage = new UserCheckoutAcceptedIntegrationEvent(userId, userName, basketCheckout.Address, basketCheckout.CardNumber, basketCheckout.RequestId, basket); // This message is published to the NCache Pub/Sub store eventBus.Publish(eventMessage); } |
- Iscriviti: Il frammento di codice seguente proviene dal microservizio Ordering.API, il cui codice è caricato su GitHub. Questo contiene un abbonamento all'evento UserCheckout in cui una volta che un utente effettua il check-out dal carrello, un evento viene pubblicato come messaggio e il gestore dell'abbonato viene chiamato per elaborare ulteriormente l'ordine.
1 2 3 4 |
var eventBus = app.ApplicationServices.GetRequiredService<IEventBus>(); eventBus.Subscribe<UserCheckoutAcceptedEvent, IIntegrationEventHandler<UserCheckoutAcceptedEvent>>(); |
NCache Dettagli Messaggistica Pub/Sub ed Eventi Pub / Sub NCache Docs
Durabilità dei messaggi Pub/Sub con abbonamenti durevoli
Poiché i microservizi sono liberamente accoppiati, significa che i microservizi potrebbero entrare o uscire dall'applicazione in qualsiasi momento. Inoltre, cosa succede se si verificano problemi di rete durante il passaggio di messaggi ad alto traffico? Ciò significa che la connessione del microservizio con il bus degli eventi deve essere sufficientemente resiliente, in modo che i messaggi non vengano persi anche se la rete è temporaneamente inattiva.
NCache offre due tipi di abbonamenti durevoli per adattarsi alla durabilità dei tuoi messaggi tra i tuoi .NET/.NET Core microservizi:
- Abbonamenti durevoli condivisi: Più abbonati possono sottoscrivere un abbonamento. Il metodo Round Robin viene utilizzato per inviare messaggi a più abbonati. Anche se un abbonato lascia la rete, i messaggi tra gli abbonati attivi continuano a essere distribuiti.
- Abbonamenti durevoli esclusivi: Un abbonamento ha un solo abbonato attivo alla volta. Nessuna nuova richiesta di abbonato viene accettata sullo stesso abbonamento fino a quando la connessione non è attiva.
NCache Dettagli Messaggistica Pub/Sub ed Eventi Pub / Sub NCache Docs
Affidabilità della comunicazione con tentativi di connessione
Poiché i microservizi si affidano alla rete per la comunicazione, possono verificarsi errori di rete imprevisti che richiederebbero un meccanismo per stabilire la connessione. Così, NCache mantiene una piattaforma di comunicazione affidabile con tentativi di connessione ed mantenersi in vita funzionalità per assicurarsi che il tuo .NET/.NET Core i servizi tentano automaticamente di connettersi alla cache in caso di errore di rete. Ciò elimina la necessità di criteri di ripetizione da parte di qualsiasi libreria di terze parti come Polly.
NCache Dettagli Tentativi di connessione Affidabilità della comunicazione NCache Docs
Perché NCache?
Poiché le organizzazioni stanno ora adottando l'architettura di microservizi su applicazioni monolitiche, NCache diventa il tuo archivio dati distribuito in memoria da utilizzare come mezzo intermediario per il tuo .NET/.NET Core applicazioni di microservizi.
- Estremamente veloce e linearmente scalabile: Essendo in memoria, NCache fornisce una comunicazione più veloce rispetto ad altre soluzioni Pub/Sub. Inoltre, essere distribuito permette NCache per consentirti di scalare in movimento man mano che aggiungi più server al cluster di Message Broker per gestire carichi maggiori.
- Alta disponibilità: NCache fornisce un'architettura cluster peer-to-peer dinamica e autoriparante che garantisce l'assenza di un singolo punto di errore. Inoltre, NCache replica in modo intelligente i messaggi e fornisce anche abbonamenti durevoli in modo che non vi siano perdite di messaggi in caso di guasto di un server cache, garantendo un'elevata disponibilità ai microservizi per la comunicazione. NCache fornisce inoltre disponibilità elevata quando è necessario aumentare il numero di server nel cluster consentendo di aggiungere questi server in fase di esecuzione senza arrestare il cluster.
- Native .NET Core: Per i microservizi integrati in .NET/.NET Core, NCache fornisce un .NET al 100% / .NET Core stack nativo per integrarsi perfettamente nello stack dell'applicazione.
Per riassumere, mentre i microservizi semplificano l'applicazione in unità logiche, diventa anche difficile gestire la comunicazione tra di loro. Quindi, NCache elimina la complessità aggiuntiva dell'introduzione di un broker di messaggistica ad alta disponibilità che allo stesso tempo rispetta anche il disaccoppiamento.
Abbiamo un altro blog su Ridimensionamento delle prestazioni dei microservizi con la cache distribuita. Vai a controllare!