History of the Dodo IS Architecture: The Back Office Path

Ο Χαμπρ αλλάζει τον κόσμο. Έχουμε blogging για πάνω από ένα χρόνο τώρα. Πριν από περίπου έξι μήνες, λάβαμε ένα απολύτως λογικό feedback από τους Khabrovites: «Dodo, λες παντού ότι έχεις το δικό σου σύστημα. Και τι είναι αυτό το σύστημα; Και γιατί το χρειάζεται μια αλυσίδα πίτσας;

Καθίσαμε, σκεφτήκαμε και καταλάβαμε ότι έχεις δίκιο. Προσπαθούμε να εξηγήσουμε τα πάντα στα δάχτυλά μας, αλλά βγαίνει σε σκισμένα κομμάτια και πουθενά δεν υπάρχει πλήρης περιγραφή του συστήματος. Έτσι ξεκίνησε ένα μακρύ ταξίδι συλλογής πληροφοριών, αναζήτησης συγγραφέων και συγγραφής μιας σειράς άρθρων για το Dodo IS. Πάμε!

Ευχαριστίες: Σας ευχαριστούμε που μοιραστήκατε τα σχόλιά σας μαζί μας. Χάρη σε αυτόν, περιγράψαμε τελικά το σύστημα, συντάξαμε ένα τεχνικό ραντάρ και σύντομα θα παρουσιάσουμε μια μεγάλη περιγραφή των διαδικασιών μας. Χωρίς εσάς, θα καθόμασταν εκεί για άλλα 5 χρόνια.

Σειρά άρθρων "Τι είναι το Dodo IS;" λέει για:

1. Πρώιμος μονόλιθος στο Dodo IS (2011-2015). (Σε εξέλιξη...)
2. Η διαδρομή πίσω γραφείου: ξεχωριστές βάσεις και λεωφορείο. (είστε εδώ)
3. Η διαδρομή από την πλευρά του πελάτη: πρόσοψη πάνω από τη βάση (2016-2017). (Σε εξέλιξη...)
4. Η ιστορία των πραγματικών μικροϋπηρεσιών. (2018-2019). (Σε εξέλιξη...)
5. Ολοκληρώθηκε το πριόνισμα του μονόλιθου και η σταθεροποίηση της αρχιτεκτονικής. (Σε εξέλιξη...)

Εάν ενδιαφέρεστε να μάθετε κάτι άλλο - γράψτε στα σχόλια.

Γνώμη για τη χρονολογική περιγραφή από τον συγγραφέα
Κάνω τακτικά μια συνάντηση για νέους εργαζόμενους με θέμα "Αρχιτεκτονική Συστήματος". Το ονομάζουμε "Intro to Dodo IS Architecture" και αποτελεί μέρος της διαδικασίας ενσωμάτωσης για νέους προγραμματιστές. Λέγοντας με τη μια ή την άλλη μορφή για την αρχιτεκτονική μας, για τα χαρακτηριστικά της, έχω γεννήσει μια ορισμένη ιστορική προσέγγιση στην περιγραφή.

Παραδοσιακά, αντιμετωπίζουμε το σύστημα ως ένα σύνολο στοιχείων (τεχνικών ή υψηλότερου επιπέδου), επιχειρηματικές ενότητες που αλληλεπιδρούν μεταξύ τους για την επίτευξη κάποιου στόχου. Και αν μια τέτοια άποψη δικαιολογείται για σχεδιασμό, τότε δεν είναι αρκετά κατάλληλη για περιγραφή και κατανόηση. Υπάρχουν διάφοροι λόγοι εδώ:

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

Το 2011, η αρχιτεκτονική Dodo IS έμοιαζε ως εξής:

Μέχρι το 2020, έχει γίνει λίγο πιο περίπλοκο και έχει γίνει έτσι:

Πώς έγινε αυτή η εξέλιξη; Γιατί χρειάζονται διαφορετικά μέρη του συστήματος; Ποιες αρχιτεκτονικές αποφάσεις λήφθηκαν και γιατί; Ας μάθουμε σε αυτή τη σειρά άρθρων.

