Στην προηγούμενη ενότητα, μιλήσαμε για τις δύο χαμηλότερες έννοιες του Service Fabric, η μία είναι ο τύπος κόμβου και ο κόμβος σε επίπεδο υλικού. Το άλλο είναι η Εφαρμογή.
Ο τύπος κόμβου είναι μια συλλογή κόμβων, οι οποίοι είναι εννοιολογικές αφαιρέσεις των μηχανών ανάπτυξης. Για το Service Fabric, ένας κόμβος μπορεί να είναι μια φυσική μηχανή, μια εικονική μηχανή ή ακόμα και το πιο δημοφιλές κοντέινερ τώρα.
Η εκτέλεση σε τύπο κόμβου είναι εφαρμογή. Είναι μια αφηρημένη κατανόηση σε επίπεδο λογισμικού συστήματος. Υπάρχουν πολλές Micro Services σε μια εφαρμογή. Ακόμη και όλες οι υποκείμενες υπηρεσίες του Service Fabric, όπως η υπηρεσία FailoverManager και η υπηρεσία ονομασίας, είναι Micro Services.
Όλες οι κατανεμημένες δυνατότητες του Service Fabric αντιστοιχούν σε αναπτύξεις Micro Service. Μπορούμε να προσαρμόσουμε δυναμικά πόσες περιπτώσεις χρειάζεται να εκτελεστεί μια Micro Service σε πόσους κόμβους θα κατανείμει την πίεση φορτίου ή θα εκτελέσει αντίγραφα ασφαλείας αποκατάστασης καταστροφών. Κάθε παρουσία ακούει μια διαφορετική θύρα και το επίπεδο εξισορρόπησης φορτίου κατανέμει αιτήματα σε διαφορετικές παρουσίες.
Πραγματικό σενάριο
Η Stateful Service είναι μία από τις Micro Services.
Πριν ξεκινήσουμε την εισαγωγή της υπηρεσίας κατάστασης, ας εξετάσουμε τα ακόλουθα κοινά επιχειρηματικά σενάρια.
Σκέφτεστε να εφαρμόσετε μια λειτουργία καλαθιού αγορών στον ιστότοπό σας. Αφού συνδεθούν, οι χρήστες θα τοποθετήσουν ορισμένα προϊόντα στο καλάθι αγορών τους.
Την επόμενη φορά που ο χρήστης θα συνδεθεί, η σελίδα της ρεσεψιόν θα καλέσει την υπηρεσία καλαθιού αγορών και θα πρέπει να διαβάσει ξανά τα αποθηκευμένα δεδομένα καλαθιού αγορών από αυτήν την υπηρεσία και να τα εμφανίσει.
Αν ναι, πώς θα το πετύχατε;
Εάν ο αριθμός των χρηστών δεν είναι ιδιαίτερα μεγάλος, θα προσθέσουμε έναν πίνακα καλαθιού αγορών στη βάση δεδομένων και θα τον συσχετίσουμε με τον πίνακα χρήστη. Ο πίνακας καλαθιού θα έχει ένα πεδίο αναγνωριστικού χρήστη και θα καταγράφει μεγάλο όγκο δεδομένων καλαθιού χρήστη.
Τότε αυτό θα φέρει κάποια επακόλουθα προβλήματα.
Εάν ο αριθμός των χρηστών συνεχίσει να αυξάνεται, η απόδοση των πινάκων της βάσης δεδομένων θα συνεχίσει να υποβαθμίζεται.
Τα δεδομένα του πίνακα βάσης δεδομένων πρέπει να δημιουργούνται τακτικά αντίγραφα ασφαλείας σε περίπτωση απώλειας δεδομένων
Εάν υπάρχει πρόβλημα με την απόδοση της βάσης δεδομένων, ο πίνακας πρέπει να καταρριφθεί ή ακόμα και να διαμεριστεί
Το ίδιο το σύστημα καλαθιού αγορών πρέπει να χειριστεί τυχόν προσαρμογές στη βάση δεδομένων και ακόμη και μπορεί να χρειαστεί να εξισορροπηθεί το φορτίο
Η ρίζα αυτού του προβλήματος είναι ότι το ίδιο το σύστημα δεν έχει σχεδιαστεί για να είναι επεκτάσιμο εξαρχής. Επιπλέον, οι βάσεις δεδομένων αποτελούν πιθανό εμπόδιο και απειλή για την απόδοση.
Κρατική υπηρεσία
Ας εξετάσουμε μια τόσο εντελώς νέα αρχιτεκτονική.
Από την αρχή, το σύστημα καλαθιού αγορών διαθέτει 36 υπο-υπηρεσίες που χειρίζονται όλα τα αιτήματα (36 επειδή τα αρχικά του αναγνωριστικού χρήστη είναι 0-9 a-z, συνολικά 36).
Το αίτημα του χρήστη υποβάλλεται σε επεξεργασία σύμφωνα με τον αρχικό κατακερματισμό του αναγνωριστικού χρήστη σε μια συγκεκριμένη υπουπηρεσία.
Η υπο-υπηρεσία αποθηκεύει τα δεδομένα του καλαθιού αγορών εσωτερικά μέσω μιας ελαφριάς βάσης δεδομένων και τα διατηρεί στη δική της συσκευή αποθήκευσης.
Κάθε υπο-υπηρεσία διαθέτει επίσης 3 αντίγραφα ασφαλείας, τα οποία συγχρονίζουν συνεχώς τα αποθηκευμένα δεδομένα και αυτά τα αντίγραφα ασφαλείας εκτελούνται πάντα σε διαφορετικούς κόμβους.
Ταυτόχρονα, μόνο ένα αντίγραφο ασφαλείας είναι υπεύθυνο για την επεξεργασία των αιτημάτων ως κατάσταση ενεργοποίησης και όταν υπάρχει πρόβλημα με την ενεργοποίηση του αντιγράφου ασφαλείας, τα άλλα δύο αντίγραφα ασφαλείας ενεργοποιούν το ένα σύμφωνα με τον αλγόριθμο προγραμματισμού.
Το υποσύστημα αποκατάστασης καταστροφών δημιουργεί ένα νέο αντίγραφο ασφαλείας για να διασφαλίσει ότι η υπουπηρεσία έχει πάντα 3 υγιή αντίγραφα ασφαλείας.
Η κρατική υπηρεσία είναι μια τέτοια λύση.
Επιστρέφοντας στο παραπάνω σενάριο, το σύστημα καλαθιού αγορών είναι μια κρατική υπηρεσία.
Τα 36 υποσυστήματα είναι οι 36 περιπτώσεις αυτής της υπηρεσίας κατάστασης, την οποία ονομάζουμε Partitions.
Το αντίγραφο ασφαλείας κάτω από κάθε υποσύστημα είναι Replica και υπάρχουν 3 Replicas σε ένα διαμέρισμα.
Το τρέχον ενεργό αντίγραφο ασφαλείας είναι το Active Replica και τα δύο ανενεργά αντίγραφα ασφαλείας αναμονής είναι το Secondary Replica.
Κάθε αντίγραφο του ίδιου Partiion πρέπει να εκτελείται σε διαφορετικό κόμβο.
Ο κωδικός υπηρεσίας κατάστασης χρησιμοποιεί <T>διασυνδέσεις όπως IReliableCollection, IReliableDictionary< T1 και T2 >για αποθήκευση δεδομένων και συγχρονισμό εσωτερικά.
Επιπλέον, το Stateful Service μπορεί να εφαρμόσει τις ακόλουθες δυνατότητες:
Όλοι οι παραπάνω αριθμοί μπορούν να επαναφερθούν και μπορείτε να έχετε εκατοντάδες διαμερίσματα στο σύστημα καλαθιού για να φορτώσετε περισσότερο άγχος. Μπορείτε ακόμη να έχετε 5 ή περισσότερα αντίγραφα ανά διαμέρισμα για να εξασφαλίσετε μεγαλύτερη στιβαρότητα.
Τα εξωτερικά συστήματα δεν ενδιαφέρονται για το πόσες κατατμήσεις έχει η Stateful Service, καλούνται με κλειδί κατάτμησης. Το κλειδί διαμερίσματος και το αντίστοιχο διαμέρισμα επιλύονται από την υποκείμενη Micro Service του Service Fabric. Για παράδειγμα, στην επιχείρησή σας, μπορεί να έχετε μερικά εκατομμύρια χρήστες, αλλά να δημιουργήσετε μόνο 5 διαμερίσματα. Όταν καλείτε το καλάθι αγορών Stateful Service, το εξωτερικό σύστημα χρειάζεται μόνο να ενημερώσει το αναγνωριστικό χρήστη (κλειδί διαμερίσματος) και τα αποθηκευμένα δεδομένα. Αυτό το αίτημα αντιστοιχίζεται αυτόματα σε ένα από τα πέντε διαμερίσματα με βάση το αναγνωριστικό χρήστη και τον αλγόριθμο κατακερματισμού.
Οι λειτουργίες δεδομένων στις κρατικές υπηρεσίες υποστηρίζουν συναλλαγές. Έτσι, μπορείτε να επαναφέρετε την αποτυχία
Ελπίζω ότι η παραπάνω εισαγωγή μπορεί να σας βοηθήσει να κατανοήσετε καλύτερα την κρατική υπηρεσία.
Θα καλύψουμε παραδείγματα κώδικα για την υπηρεσία κατάστασης στις ακόλουθες ενότητες. |
Δημοσιεύτηκε στις 15/3/2018 10:03:44 π.μ.
|
|
|
|
