Πώς να σταματήσετε να ανησυχείτε και να αρχίσετε να ζείτε χωρίς μονόλιθο

Πώς να σταματήσετε να ανησυχείτε και να αρχίσετε να ζείτε χωρίς μονόλιθο

Όλοι αγαπάμε τις ιστορίες. Μας αρέσει να καθόμαστε γύρω από τη φωτιά και να μιλάμε για τις προηγούμενες νίκες, τις μάχες ή απλώς την εργασιακή μας εμπειρία.

Σήμερα είναι ακριβώς μια τέτοια μέρα. Και ακόμα κι αν δεν είστε στη φωτιά αυτή τη στιγμή, έχουμε μια ιστορία για εσάς. Η ιστορία του πώς ξεκινήσαμε να δουλεύουμε με την αποθήκευση στο Tarantool.

Μια φορά κι έναν καιρό, η εταιρεία μας είχε δυο «μονόλιθους» και ένα «ταβάνι» για όλους, στους οποίους αυτοί οι μονόλιθοι πλησίαζαν αργά αλλά σταθερά, περιορίζοντας την πτήση της εταιρείας μας, την εξέλιξή μας. Και υπήρχε σαφής κατανόηση: μια μέρα θα χτυπήσουμε δυνατά αυτό το ταβάνι.

Είναι πλέον η κυρίαρχη ιδεολογία του διαχωρισμού των πάντων και όλων, από τον εξοπλισμό μέχρι την επιχειρηματική λογική. Ως αποτέλεσμα, έχουμε, για παράδειγμα, δύο DC που είναι πρακτικά ανεξάρτητα σε επίπεδο δικτύου. Και τότε όλα ήταν τελείως διαφορετικά.

Σήμερα, υπάρχουν πολλά εργαλεία και εργαλεία για την πραγματοποίηση αλλαγών σε μορφή CI/CD, K8S κ.λπ. Στη «μονολιθική» εποχή δεν χρειαζόμασταν τόσες ξένες λέξεις. Αρκούσε απλώς να διορθωθεί η «αποθήκευση» στη βάση δεδομένων.

Αλλά ο χρόνος προχώρησε και ο αριθμός των αιτημάτων προχώρησε μαζί του, μερικές φορές εκτοξεύοντας RPS πέρα ​​από τις δυνατότητές μας. Με την είσοδο των χωρών της ΚΑΚ στην αγορά, το φορτίο στον επεξεργαστή βάσης δεδομένων του πρώτου μονόλιθου δεν έπεσε κάτω από το 90% και το RPS παρέμεινε στο επίπεδο των 2400. Και αυτά δεν ήταν απλώς μικροί επιλογείς, αλλά βαριά ερωτήματα με μια δέσμη επιταγών και JOIN που θα μπορούσαν να εκτελεστούν σχεδόν για τα μισά δεδομένα στο φόντο των μεγάλων IO.

Όταν οι πλήρεις εκπτώσεις της Black Friday άρχισαν να εμφανίζονται στη σκηνή - και οι Wildberries ήταν από τους πρώτους που τις πραγματοποίησαν στη Ρωσία - η κατάσταση έγινε εντελώς θλιβερή. Μετά από όλα, το φορτίο σε τέτοιες ημέρες αυξάνεται τρεις φορές.
Ω, αυτές οι «μονολιθικές εποχές»! Είμαι σίγουρος ότι έχεις βιώσει κάτι παρόμοιο και ακόμα δεν μπορείς να καταλάβεις πώς μπορεί να σου συμβεί αυτό.

Τι μπορείτε να κάνετε - η μόδα είναι εγγενής στην τεχνολογία. Πριν από περίπου 5 χρόνια, έπρεπε να ξανασκεφτούμε ένα από αυτά τα mod με τη μορφή ενός υπάρχοντος ιστότοπου σε διακομιστή .NET και MS SQL, ο οποίος αποθήκευε προσεκτικά όλη τη λογική του ίδιου του ιστότοπου. Το κράτησα τόσο προσεκτικά που το πριόνισμα ενός τέτοιου μονόλιθου αποδείχθηκε μεγάλη και καθόλου εύκολη απόλαυση.
Μια μικρή παρέκκλιση.