Τα πρώτα προβλήματα του 2016: γιατί οι υπηρεσίες να φύγουν από το μονόλιθο

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

Μια ενιαία βάση δεδομένων MySql, στην οποία όλες οι εφαρμογές που υπήρχαν εκείνη την εποχή στο Dodo IS έγραψαν τα αρχεία τους. Οι συνέπειες ήταν:

• Βαρύ φορτίο (με το 85% των αιτημάτων να αφορούν ανάγνωση).
• Η βάση μεγάλωσε. Εξαιτίας αυτού, το κόστος και η υποστήριξή του έγιναν πρόβλημα.
• Μοναδικό σημείο αποτυχίας. Εάν μια εφαρμογή που έγραφε στη βάση δεδομένων άρχισε ξαφνικά να το κάνει πιο ενεργά, τότε άλλες εφαρμογές το ένιωσαν από μόνες τους.
• Αναποτελεσματικότητα στην αποθήκευση και τα ερωτήματα. Συχνά τα δεδομένα αποθηκεύονταν σε κάποια δομή που ήταν βολική για ορισμένα σενάρια αλλά δεν ήταν κατάλληλη για άλλα. Τα ευρετήρια επιταχύνουν ορισμένες λειτουργίες, αλλά μπορούν να επιβραδύνουν άλλες.
• Μερικά από τα προβλήματα αφαιρέθηκαν από βιαστικά δημιουργημένες κρυφές μνήμες και αντίγραφα ανάγνωσης στις βάσεις (αυτό θα είναι ξεχωριστό άρθρο), αλλά τους επέτρεψαν μόνο να κερδίσουν χρόνο και δεν έλυσαν ουσιαστικά το πρόβλημα.

Το πρόβλημα ήταν η παρουσία του ίδιου του μονόλιθου. Οι συνέπειες ήταν:

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

Προβλήματα με τη βάση και το μονόλιθο έχουν περιγραφεί πολλές φορές, για παράδειγμα, στο πλαίσιο ατυχημάτων στις αρχές του 2018 (Γίνε σαν τον Μουνκ, ή λίγα λόγια για το τεχνικό χρέος, Την ημέρα που ο Dodo σταμάτησε. Ασύγχρονο σενάριο и Η ιστορία του πουλιού Dodo από την οικογένεια Phoenix. Η Μεγάλη Πτώση του Ντόντο ΕΙΝΑΙ), οπότε δεν θα μείνω πολύ. Επιτρέψτε μου απλώς να πω ότι θέλαμε να δώσουμε μεγαλύτερη ευελιξία κατά την ανάπτυξη υπηρεσιών. Πρώτα απ 'όλα, αυτό αφορούσε εκείνα που ήταν τα πιο φορτωμένα και root σε ολόκληρο το σύστημα - Auth και Tracker.

The Back Office Path: Ξεχωριστές Βάσεις και Λεωφορείο

Πλοήγηση κεφαλαίων

1. Μονόλιθος σχέδιο 2016
2. Ξεκινώντας να ξεφορτώνετε το Monolith: Auth and Tracker Separation
   
3. Τι κάνει το Auth;
4. Από πού είναι τα φορτία;
5. Unloading Auth
6. Τι κάνει το Tracker;
7. Από πού είναι τα φορτία;
8. Εκφόρτωση Tracker

Μονόλιθος σχέδιο 2016

Εδώ είναι τα κύρια μπλοκ του μονόλιθου Dodo IS 2016 και ακριβώς από κάτω είναι μια μεταγραφή των κύριων εργασιών τους.

