Από το 2019, η Ρωσία έχει νόμο για την υποχρεωτική επισήμανση. Ο νόμος δεν ισχύει για όλες τις ομάδες προϊόντων και οι ημερομηνίες για την έναρξη ισχύος της υποχρεωτικής επισήμανσης για τις ομάδες προϊόντων είναι διαφορετικές. Ο καπνός, τα παπούτσια και τα φάρμακα θα είναι τα πρώτα που θα υπόκεινται σε υποχρεωτική επισήμανση· άλλα προϊόντα θα προστεθούν αργότερα, για παράδειγμα, αρώματα, υφάσματα και γάλα. Αυτή η νομοθετική καινοτομία ώθησε την ανάπτυξη νέων λύσεων πληροφορικής που θα καταστήσουν δυνατή την παρακολούθηση ολόκληρης της αλυσίδας ζωής ενός προϊόντος από την παραγωγή έως την αγορά από τον τελικό καταναλωτή, σε όλους τους συμμετέχοντες στη διαδικασία: τόσο το ίδιο το κράτος όσο και όλοι οι οργανισμοί που πωλούν αγαθά με υποχρεωτική επισήμανση.
Στο X5, το σύστημα που θα παρακολουθεί τα προϊόντα με ετικέτα και θα ανταλλάσσει δεδομένα με το κράτος και τους προμηθευτές ονομάζεται "Marcus". Ας σας πούμε με τη σειρά πώς και ποιος το ανέπτυξε, ποια είναι η τεχνολογική του στοίβα και γιατί έχουμε κάτι για το οποίο πρέπει να είμαστε περήφανοι.
Πραγματικό Υψηλό Φορτίο
Το "Marcus" επιλύει πολλά προβλήματα, το κυριότερο είναι η αλληλεπίδραση ενοποίησης μεταξύ των συστημάτων πληροφοριών X5 και του κρατικού συστήματος πληροφοριών για προϊόντα με ετικέτα (GIS MP) για την παρακολούθηση της κίνησης των προϊόντων με ετικέτα. Η πλατφόρμα αποθηκεύει επίσης όλους τους κωδικούς ετικετών που λάβαμε και ολόκληρο το ιστορικό της μετακίνησης αυτών των κωδικών μεταξύ των αντικειμένων και βοηθά στην εξάλειψη της αναβαθμολόγησης των προϊόντων με ετικέτα. Χρησιμοποιώντας το παράδειγμα των προϊόντων καπνού, που περιλαμβάνονταν στις πρώτες ομάδες προϊόντων με ετικέτα, μόνο ένα φορτηγό τσιγάρα περιέχει περίπου 600 πακέτα, καθένα από τα οποία έχει τον δικό του μοναδικό κωδικό. Και το καθήκον του συστήματός μας είναι να παρακολουθεί και να επαληθεύει τη νομιμότητα των μετακινήσεων κάθε τέτοιου πακέτου μεταξύ αποθηκών και καταστημάτων και, τελικά, να επαληθεύει το παραδεκτό της πώλησής τους στον τελικό αγοραστή. Και καταγράφουμε περίπου 000 συναλλαγές σε μετρητά ανά ώρα, και πρέπει επίσης να καταγράψουμε πώς κάθε τέτοιο πακέτο μπήκε στο κατάστημα. Έτσι, λαμβάνοντας υπόψη όλες τις κινήσεις μεταξύ αντικειμένων, αναμένουμε δεκάδες δισεκατομμύρια εγγραφές ετησίως.
Η ομάδα Μ
Παρά το γεγονός ότι το Marcus θεωρείται έργο εντός του X5, υλοποιείται χρησιμοποιώντας μια προσέγγιση προϊόντος. Η ομάδα λειτουργεί σύμφωνα με το Scrum. Το έργο ξεκίνησε το περασμένο καλοκαίρι, αλλά τα πρώτα αποτελέσματα ήρθαν μόλις τον Οκτώβριο - η δική μας ομάδα συγκεντρώθηκε πλήρως, αναπτύχθηκε η αρχιτεκτονική του συστήματος και αγοράστηκε εξοπλισμός. Τώρα η ομάδα έχει 16 άτομα, έξι από τα οποία ασχολούνται με την ανάπτυξη backend και frontend, τρία από τα οποία ασχολούνται με την ανάλυση συστήματος. Έξι ακόμη άτομα εμπλέκονται σε χειροκίνητες δοκιμές, φόρτωση, αυτοματοποιημένες δοκιμές και συντήρηση προϊόντων. Επιπλέον, έχουμε έναν ειδικό σε SRE.
Όχι μόνο οι προγραμματιστές γράφουν κώδικα στην ομάδα μας· σχεδόν όλα τα παιδιά ξέρουν πώς να προγραμματίζουν και να γράφουν αυτόματα τεστ, να φορτώνουν σενάρια και σενάρια αυτοματισμού. Δίνουμε ιδιαίτερη προσοχή σε αυτό, καθώς ακόμη και η υποστήριξη προϊόντων απαιτεί υψηλό επίπεδο αυτοματισμού. Προσπαθούμε πάντα να συμβουλεύουμε και να βοηθάμε συναδέλφους που δεν έχουν προγραμματίσει πριν, και τους αναθέτουμε κάποιες μικρές εργασίες για να δουλέψουν.
Λόγω της πανδημίας του κορωνοϊού, μεταφέραμε ολόκληρη την ομάδα σε απομακρυσμένη εργασία· η διαθεσιμότητα όλων των εργαλείων για τη διαχείριση ανάπτυξης, η ενσωματωμένη ροή εργασίας στο Jira και στο GitLab κατέστησαν δυνατή την εύκολη μετάβαση σε αυτό το στάδιο. Οι μήνες που πέρασαν εξ αποστάσεως έδειξαν ότι η παραγωγικότητα της ομάδας δεν υπέφερε ως αποτέλεσμα· για πολλούς, η άνεση στη δουλειά αυξήθηκε, το μόνο που έλειπε ήταν η ζωντανή επικοινωνία.
Συνάντηση ομάδας εξ αποστάσεως
Συναντήσεις κατά την εξ αποστάσεως εργασία
Τεχνολογική στοίβα της λύσης
Το τυπικό αποθετήριο και το εργαλείο CI/CD για το X5 είναι το GitLab. Το χρησιμοποιούμε για αποθήκευση κώδικα, συνεχείς δοκιμές και ανάπτυξη σε διακομιστές δοκιμής και παραγωγής. Χρησιμοποιούμε επίσης την πρακτική του ελέγχου κώδικα, όταν τουλάχιστον 2 συνάδελφοι πρέπει να εγκρίνουν τις αλλαγές που έγιναν από τον προγραμματιστή στον κώδικα. Οι αναλυτές στατικού κώδικα SonarQube και JaCoCo μας βοηθούν να διατηρήσουμε τον κώδικά μας καθαρό και να εξασφαλίσουμε το απαιτούμενο επίπεδο κάλυψης δοκιμής μονάδας. Όλες οι αλλαγές στον κωδικό πρέπει να περάσουν από αυτούς τους ελέγχους. Όλα τα δοκιμαστικά σενάρια που εκτελούνται με μη αυτόματο τρόπο στη συνέχεια αυτοματοποιούνται.
Για την επιτυχή εφαρμογή των επιχειρηματικών διαδικασιών από τη «Marcus», έπρεπε να λύσουμε μια σειρά από τεχνολογικά προβλήματα, για το καθένα με τη σειρά.
Εργασία 1. Η ανάγκη για οριζόντια επεκτασιμότητα του συστήματος
Για να λύσουμε αυτό το πρόβλημα, επιλέξαμε μια προσέγγιση microservice στην αρχιτεκτονική. Ταυτόχρονα, ήταν πολύ σημαντικό να κατανοήσουμε τους τομείς ευθύνης των υπηρεσιών. Προσπαθήσαμε να τα χωρίσουμε σε επιχειρηματικές δραστηριότητες, λαμβάνοντας υπόψη τις ιδιαιτερότητες των διαδικασιών. Για παράδειγμα, η αποδοχή σε μια αποθήκη δεν είναι μια πολύ συχνή, αλλά πολύ μεγάλης κλίμακας λειτουργία, κατά την οποία είναι απαραίτητο να ληφθούν γρήγορα από την κρατική ρυθμιστική αρχή πληροφορίες σχετικά με τις μονάδες των αγαθών που γίνονται δεκτές, ο αριθμός των οποίων σε μία παράδοση φτάνει τις 600000 , ελέγξτε το παραδεκτό της αποδοχής αυτού του προϊόντος στην αποθήκη και επιστρέψτε όλες τις απαραίτητες πληροφορίες για το σύστημα αυτοματισμού της αποθήκης. Όμως η αποστολή από αποθήκες έχει πολύ μεγαλύτερη ένταση, αλλά ταυτόχρονα λειτουργεί με μικρούς όγκους δεδομένων.
Υλοποιούμε όλες τις υπηρεσίες σε ανιθαγενή βάση και ακόμη προσπαθούμε να χωρίσουμε τις εσωτερικές λειτουργίες σε βήματα, χρησιμοποιώντας αυτό που ονομάζουμε αυτοθέματα του Κάφκα. Αυτό συμβαίνει όταν μια μικρουπηρεσία στέλνει ένα μήνυμα στον εαυτό της, το οποίο σας επιτρέπει να εξισορροπήσετε το φορτίο σε λειτουργίες που απαιτούν περισσότερους πόρους και απλοποιεί τη συντήρηση του προϊόντος, αλλά περισσότερο αργότερα.
Αποφασίσαμε να διαχωρίσουμε τις ενότητες για αλληλεπίδραση με εξωτερικά συστήματα σε ξεχωριστές υπηρεσίες. Αυτό κατέστησε δυνατή την επίλυση του προβλήματος της συχνής αλλαγής API εξωτερικών συστημάτων, χωρίς ουσιαστικά καμία επίδραση στις υπηρεσίες με επιχειρηματική λειτουργικότητα.
Όλες οι μικροϋπηρεσίες αναπτύσσονται σε ένα σύμπλεγμα OpenShift, το οποίο λύνει τόσο το πρόβλημα της κλιμάκωσης κάθε μικρουπηρεσίας όσο και μας επιτρέπει να μην χρησιμοποιούμε εργαλεία Service Discovery τρίτων.
Εργασία 2. Η ανάγκη διατήρησης υψηλού φορτίου και πολύ εντατικής ανταλλαγής δεδομένων μεταξύ υπηρεσιών πλατφόρμας: Μόνο κατά τη φάση έναρξης του έργου εκτελούνται περίπου 600 λειτουργίες ανά δευτερόλεπτο. Αναμένουμε ότι αυτή η τιμή θα αυξηθεί στα 5000 ops/sec καθώς τα καταστήματα λιανικής συνδέονται στην πλατφόρμα μας.
Αυτό το πρόβλημα επιλύθηκε αναπτύσσοντας ένα σύμπλεγμα Kafka και εγκαταλείποντας σχεδόν πλήρως τη σύγχρονη αλληλεπίδραση μεταξύ των μικροϋπηρεσιών της πλατφόρμας. Αυτό απαιτεί πολύ προσεκτική ανάλυση των απαιτήσεων του συστήματος, καθώς δεν μπορούν όλες οι λειτουργίες να είναι ασύγχρονες. Ταυτόχρονα, όχι μόνο μεταδίδουμε συμβάντα μέσω του μεσίτη, αλλά μεταφέρουμε και όλες τις απαιτούμενες επιχειρηματικές πληροφορίες στο μήνυμα. Έτσι, το μέγεθος του μηνύματος μπορεί να φτάσει αρκετές εκατοντάδες kilobyte. Το όριο μεγέθους μηνύματος στον Κάφκα απαιτεί από εμάς να προβλέψουμε με ακρίβεια το μέγεθος του μηνύματος και, εάν είναι απαραίτητο, τα διαιρούμε, αλλά η διαίρεση είναι λογική και σχετίζεται με τις επιχειρηματικές δραστηριότητες.
Για παράδειγμα, χωρίζουμε τα αγαθά που φτάνουν σε ένα αυτοκίνητο σε κουτιά. Για σύγχρονες λειτουργίες, εκχωρούνται ξεχωριστές μικροϋπηρεσίες και διενεργείται ενδελεχής δοκιμή φορτίου. Η χρήση του Kafka μας παρουσίασε μια άλλη πρόκληση - η δοκιμή της λειτουργίας της υπηρεσίας μας λαμβάνοντας υπόψη την ενσωμάτωση του Kafka καθιστά όλες τις δοκιμές των μονάδων μας ασύγχρονες. Επιλύσαμε αυτό το πρόβλημα γράφοντας τις δικές μας βοηθητικές μεθόδους χρησιμοποιώντας το Embedded Kafka Broker. Αυτό δεν εξαλείφει την ανάγκη να γράφουμε μοναδιαίες δοκιμές για μεμονωμένες μεθόδους, αλλά προτιμούμε να δοκιμάζουμε πολύπλοκες περιπτώσεις χρησιμοποιώντας τον Κάφκα.
Δόθηκε μεγάλη προσοχή στην ανίχνευση των αρχείων καταγραφής, ώστε το TraceId τους να μην χάνεται όταν προκύπτουν εξαιρέσεις κατά τη λειτουργία των υπηρεσιών ή κατά την εργασία με παρτίδα Kafka. Και αν δεν υπήρχαν ειδικά προβλήματα με το πρώτο, τότε στη δεύτερη περίπτωση αναγκαζόμαστε να καταγράψουμε όλα τα TraceId με τα οποία ήρθε η παρτίδα και να επιλέξουμε ένα για να συνεχίσουμε την ανίχνευση. Στη συνέχεια, κατά την αναζήτηση με το αρχικό TraceId, ο χρήστης θα ανακαλύψει εύκολα με ποιον τρόπο συνεχίστηκε η ανίχνευση.
Εργασία 3. Η ανάγκη αποθήκευσης μεγάλου όγκου δεδομένων: Περισσότερες από 1 δισεκατομμύριο ετικέτες ετησίως μόνο για τον καπνό έρχονται στο X5. Απαιτούν συνεχή και γρήγορη πρόσβαση. Συνολικά, το σύστημα πρέπει να επεξεργαστεί περίπου 10 δισεκατομμύρια εγγραφές του ιστορικού μετακίνησης αυτών των εμπορευμάτων με ετικέτα.
Για την επίλυση του τρίτου προβλήματος, επιλέχθηκε η βάση δεδομένων NoSQL MongoDB. Έχουμε δημιουργήσει ένα θραύσμα 5 κόμβων και κάθε κόμβος έχει ένα Replica Set 3 διακομιστών. Αυτό σας επιτρέπει να κλιμακώσετε το σύστημα οριζόντια, προσθέτοντας νέους διακομιστές στο σύμπλεγμα και διασφαλίζετε την ανοχή σφαλμάτων του. Εδώ αντιμετωπίσαμε ένα άλλο πρόβλημα - τη διασφάλιση της συναλλακτικότητας στο σύμπλεγμα mongo, λαμβάνοντας υπόψη τη χρήση οριζόντια κλιμακούμενων μικροϋπηρεσιών. Για παράδειγμα, μία από τις εργασίες του συστήματός μας είναι να εντοπίζει προσπάθειες επαναπώλησης προϊόντων με τους ίδιους κωδικούς ετικετών. Εδώ, εμφανίζονται επικαλύψεις με λανθασμένες σαρώσεις ή εσφαλμένες λειτουργίες από ταμίες. Βρήκαμε ότι τέτοια διπλότυπα μπορούν να προκύψουν τόσο εντός μιας παρτίδας Kafka που υποβάλλεται σε επεξεργασία όσο και εντός δύο παρτίδων που επεξεργάζονται παράλληλα. Έτσι, ο έλεγχος για διπλότυπα μέσω ερωτήματος στη βάση δεδομένων δεν έδωσε τίποτα. Για κάθε microservice, λύσαμε το πρόβλημα ξεχωριστά με βάση την επιχειρηματική λογική αυτής της υπηρεσίας. Για παράδειγμα, για ελέγχους, προσθέσαμε μια επιταγή εντός παρτίδας και ξεχωριστή επεξεργασία για την εμφάνιση διπλότυπων κατά την εισαγωγή.
Για να διασφαλίσουμε ότι η εργασία των χρηστών με το ιστορικό των λειτουργιών δεν επηρεάζει με κανέναν τρόπο το πιο σημαντικό πράγμα - τη λειτουργία των επιχειρηματικών διαδικασιών μας, έχουμε διαχωρίσει όλα τα ιστορικά δεδομένα σε μια ξεχωριστή υπηρεσία με ξεχωριστή βάση δεδομένων, η οποία λαμβάνει επίσης πληροφορίες μέσω του Kafka . Με αυτόν τον τρόπο, οι χρήστες εργάζονται με μια απομονωμένη υπηρεσία χωρίς να επηρεάζουν τις υπηρεσίες που επεξεργάζονται δεδομένα για συνεχείς λειτουργίες.
Εργασία 4: Επανεπεξεργασία και παρακολούθηση ουράς:
Στα κατανεμημένα συστήματα, αναπόφευκτα προκύπτουν προβλήματα και σφάλματα στη διαθεσιμότητα βάσεων δεδομένων, ουρών και εξωτερικών πηγών δεδομένων. Στην περίπτωση του Marcus, η πηγή τέτοιων σφαλμάτων είναι η ενοποίηση με εξωτερικά συστήματα. Ήταν απαραίτητο να βρεθεί μια λύση που θα επέτρεπε επαναλαμβανόμενα αιτήματα για λανθασμένες απαντήσεις με κάποιο καθορισμένο χρονικό όριο, αλλά ταυτόχρονα δεν θα σταματούσε την επεξεργασία επιτυχημένων αιτημάτων στην κύρια ουρά. Για το σκοπό αυτό, επιλέχθηκε η λεγόμενη έννοια «επανάληψης δοκιμής βάσει θέματος». Για κάθε κύριο θέμα, δημιουργούνται ένα ή περισσότερα θέματα επανάληψης στα οποία αποστέλλονται λανθασμένα μηνύματα και ταυτόχρονα εξαλείφεται η καθυστέρηση στην επεξεργασία των μηνυμάτων από το κύριο θέμα. Σχέδιο αλληλεπίδρασης -
Για να εφαρμόσουμε ένα τέτοιο σχήμα, χρειαζόμασταν τα εξής: να ενσωματώσουμε αυτήν τη λύση με το Spring και να αποφύγουμε την αντιγραφή κώδικα. Σερφάροντας στο διαδίκτυο, συναντήσαμε μια παρόμοια λύση που βασίζεται στο Spring BeanPostProccessor, αλλά μας φαινόταν αδικαιολόγητα δυσκίνητη. Η ομάδα μας έχει φτιάξει μια απλούστερη λύση που μας επιτρέπει να ενσωματωθούμε στον κύκλο της Άνοιξης για τη δημιουργία καταναλωτών και επιπλέον να προσθέσουμε Επανάληψη Καταναλωτών. Προσφέραμε ένα πρωτότυπο της λύσης μας στην ομάδα Spring, μπορείτε να το δείτε . Ο αριθμός των Καταναλωτών Επανάληψης και ο αριθμός των προσπαθειών για κάθε καταναλωτή διαμορφώνονται μέσω παραμέτρων, ανάλογα με τις ανάγκες της επιχειρηματικής διαδικασίας, και για να λειτουργήσουν όλα, το μόνο που μένει είναι να προσθέσετε τον σχολιασμό org.springframework.kafka.annotation.KafkaListener , το οποίο είναι γνωστό σε όλους τους προγραμματιστές της Spring.
Εάν δεν ήταν δυνατή η επεξεργασία του μηνύματος μετά από όλες τις προσπάθειες επανάληψης, μεταβαίνει στο DLT (θέμα νεκρού γράμματος) χρησιμοποιώντας το Spring DeadLetterPublishingRecoverer. Κατόπιν αιτήματος υποστήριξης, επεκτείναμε αυτήν τη λειτουργία και δημιουργήσαμε μια ξεχωριστή υπηρεσία που σας επιτρέπει να προβάλλετε μηνύματα που περιλαμβάνονται στο DLT, στο stackTrace, στο traceId και άλλες χρήσιμες πληροφορίες σχετικά με αυτά. Επιπλέον, η παρακολούθηση και οι ειδοποιήσεις προστέθηκαν σε όλα τα θέματα DLT και τώρα, στην πραγματικότητα, η εμφάνιση ενός μηνύματος σε ένα θέμα DLT είναι ένας λόγος για ανάλυση και διόρθωση ενός ελαττώματος. Αυτό είναι πολύ βολικό - με το όνομα του θέματος, καταλαβαίνουμε αμέσως σε ποιο βήμα της διαδικασίας προέκυψε το πρόβλημα, το οποίο επιταχύνει σημαντικά την αναζήτηση για τη βασική του αιτία.
Πιο πρόσφατα, εφαρμόσαμε μια διεπαφή που μας επιτρέπει να στέλνουμε ξανά μηνύματα χρησιμοποιώντας την υποστήριξή μας αφού εξαλείψουμε τις αιτίες τους (για παράδειγμα, επαναφέρουμε τη λειτουργικότητα του εξωτερικού συστήματος) και, φυσικά, καθορίζουμε το αντίστοιχο ελάττωμα για ανάλυση. Εδώ είναι χρήσιμα τα αυτοθέματά μας: για να μην επανεκκινήσετε μια μακρά αλυσίδα επεξεργασίας, μπορείτε να την επανεκκινήσετε από το επιθυμητό βήμα.
Λειτουργία πλατφόρμας
Η πλατφόρμα βρίσκεται ήδη σε παραγωγική λειτουργία, καθημερινά πραγματοποιούμε παραδόσεις και αποστολές, συνδέουμε νέα κέντρα διανομής και καταστήματα. Ως μέρος του πιλοτικού, το σύστημα συνεργάζεται με τις ομάδες προϊόντων «Καπνός» και «Παπούτσια».
Ολόκληρη η ομάδα μας συμμετέχει στη διεξαγωγή πιλοτικών προγραμμάτων, αναλύει τα αναδυόμενα προβλήματα και κάνει προτάσεις για τη βελτίωση του προϊόντος μας, από τη βελτίωση των αρχείων καταγραφής έως την αλλαγή διαδικασιών.
Για να μην επαναλάβουμε τα λάθη μας, όλες οι περιπτώσεις που βρέθηκαν κατά τη διάρκεια του πιλότου αντικατοπτρίζονται σε αυτοματοποιημένες δοκιμές. Η παρουσία μεγάλου αριθμού αυτόματων δοκιμών και δοκιμών μονάδας σάς επιτρέπει να διεξάγετε δοκιμές παλινδρόμησης και να εγκαταστήσετε μια επείγουσα επιδιόρθωση κυριολεκτικά μέσα σε λίγες ώρες.
Τώρα συνεχίζουμε να αναπτύσσουμε και να βελτιώνουμε την πλατφόρμα μας και συνεχώς αντιμετωπίζουμε νέες προκλήσεις. Αν σας ενδιαφέρει, θα μιλήσουμε για τις λύσεις μας στα παρακάτω άρθρα.
Πηγή: www.habr.com