Σε διάφορες εκδηλώσεις λέω: "αν δεν είδες μονόλιθο, τότε δεν μεγάλωσες!" Με ενδιαφέρει η γνώμη σας για αυτό το θέμα, γράψτε την στα σχόλια.

A Sound of Thunder

Ας επιστρέψουμε στη «φωτιά» μας. Για να διανείμουμε το φορτίο της «μονολιθικής» λειτουργικότητας, αποφασίσαμε να χωρίσουμε το σύστημα σε μικροϋπηρεσίες που βασίζονται σε τεχνολογίες ανοιχτού κώδικα. Επειδή, τουλάχιστον, είναι φθηνότερα στην κλίμακα. Και είχαμε 100% κατανόηση ότι θα έπρεπε να κλιμακώσουμε (και πολύ). Εξάλλου, ήδη εκείνη την εποχή ήταν δυνατή η είσοδος στις αγορές γειτονικών χωρών και ο αριθμός των εγγραφών, καθώς και ο αριθμός των παραγγελιών, άρχισαν να αυξάνονται ακόμη πιο έντονα.

Έχοντας αναλύσει τους πρώτους υποψήφιους για αποχώρηση από το μονόλιθο στις μικροϋπηρεσίες, συνειδητοποιήσαμε ότι το 80% της γραφής σε αυτά προέρχεται από συστήματα back office και ανάγνωση από το front office. Πρώτα απ 'όλα, αυτό αφορούσε μερικά σημαντικά υποσυστήματα για εμάς - δεδομένα χρήστη και ένα σύστημα για τον υπολογισμό του τελικού κόστους των αγαθών με βάση πληροφορίες σχετικά με πρόσθετες εκπτώσεις και κουπόνια πελατών.

Οδοντωτός. Τώρα είναι τρομακτικό να το φανταστούμε, αλλά εκτός από τα προαναφερθέντα υποσυστήματα, από το μονόλιθο μας αφαιρέθηκαν επίσης κατάλογοι προϊόντων, ένα καλάθι αγορών χρηστών, ένα σύστημα αναζήτησης προϊόντων, ένα σύστημα φιλτραρίσματος για καταλόγους προϊόντων και διάφορα είδη συστημάτων συστάσεων. Για τη λειτουργία καθενός από αυτά, υπάρχουν ξεχωριστές κατηγορίες στενά προσαρμοσμένων συστημάτων, αλλά κάποτε ζούσαν όλοι σε ένα «σπίτι».

Σχεδιάσαμε αμέσως να μεταφέρουμε δεδομένα σχετικά με τους πελάτες μας στο κοινόχρηστο σύστημα. Η κατάργηση της λειτουργικότητας για τον υπολογισμό του τελικού κόστους των αγαθών απαιτούσε καλή επεκτασιμότητα για την ανάγνωση, επειδή δημιουργούσε το μεγαλύτερο φορτίο RPS και ήταν το πιο δύσκολο να εφαρμοστεί για τη βάση δεδομένων (πολλά δεδομένα εμπλέκονται στη διαδικασία υπολογισμού).

Ως αποτέλεσμα, καταλήξαμε σε ένα σχέδιο που ταιριάζει καλά με το Tarantool.

Εκείνη την εποχή, για τη λειτουργία των μικροϋπηρεσιών, επιλέχθηκαν σχήματα εργασίας με πολλά κέντρα δεδομένων σε εικονικές μηχανές και μηχανήματα υλικού. Όπως φαίνεται στα σχήματα, οι επιλογές αναπαραγωγής Tarantool εφαρμόστηκαν τόσο σε λειτουργίες master-master όσο και master-slave.

Πώς να σταματήσετε να ανησυχείτε και να αρχίσετε να ζείτε χωρίς μονόλιθο
Αρχιτεκτονική. Επιλογή 1. Εξυπηρέτηση χρήστη

Αυτή τη στιγμή, υπάρχουν 24 θραύσματα, καθένα από τα οποία έχει 2 περιπτώσεις (μία για κάθε DC), όλα σε λειτουργία master-master.