Παράδοση στο ταμείο. Λογιστική για ταχυμεταφορείς, έκδοση παραγγελιών σε ταχυμεταφορείς.
Κέντρο επικοινωνίας. Αποδοχή παραγγελιών μέσω του χειριστή.
Τοποθεσία. Οι ιστοσελίδες μας (dodopizza.ru, dodopizza.co.uk, dodopizza.by, κ.λπ.).
Auth. Εξουσιοδότηση και υπηρεσία ελέγχου ταυτότητας για το back office.
Tracker. Ιχνηλάτη παραγγελιών στην κουζίνα. Υπηρεσία επισήμανσης καταστάσεων ετοιμότητας κατά την προετοιμασία μιας παραγγελίας.
Ταμείο του Εστιατορίου. Λήψη παραγγελιών σε εστιατόριο, διεπαφές ταμείου.
εξαγωγή. Μεταφόρτωση αναφορών σε 1C για λογιστική.
Ειδοποιήσεις και τιμολόγια. Φωνητικές εντολές στην κουζίνα (για παράδειγμα, "Η νέα πίτσα έφτασε") + εκτύπωση τιμολογίου για κούριερ.
ΥΠΕΥΘΥΝΟΣ ΒΑΡΔΙΑΣ. Διεπαφές για την εργασία του διευθυντή βάρδιας: λίστα παραγγελιών, γραφήματα απόδοσης, μεταφορά εργαζομένων στη βάρδια.
Διευθυντής γραφείου. Διεπαφές για την εργασία του δικαιοδόχου και του διευθυντή: υποδοχή εργαζομένων, αναφορές για το έργο της πιτσαρίας.
Πίνακας αποτελεσμάτων εστιατορίου. Εμφάνιση μενού σε τηλεοράσεις σε πιτσαρίες.
διαχειριστής. Ρυθμίσεις σε μια συγκεκριμένη πιτσαρία: μενού, τιμές, λογιστικά, κωδικοί προσφοράς, προσφορές, banner ιστότοπου κ.λπ.
Προσωπικός Λογαριασμός Υπαλλήλου. Προγράμματα εργασίας των εργαζομένων, πληροφορίες για τους εργαζόμενους.
Πίνακας κινήτρων κουζίνας. Μια ξεχωριστή οθόνη που κρέμεται στην κουζίνα και εμφανίζει την ταχύτητα των πίτσας.
Επικοινωνία. Αποστολή sms και email.
Αποθήκευση αρχείων. Ίδια υπηρεσία λήψης και έκδοσης στατικών αρχείων.

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

Ξεκινώντας να ξεφορτώνετε το Monolith: Auth and Tracker Separation

Οι κύριες υπηρεσίες που στη συνέχεια κατέγραψαν και διάβασαν από τη βάση δεδομένων περισσότερο από άλλες:

1. Auth. Εξουσιοδότηση και υπηρεσία ελέγχου ταυτότητας για το back office.
2. Ιχνηλάτης. Ιχνηλάτη παραγγελιών στην κουζίνα. Υπηρεσία επισήμανσης καταστάσεων ετοιμότητας κατά την προετοιμασία μιας παραγγελίας.

Τι κάνει το Auth;

Το Auth είναι μια υπηρεσία μέσω της οποίας οι χρήστες συνδέονται στο back office (υπάρχει ξεχωριστή ανεξάρτητη είσοδος στην πλευρά του πελάτη). Καλείται επίσης στο αίτημα να βεβαιωθεί ότι υπάρχουν τα απαιτούμενα δικαιώματα πρόσβασης και ότι αυτά τα δικαιώματα δεν έχουν αλλάξει από την τελευταία σύνδεση. Μέσω αυτού μπαίνουν συσκευές στην πιτσαρία.

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

Από πού είναι τα φορτία;

Κάθε συνδεδεμένος χρήστης του back office πηγαίνει στη βάση δεδομένων, στον πίνακα χρηστών για κάθε αίτημα, βγάζει τον χρήστη μέσω ενός ερωτήματος sql και ελέγχει αν έχει την απαραίτητη πρόσβαση και δικαιώματα σε αυτή τη σελίδα.

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

Unloading Auth

Το Auth έχει έναν απομονωμένο τομέα, δηλαδή δεδομένα σχετικά με χρήστες, συνδέσεις ή συσκευές εισέρχονται στην υπηρεσία (προς το παρόν) και παραμένουν εκεί. Αν κάποιος τα χρειάζεται, τότε θα πάει σε αυτή την υπηρεσία για δεδομένα.

