Στις 26 Φεβρουαρίου, πραγματοποιήσαμε μια συνάντηση Apache Ignite GreenSource, όπου μίλησαν οι συντελεστές του έργου ανοιχτού κώδικα . Ένα σημαντικό γεγονός στη ζωή αυτής της κοινότητας ήταν η αναδιάρθρωση του στοιχείου , το οποίο σας επιτρέπει να αναπτύξετε προσαρμοσμένες μικροϋπηρεσίες απευθείας σε ένα σύμπλεγμα Ignite. Μίλησε για αυτή τη δύσκολη διαδικασία στη συνάντηση , μηχανικός λογισμικού και συνεργάτης του Apache Ignite για περισσότερα από δύο χρόνια.
Ας ξεκινήσουμε με το τι είναι γενικά το Apache Ignite. Αυτή είναι μια βάση δεδομένων που είναι ένας κατανεμημένος χώρος αποθήκευσης κλειδιού/τιμής με υποστήριξη για SQL, συναλλακτικότητα και προσωρινή αποθήκευση. Επιπλέον, το Ignite σάς επιτρέπει να αναπτύξετε προσαρμοσμένες υπηρεσίες απευθείας σε ένα σύμπλεγμα Ignite. Ο προγραμματιστής έχει πρόσβαση σε όλα τα εργαλεία που παρέχει το Ignite - κατανεμημένες δομές δεδομένων, Messaging, Streaming, Compute και Data Grid. Για παράδειγμα, όταν χρησιμοποιείτε το Data Grid, το πρόβλημα της διαχείρισης μιας ξεχωριστής υποδομής για την αποθήκευση δεδομένων και, κατά συνέπεια, τα γενικά έξοδα που προκύπτουν εξαφανίζονται.
Χρησιμοποιώντας το Service Grid API, μπορείτε να αναπτύξετε μια υπηρεσία προσδιορίζοντας απλώς το σχήμα ανάπτυξης και, κατά συνέπεια, την ίδια την υπηρεσία στη διαμόρφωση.
Συνήθως, ένα σχήμα ανάπτυξης είναι μια ένδειξη του αριθμού των περιπτώσεων που πρέπει να αναπτυχθούν σε κόμβους συμπλέγματος. Υπάρχουν δύο τυπικά σχήματα ανάπτυξης. Το πρώτο είναι το Cluster Singleton: ανά πάσα στιγμή, μια παρουσία μιας υπηρεσίας χρήστη είναι εγγυημένη ότι είναι διαθέσιμη στο σύμπλεγμα. Το δεύτερο είναι το Node Singleton: μία παρουσία της υπηρεσίας αναπτύσσεται σε κάθε κόμβο συμπλέγματος.
Ο χρήστης μπορεί επίσης να καθορίσει τον αριθμό των παρουσιών υπηρεσίας σε ολόκληρο το σύμπλεγμα και να ορίσει ένα κατηγόρημα για το φιλτράρισμα των κατάλληλων κόμβων. Σε αυτό το σενάριο, το ίδιο το Service Grid θα υπολογίσει τη βέλτιστη κατανομή για την ανάπτυξη υπηρεσιών.
Επιπλέον, υπάρχει μια τέτοια δυνατότητα όπως η υπηρεσία Affinity. Το Affinity είναι μια συνάρτηση που ορίζει τη σχέση των κλειδιών με τα διαμερίσματα και τη σχέση των μερών με τους κόμβους στην τοπολογία. Χρησιμοποιώντας το κλειδί, μπορείτε να προσδιορίσετε τον κύριο κόμβο στον οποίο είναι αποθηκευμένα τα δεδομένα. Με αυτόν τον τρόπο μπορείτε να συσχετίσετε τη δική σας υπηρεσία με μια κρυφή μνήμη κλειδιού και συνάρτησης συνάφειας. Εάν αλλάξει η συνάρτηση συνάφειας, θα πραγματοποιηθεί αυτόματη αναδιάταξη. Με αυτόν τον τρόπο, η υπηρεσία θα βρίσκεται πάντα κοντά στα δεδομένα που χρειάζεται να χειριστεί και, κατά συνέπεια, θα μειώσει τα γενικά έξοδα πρόσβασης σε πληροφορίες. Αυτό το σχήμα μπορεί να ονομαστεί ένα είδος συγκεντρωτικού υπολογισμού.
Τώρα που καταλάβαμε ποια είναι η ομορφιά του Service Grid, ας μιλήσουμε για το ιστορικό ανάπτυξής του.
Τι συνέβη πριν
Η προηγούμενη εφαρμογή του Service Grid βασιζόταν στη μνήμη cache του συστήματος αναπαραγωγής συναλλαγών του Ignite. Η λέξη "cache" στο Ignite αναφέρεται στην αποθήκευση. Δηλαδή, αυτό δεν είναι κάτι προσωρινό, όπως ίσως νομίζετε. Παρά το γεγονός ότι η κρυφή μνήμη αναπαράγεται και κάθε κόμβος περιέχει ολόκληρο το σύνολο δεδομένων, μέσα στη μνήμη cache έχει μια διαμερισμένη αναπαράσταση. Αυτό οφείλεται στη βελτιστοποίηση αποθήκευσης.
Τι συνέβη όταν ο χρήστης ήθελε να αναπτύξει την υπηρεσία;
- Όλοι οι κόμβοι στο σύμπλεγμα έχουν εγγραφεί για ενημέρωση δεδομένων στο χώρο αποθήκευσης χρησιμοποιώντας τον ενσωματωμένο μηχανισμό συνεχούς ερωτήματος.
- Ο κόμβος εκκίνησης, στο πλαίσιο μιας συναλλαγής με δέσμευση ανάγνωσης, έκανε μια εγγραφή στη βάση δεδομένων που περιείχε τη διαμόρφωση της υπηρεσίας, συμπεριλαμβανομένης της σειριακής παρουσίας.
- Όταν ειδοποιήθηκε για μια νέα καταχώριση, ο συντονιστής υπολόγισε τη διανομή με βάση τη διαμόρφωση. Το αντικείμενο που προέκυψε εγγράφηκε πίσω στη βάση δεδομένων.
- Εάν ένας κόμβος ήταν μέρος της διανομής, ο συντονιστής έπρεπε να τον αναπτύξει.
Τι δεν μας ταίριαζε
Κάποια στιγμή καταλήξαμε στο συμπέρασμα: δεν είναι αυτός ο τρόπος δουλειάς με τις υπηρεσίες. Υπήρχαν αρκετοί λόγοι.
Εάν παρουσιάστηκε κάποιο σφάλμα κατά την ανάπτυξη, τότε θα μπορούσε να εντοπιστεί μόνο από τα αρχεία καταγραφής του κόμβου όπου συνέβησαν όλα. Υπήρχε μόνο ασύγχρονη ανάπτυξη, οπότε μετά την επιστροφή του ελέγχου στον χρήστη από τη μέθοδο ανάπτυξης, χρειαζόταν κάποιος επιπλέον χρόνος για να ξεκινήσει η υπηρεσία - και κατά τη διάρκεια αυτής της περιόδου ο χρήστης δεν μπορούσε να ελέγξει τίποτα. Για να αναπτύξετε περαιτέρω το Πλέγμα Υπηρεσιών, να δημιουργήσετε νέες δυνατότητες, να προσελκύσετε νέους χρήστες και να κάνετε τη ζωή όλων πιο εύκολη, κάτι πρέπει να αλλάξει.
Κατά το σχεδιασμό του νέου Πλέγματος Υπηρεσιών, θέλαμε πρώτα απ 'όλα να παράσχουμε μια εγγύηση σύγχρονης ανάπτυξης: μόλις ο χρήστης επέστρεφε τον έλεγχο από το API, θα μπορούσε να χρησιμοποιήσει αμέσως τις υπηρεσίες. Ήθελα επίσης να δώσω στον εκκινητή τη δυνατότητα να χειρίζεται σφάλματα ανάπτυξης.
Επιπλέον, ήθελα να απλοποιήσω την υλοποίηση, δηλαδή να ξεφύγω από τις συναλλαγές και την επανεξισορρόπηση. Παρά το γεγονός ότι η κρυφή μνήμη αναπαράγεται και δεν υπάρχει εξισορρόπηση, προέκυψαν προβλήματα κατά τη διάρκεια μιας μεγάλης ανάπτυξης με πολλούς κόμβους. Όταν αλλάζει η τοπολογία, οι κόμβοι πρέπει να ανταλλάσσουν πληροφορίες και με μεγάλη ανάπτυξη, αυτά τα δεδομένα μπορεί να ζυγίζουν πολύ.
Όταν η τοπολογία ήταν ασταθής, ο συντονιστής έπρεπε να υπολογίσει εκ νέου την κατανομή των υπηρεσιών. Και γενικά, όταν πρέπει να εργαστείτε με συναλλαγές σε ασταθή τοπολογία, αυτό μπορεί να οδηγήσει σε δύσκολα προβλέψιμα σφάλματα.
Προβλήματα
Ποιες είναι οι παγκόσμιες αλλαγές χωρίς συνοδά προβλήματα; Το πρώτο από αυτά ήταν μια αλλαγή στην τοπολογία. Πρέπει να καταλάβετε ότι ανά πάσα στιγμή, ακόμη και τη στιγμή της ανάπτυξης της υπηρεσίας, ένας κόμβος μπορεί να εισέλθει ή να εξέλθει από το σύμπλεγμα. Επιπλέον, εάν κατά τη στιγμή της ανάπτυξης ο κόμβος ενταχθεί στο σύμπλεγμα, θα είναι απαραίτητο να μεταφέρονται με συνέπεια όλες οι πληροφορίες σχετικά με τις υπηρεσίες στον νέο κόμβο. Και δεν μιλάμε μόνο για ό,τι έχει ήδη αναπτυχθεί, αλλά και για τρέχουσες και μελλοντικές αναπτύξεις.
Αυτό είναι μόνο ένα από τα προβλήματα που μπορούν να συγκεντρωθούν σε ξεχωριστή λίστα:
- Πώς να αναπτύξετε υπηρεσίες που έχουν διαμορφωθεί στατικά κατά την εκκίνηση του κόμβου;
- Αφήνοντας έναν κόμβο από το σύμπλεγμα - τι να κάνετε εάν ο κόμβος φιλοξενούσε υπηρεσίες;
- Τι να κάνετε εάν ο συντονιστής έχει αλλάξει;
- Τι να κάνετε εάν ο πελάτης επανασυνδεθεί στο σύμπλεγμα;
- Χρειάζεται επεξεργασία των αιτημάτων ενεργοποίησης/απενεργοποίησης και πώς;
- Τι θα γινόταν αν ζητούσαν την καταστροφή της κρυφής μνήμης και έχουμε συνδεδεμένες υπηρεσίες συνάφειας;
Και δεν είναι μόνο αυτό.
Λύση
Ως στόχο, επιλέξαμε την προσέγγιση Event Driven με την υλοποίηση της επικοινωνίας διαδικασίας με χρήση μηνυμάτων. Το Ignite εφαρμόζει ήδη δύο στοιχεία που επιτρέπουν στους κόμβους να προωθούν μηνύματα μεταξύ τους - επικοινωνία-spi και Discovery-spi.
Το Communication-spi επιτρέπει στους κόμβους να επικοινωνούν απευθείας και να προωθούν μηνύματα. Είναι κατάλληλο για αποστολή μεγάλων ποσοτήτων δεδομένων. Το Discovery-spi σάς επιτρέπει να στέλνετε ένα μήνυμα σε όλους τους κόμβους του συμπλέγματος. Στην τυπική υλοποίηση, αυτό γίνεται χρησιμοποιώντας μια τοπολογία δακτυλίου. Υπάρχει επίσης ενοποίηση με το Zookeeper, σε αυτήν την περίπτωση χρησιμοποιείται τοπολογία αστεριού. Ένα άλλο σημαντικό σημείο που αξίζει να σημειωθεί είναι ότι το discovery-spi παρέχει εγγυήσεις ότι το μήνυμα σίγουρα θα παραδοθεί με τη σωστή σειρά σε όλους τους κόμβους.
Ας δούμε το πρωτόκολλο ανάπτυξης. Όλα τα αιτήματα των χρηστών για ανάπτυξη και κατάργηση της ανάπτυξης αποστέλλονται μέσω Discovery-spi. Αυτό δίνει τα εξής εγγυήσεις:
- Το αίτημα θα ληφθεί από όλους τους κόμβους του συμπλέγματος. Αυτό θα επιτρέψει στο αίτημα να συνεχιστεί η επεξεργασία όταν αλλάξει ο συντονιστής. Αυτό σημαίνει επίσης ότι σε ένα μήνυμα, κάθε κόμβος θα έχει όλα τα απαραίτητα μεταδεδομένα, όπως η διαμόρφωση της υπηρεσίας και η σειριακή παρουσία της.
- Η αυστηρή παραγγελία παράδοσης μηνυμάτων βοηθά στην επίλυση διενέξεων διαμόρφωσης και ανταγωνιστικών αιτημάτων.
- Δεδομένου ότι η είσοδος του κόμβου στην τοπολογία επεξεργάζεται επίσης μέσω Discovery-spi, ο νέος κόμβος θα λάβει όλα τα δεδομένα που είναι απαραίτητα για την εργασία με υπηρεσίες.
Όταν λαμβάνεται ένα αίτημα, οι κόμβοι στο σύμπλεγμα το επικυρώνουν και δημιουργούν εργασίες επεξεργασίας. Αυτές οι εργασίες τοποθετούνται στην ουρά και στη συνέχεια υποβάλλονται σε επεξεργασία σε άλλο νήμα από έναν ξεχωριστό εργαζόμενο. Εφαρμόζεται με αυτόν τον τρόπο, επειδή η ανάπτυξη μπορεί να πάρει σημαντικό χρόνο και να καθυστερήσει αφόρητα την ακριβή ροή ανακάλυψης.
Όλα τα αιτήματα από την ουρά υποβάλλονται σε επεξεργασία από τον διαχειριστή ανάπτυξης. Έχει έναν ειδικό εργαζόμενο που τραβά μια εργασία από αυτήν την ουρά και την προετοιμάζει για να ξεκινήσει η ανάπτυξη. Μετά από αυτό, πραγματοποιούνται οι ακόλουθες ενέργειες:
- Κάθε κόμβος υπολογίζει ανεξάρτητα την κατανομή χάρη σε μια νέα ντετερμινιστική συνάρτηση εκχώρησης.
- Οι κόμβοι δημιουργούν ένα μήνυμα με τα αποτελέσματα της ανάπτυξης και το στέλνουν στον συντονιστή.
- Ο συντονιστής συγκεντρώνει όλα τα μηνύματα και δημιουργεί το αποτέλεσμα ολόκληρης της διαδικασίας ανάπτυξης, το οποίο αποστέλλεται μέσω Discovery-spi σε όλους τους κόμβους του συμπλέγματος.
- Όταν ληφθεί το αποτέλεσμα, η διαδικασία ανάπτυξης τελειώνει, μετά την οποία η εργασία αφαιρείται από την ουρά.
Νέα σχεδίαση που βασίζεται σε συμβάντα: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Εάν παρουσιαστεί σφάλμα κατά την ανάπτυξη, ο κόμβος περιλαμβάνει αμέσως αυτό το σφάλμα σε ένα μήνυμα που στέλνει στον συντονιστή. Μετά τη συγκέντρωση μηνυμάτων, ο συντονιστής θα έχει πληροφορίες για όλα τα σφάλματα κατά την ανάπτυξη και θα στείλει αυτό το μήνυμα μέσω του Discovery-spi. Οι πληροφορίες σφάλματος θα είναι διαθέσιμες σε οποιονδήποτε κόμβο του συμπλέγματος.
Όλα τα σημαντικά συμβάντα στο Service Grid υποβάλλονται σε επεξεργασία χρησιμοποιώντας αυτόν τον αλγόριθμο λειτουργίας. Για παράδειγμα, η αλλαγή της τοπολογίας είναι επίσης ένα μήνυμα μέσω του Discovery-spi. Και γενικά, σε σύγκριση με αυτό που ήταν πριν, το πρωτόκολλο αποδείχθηκε αρκετά ελαφρύ και αξιόπιστο. Αρκετά για να χειριστείτε οποιαδήποτε κατάσταση κατά την ανάπτυξη.
Τι θα συμβεί μετά
Τώρα για τα σχέδια. Οποιαδήποτε σημαντική αλλαγή στο έργο Ignite ολοκληρώνεται ως πρωτοβουλία βελτίωσης Ignite, που ονομάζεται IEP. Ο επανασχεδιασμός του Service Grid έχει επίσης ένα IEP - με τον σκωπτικό τίτλο “Oil change in the Service Grid”. Αλλά στην πραγματικότητα, δεν αλλάξαμε το λάδι του κινητήρα, αλλά ολόκληρο τον κινητήρα.
Χωρίσαμε τις εργασίες στο ΙΕΠ σε 2 φάσεις. Η πρώτη είναι μια σημαντική φάση, η οποία συνίσταται στην εκ νέου επεξεργασία του πρωτοκόλλου ανάπτυξης. Περιλαμβάνεται ήδη στο master, μπορείτε να δοκιμάσετε το νέο Service Grid, το οποίο θα εμφανιστεί στην έκδοση 2.8. Η δεύτερη φάση περιλαμβάνει πολλές άλλες εργασίες:
- Ζεστή αναδιάταξη
- Εκδόσεις υπηρεσιών
- Αυξημένη ανοχή σε σφάλματα
- Λεπτός πελάτης
- Εργαλεία για την παρακολούθηση και τον υπολογισμό διαφόρων μετρήσεων
Τέλος, μπορούμε να σας συμβουλεύσουμε για το Service Grid για την κατασκευή συστημάτων υψηλής διαθεσιμότητας και ανοχής σε σφάλματα. Σας προσκαλούμε επίσης να μας επισκεφτείτε στο и μοιραστείτε την εμπειρία σας. Η εμπειρία σας είναι πραγματικά σημαντική για την κοινότητα· θα σας βοηθήσει να κατανοήσετε πού να προχωρήσετε στη συνέχεια, πώς να αναπτύξετε το στοιχείο στο μέλλον.
Πηγή: www.habr.com