Στην κορυφή της βάσης δεδομένων υπάρχουν εφαρμογές που έχουν πρόσβαση σε αντίγραφα βάσεων δεδομένων. Οι εφαρμογές λειτουργούν με το Tarantool μέσω της προσαρμοσμένης βιβλιοθήκης μας, η οποία υλοποιεί τη διεπαφή προγράμματος οδήγησης Tarantool Go. Βλέπει όλα τα αντίγραφα και μπορεί να συνεργαστεί με τον κύριο για ανάγνωση και γραφή. Ουσιαστικά, υλοποιεί το μοντέλο συνόλου αντιγράφων, το οποίο προσθέτει λογική για την επιλογή αντιγράφων, την εκτέλεση επαναλήψεων, έναν διακόπτη κυκλώματος και ένα όριο ταχύτητας.

Σε αυτήν την περίπτωση, είναι δυνατό να διαμορφώσετε την πολιτική επιλογής αντιγράφων στο πλαίσιο των θραυσμάτων. Για παράδειγμα, roundrobin.

Πώς να σταματήσετε να ανησυχείτε και να αρχίσετε να ζείτε χωρίς μονόλιθο
Αρχιτεκτονική. Επιλογή 2. Υπηρεσία για τον υπολογισμό του τελικού κόστους των αγαθών

Πριν από λίγους μήνες, τα περισσότερα από τα αιτήματα για τον υπολογισμό του τελικού κόστους των αγαθών πήγαν σε μια νέα υπηρεσία, η οποία, κατ 'αρχήν, λειτουργεί χωρίς βάσεις δεδομένων, αλλά πριν από λίγο καιρό όλα υποβλήθηκαν σε επεξεργασία 100% από μια υπηρεσία με Tarantool κάτω από την κουκούλα.

Η βάση δεδομένων της υπηρεσίας αποτελείται από 4 κύρια στοιχεία στα οποία ο συγχρονιστής συλλέγει δεδομένα και καθένα από αυτά τα κύρια συστήματα αναπαραγωγής διανέμει δεδομένα σε αντίγραφα μόνο για ανάγνωση. Κάθε master έχει περίπου 15 τέτοια αντίγραφα.

Είτε στο πρώτο είτε στο δεύτερο σχήμα, εάν ένα DC δεν είναι διαθέσιμο, η εφαρμογή μπορεί να λάβει δεδομένα στο δεύτερο.

Αξίζει να σημειωθεί ότι η αναπαραγωγή στο Tarantool είναι αρκετά ευέλικτη και μπορεί να ρυθμιστεί κατά το χρόνο εκτέλεσης. Σε άλλα συστήματα προέκυψαν δυσκολίες. Για παράδειγμα, η αλλαγή των παραμέτρων max_wal_senders και max_replication_slots στο PostgreSQL απαιτεί επανεκκίνηση του οδηγού, κάτι που σε ορισμένες περιπτώσεις μπορεί να οδηγήσει σε διακοπή των συνδέσεων μεταξύ της εφαρμογής και του DBMS.

Ψάξε και βρες!

Γιατί δεν το κάναμε «σαν κανονικοί άνθρωποι», αλλά επιλέξαμε έναν άτυπο τρόπο; Εξαρτάται από το τι θεωρείται φυσιολογικό. Πολλοί άνθρωποι γενικά δημιουργούν ένα σύμπλεγμα από το Mongo και το διανέμουν σε τρία γεωδιανεμημένα DC.

Τότε είχαμε ήδη δύο έργα Redis. Το πρώτο ήταν μια κρυφή μνήμη και το δεύτερο ήταν μια μόνιμη αποθήκευση για όχι πολύ κρίσιμα δεδομένα. Ήταν αρκετά δύσκολο μαζί του, εν μέρει λόγω της υπαιτιότητάς μας. Μερικές φορές αρκετά μεγάλοι τόμοι ήταν στο κλειδί, και από καιρό σε καιρό ο ιστότοπος δεν ήταν καλά. Χρησιμοποιήσαμε αυτό το σύστημα στην έκδοση master-slave. Και υπήρξαν πολλές περιπτώσεις όπου κάτι συνέβη στον κύριο και η αναπαραγωγή χάλασε.