ΗΤΑΝ. Το αρχικό σχέδιο εργασίας ήταν το εξής:

Θα ήθελα να εξηγήσω λίγο πώς λειτούργησε:

1. Ένα αίτημα από το εξωτερικό έρχεται στο backend (υπάρχει Asp.Net MVC), φέρνει μαζί του ένα cookie περιόδου λειτουργίας, το οποίο χρησιμοποιείται για τη λήψη δεδομένων συνεδρίας από το Redis(1). Είτε περιέχει πληροφορίες σχετικά με τις προσβάσεις και, στη συνέχεια, η πρόσβαση στον ελεγκτή είναι ανοιχτή (3,4) ή όχι.
2. Εάν δεν υπάρχει πρόσβαση, πρέπει να περάσετε από τη διαδικασία εξουσιοδότησης. Εδώ, για λόγους απλότητας, εμφανίζεται ως μέρος της διαδρομής στο ίδιο χαρακτηριστικό, αν και είναι μια μετάβαση στη σελίδα σύνδεσης. Σε περίπτωση θετικού σεναρίου, θα λάβουμε μια σωστά ολοκληρωμένη περίοδο λειτουργίας και θα πάμε στον Ελεγκτή Backoffice.
3. Εάν υπάρχουν δεδομένα, τότε πρέπει να τα ελέγξετε για συνάφεια στη βάση δεδομένων των χρηστών. Έχει αλλάξει ο ρόλος του, δεν πρέπει να του επιτραπεί να μπει στη σελίδα τώρα; Σε αυτήν την περίπτωση, μετά τη λήψη της συνεδρίας (1), πρέπει να μεταβείτε απευθείας στη βάση δεδομένων και να ελέγξετε την πρόσβαση του χρήστη χρησιμοποιώντας το επίπεδο λογικής ελέγχου ταυτότητας (2). Στη συνέχεια, είτε στη σελίδα σύνδεσης, είτε μεταβείτε στον ελεγκτή. Ένα τόσο απλό σύστημα, αλλά όχι αρκετά τυπικό.
4. Εάν περάσουν όλες οι διαδικασίες, τότε παρακάμπτουμε περαιτέρω τη λογική στους ελεγκτές και τις μεθόδους.

Τα δεδομένα χρήστη διαχωρίζονται από όλα τα άλλα δεδομένα, αποθηκεύονται σε ξεχωριστό πίνακα μελών, οι λειτουργίες από το λογικό επίπεδο AuthService μπορεί κάλλιστα να γίνουν μέθοδοι api. Τα όρια του τομέα ορίζονται αρκετά ξεκάθαρα: οι χρήστες, οι ρόλοι τους, τα δεδομένα πρόσβασης, η παραχώρηση και η ανάκληση πρόσβασης. Όλα φαίνονται έτσι ώστε να μπορεί να βγει σε ξεχωριστή υπηρεσία.

ΓΙΝΟΜΑΙ. Έτσι έκαναν:

Αυτή η προσέγγιση έχει μια σειρά από προβλήματα. Για παράδειγμα, η κλήση μιας μεθόδου μέσα σε μια διεργασία δεν είναι το ίδιο με την κλήση μιας εξωτερικής υπηρεσίας μέσω http. Η καθυστέρηση, η αξιοπιστία, η συντηρησιμότητα, η διαφάνεια της λειτουργίας είναι εντελώς διαφορετικά. Ο Andrey Morevskiy μίλησε λεπτομερέστερα για τέτοια προβλήματα στην έκθεσή του. "50 Shades of Microservices".

Η υπηρεσία ελέγχου ταυτότητας και, μαζί με αυτήν, η υπηρεσία συσκευών χρησιμοποιούνται για το back office, δηλαδή για υπηρεσίες και διεπαφές που χρησιμοποιούνται στην παραγωγή. Ο έλεγχος ταυτότητας για υπηρεσίες πελατών (όπως ένας ιστότοπος ή μια εφαρμογή για κινητά) πραγματοποιείται ξεχωριστά χωρίς τη χρήση του Auth. Ο διαχωρισμός κράτησε περίπου ένα χρόνο και τώρα ασχολούμαστε ξανά με αυτό το θέμα, μεταφέροντας το σύστημα σε νέες υπηρεσίες ελέγχου ταυτότητας (με τυπικά πρωτόκολλα).

Γιατί άργησε τόσο πολύ ο χωρισμός;
Υπήρχαν πολλά προβλήματα στην πορεία που μας επιβράδυναν:

1. Θέλαμε να μετακινήσουμε δεδομένα χρήστη, συσκευής και ελέγχου ταυτότητας από βάσεις δεδομένων συγκεκριμένης χώρας σε μία. Για να γίνει αυτό, έπρεπε να μεταφράσουμε όλους τους πίνακες και τη χρήση από το αναγνωριστικό int στο καθολικό αναγνωριστικό UUId (επεξεργάστηκε πρόσφατα αυτόν τον κώδικα Roman Bukin "Uuid - μια μεγάλη ιστορία μιας μικρής δομής" και έργο ανοιχτού κώδικα Πρωτόγονοι). Η αποθήκευση δεδομένων χρήστη (καθώς είναι προσωπικές πληροφορίες) έχει τους περιορισμούς της και για ορισμένες χώρες είναι απαραίτητο να αποθηκεύονται χωριστά. Αλλά το καθολικό αναγνωριστικό του χρήστη πρέπει να είναι.
2. Πολλοί πίνακες στη βάση δεδομένων έχουν πληροφορίες ελέγχου σχετικά με τον χρήστη που πραγματοποίησε τη λειτουργία. Αυτό απαιτούσε έναν πρόσθετο μηχανισμό συνέπειας.
3. Μετά τη δημιουργία των api-services, υπήρξε μια μακρά και σταδιακή περίοδος μετάβασης σε άλλο σύστημα. Η εναλλαγή έπρεπε να είναι απρόσκοπτη για τους χρήστες και απαιτούσε χειρωνακτική εργασία.

Πρόγραμμα εγγραφής συσκευής σε πιτσαρία:

Γενική αρχιτεκτονική μετά την εξαγωγή της υπηρεσίας Auth and Devices:

Σημείωση. Για το 2020, εργαζόμαστε σε μια νέα έκδοση του Auth, η οποία βασίζεται στο πρότυπο εξουσιοδότησης OAuth 2.0. Αυτό το πρότυπο είναι αρκετά περίπλοκο, αλλά είναι χρήσιμο για την ανάπτυξη μιας υπηρεσίας ελέγχου ταυτότητας μετάδοσης. Στο άρθρο "Λεπτές λεπτομέρειες της εξουσιοδότησης: μια επισκόπηση της τεχνολογίας OAuth 2.0» Εμείς ο Alexey Chernyaev προσπαθήσαμε να πούμε για το πρότυπο όσο το δυνατόν πιο απλά και ξεκάθαρα, ώστε να εξοικονομήσετε χρόνο στη μελέτη του.

Τι κάνει το Tracker;

Τώρα για τη δεύτερη από τις φορτωμένες υπηρεσίες. Ο ιχνηλάτης εκτελεί διπλό ρόλο:

• Από τη μία πλευρά, το καθήκον του είναι να δείξει στους υπαλλήλους στην κουζίνα ποιες παραγγελίες γίνονται αυτήν τη στιγμή, ποια προϊόντα πρέπει να μαγειρέψουν τώρα.
• Από την άλλη, να ψηφιοποιηθούν όλες οι διαδικασίες στην κουζίνα.

Όταν ένα νέο προϊόν εμφανίζεται σε μια παραγγελία (για παράδειγμα, πίτσα), πηγαίνει στο σταθμό παρακολούθησης Rolling out. Σε αυτόν τον σταθμό, υπάρχει ένας παρασκευαστής πίτσας που παίρνει ένα τσουρέκι του απαιτούμενου μεγέθους και το ξετυλίγει, μετά το οποίο σημειώνει στο tablet παρακολούθησης ότι ολοκλήρωσε την εργασία του και μεταφέρει τη βάση της ζύμης στον επόμενο σταθμό - "Initiation" .

Εκεί, ο επόμενος παρασκευαστής πίτσας γεμίζει την πίτσα, μετά σημειώνει στο tablet ότι ολοκλήρωσε την εργασία του και βάζει την πίτσα στο φούρνο (αυτός είναι επίσης ένας ξεχωριστός σταθμός που πρέπει να σημειωθεί στο tablet). Ένα τέτοιο σύστημα ήταν από την αρχή στο Dodo και από την αρχή της ύπαρξης του Dodo IS. Σας επιτρέπει να παρακολουθείτε πλήρως και να ψηφιοποιείτε όλες τις συναλλαγές. Επιπλέον, ο ιχνηλάτης προτείνει τον τρόπο μαγειρέματος ενός συγκεκριμένου προϊόντος, καθοδηγεί κάθε τύπο προϊόντος σύμφωνα με τα σχέδια κατασκευής του, αποθηκεύει τον βέλτιστο χρόνο μαγειρέματος για το προϊόν και παρακολουθεί όλες τις λειτουργίες του προϊόντος.

Έτσι μοιάζει η οθόνη του tablet στο σταθμό του ιχνηλάτη "Raskatka"

Από πού είναι τα φορτία;

Κάθε μια από τις πιτσαρίες έχει περίπου πέντε ταμπλέτες με ιχνηλάτη. Το 2016 είχαμε περισσότερες από 100 πιτσαρίες (και τώρα περισσότερες από 600). Κάθε ένα από τα tablet κάνει ένα αίτημα στο backend μία φορά κάθε 10 δευτερόλεπτα και αφαιρεί δεδομένα από τον πίνακα παραγγελιών (σύνδεση με τον πελάτη και διεύθυνση), τη σύνθεση παραγγελίας (σύνδεση με το προϊόν και ένδειξη της ποσότητας), τον πίνακα λογιστικής κινήτρων (το ο χρόνος πίεσης παρακολουθείται σε αυτό). Όταν ένας παρασκευαστής πίτσας κάνει κλικ σε ένα προϊόν στον ιχνηλάτη, οι καταχωρήσεις σε όλους αυτούς τους πίνακες ενημερώνονται. Ο πίνακας παραγγελιών είναι γενικός, περιέχει επίσης ένθετα κατά την αποδοχή μιας παραγγελίας, ενημερώσεις από άλλα μέρη του συστήματος και πολλές αναγνώσεις, για παράδειγμα, σε μια τηλεόραση που βρίσκεται σε μια πιτσαρία και εμφανίζει έτοιμες παραγγελίες στους πελάτες.

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

Επίσης, η έλλειψη δικών πινάκων και ευρετηρίων σε αυτούς δεν επέτρεπε τη σύνταξη πιο συγκεκριμένων ερωτημάτων προσαρμοσμένων για τη χρήση τους. Για παράδειγμα, μπορεί να είναι αποτελεσματικό για έναν ιχνηλάτη να έχει ένα ευρετήριο για μια πιτσαρία σε έναν πίνακα παραγγελιών. Πάντα αφαιρούμε τις παραγγελίες πιτσαρίας από τη βάση δεδομένων παρακολούθησης. Ταυτόχρονα, για τη λήψη μιας παραγγελίας, δεν είναι τόσο σημαντικό σε ποια πιτσαρία ανήκει, είναι πιο σημαντικό σε ποιον πελάτη έκανε αυτή την παραγγελία. Και σημαίνει ότι εκεί το ευρετήριο στον πελάτη είναι απαραίτητο. Επίσης, δεν είναι απαραίτητο για το tracker να αποθηκεύει το αναγνωριστικό της εκτυπωμένης απόδειξης ή τις προσφορές μπόνους που σχετίζονται με την παραγγελία στον πίνακα παραγγελιών. Αυτές οι πληροφορίες δεν ενδιαφέρουν την υπηρεσία παρακολούθησης. Σε μια κοινή μονολιθική βάση δεδομένων, οι πίνακες θα μπορούσαν να αποτελούν συμβιβασμό μόνο μεταξύ όλων των χρηστών. Αυτό ήταν ένα από τα αρχικά προβλήματα.

ΗΤΑΝ. Η αρχική αρχιτεκτονική ήταν:

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

Εκφόρτωση Tracker

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

Δεχόμαστε μια παραγγελία στο Ταμείο του Εστιατορίου (αυτή είναι υπηρεσία), αποθηκεύεται στη βάση δεδομένων στην κατάσταση "Αποδεκτό". Μετά από αυτό, θα πρέπει να φτάσει στον ιχνηλάτη, όπου θα αλλάξει την κατάστασή του αρκετές φορές: από "Κουζίνα" σε "Συσκευασμένο". Ταυτόχρονα, ενδέχεται να προκύψουν ορισμένες εξωτερικές επιρροές από το ταμείο ή τη διεπαφή του Shift Manager με την παραγγελία. Θα δώσω τις καταστάσεις παραγγελιών με την περιγραφή τους στον πίνακα:

Το σχέδιο για την αλλαγή των καταστάσεων παραγγελιών μοιάζει με αυτό:

Οι καταστάσεις αλλάζουν μεταξύ διαφορετικών συστημάτων. Και εδώ το tracker δεν είναι ένα τελικό σύστημα στο οποίο τα δεδομένα είναι κλειστά. Έχουμε δει πολλές πιθανές προσεγγίσεις για την κατάτμηση σε μια τέτοια περίπτωση:

1. Συγκεντρώνουμε όλες τις ενέργειες παραγγελίας σε μία υπηρεσία. Στην περίπτωσή μας, αυτή η επιλογή απαιτεί πάρα πολλές υπηρεσίες για να λειτουργήσει με την παραγγελία. Αν σταματούσαμε σε αυτό, θα παίρναμε το δεύτερο μονόπετρο. Δεν θα λύναμε το πρόβλημα.
2. Το ένα σύστημα καλεί ένα άλλο. Η δεύτερη επιλογή είναι ήδη πιο ενδιαφέρουσα. Αλλά με αυτό, αλυσίδες κλήσεων είναι δυνατές (διαδοχικές αστοχίες), η συνδεσιμότητα των εξαρτημάτων είναι υψηλότερη, είναι πιο δύσκολη η διαχείριση.
3. Διοργανώνουμε εκδηλώσεις και κάθε υπηρεσία επικοινωνεί με μια άλλη μέσω αυτών των εκδηλώσεων. Ως αποτέλεσμα, ήταν η τρίτη επιλογή που επιλέχθηκε, σύμφωνα με την οποία όλες οι υπηρεσίες αρχίζουν να ανταλλάσσουν εκδηλώσεις μεταξύ τους.

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

Μέχρι εκείνη τη στιγμή, είχαμε ήδη το RabbitMQ στη στοίβα, εξ ου και η τελική απόφαση να το χρησιμοποιήσουμε ως μεσίτη μηνυμάτων. Το διάγραμμα δείχνει τη μετάβαση μιας παραγγελίας από το Ταμείο του Εστιατορίου μέσω του Tracker, όπου αλλάζει την κατάστασή της και την εμφάνισή της στη διεπαφή παραγγελιών του διαχειριστή. ΕΓΙΝΕ:

Διαδρομή παραγγελίας βήμα προς βήμα
Η διαδρομή παραγγελίας ξεκινά σε μία από τις υπηρεσίες προέλευσης παραγγελίας. Εδώ είναι το ταμείο του εστιατορίου:

