Nella sezione precedente, abbiamo parlato dei due concetti più bassi del Service Fabric: uno è il Tipo di Nodo e il Nodo a livello hardware. L'altro è l'Applicazione.
Il Tipo di Nodo è una raccolta di Nodi, che sono astrazioni concettuali delle macchine in dispiegamento. Per Service Fabric, un nodo può essere una macchina fisica, una macchina virtuale o anche il container più popolare attuale.
Su Tipo di Nodo è eseguito Application. È una comprensione astratta a livello del software di sistema. Ci sono più Micro Servizi in un'applicazione. Anche tutti i servizi sottostanti di Service Fabric, come FailoverManager Service e Naming Service, sono Micro Servizi.
Tutte le funzionalità distribuite di Service Fabric corrispondono alle implementazioni Micro Service. Possiamo regolare dinamicamente quante istanze un Micro Service deve eseguire su quanti nodi distribuire la pressione di carico o eseguire backup di disaster recovery. Ogni istanza ascolta una porta diversa e il livello di bilanciamento del carico distribuisce le richieste a istanze diverse.
Scenario reale
Il servizio statale è uno dei Micro Servizi.
Prima di iniziare a introdurre il Servizio Stateful, consideriamo i seguenti scenari di business comuni.
Stai pensando di implementare una funzione carrello della spesa sul tuo sito web. Dopo l'accesso, gli utenti inseriscono alcuni articoli nel carrello della spesa.
La prossima volta che l'utente effettua l'accesso, la pagina della reception chiamerà il servizio carrello della spesa e dovrà rileggere i dati salvati del carrello da questo servizio e visualizzarli.
Se sì, come lo otterreste?
Se il numero di utenti non è particolarmente elevato, aggiungeremo una tabella carrello della spesa al database e la associeremo alla tabella utente. La tabella del carrello avrà un campo ID utente e registrerà una grande quantità di dati del carrello utente.
Poi questo porterà qualche problema successivo.
Se il numero di utenti continua ad aumentare, le prestazioni delle tabelle del database continueranno a degradarsi.
I dati delle tabelle del database devono essere salvati regolarmente in caso di perdita di dati
Se c'è un problema di prestazioni del database, la tabella deve essere smontata o addirittura partizionata
Il sistema del carrello della spesa stesso deve gestire eventuali modifiche al database, e anche questo potrebbe dover essere bilanciato con il carico
La radice di questo problema è che il sistema stesso non è progettato per essere scalabile fin dall'inizio. Inoltre, i database rappresentano un potenziale collo di bottiglia e una minaccia per le prestazioni.
Servizio statale
Consideriamo un'architettura così completamente nuova.
Fin dall'inizio, il sistema del carrello della spesa ha 36 sottoservizi che gestiscono tutte le richieste (36 perché le iniziali dell'ID utente sono 0-9 a-z, per un totale di 36).
La richiesta dell'utente viene elaborata in base all'hash iniziale dell'ID utente per un sottoservizio specifico.
Il sottoservizio memorizza i dati del carrello internamente tramite un database leggero e li conserva sul proprio dispositivo di archiviazione.
Ogni sotto-servizio ha anche 3 backup, che sincronizzano costantemente i dati memorizzati, e questi backup sono sempre in esecuzione su nodi diversi.
Allo stesso tempo, solo un backup è responsabile dell'elaborazione delle richieste come stato di attivazione, e quando c'è un problema nell'attivazione del backup, gli altri due backup ne attivano uno secondo l'algoritmo di programmazione.
Il sottosistema di disaster recovery crea un nuovo backup per garantire che il sottoservizio abbia sempre 3 backup sani.
Il servizio statale è una di queste soluzioni.
Tornando allo scenario sopra, il sistema del carrello della spesa è un servizio con stato.
I 36 sottosistemi sono le 36 istanze di questo Servizio Stateful, che chiamiamo Partizioni.
Il backup sotto ogni sottosistema è Replica, e ci sono 3 Replica in una partizione.
Il backup attualmente attivo è Active Replica, e i due backup di riserva inattivi sono Secondary Replica.
Ogni replica dello stesso Partion deve essere eseguita su un nodo diverso.
Il codice Stateful Service utilizza <T>interfacce come IReliableCollection, IReliableDictionary< T1 e T2 >per salvare i dati e sincronizzarsi internamente.
Inoltre, il Servizio Stateful può implementare le seguenti funzionalità:
Tutti i numeri sopra possono essere resettati, e puoi avere centinaia di partizioni nel sistema di cartucce per caricare più stress. Puoi anche avere 5 o più repliche per partizione per garantire maggiore robustezza.
I sistemi esterni non si preoccupano di quante partizioni abbia il Servizio Stateful, sono chiamati tramite chiave di partizione. La chiave di partizione e la corrispondente partizione vengono risolte dal Micro Service di servizio sottostante. Ad esempio, nella tua azienda potresti avere qualche milione di utenti, ma configurare solo 5 partizioni. Quando si chiama il servizio con stato al carrello, il sistema esterno deve solo informare l'ID utente (chiave di partizione) e i dati salvati. Questa richiesta viene automaticamente mappata su una delle cinque partizioni in base all'ID utente e all'algoritmo di hash.
Le operazioni dati nei Servizi Stateful supportano le transazioni. Così puoi tornare indietro in caso di fallimento
Spero che l'introduzione sopra possa aiutarti a comprendere meglio il Servizio Statale.
Nei seguenti sezioni parleremo degli esempi di codice per il Servizio Statale. |
Pubblicato su 15/03/2018 10:03:44
|
|
|
|