Δηλαδή, ο Redis είναι καλός για ανιθαγενείς εργασίες, όχι για κρατικές. Κατ' αρχήν, επέτρεπε την επίλυση των περισσότερων προβλημάτων, αλλά μόνο εάν ήταν λύσεις βασικής τιμής με ένα ζεύγος ευρετηρίων. Αλλά ο Ρέντις εκείνη την εποχή ήταν πολύ λυπημένος με την επιμονή και την αναπαραγωγή. Επιπλέον, υπήρξαν παράπονα για την απόδοση.

Σκεφτήκαμε τη MySQL και την PostgreSQL. Αλλά το πρώτο με κάποιο τρόπο δεν μας έπιασε και το δεύτερο είναι ένα αρκετά εξελιγμένο προϊόν από μόνο του και θα ήταν ακατάλληλο να δημιουργήσουμε απλές υπηρεσίες σε αυτό.
Δοκιμάσαμε το RIAK, την Κασσάνδρα, ακόμη και μια βάση δεδομένων γραφημάτων. Αυτές είναι όλες αρκετά εξειδικευμένες λύσεις που δεν ήταν κατάλληλες για το ρόλο ενός γενικού καθολικού εργαλείου για τη δημιουργία υπηρεσιών.

Τελικά εγκατασταθήκαμε στο Tarantool.

Απευθυνθήκαμε σε αυτό όταν ήταν στην έκδοση 1.6. Μας ενδιέφερε η συμβίωση κλειδιού-τιμής και η λειτουργικότητα μιας σχεσιακής βάσης δεδομένων. Υπάρχουν δευτερεύοντα ευρετήρια, συναλλαγές και κενά, αυτά είναι σαν πίνακες, αλλά όχι απλά, μπορείτε να αποθηκεύσετε διαφορετικούς αριθμούς στηλών σε αυτά. Αλλά το δολοφονικό χαρακτηριστικό του Tarantool ήταν οι δευτερεύοντες δείκτες σε συνδυασμό με την τιμή-κλειδί και τη συναλλακτικότητα.

Η ανταποκρινόμενη ρωσόφωνη κοινότητα, έτοιμη να βοηθήσει στη συνομιλία, έπαιξε επίσης ρόλο. Το χρησιμοποιήσαμε ενεργά και ζούμε απευθείας στη συνομιλία. Και μην ξεχνάτε την αξιοπρεπή επίμονη χωρίς εμφανείς γκάφες και λάθη. Αν κοιτάξετε το ιστορικό μας με το Tarantool, είχαμε πολύ πόνο και αποτυχίες με την αναπαραγωγή, αλλά ποτέ δεν χάσαμε δεδομένα λόγω υπαιτιότητας του!

Η εφαρμογή ξεκίνησε δύσκολα

Εκείνη την εποχή, η κύρια στοίβα ανάπτυξης μας ήταν το .NET, στο οποίο δεν υπήρχε σύνδεση για το Tarantool. Αρχίσαμε αμέσως να κάνουμε κάτι στο Go. Δούλεψε καλά και με τον Λούα. Το κύριο πρόβλημα εκείνη την εποχή ήταν με τον εντοπισμό σφαλμάτων: στο .NET όλα είναι υπέροχα με αυτό, αλλά μετά από αυτό ήταν δύσκολο να βουτήξεις στον κόσμο του ενσωματωμένου Lua, όταν δεν έχεις εντοπισμό σφαλμάτων εκτός από αρχεία καταγραφής. Επιπλέον, για κάποιο λόγο η αναπαραγωγή καταρρέει περιοδικά, οπότε έπρεπε να εμβαθύνω στη δομή του κινητήρα Tarantool. Η συνομιλία βοήθησε σε αυτό, και σε μικρότερο βαθμό, η τεκμηρίωση· μερικές φορές κοιτάζαμε τον κώδικα. Εκείνη την εποχή, η τεκμηρίωση ήταν έτσι-έτσι.

Έτσι, κατά τη διάρκεια αρκετών μηνών, κατάφερα να βρω το μυαλό μου και να έχω αξιοπρεπή αποτελέσματα από τη συνεργασία με το Tarantool. Συγκεντρώσαμε εξελίξεις αναφοράς στο git που βοήθησαν στη δημιουργία νέων μικροϋπηρεσιών. Για παράδειγμα, όταν προέκυψε μια εργασία: για τη δημιουργία μιας άλλης microservice, ο προγραμματιστής εξέτασε τον πηγαίο κώδικα της λύσης αναφοράς στο αποθετήριο και δεν χρειάστηκε περισσότερο από μία εβδομάδα για να δημιουργήσει μια νέα.