1. Στο ταμείο, η παραγγελία είναι εντελώς έτοιμη και ήρθε η ώρα να την στείλετε στο tracker. Το συμβάν στο οποίο είναι εγγεγραμμένος ο ιχνηλάτης ρίχνεται.
2. Ο ιχνηλάτης, αποδεχόμενος μια παραγγελία για τον εαυτό του, την αποθηκεύει στη δική του βάση δεδομένων, κάνοντας το συμβάν "Παραγγελία αποδεκτή από τον Ιχνηλάτη" και στέλνοντάς το στο RMQ.
3. Υπάρχουν ήδη αρκετοί χειριστές που έχουν εγγραφεί στο λεωφορείο συμβάντων ανά παραγγελία. Για εμάς είναι σημαντικός αυτός που κάνει συγχρονισμό με μια μονολιθική βάση.
4. Ο χειριστής λαμβάνει ένα συμβάν, επιλέγει από αυτό δεδομένα που είναι σημαντικά για αυτόν: στην περίπτωσή μας, αυτή είναι η κατάσταση της παραγγελίας "Αποδεκτή από τον Ιχνηλάτη" και ενημερώνει την οντότητα παραγγελίας της στην κύρια βάση δεδομένων.

Αν κάποιος χρειάζεται παραγγελία από τις μονολιθικές επιτραπέζιες παραγγελίες, τότε μπορείτε να το διαβάσετε και από εκεί. Για παράδειγμα, η διεπαφή Orders στο Shift Manager χρειάζεται αυτό:

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

Εάν μετά από λίγο η παραγγελία τεθεί σε λειτουργία, τότε η κατάστασή της αλλάζει πρώτα στη βάση δεδομένων της (βάση δεδομένων Tracker) και στη συνέχεια δημιουργείται αμέσως το συμβάν "OrderIn Progress". Μπαίνει επίσης στο RMQ, από όπου συγχρονίζεται σε μια μονολιθική βάση δεδομένων και παραδίδεται σε άλλες υπηρεσίες. Μπορεί να υπάρχουν διάφορα προβλήματα στην πορεία, περισσότερες λεπτομέρειες σχετικά με αυτά μπορείτε να βρείτε στην αναφορά του Zhenya Peshkov σχετικά με τις λεπτομέρειες υλοποίησης του Eventual Consistency στο Tracker.

Τελική αρχιτεκτονική μετά από αλλαγές σε Auth και Tracker

Συνοψίζοντας το ενδιάμεσο αποτέλεσμα: Αρχικά, είχα την ιδέα να συσκευάσω την εννιάχρονη ιστορία του συστήματος Dodo IS σε ένα άρθρο. Ήθελα να μιλήσω γρήγορα και απλά για τα στάδια της εξέλιξης. Ωστόσο, καθίζοντας για το υλικό, κατάλαβα ότι όλα είναι πολύ πιο περίπλοκα και ενδιαφέροντα από ό,τι φαίνονται.

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

Ελπίζω ότι ήταν χρήσιμο και ενδιαφέρον για εσάς να μάθετε για την πορεία μας. Τώρα βρίσκομαι αντιμέτωπος με την επιλογή ποιο μέρος του συστήματος Dodo IS να περιγράψω στο επόμενο άρθρο: γράψτε στα σχόλια ή ψηφίστε.

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

Για ποιο μέρος του Dodo IS θα θέλατε να μάθετε στο επόμενο άρθρο;

• 24,1%Early monolith in Dodo IS (2011-2015)14

• 24,1%Τα πρώτα προβλήματα και οι λύσεις τους (2015-2016)14

• 20,7%Η διαδρομή από την πλευρά του πελάτη: πρόσοψη πάνω από τη βάση (2016-2017)12

• 36,2%Η ιστορία των πραγματικών μικροϋπηρεσιών (2018-2019)21

• 44,8%Πλήρες πριόνισμα του μονόλιθου και σταθεροποίηση της αρχιτεκτονικής26

• 29,3%Σχετικά με περαιτέρω σχέδια για την ανάπτυξη του συστήματος17

• 19,0%Δεν θέλω να μάθω τίποτα για το Dodo IS11

Ψήφισαν 58 χρήστες. 6 χρήστες απείχαν.

Πηγή: www.habr.com