Ή κάθε δυστυχισμένη εταιρεία με μονόλιθο είναι δυστυχισμένη με τον δικό της τρόπο.
Η ανάπτυξη του συστήματος Dodo IS ξεκίνησε αμέσως, όπως η επιχείρηση Dodo Pizza - το 2011. Βασίστηκε στην ιδέα της πλήρους και συνολικής ψηφιοποίησης των επιχειρηματικών διαδικασιών και , που ακόμα και τότε το 2011 προκάλεσε πολλά ερωτηματικά και σκεπτικισμό. Αλλά εδώ και 9 χρόνια ακολουθούμε αυτόν τον δρόμο - με τη δική μας ανάπτυξη, που ξεκίνησε με ένα μονόλιθο.
Αυτό το άρθρο είναι η «απάντηση» στις ερωτήσεις «Γιατί να ξαναγράψουμε την αρχιτεκτονική και να κάνουμε τόσο μεγάλης κλίμακας και μακροπρόθεσμες αλλαγές;» στο προηγούμενο άρθρο . Θα ξεκινήσω με το πώς ξεκίνησε η ανάπτυξη του Dodo IS, πώς φαινόταν η αρχική αρχιτεκτονική, πώς εμφανίστηκαν οι νέες ενότητες και λόγω των προβλημάτων που έπρεπε να γίνουν αλλαγές μεγάλης κλίμακας.
Σειρά άρθρων "Τι είναι το Dodo IS;" λέει για:
-
Πρώιμος μονόλιθος στο Dodo IS (2011-2015). (Είστε εδώ)
-
.
-
Η διαδρομή από την πλευρά του πελάτη: πρόσοψη πάνω από τη βάση (2016-2017). (Σε εξέλιξη...)
-
Η ιστορία των πραγματικών μικροϋπηρεσιών. (2018-2019). (Σε εξέλιξη...)
-
Ολοκληρώθηκε το πριόνισμα του μονόλιθου και η σταθεροποίηση της αρχιτεκτονικής. (Σε εξέλιξη...)
Αρχέγονη αρχιτεκτονική
Το 2011, η αρχιτεκτονική Dodo IS έμοιαζε ως εξής:
Η πρώτη ενότητα στην αρχιτεκτονική είναι η αποδοχή παραγγελιών. Η επιχειρηματική διαδικασία είχε ως εξής:
-
ένας πελάτης καλεί την πιτσαρία?
-
Ο διευθυντής σηκώνει το τηλέφωνο.
-
δέχεται παραγγελίες μέσω τηλεφώνου.
-
Ταυτόχρονα, το συμπληρώνει στη διεπαφή αποδοχής παραγγελιών: λαμβάνονται υπόψη πληροφορίες για τον πελάτη, δεδομένα σχετικά με τις λεπτομέρειες της παραγγελίας και η διεύθυνση παράδοσης.
Η διεπαφή του συστήματος πληροφοριών έμοιαζε κάπως έτσι...
Πρώτη έκδοση από τον Οκτώβριο του 2011:
Οι πόροι για την ανάπτυξη της ενότητας λήψης πρώτης παραγγελίας ήταν περιορισμένοι. Ήταν απαραίτητο να κάνουμε πολλά, γρήγορα και με μικρή ομάδα. Η μικρή ομάδα αποτελείται από 2 προγραμματιστές που έθεσαν τα θεμέλια για ολόκληρο το μελλοντικό σύστημα.
Η πρώτη τους απόφαση καθόρισε τη μελλοντική μοίρα της στοίβας τεχνολογίας:
-
Backend σε ASP.NET MVC, γλώσσα C#. Οι προγραμματιστές ήταν κουκκίδες· αυτή η στοίβα τους ήταν οικεία και ευχάριστη.
-
Frontend σε Bootstrap και JQuery: διεπαφές χρήστη που βασίζονται σε προσαρμοσμένα στυλ και σενάρια.
-
Βάση δεδομένων MySQL: χωρίς κόστος άδειας χρήσης, εύκολο στη χρήση.
-
Διακομιστές στον Windows Server, επειδή τότε το .NET θα μπορούσε να είναι μόνο σε Windows (δεν θα συζητήσουμε το Mono).
Σωματικά, όλα αυτά εκφράστηκαν στο «γραφείο του οικοδεσπότη».
Αρχιτεκτονική της αίτησης αποδοχής παραγγελίας
Εκείνη την εποχή, όλοι μιλούσαν ήδη για μικροϋπηρεσίες και το SOA είχε χρησιμοποιηθεί σε μεγάλα έργα για περίπου 5 χρόνια, για παράδειγμα, το WCF κυκλοφόρησε το 2006. Στη συνέχεια όμως επέλεξαν μια αξιόπιστη και δοκιμασμένη λύση.
Εδώ είναι.
Το Asp.Net MVC είναι το Razor, το οποίο, κατόπιν αιτήματος από μια φόρμα ή από έναν πελάτη, παράγει μια σελίδα HTML με απόδοση στον διακομιστή. Στον πελάτη, τα σενάρια CSS και JS εμφανίζουν ήδη πληροφορίες και, εάν είναι απαραίτητο, εκτελούν αιτήματα AJAX μέσω JQuery.
Τα αιτήματα στον διακομιστή εμπίπτουν στις κλάσεις *Controller, όπου η μέθοδος επεξεργάζεται και δημιουργεί την τελική σελίδα HTML. Οι ελεγκτές υποβάλλουν αιτήματα σε ένα επίπεδο λογικής που ονομάζεται *Υπηρεσίες. Κάθε μία από τις υπηρεσίες αντιστοιχούσε σε κάποια πτυχή της επιχείρησης:
-
Για παράδειγμα, το DepartmentStructureService παρείχε πληροφορίες για πιτσαρίες και τμήματα. Ένα τμήμα είναι μια ομάδα πιτσαριών που διαχειρίζεται ένας δικαιοδόχος.
-
Η υπηρεσία ReceivingOrders έλαβε και υπολόγισε τα περιεχόμενα της παραγγελίας.
-
Και το SmsService έστειλε SMS καλώντας τις υπηρεσίες API για αποστολή SMS.
Οι υπηρεσίες επεξεργάζονταν δεδομένα από τη βάση δεδομένων και αποθήκευαν επιχειρηματική λογική. Κάθε υπηρεσία είχε ένα ή περισσότερα *Αποθετήρια με το κατάλληλο όνομα. Περιείχαν ήδη ερωτήματα για αποθηκευμένες διαδικασίες στη βάση δεδομένων και ένα επίπεδο αντιστοιχιστών. Τα αποθετήρια είχαν επιχειρηματική λογική, ειδικά πολλά από αυτά που παρήγαγαν δεδομένα αναφοράς. Το ORM δεν χρησιμοποιήθηκε, όλοι βασίζονταν σε χειρόγραφη sql.
Υπήρχε επίσης ένα επίπεδο του μοντέλου τομέα και γενικών βοηθητικών κλάσεων, για παράδειγμα, η τάξη Order, η οποία αποθήκευε την παραγγελία. Εκεί, στο επίπεδο, υπήρχε ένας βοηθός για τη μετατροπή κειμένου εμφάνισης σύμφωνα με το επιλεγμένο νόμισμα.
Όλα αυτά μπορούν να αντιπροσωπευτούν από αυτό το μοντέλο:
Τρόπος παραγγελίας
Ας εξετάσουμε έναν απλοποιημένο αρχικό τρόπο δημιουργίας μιας τέτοιας παραγγελίας.
Αρχικά η τοποθεσία ήταν στατική. Υπήρχαν τιμές σε αυτό, και στην κορυφή υπήρχε ένας αριθμός τηλεφώνου και η επιγραφή "Αν θέλετε πίτσα, καλέστε τον αριθμό και παραγγείλετε." Για να παραγγείλουμε, πρέπει να εφαρμόσουμε μια απλή ροή:
-
Ο πελάτης πηγαίνει σε έναν στατικό ιστότοπο με τιμές, επιλέγει προϊόντα και καλεί τον αριθμό που αναγράφεται στον ιστότοπο.
-
Ο πελάτης ονομάζει τα προϊόντα που θέλει να προσθέσει στην παραγγελία.
-
Δίνει τη διεύθυνση και το όνομά του.
-
Ο χειριστής αποδέχεται την παραγγελία.
-
Η παραγγελία εμφανίζεται στη διεπαφή αποδεκτών παραγγελιών.
Όλα ξεκινούν με την εμφάνιση του μενού. Ένας συνδεδεμένος χρήστης χειριστή αποδέχεται μόνο μία παραγγελία κάθε φορά. Επομένως, το πρόχειρο καλάθι μπορεί να αποθηκευτεί στη συνεδρία του (η περίοδος λειτουργίας του χρήστη αποθηκεύεται στη μνήμη). Υπάρχει ένα αντικείμενο Καλαθιού που περιέχει προϊόντα και πληροφορίες πελατών.
Ο πελάτης ονομάζει το προϊόν, ο χειριστής κάνει κλικ + δίπλα στο προϊόν και αποστέλλεται αίτημα στον διακομιστή. Πληροφορίες σχετικά με το προϊόν ανασύρονται από τη βάση δεδομένων και πληροφορίες σχετικά με το προϊόν προστίθενται στο καλάθι.
Σημείωση. Ναι, εδώ δεν χρειάζεται να βγάλετε το προϊόν από τη βάση δεδομένων, αλλά να το μεταφέρετε από το μπροστινό μέρος. Αλλά για λόγους σαφήνειας, έδειξα ακριβώς τη διαδρομή από τη βάση.
Στη συνέχεια, εισαγάγετε τη διεύθυνση και το όνομα του πελάτη.
Όταν κάνετε κλικ στο «Δημιουργία παραγγελίας»:
-
Στέλνουμε το αίτημα στο OrderController.SaveOrder().
-
Παίρνουμε καλάθι από τη συνεδρία, υπάρχουν προϊόντα στην ποσότητα που χρειαζόμαστε.
-
Συμπληρώνουμε το Καλάθι με πληροφορίες για τον πελάτη και το περνάμε στη μέθοδο AddOrder της κλάσης ReceivingOrderService, όπου αποθηκεύεται στη βάση δεδομένων.
-
Η βάση δεδομένων έχει πίνακες με την παραγγελία, τα περιεχόμενα της παραγγελίας, τον πελάτη και είναι όλα συνδεδεμένα.
-
Η διεπαφή εμφάνισης παραγγελιών πηγαίνει και βγάζει τις πιο πρόσφατες παραγγελίες και τις εμφανίζει.
Νέες ενότητες
Η παραλαβή της παραγγελίας ήταν σημαντική και απαραίτητη. Δεν μπορείτε να διευθύνετε μια επιχείρηση πίτσας εάν δεν έχετε παραγγελία να πουλήσετε. Ως εκ τούτου, το σύστημα άρχισε να αποκτά λειτουργικότητα - περίπου από το 2012 έως το 2015. Κατά τη διάρκεια αυτής της περιόδου, εμφανίστηκαν πολλά διαφορετικά μπλοκ του συστήματος, τα οποία θα καλέσω ενότητες, σε αντίθεση με την έννοια της υπηρεσίας ή του προϊόντος.
Μια ενότητα είναι ένα σύνολο λειτουργιών που ενώνονται από κάποιο κοινό επιχειρηματικό στόχο. Επιπλέον, βρίσκονται φυσικά στην ίδια εφαρμογή.
Οι μονάδες μπορούν να ονομαστούν μπλοκ συστήματος. Για παράδειγμα, αυτή είναι μια ενότητα αναφοράς, διεπαφές διαχειριστή, , εξουσιοδότηση. Όλα αυτά είναι διαφορετικά περιβάλλοντα χρήστη, μερικά έχουν ακόμη και διαφορετικά οπτικά στυλ. Επιπλέον, όλα βρίσκονται μέσα σε μία εφαρμογή, μία διαδικασία που εκτελείται.
Τεχνικά, οι ενότητες σχεδιάστηκαν ως Περιοχή (αυτή η ιδέα παρέμεινε ακόμη και μέσα ). Υπήρχαν ξεχωριστά αρχεία για το frontend, τα μοντέλα, καθώς και τις δικές τους κατηγορίες ελεγκτών. Ως αποτέλεσμα, το σύστημα μετατράπηκε από τέτοια...
...σ 'αυτό:
Ορισμένες ενότητες υλοποιούνται από ξεχωριστούς ιστότοπους (εκτελέσιμο έργο), λόγω εντελώς ξεχωριστής λειτουργικότητας και εν μέρει λόγω κάπως ξεχωριστής, πιο εστιασμένης ανάπτυξης. Αυτό:
-
Τοποθεσία - ιστοσελίδα dodopizza.ru.
-
εξαγωγή: λήψη αναφορών από το Dodo IS για 1C.
-
ΠΡΟΣΩΠΙΚΟ — προσωπικός λογαριασμός υπαλλήλου. Αναπτύχθηκε ξεχωριστά και έχει το δικό του σημείο εισόδου και ξεχωριστό σχεδιασμό.
-
fs — έργο για στατική φιλοξενία. Αργότερα απομακρυνθήκαμε από αυτό, μεταφέροντας όλο το στατικό περιεχόμενο στο Akamai CDN.
Τα υπόλοιπα μπλοκ εντοπίστηκαν στην εφαρμογή BackOffice.
Επεξήγηση ονομάτων:
-
Ταμείο - Ταμείο εστιατορίου.
-
ShiftManager - διεπαφές για το ρόλο "Shift Manager": λειτουργικά στατιστικά στοιχεία για τις πωλήσεις πιτσαρίας, δυνατότητα τοποθέτησης προϊόντων σε λίστα διακοπής, αλλαγή παραγγελίας.
-
OfficeManager - διεπαφές για τους ρόλους "Pizzeria Manager" και "Franchisee". Εδώ μπορείτε να βρείτε λειτουργίες για τη δημιουργία μιας πιτσαρίας, τις προσφορές μπόνους της, τη λήψη και τη συνεργασία με υπαλλήλους και αναφορές.
-
PublicScreens - διεπαφές για τηλεοράσεις και tablet που κρέμονται σε πιτσαρίες. Οι τηλεοράσεις εμφανίζουν το μενού, τις πληροφορίες διαφήμισης και την κατάσταση της παραγγελίας κατά την παράδοση.
Χρησιμοποίησαν ένα κοινό επίπεδο υπηρεσίας, ένα κοινό μπλοκ κλάσεων τομέα Dodo.Core και μια κοινή βάση. Μερικές φορές μπορούσαν ακόμα να οδηγήσουν μέσα από περάσματα ο ένας στον άλλο. Επιπλέον, μεμονωμένες τοποθεσίες, όπως το dodopizza.ru ή το personal.dodopizza.ru, είχαν επίσης πρόσβαση σε κοινές υπηρεσίες.
Όταν εμφανίστηκαν νέες ενότητες, προσπαθήσαμε να επαναχρησιμοποιήσουμε όσο το δυνατόν περισσότερο τον ήδη δημιουργημένο κώδικα για υπηρεσίες, αποθηκευμένες διαδικασίες και πίνακες στη βάση δεδομένων.
Για καλύτερη κατανόηση της κλίμακας των ενοτήτων που κατασκευάζονται στο σύστημα, ακολουθεί ένα διάγραμμα από το 2012 με σχέδια ανάπτυξης:
Μέχρι το 2015, όλα ήταν σε καλό δρόμο και ακόμη περισσότερα ήταν στην παραγωγή.
-
Η αποδοχή παραγγελίας έχει εξελιχθεί σε ξεχωριστό μπλοκ του Κέντρου Επικοινωνίας, όπου η παραγγελία γίνεται αποδεκτή από τον χειριστή.
-
Δημόσιες οθόνες με μενού και πληροφορίες έχουν εμφανιστεί στις πιτσαρίες.
-
Η κουζίνα διαθέτει μια μονάδα που αναπαράγει αυτόματα ένα φωνητικό μήνυμα "New Pizza" όταν φτάσει μια νέα παραγγελία και εκτυπώνει επίσης ένα τιμολόγιο για τον ταχυμεταφορέα. Αυτό απλοποιεί σημαντικά τις διαδικασίες στην κουζίνα και επιτρέπει στους εργαζόμενους να μην αποσπώνται από μεγάλο αριθμό απλών λειτουργιών.
-
Το μπλοκ παράδοσης έγινε ξεχωριστό Ταμείο παράδοσης, όπου η παραγγελία εκδόθηκε στον ταχυμεταφορέα, ο οποίος είχε πάρει προηγουμένως τη βάρδια του. Για τον υπολογισμό του μισθού του ελήφθησαν υπόψη οι ώρες εργασίας του.
Παράλληλα, από το 2012 έως το 2015, εμφανίστηκαν περισσότεροι από 10 προγραμματιστές, άνοιξαν 35 πιτσαρίες, το σύστημα αναπτύχθηκε στη Ρουμανία και προετοιμάστηκε για το άνοιγμα σημείων στις ΗΠΑ. Οι προγραμματιστές δεν συμμετείχαν πλέον σε όλες τις εργασίες, αλλά χωρίστηκαν σε ομάδες. το καθένα ειδικεύεται στο δικό του μέρος του συστήματος.
Προβλήματα
Συμπεριλαμβανομένων λόγω της αρχιτεκτονικής (αλλά όχι μόνο).
Χάος στη βάση
Μια βάση είναι βολική. Είναι δυνατό να επιτευχθεί συνέπεια και σε βάρος των εργαλείων που είναι ενσωματωμένα σε σχεσιακές βάσεις δεδομένων. Η εργασία με αυτό είναι οικεία και βολική, ειδικά αν υπάρχουν λίγοι πίνακες και λίγα δεδομένα.
Αλλά για 4 χρόνια ανάπτυξης, η βάση δεδομένων περιείχε περίπου 600 πίνακες, 1500 αποθηκευμένες διαδικασίες, πολλές από τις οποίες είχαν επίσης λογική. Δυστυχώς, οι αποθηκευμένες διαδικασίες δεν προσφέρουν πολλά οφέλη όταν εργάζεστε με τη MySQL. Δεν αποθηκεύονται προσωρινά από τη βάση δεδομένων και η αποθήκευση λογικής σε αυτές περιπλέκει την ανάπτυξη και τον εντοπισμό σφαλμάτων. Η επαναχρησιμοποίηση του κώδικα είναι επίσης δύσκολη.
Πολλοί πίνακες δεν είχαν κατάλληλα ευρετήρια, κάπου, αντίθετα, υπήρχαν πολλά ευρετήρια, που δυσκόλευαν την εισαγωγή. Περίπου 20 πίνακες έπρεπε να τροποποιηθούν—η συναλλαγή για τη δημιουργία μιας παραγγελίας μπορεί να διαρκέσει περίπου 3-5 δευτερόλεπτα.
Τα δεδομένα στους πίνακες δεν ήταν πάντα στην πιο κατάλληλη μορφή. Κάπου χρειάστηκε να γίνει αποκανονικοποίηση. Μερικά από τα δεδομένα που λαμβάνονταν τακτικά ήταν σε μια στήλη με τη μορφή δομής XML, η οποία αύξησε τον χρόνο εκτέλεσης, επιμήκυνε τα ερωτήματα και περίπλοκη ανάπτυξη.
Οι ίδιοι πίνακες υπόκεινταν σε πολύ ετερογενή αιτήματα. Οι δημοφιλείς πίνακες, όπως ο πίνακας που αναφέρθηκε παραπάνω, επηρεάστηκαν ιδιαίτερα παραγγελιών ή τραπέζια πιτσαρία. Χρησιμοποιήθηκαν για την εμφάνιση λειτουργικών διεπαφών στην κουζίνα και αναλυτικών στοιχείων. Ο ιστότοπος επικοινώνησε επίσης μαζί τους (), όπου πολλά αιτήματα θα μπορούσαν να φτάσουν ξαφνικά ανά πάσα στιγμή.
Τα δεδομένα δεν συγκεντρώθηκαν και πολλοί υπολογισμοί έγιναν εν κινήσει χρησιμοποιώντας τη βάση. Αυτό δημιούργησε περιττούς υπολογισμούς και πρόσθετο φορτίο.
Συχνά ο κώδικας έμπαινε στη βάση δεδομένων όταν δεν μπορούσε να το κάνει. Κάπου υπήρχε έλλειψη μαζικών λειτουργιών, κάπου θα ήταν απαραίτητο να χωριστεί ένα αίτημα σε πολλά μέσω κώδικα για να επιταχυνθεί και να αυξηθεί η αξιοπιστία.
Συνοχή και Σύγχυση στον Κώδικα
Οι ενότητες που υποτίθεται ότι ήταν υπεύθυνες για το μέρος της επιχείρησής τους δεν το έκαναν με ειλικρίνεια. Μερικοί από αυτούς είχαν διπλασιασμό λειτουργιών για ρόλους. Για παράδειγμα, ένας τοπικός έμπορος που είναι υπεύθυνος για τη δραστηριότητα μάρκετινγκ ενός δικτύου στην πόλη του έπρεπε να χρησιμοποιήσει τόσο τη διεπαφή "Διαχειριστής" (για τη ρύθμιση των προωθήσεων) και τη διεπαφή "Διαχειριστής γραφείου" (για να δει τον αντίκτυπο των προωθήσεων στο επιχείρηση). Φυσικά, μέσα και στις δύο ενότητες χρησιμοποιήθηκε η ίδια υπηρεσία, η οποία λειτουργούσε με προσφορές μπόνους.
Οι υπηρεσίες (τάξεις σε ένα μονολιθικό μεγάλο έργο) θα μπορούσαν να καλέσουν η μία την άλλη για να εμπλουτίσουν τα δεδομένα τους.
Με τις ίδιες τις κατηγορίες μοντέλων που αποθηκεύουν τα δεδομένα, οι εργασίες στον κώδικα έγιναν διαφορετικά. Κάπου υπήρχαν κατασκευαστές μέσω των οποίων μπορούσατε να καθορίσετε τα απαιτούμενα πεδία. Κάπου αυτό έγινε μέσω των δημοσίων περιουσιών. Φυσικά, η λήψη και η μετατροπή δεδομένων από τη βάση δεδομένων ήταν ποικίλη.
Η λογική ήταν είτε σε ελεγκτές είτε σε κλάσεις υπηρεσιών.
Αυτά φαίνονται σαν μικρά προβλήματα, αλλά επιβράδυναν σημαντικά την ανάπτυξη και μείωσαν την ποιότητα, οδηγώντας σε αστάθεια και σφάλματα.
Πολυπλοκότητα μεγάλης ανάπτυξης
Προέκυψαν δυσκολίες στην ίδια την ανάπτυξη. Ήταν απαραίτητο να δημιουργηθούν διαφορετικά μπλοκ του συστήματος και παράλληλα. Γινόταν όλο και πιο δύσκολο να ενσωματωθούν οι ανάγκες κάθε στοιχείου σε έναν ενιαίο κώδικα. Δεν ήταν εύκολο να συμφωνήσουμε και να ευχαριστήσουμε όλα τα συστατικά ταυτόχρονα. Σε αυτό προστέθηκαν περιορισμοί στην τεχνολογία, ειδικά όσον αφορά τη βάση και το μπροστινό μέρος. Ήταν απαραίτητο να εγκαταλειφθεί το JQuery προς όφελος των πλαισίων υψηλού επιπέδου, ειδικά όσον αφορά τις υπηρεσίες πελατών (ιστοσελίδα).
Ορισμένα μέρη του συστήματος θα μπορούσαν να χρησιμοποιούν βάσεις δεδομένων που είναι πιο κατάλληλες για αυτό. Για παράδειγμα, αργότερα είχαμε ένα προηγούμενο για τη μετάβαση από το Redis στο CosmosDB για την αποθήκευση ενός καλαθιού παραγγελιών.
Οι ομάδες και οι προγραμματιστές που εργάζονται στην περιοχή τους ήθελαν σαφώς μεγαλύτερη ανεξαρτησία για τις υπηρεσίες τους, τόσο από την άποψη της ανάπτυξης όσο και από την άποψη της διάθεσης. Συγκρούσεις κατά τις συγχωνεύσεις, προβλήματα κατά τις εκδόσεις. Εάν για 5 προγραμματιστές αυτό το πρόβλημα είναι ασήμαντο, τότε με 10, και ακόμη περισσότερο με την προγραμματισμένη ανάπτυξη, όλα θα γίνονταν πιο σοβαρά. Και αυτό που επρόκειτο ήταν η ανάπτυξη μιας εφαρμογής για κινητά (ξεκίνησε το 2017 και το 2018 υπήρξε ).
Διαφορετικά μέρη του συστήματος απαιτούσαν διαφορετικούς δείκτες σταθερότητας, αλλά λόγω της ισχυρής συνδεσιμότητας του συστήματος, δεν μπορέσαμε να το παρέχουμε. Ένα σφάλμα κατά την ανάπτυξη μιας νέας λειτουργίας στον πίνακα διαχείρισης θα μπορούσε κάλλιστα να είχε ως αποτέλεσμα την αποδοχή της παραγγελίας στον ιστότοπο, επειδή ο κώδικας είναι κοινός και επαναχρησιμοποιήσιμος, η βάση δεδομένων και τα δεδομένα είναι επίσης τα ίδια.
Θα ήταν πιθανώς δυνατό να αποφευχθούν αυτά τα λάθη και τα προβλήματα στο πλαίσιο μιας τέτοιας μονολιθικής-αρθρωτής αρχιτεκτονικής: δημιουργήστε έναν διαχωρισμό ευθυνών, αναδιαμορφώστε τόσο τον κώδικα όσο και τη βάση δεδομένων, ξεχωρίστε σαφώς τα επίπεδα το ένα από το άλλο και παρακολουθήστε την ποιότητα κάθε μέρα. Όμως οι επιλεγμένες αρχιτεκτονικές λύσεις και η εστίαση στη γρήγορη επέκταση της λειτουργικότητας του συστήματος οδήγησαν σε προβλήματα σε θέματα σταθερότητας.
Πώς το blog Power of Mind έβαλε ταμειακές μηχανές στα εστιατόρια
Αν η ανάπτυξη του δικτύου της πιτσαρίας (και του φορτίου) συνεχιζόταν με τον ίδιο ρυθμό, τότε μετά από λίγο οι πτώσεις θα ήταν τέτοιες που το σύστημα δεν θα ανακάμψει. Η παρακάτω ιστορία απεικονίζει καλά τα προβλήματα που αρχίσαμε να αντιμετωπίζουμε μέχρι το 2015.
στο blog""Υπήρχε ένα widget που έδειχνε δεδομένα εσόδων για το έτος για ολόκληρο το δίκτυο. Το γραφικό στοιχείο είχε πρόσβαση στο δημόσιο API Dodo, το οποίο παρέχει αυτά τα δεδομένα. Αυτά τα στατιστικά στοιχεία είναι πλέον διαθέσιμα στο . Το γραφικό στοιχείο εμφανιζόταν σε κάθε σελίδα και έκανε αιτήματα σε ένα χρονόμετρο κάθε 20 δευτερόλεπτα. Το αίτημα πήγε στο api.dodopizza.ru και ρώτησε:
-
αριθμός πιτσαριών στο δίκτυο·
-
συνολικά έσοδα δικτύου από την αρχή του έτους·
-
τα σημερινά έσοδα.
Ένα αίτημα για στατιστικές εσόδων πήγε κατευθείαν στη βάση δεδομένων και άρχισε να ζητά δεδομένα για παραγγελίες, να συγκεντρώνει τα δεδομένα απευθείας εν κινήσει και να εκδίδει το ποσό.
Οι ταμειακές μηχανές στα εστιατόρια πήγαν στον ίδιο πίνακα παραγγελιών, ανέβασαν μια λίστα με τις παραγγελίες που έγιναν δεκτές για σήμερα και προστέθηκαν νέες παραγγελίες σε αυτόν. Οι ταμειακές μηχανές έκαναν τα αιτήματά τους κάθε 5 δευτερόλεπτα ή όταν η σελίδα ανανεωνόταν.
Το διάγραμμα έμοιαζε με αυτό:
Μια μέρα το φθινόπωρο, ο Fyodor Ovchinnikov έγραψε ένα μεγάλο και δημοφιλές άρθρο στο blog του. Πολλοί άνθρωποι ήρθαν στο blog και άρχισαν να διαβάζουν τα πάντα προσεκτικά. Ενώ καθένας από τους ανθρώπους που ήρθαν διάβαζε το άρθρο, το γραφικό στοιχείο εσόδων λειτουργούσε σωστά και ζητούσε το API κάθε 20 δευτερόλεπτα.
Το API κάλεσε μια αποθηκευμένη διαδικασία για τον υπολογισμό του ποσού όλων των παραγγελιών από την αρχή του έτους για όλες τις πιτσαρίες του δικτύου. Η συγκέντρωση βασίστηκε στον πίνακα παραγγελιών, ο οποίος είναι πολύ δημοφιλής. Σε αυτό πάνε όλες οι ταμειακές μηχανές όλων των ανοιχτών εστιατορίων εκείνη την ώρα. Οι ταμειακές μηχανές σταμάτησαν να ανταποκρίνονται και παραγγελίες δεν γίνονταν δεκτές. Επίσης, δεν έγιναν δεκτά από τον ιστότοπο, δεν εμφανίστηκαν στον ιχνηλάτη και ο διευθυντής βάρδιας δεν μπορούσε να τα δει στη διεπαφή του.
Αυτή δεν είναι η μόνη ιστορία. Μέχρι το φθινόπωρο του 2015, κάθε Παρασκευή το φορτίο στο σύστημα ήταν κρίσιμο. Αρκετές φορές απενεργοποιήσαμε το δημόσιο API και μια φορά χρειάστηκε να απενεργοποιήσουμε τον ιστότοπο επειδή τίποτα δεν βοηθούσε. Υπήρχε ακόμη και ένας κατάλογος υπηρεσιών με εντολή διακοπής λειτουργίας κάτω από βαριά φορτία.
Από αυτή τη στιγμή ξεκινά ο αγώνας μας με τα φορτία και για τη σταθεροποίηση του συστήματος (από το φθινόπωρο του 2015 έως το φθινόπωρο του 2018). Τότε έγινε»" Επιπλέον, μερικές φορές υπήρχαν και αποτυχίες, μερικές από τις οποίες ήταν πολύ ευαίσθητες, αλλά η γενική περίοδος αστάθειας μπορεί τώρα να θεωρηθεί ότι έχει τελειώσει.
Ταχεία ανάπτυξη των επιχειρήσεων
Γιατί δεν μπορούσε να «γίνει καλά αμέσως»; Απλώς κοιτάξτε τα παρακάτω γραφήματα.
Επίσης το 2014-2015 έγινε άνοιγμα στη Ρουμανία και ετοιμαζόταν άνοιγμα στις ΗΠΑ.
Η αλυσίδα μεγάλωσε πολύ γρήγορα, άνοιξαν νέες χώρες, εμφανίστηκαν νέες μορφές πιτσαριών, για παράδειγμα, μια πιτσαρία που άνοιξε στο food court. Όλα αυτά απαιτούσαν ιδιαίτερη προσοχή ειδικά στην επέκταση των λειτουργιών του Dodo IS. Χωρίς όλες αυτές τις λειτουργίες, χωρίς παρακολούθηση στην κουζίνα, λογιστικοποίηση προϊόντων και απωλειών στο σύστημα, εμφάνιση της παράδοσης των παραγγελιών στην αίθουσα εστίασης, είναι απίθανο να μιλάμε τώρα για τη «σωστή» αρχιτεκτονική και τη «σωστή». » προσέγγιση στην ανάπτυξη.
Ένα άλλο εμπόδιο για την έγκαιρη αναθεώρηση της αρχιτεκτονικής και τη γενική προσοχή στα τεχνικά προβλήματα ήταν η κρίση του 2014. Τέτοια πράγματα βλάπτουν τις ευκαιρίες ανάπτυξης των ομάδων, ειδικά για μια νέα επιχείρηση όπως η Dodo Pizza.
Γρήγορες λύσεις που βοήθησαν
Τα προβλήματα χρειάζονταν λύσεις. Συμβατικά, οι λύσεις μπορούν να χωριστούν σε 2 ομάδες:
-
Γρήγορες που σβήνουν τη φωτιά και μας δίνουν ένα μικρό περιθώριο ασφάλειας και μας αγοράζουν χρόνο να αλλάξουμε.
-
Συστημική και, επομένως, μακροχρόνια. Ανασχεδιασμός μιας σειράς ενοτήτων, διαίρεση της μονολιθικής αρχιτεκτονικής σε ξεχωριστές υπηρεσίες (οι περισσότερες από αυτές δεν είναι μικρού μεγέθους, αλλά μάλλον μακρο-υπηρεσίες, και υπάρχουν περισσότερα για αυτό ).
Η ξηρή λίστα γρήγορων αλλαγών είναι:
Κλιμακώστε τον κύριο βάσης
Φυσικά, το πρώτο πράγμα που γίνεται για την καταπολέμηση του φόρτου είναι να αυξηθεί η ισχύς του διακομιστή. Αυτό έγινε για την κύρια βάση δεδομένων και τους διακομιστές Ιστού. Δυστυχώς, αυτό είναι δυνατό μόνο μέχρι ένα ορισμένο όριο· πέρα από αυτό γίνεται πολύ ακριβό.
Από το 2014, μετακομίσαμε στο Azure· γράψαμε επίσης για αυτό το θέμα τότε στο άρθρο "" Αλλά μετά από μια σειρά αυξήσεων διακομιστή, το κόστος της βάσης έφτασε ένα όριο.
Αντίγραφα βάσης δεδομένων για ανάγνωση
Φτιάξαμε δύο αντίγραφα για τη βάση:
ReadReplica για αιτήματα καταλόγου. Χρησιμοποιείται για την ανάγνωση καταλόγων, όπως πόλη, δρόμος, πιτσαρία, προϊόντα (με αργούς ρυθμούς αλλαγή τομέα) και σε εκείνες τις διεπαφές όπου μια μικρή καθυστέρηση είναι αποδεκτή. Υπήρχαν 2 από αυτά τα αντίγραφα, εξασφαλίσαμε τη διαθεσιμότητά τους με τον ίδιο τρόπο όπως ο κύριος.
ReadReplica για αιτήματα αναφοράς. Αυτή η βάση δεδομένων είχε χαμηλότερη διαθεσιμότητα, αλλά όλες οι αναφορές πήγαν σε αυτήν. Μπορεί να έχουν βαριά αιτήματα για τεράστιους επανυπολογισμούς δεδομένων, αλλά δεν επηρεάζουν την κύρια βάση δεδομένων και τις λειτουργικές διεπαφές.
Κρυφές μνήμες σε κώδικα
Δεν υπήρχαν κρυφές μνήμες πουθενά στον κώδικα (καθόλου). Αυτό οδήγησε σε πρόσθετα, όχι πάντα απαραίτητα, αιτήματα στη φορτωμένη βάση δεδομένων. Αρχικά, οι κρυφές μνήμες ήταν και στη μνήμη και σε μια εξωτερική υπηρεσία προσωρινής μνήμης, ήταν το Redis. Όλα ακυρώθηκαν χρονικά, οι ρυθμίσεις καθορίστηκαν στον κώδικα.
Πολλαπλοί διακομιστές για backend
Το backend της εφαρμογής έπρεπε επίσης να κλιμακωθεί για να αντέχει σε αυξημένα φορτία. Ήταν απαραίτητο να δημιουργηθεί ένα σύμπλεγμα από έναν διακομιστή IIS. Μετακομίσαμε από τη μνήμη στο RedisCache, το οποίο κατέστησε δυνατή τη δημιουργία πολλών διακομιστών πίσω από έναν απλό εξισορροπητή φορτίου με στρογγυλή σειρά. Στην αρχή χρησιμοποιήθηκε το ίδιο Redis όπως και για τις κρυφές μνήμες, μετά χωρίστηκαν σε πολλές.
Ως αποτέλεσμα, η αρχιτεκτονική έγινε πιο περίπλοκη...
...αλλά λίγο από την ένταση εκτονώθηκε.
Και τότε ήταν απαραίτητο να επαναλάβουμε τα φορτωμένα εξαρτήματα, κάτι που αναλάβαμε. Θα μιλήσουμε για αυτό στο επόμενο μέρος.
Πηγή: www.habr.com