Ήταν ειδικές εποχές. Συμβατικά, τότε θα μπορούσατε να πάτε στον διαχειριστή στο διπλανό τραπέζι και να ρωτήσετε: "Δώστε μου μια εικονική μηχανή". Περίπου τριάντα λεπτά αργότερα το αυτοκίνητο ήταν ήδη μαζί σας. Συνδεθήκατε μόνοι σας, εγκαταστήσατε τα πάντα και η κίνηση στάλθηκε σε εσάς.

Σήμερα αυτό δεν θα λειτουργεί πλέον: πρέπει να προσθέσετε παρακολούθηση και καταγραφή στην υπηρεσία, να καλύψετε τη λειτουργικότητα με δοκιμές, να παραγγείλετε μια εικονική μηχανή ή παράδοση στην Kuber κ.λπ. Σε γενικές γραμμές, θα είναι καλύτερα έτσι, αν και θα πάρει περισσότερο χρόνο και θα είναι πιο ενοχλητικό.

Διαίρει και βασίλευε. Τι συμβαίνει με τον Λούα;

Υπήρχε ένα σοβαρό δίλημμα: ορισμένες ομάδες δεν μπόρεσαν να κάνουν αξιόπιστες αλλαγές σε μια υπηρεσία με πολλή λογική στο Lua. Αυτό συνοδευόταν συχνά από το ότι η υπηρεσία δεν λειτουργούσε.

Δηλαδή, οι προγραμματιστές ετοιμάζουν κάποιου είδους αλλαγή. Το Tarantool ξεκινά να κάνει τη μετεγκατάσταση, αλλά το αντίγραφο εξακολουθεί να είναι με τον παλιό κώδικα. Κάποιο DDL ή κάτι άλλο φτάνει εκεί μέσω αναπαραγωγής και ο κώδικας απλώς καταρρέει επειδή δεν λαμβάνεται υπόψη. Ως αποτέλεσμα, η διαδικασία ενημέρωσης για τους διαχειριστές παρουσιάστηκε σε φύλλο Α4: διακοπή αναπαραγωγής, ενημέρωση αυτού, ενεργοποίηση αναπαραγωγής, απενεργοποίηση εδώ, ενημέρωση εκεί. Εφιάλτης!

Ως αποτέλεσμα, τώρα προσπαθούμε τις περισσότερες φορές να μην κάνουμε τίποτα στη Λούα. Απλώς χρησιμοποιήστε το iproto (ένα δυαδικό πρωτόκολλο για την αλληλεπίδραση με τον διακομιστή) και αυτό είναι. Ίσως πρόκειται για έλλειψη γνώσης μεταξύ των προγραμματιστών, αλλά από αυτή την άποψη το σύστημα είναι πολύπλοκο.

Δεν ακολουθούμε πάντα τυφλά αυτό το σενάριο. Σήμερα δεν έχουμε ασπρόμαυρο: είτε όλα είναι στο Λούα, είτε όλα είναι στο Γκό. Καταλαβαίνουμε ήδη πώς μπορούμε να τα συνδυάσουμε ώστε να μην καταλήξουμε αργότερα με προβλήματα μετανάστευσης.

Πού είναι τώρα ο Tarantool;
Το Tarantool χρησιμοποιείται στην υπηρεσία για τον υπολογισμό του τελικού κόστους των αγαθών λαμβάνοντας υπόψη τα εκπτωτικά κουπόνια, γνωστή και ως «Promoter». Όπως είπα νωρίτερα, τώρα συνταξιοδοτείται: αντικαθίσταται από μια νέα υπηρεσία καταλόγου με προυπολογισμένες τιμές, αλλά πριν από έξι μήνες όλοι οι υπολογισμοί έγιναν στο Promotizer. Παλαιότερα, η μισή λογική του ήταν γραμμένη στο Lua. Πριν από δύο χρόνια, η υπηρεσία μετατράπηκε σε αποθηκευτικό χώρο και η λογική ξαναγράφτηκε στο Go, επειδή είχαν αλλάξει λίγο οι μηχανισμοί των εκπτώσεων και η υπηρεσία δεν είχε απόδοση.

Μία από τις πιο κρίσιμες υπηρεσίες είναι το προφίλ χρήστη. Δηλαδή, όλοι οι χρήστες του Wildberries είναι αποθηκευμένοι στο Tarantool, και υπάρχουν περίπου 50 εκατομμύρια από αυτούς.Ένα σύστημα κατανεμημένο με αναγνωριστικό χρήστη, κατανεμημένο σε πολλά DC συνδεδεμένα με υπηρεσίες Go.
Σύμφωνα με την RPS, ο Promoter ήταν κάποτε ο ηγέτης, φτάνοντας τα 6 χιλιάδες αιτήματα. Κάποια στιγμή είχαμε 50-60 αντίτυπα. Τώρα ο ηγέτης στο RPS είναι τα προφίλ χρηστών, περίπου 12 χιλιάδες. Αυτή η υπηρεσία χρησιμοποιεί προσαρμοσμένο κοινόχρηστο, διαιρούμενο με εύρη αναγνωριστικών χρηστών. Η υπηρεσία εξυπηρετεί περισσότερα από 20 μηχανήματα, αλλά αυτά είναι πάρα πολλά· σχεδιάζουμε να μειώσουμε τους διατιθέμενους πόρους, επειδή η χωρητικότητα 4-5 μηχανών είναι αρκετή για αυτό.

Η υπηρεσία συνεδρίας είναι η πρώτη μας υπηρεσία σε vshard και Cartridge. Η εγκατάσταση του vshard και η ενημέρωση του Cartridge απαιτούσαν λίγη προσπάθεια από εμάς, αλλά τελικά όλα λειτούργησαν.

Η υπηρεσία για την εμφάνιση διαφορετικών banner στον ιστότοπο και στην εφαρμογή για κινητά ήταν από τις πρώτες που κυκλοφόρησε απευθείας στο Tarantool. Αυτή η υπηρεσία είναι αξιοσημείωτη για το γεγονός ότι είναι 6-7 ετών, είναι ακόμα σε λειτουργία και δεν έχει γίνει ποτέ επανεκκίνηση. Χρησιμοποιήθηκε αντιγραφή Master-master. Τίποτα δεν χάλασε ποτέ.

Υπάρχει ένα παράδειγμα χρήσης του Tarantool για λειτουργία γρήγορης αναφοράς σε ένα σύστημα αποθήκης για τον γρήγορο διπλό έλεγχο των πληροφοριών σε ορισμένες περιπτώσεις. Προσπαθήσαμε να χρησιμοποιήσουμε το Redis για αυτό, αλλά τα δεδομένα στη μνήμη καταλάμβαναν περισσότερο χώρο από το Tarantool.

Οι υπηρεσίες μιας λίστας αναμονής, οι συνδρομές πελατών, οι επί του παρόντος μοδάτες ιστορίες και τα προϊόντα αναβολής συνεργάζονται επίσης με το Tarantool. Η τελευταία υπηρεσία στη μνήμη καταλαμβάνει περίπου 120 GB. Αυτή είναι η πιο ολοκληρωμένη υπηρεσία από τις παραπάνω.

Συμπέρασμα

Χάρη στα δευτερεύοντα ευρετήρια σε συνδυασμό με το κλειδί-τιμή και τη συναλλακτικότητα, το Tarantool είναι κατάλληλο για αρχιτεκτονικές που βασίζονται σε μικροϋπηρεσίες. Ωστόσο, αντιμετωπίσαμε δυσκολίες κατά την ανάπτυξη αλλαγών σε υπηρεσίες με πολλή λογική στο Lua - οι υπηρεσίες συχνά σταματούσαν να λειτουργούν. Δεν μπορέσαμε να το ξεπεράσουμε και με τον καιρό καταλήξαμε σε διαφορετικούς συνδυασμούς Lua και Go: ξέρουμε πού να χρησιμοποιήσουμε μια γλώσσα και πού να χρησιμοποιήσουμε μια άλλη.

Τι άλλο να διαβάσετε για το θέμα

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο