Τι θα μπορούσε να αναγκάσει μια τόσο μεγάλη εταιρεία όπως η Lamoda, με μια βελτιωμένη διαδικασία και δεκάδες διασυνδεδεμένες υπηρεσίες, να αλλάξει σημαντικά την προσέγγισή της; Το κίνητρο μπορεί να είναι εντελώς διαφορετικό: από νομοθετικό έως την επιθυμία πειραματισμού που είναι εγγενής σε όλους τους προγραμματιστές.
Αλλά αυτό δεν σημαίνει ότι δεν μπορείτε να υπολογίζετε σε πρόσθετα οφέλη. Ο Sergey Zaika θα σας πει τι ακριβώς μπορείτε να κερδίσετε εάν εφαρμόσετε το API που βασίζεται σε εκδηλώσεις στον Kafka (). Θα υπάρξει επίσης σίγουρα λόγος για μεγάλα πλάνα και ενδιαφέρουσες ανακαλύψεις - το πείραμα δεν μπορεί να κάνει χωρίς αυτά.
Αποποίηση ευθύνης: Αυτό το άρθρο βασίζεται σε υλικά από μια συνάντηση που πραγματοποιήθηκε ο Sergey τον Νοέμβριο του 2018 στο HighLoad++. Η ζωντανή εμπειρία της Lamoda από τη συνεργασία με τον Kafka προσέλκυσε τους ακροατές όχι λιγότερο από άλλες αναφορές στο πρόγραμμα. Πιστεύουμε ότι αυτό είναι ένα εξαιρετικό παράδειγμα του γεγονότος ότι μπορείτε και πρέπει να βρίσκετε πάντα ομοϊδεάτες και οι διοργανωτές του HighLoad++ θα συνεχίσουν να προσπαθούν να δημιουργήσουν μια ατμόσφαιρα που να ευνοεί αυτό.
Σχετικά με τη διαδικασία
Η Lamoda είναι μια μεγάλη πλατφόρμα ηλεκτρονικού εμπορίου που έχει το δικό της κέντρο επικοινωνίας, υπηρεσία παράδοσης (και πολλές θυγατρικές), ένα φωτογραφικό στούντιο, μια τεράστια αποθήκη και όλα αυτά λειτουργούν με το δικό της λογισμικό. Υπάρχουν δεκάδες τρόποι πληρωμής, συνεργάτες b2b που ενδέχεται να χρησιμοποιούν ορισμένες ή όλες αυτές τις υπηρεσίες και θέλουν να γνωρίζουν ενημερωμένες πληροφορίες για τα προϊόντα τους. Επιπλέον, η Lamoda δραστηριοποιείται σε τρεις χώρες εκτός από τη Ρωσική Ομοσπονδία και εκεί όλα είναι λίγο διαφορετικά. Συνολικά, υπάρχουν πιθανώς περισσότεροι από εκατό τρόποι για να διαμορφώσετε μια νέα παραγγελία, η οποία πρέπει να επεξεργαστεί με τον δικό της τρόπο. Όλα αυτά λειτουργούν με τη βοήθεια δεκάδων υπηρεσιών που μερικές φορές επικοινωνούν με μη προφανείς τρόπους. Υπάρχει επίσης ένα κεντρικό σύστημα του οποίου η κύρια ευθύνη είναι οι καταστάσεις παραγγελιών. Τη λέμε BOB, δουλεύω μαζί της.
Εργαλείο επιστροφής χρημάτων με API που βασίζεται σε συμβάντα
Η λέξη με γνώμονα τα γεγονότα είναι αρκετά παραπλανητική· λίγο παρακάτω θα ορίσουμε με περισσότερες λεπτομέρειες τι σημαίνει αυτό. Θα ξεκινήσω με το πλαίσιο στο οποίο αποφασίσαμε να δοκιμάσουμε την προσέγγιση API που βασίζεται σε γεγονότα στον Κάφκα.
Σε οποιοδήποτε κατάστημα, εκτός από τις παραγγελίες για τις οποίες πληρώνουν οι πελάτες, υπάρχουν φορές που το κατάστημα υποχρεούται να επιστρέψει χρήματα επειδή το προϊόν δεν ταίριαζε στον πελάτη. Αυτή είναι μια σχετικά σύντομη διαδικασία: διευκρινίζουμε τις πληροφορίες, εάν χρειάζεται, και μεταφέρουμε τα χρήματα.
Αλλά η επιστροφή έγινε πιο περίπλοκη λόγω αλλαγών στη νομοθεσία και έπρεπε να εφαρμόσουμε μια ξεχωριστή μικρουπηρεσία για αυτήν.
Το κίνητρό μας:
- Νόμος FZ-54 - εν ολίγοις, ο νόμος απαιτεί την αναφορά στην εφορία για κάθε νομισματική συναλλαγή, είτε πρόκειται για επιστροφή είτε για απόδειξη, μέσα σε ένα αρκετά σύντομο SLA λίγων λεπτών. Εμείς, ως εταιρεία ηλεκτρονικού εμπορίου, πραγματοποιούμε πολλές εργασίες. Τεχνικά, αυτό σημαίνει νέα ευθύνη (και επομένως μια νέα υπηρεσία) και βελτιώσεις σε όλα τα εμπλεκόμενα συστήματα.
- Split BOB είναι ένα εσωτερικό έργο της εταιρείας για την απαλλαγή του BOB από έναν μεγάλο αριθμό μη βασικών ευθυνών και τη μείωση της συνολικής πολυπλοκότητάς του.
Αυτό το διάγραμμα δείχνει τα κύρια συστήματα Lamoda. Τώρα οι περισσότεροι είναι περισσότεροι ένας αστερισμός 5-10 μικροϋπηρεσιών γύρω από έναν συρρικνούμενο μονόλιθο. Αυξάνονται σιγά σιγά, αλλά προσπαθούμε να τα κάνουμε μικρότερα, γιατί η ανάπτυξη του θραύσματος που έχει επιλεγεί στη μέση είναι τρομακτική - δεν μπορούμε να του επιτρέψουμε να πέσει. Είμαστε αναγκασμένοι να κάνουμε κράτηση για όλες τις ανταλλαγές (βέλη) και να λάβουμε υπόψη το γεγονός ότι οποιαδήποτε από αυτές μπορεί να αποδειχθεί ότι δεν είναι διαθέσιμη.
Το BOB έχει επίσης πολλές ανταλλαγές: συστήματα πληρωμών, συστήματα παράδοσης, συστήματα ειδοποιήσεων κ.λπ.
Τεχνικά το BOB είναι:
- ~ 150 χιλιάδες γραμμές κώδικα + ~ 100 χιλιάδες γραμμές δοκιμών.
- php7.2 + Zend 1 & Symfony Components 3;
- >100 API & ~50 εξερχόμενες ενσωματώσεις.
- 4 χώρες με τη δική τους επιχειρηματική λογική.
Η ανάπτυξη του BOB είναι δαπανηρή και επίπονη, η ποσότητα του κώδικα και των προβλημάτων που επιλύει είναι τέτοια που κανείς δεν μπορεί να τα βάλει όλα στο μυαλό του. Γενικά, υπάρχουν πολλοί λόγοι για να το απλοποιήσουμε.
Διαδικασία Επιστροφής
Αρχικά, δύο συστήματα εμπλέκονται στη διαδικασία: BOB και Payment. Τώρα εμφανίζονται άλλα δύο:
- Υπηρεσία Fiscalization, η οποία θα φροντίζει για προβλήματα φορολογίας και επικοινωνίας με εξωτερικές υπηρεσίες.
- Εργαλείο επιστροφής χρημάτων, το οποίο περιέχει απλώς νέες ανταλλαγές για να μην φουσκώσει το BOB.
Τώρα η διαδικασία μοιάζει με αυτό:
- Ο BOB λαμβάνει ένα αίτημα για επιστροφή χρημάτων.
- Ο BOB μιλάει για αυτό το Εργαλείο επιστροφής χρημάτων.
- Το Εργαλείο Επιστροφής Χρημάτων λέει στην Πληρωμή: "Επιστρέψτε τα χρήματα".
- Η πληρωμή επιστρέφει τα χρήματα.
- Το εργαλείο επιστροφής χρημάτων και το BOB συγχρονίζουν καταστάσεις μεταξύ τους, γιατί προς το παρόν το χρειάζονται και οι δύο. Δεν είμαστε ακόμη έτοιμοι να μεταβούμε πλήρως στο Εργαλείο Επιστροφής Χρημάτων, καθώς το BOB διαθέτει διεπαφή χρήστη, αναφορές για λογιστική και γενικά πολλά δεδομένα που δεν μπορούν να μεταφερθούν τόσο εύκολα. Πρέπει να καθίσετε σε δύο καρέκλες.
- Το αίτημα για φορολογική εξάλειψη φεύγει.
Ως αποτέλεσμα, φτιάξαμε ένα είδος λεωφορείου εκδηλώσεων στον Κάφκα - event-bus, στο οποίο ξεκίνησαν όλα. Ούρα, τώρα έχουμε ένα μόνο σημείο αποτυχίας (σαρκασμός).
Τα πλεονεκτήματα και τα μειονεκτήματα είναι αρκετά προφανή. Φτιάξαμε ένα λεωφορείο, που σημαίνει ότι πλέον όλες οι υπηρεσίες εξαρτώνται από αυτό. Αυτό απλοποιεί τη σχεδίαση, αλλά εισάγει ένα μόνο σημείο αστοχίας στο σύστημα. Ο Κάφκα θα συντριβεί, η διαδικασία θα σταματήσει.
Τι είναι ένα API που βασίζεται σε συμβάντα
Μια καλή απάντηση σε αυτό το ερώτημα βρίσκεται στην έκθεση του Martin Fowler (GOTO 2017) .
Συνοπτικά τι κάναμε:
- Ολοκληρώστε όλες τις ασύγχρονες ανταλλαγές μέσω αποθήκευση εκδηλώσεων. Αντί να ενημερώνουμε κάθε ενδιαφερόμενο καταναλωτή για μια αλλαγή κατάστασης μέσω του δικτύου, γράφουμε ένα συμβάν σχετικά με μια αλλαγή κατάστασης σε έναν κεντρικό χώρο αποθήκευσης και οι καταναλωτές που ενδιαφέρονται για το θέμα διαβάζουν όλα όσα εμφανίζονται από εκεί.
- Το συμβάν σε αυτή την περίπτωση είναι μια ειδοποίηση (κοινοποιήσεις) ότι κάτι έχει αλλάξει κάπου. Για παράδειγμα, η κατάσταση παραγγελίας έχει αλλάξει. Ένας καταναλωτής που ενδιαφέρεται για ορισμένα δεδομένα που συνοδεύουν την αλλαγή κατάστασης που δεν περιλαμβάνονται στην ειδοποίηση, μπορεί να μάθει ο ίδιος την κατάστασή της.
- Η μέγιστη επιλογή είναι η πλήρης προμήθεια συμβάντων, μεταβίβαση του κράτους, στην οποία η εκδήλωση περιέχει όλες τις απαραίτητες πληροφορίες για την επεξεργασία: από πού προήλθε και σε ποια κατάσταση πήγε, πώς ακριβώς άλλαξαν τα δεδομένα κ.λπ. Το μόνο ερώτημα είναι η σκοπιμότητα και ο όγκος των πληροφοριών που μπορείτε να αντέξετε οικονομικά να αποθηκεύσετε.
Ως μέρος της κυκλοφορίας του Εργαλείου επιστροφής χρημάτων, χρησιμοποιήσαμε την τρίτη επιλογή. Αυτή η απλούστευση της επεξεργασίας συμβάντων, καθώς δεν υπήρχε ανάγκη εξαγωγής λεπτομερών πληροφοριών, καθώς και εξάλειψε το σενάριο όπου κάθε νέο συμβάν δημιουργεί μια έκρηξη διευκρινιστικών αιτημάτων λήψης από τους καταναλωτές.
Υπηρεσία εργαλείου επιστροφής χρημάτων μη φορτωμένο, οπότε ο Κάφκα υπάρχει περισσότερο μια γεύση από το στυλό παρά μια ανάγκη. Δεν νομίζω ότι αν η υπηρεσία επιστροφής χρημάτων γινόταν έργο μεγάλου φόρτου, οι επιχειρήσεις θα ήταν ευχαριστημένες.
Ασύγχρονη ανταλλαγή ΟΠΩΣ ΕΧΕΙ
Για ασύγχρονες ανταλλαγές, το τμήμα PHP χρησιμοποιεί συνήθως το RabbitMQ. Συλλέξαμε τα δεδομένα για το αίτημα, το βάλαμε σε ουρά και ο καταναλωτής της ίδιας υπηρεσίας το διάβασε και το έστειλε (ή δεν το έστειλε). Για το ίδιο το API, η Lamoda χρησιμοποιεί ενεργά το Swagger. Σχεδιάζουμε ένα API, το περιγράφουμε στο Swagger και δημιουργούμε κώδικα πελάτη και διακομιστή. Χρησιμοποιούμε επίσης ένα ελαφρώς βελτιωμένο JSON RPC 2.0.
Σε ορισμένα μέρη χρησιμοποιούνται λεωφορεία ESB, μερικά ζωντανά στο activeMQ, αλλά, γενικά, RabbitMQ - στάνταρ.
Ασύγχρονη ανταλλαγή TO BE
Κατά το σχεδιασμό ανταλλαγής μέσω διαύλου εκδηλώσεων, μπορεί να εντοπιστεί μια αναλογία. Ομοίως περιγράφουμε τη μελλοντική ανταλλαγή δεδομένων μέσω περιγραφών δομών συμβάντων. Στη μορφή yaml, έπρεπε να κάνουμε τη δημιουργία κώδικα μόνοι μας, η γεννήτρια δημιουργεί DTO σύμφωνα με τις προδιαγραφές και διδάσκει σε πελάτες και διακομιστές να συνεργάζονται μαζί τους. Η γενιά πηγαίνει σε δύο γλώσσες - golang και php. Αυτό βοηθά στη διατήρηση της συνοχής των βιβλιοθηκών. Η γεννήτρια είναι γραμμένη σε golang, γι' αυτό και πήρε το όνομα gogi.
Η προέλευση γεγονότων στον Κάφκα είναι τυπικό πράγμα. Υπάρχει λύση από την κύρια εταιρική έκδοση του Kafka Confluent, υπάρχει , μια λύση από τα αδέρφια του τομέα μας Zalando. Μας κίνητρο να ξεκινήσω με βανίλια Κάφκα - αυτό σημαίνει να αφήνουμε τη λύση ελεύθερη μέχρι να αποφασίσουμε τελικά αν θα τη χρησιμοποιήσουμε παντού, και επίσης να αφήνουμε στον εαυτό μας χώρο για ελιγμούς και βελτιώσεις: θέλουμε υποστήριξη για JSON RPC 2.0, γεννήτριες για δύο γλώσσες και ας δούμε τι άλλο.
Είναι ειρωνικό ότι ακόμη και σε μια τόσο χαρούμενη περίπτωση, όταν υπάρχει μια περίπου παρόμοια επιχείρηση, η Zalando, η οποία έφτιαξε μια περίπου παρόμοια λύση, δεν μπορούμε να τη χρησιμοποιήσουμε αποτελεσματικά.
Το αρχιτεκτονικό μοτίβο κατά την εκτόξευση είναι το εξής: διαβάζουμε απευθείας από τον Κάφκα, αλλά γράφουμε μόνο μέσω εκδηλώσεων-λεωφορείων. Υπάρχουν πολλά έτοιμα για ανάγνωση στον Κάφκα: μεσίτες, εξισορροπητές, και είναι λίγο πολύ έτοιμο για οριζόντια κλιμάκωση, ήθελα να το κρατήσω αυτό. Θέλαμε να ολοκληρώσουμε την ηχογράφηση μέσω ενός Gateway aka Events-bus, και να γιατί.
Εκδηλώσεις-λεωφορείο
Ή ένα λεωφορείο εκδηλώσεων. Αυτή είναι απλώς μια πύλη http χωρίς πολιτεία, η οποία αναλαμβάνει αρκετούς σημαντικούς ρόλους:
- Παραγωγή Επικύρωσης — ελέγχουμε ότι οι εκδηλώσεις πληρούν τις προδιαγραφές μας.
- Κύριο σύστημα συμβάντων, δηλαδή, αυτό είναι το κύριο και μοναδικό σύστημα στην εταιρεία που απαντά στο ερώτημα ποιες εκδηλώσεις με ποιες δομές θεωρούνται έγκυρες. Η επικύρωση περιλαμβάνει απλώς τύπους δεδομένων και αριθμούς για τον αυστηρό προσδιορισμό του περιεχομένου.
- Λειτουργία κατακερματισμού για διαμοιρασμό - η δομή του μηνύματος Kafka είναι κλειδί-τιμή και χρησιμοποιώντας τον κατακερματισμό του κλειδιού υπολογίζεται πού θα το τοποθετήσετε.
Γιατί
Εργαζόμαστε σε μια μεγάλη εταιρεία με απλοποιημένη διαδικασία. Γιατί να αλλάξει κάτι; Αυτό είναι ένα πείραμα, και αναμένουμε να αποκομίσουμε πολλά οφέλη.
1:n+1 ανταλλαγές (ένα προς πολλές)
Ο Κάφκα καθιστά πολύ εύκολη τη σύνδεση νέων καταναλωτών στο API.
Ας υποθέσουμε ότι έχετε έναν κατάλογο που πρέπει να ενημερώνετε σε πολλά συστήματα ταυτόχρονα (και σε ορισμένα νέα). Προηγουμένως, εφεύραμε μια δέσμη που υλοποιούσε set-API και το κύριο σύστημα ενημερωνόταν για τις διευθύνσεις των καταναλωτών. Τώρα το κύριο σύστημα στέλνει ενημερώσεις στο θέμα και όλοι όσοι ενδιαφέρονται το διαβάζουν. Εμφανίστηκε ένα νέο σύστημα - το εγγράψαμε για το θέμα. Ναι, επίσης πακέτο, αλλά πιο απλό.
Στην περίπτωση του εργαλείου επιστροφής χρημάτων, που είναι ένα κομμάτι BOB, είναι βολικό για εμάς να τα κρατάμε συγχρονισμένα μέσω του Kafka. Η πληρωμή λέει ότι τα χρήματα επιστράφηκαν: Ο BOB, η RT το ανακάλυψε αυτό, άλλαξε την κατάστασή τους, η Υπηρεσία φορολογίας το ανακάλυψε και εξέδωσε επιταγή.
Έχουμε σχέδια να δημιουργήσουμε μια ενοποιημένη Υπηρεσία Ειδοποιήσεων που θα ειδοποιεί τον πελάτη για νέα σχετικά με την παραγγελία/επιστροφές του. Τώρα αυτή η ευθύνη κατανέμεται μεταξύ των συστημάτων. Θα αρκεί να διδάξουμε στην Υπηρεσία Ειδοποιήσεων να συλλαμβάνει σχετικές πληροφορίες από τον Κάφκα και να απαντά σε αυτές (και να απενεργοποιεί αυτές τις ειδοποιήσεις σε άλλα συστήματα). Δεν θα απαιτηθούν νέες άμεσες ανταλλαγές.
Βάσει δεδομένων
Οι πληροφορίες μεταξύ των συστημάτων γίνονται διαφανείς - ανεξάρτητα από το τι «αιματηρή επιχείρηση» έχετε και όσο πυκνό κι αν είναι το ανεκτέλεστο σας. Η Lamoda διαθέτει ένα τμήμα Data Analytics που συλλέγει δεδομένα από συστήματα και τα τοποθετεί σε επαναχρησιμοποιήσιμη μορφή, τόσο για επιχειρήσεις όσο και για έξυπνα συστήματα. Ο Κάφκα σάς επιτρέπει να τους δίνετε γρήγορα πολλά δεδομένα και να διατηρείτε ενημερωμένη αυτή τη ροή πληροφοριών.
Ημερολόγιο αναπαραγωγής
Τα μηνύματα δεν εξαφανίζονται μετά την ανάγνωση, όπως στο RabbitMQ. Όταν ένα συμβάν περιέχει αρκετές πληροφορίες για επεξεργασία, έχουμε ένα ιστορικό πρόσφατων αλλαγών στο αντικείμενο και, εάν το επιθυμούμε, τη δυνατότητα εφαρμογής αυτών των αλλαγών.
Η περίοδος αποθήκευσης του αρχείου καταγραφής αναπαραγωγής εξαρτάται από την ένταση της εγγραφής σε αυτό το θέμα· ο Kafka σάς επιτρέπει να ορίζετε με ευελιξία όρια στο χρόνο αποθήκευσης και τον όγκο δεδομένων. Για εντατικά θέματα, είναι σημαντικό όλοι οι καταναλωτές να έχουν χρόνο να διαβάσουν τις πληροφορίες προτού εξαφανιστούν, ακόμη και σε περίπτωση βραχυπρόθεσμης αλειτουργίας. Συνήθως είναι δυνατή η αποθήκευση δεδομένων για μονάδες ημερών, που είναι αρκετά για υποστήριξη.
Στη συνέχεια, μια μικρή επανάληψη της τεκμηρίωσης, για όσους δεν γνωρίζουν τον Κάφκα (η εικόνα είναι επίσης από την τεκμηρίωση)
Το AMQP έχει ουρές: γράφουμε μηνύματα σε μια ουρά για τον καταναλωτή. Συνήθως, μια ουρά επεξεργάζεται από ένα σύστημα με την ίδια επιχειρηματική λογική. Εάν χρειάζεται να ειδοποιήσετε πολλά συστήματα, μπορείτε να διδάξετε την εφαρμογή να γράφει σε πολλές ουρές ή να διαμορφώνει την ανταλλαγή με τον μηχανισμό fanout, ο οποίος τα κλωνοποιεί η ίδια.
Ο Κάφκα έχει μια παρόμοια αφαίρεση τοπικός, στο οποίο γράφετε μηνύματα, αλλά δεν εξαφανίζονται μετά την ανάγνωση. Από προεπιλογή, όταν συνδέεστε στο Kafka, λαμβάνετε όλα τα μηνύματα και έχετε την επιλογή να αποθηκεύσετε από εκεί που σταματήσατε. Δηλαδή, διαβάζετε διαδοχικά, μπορείτε να μην επισημάνετε το μήνυμα ως αναγνωσμένο, αλλά να αποθηκεύσετε το αναγνωριστικό από το οποίο μπορείτε στη συνέχεια να συνεχίσετε την ανάγνωση. Το αναγνωριστικό στο οποίο ρυθμίσατε ονομάζεται μετατόπιση και ο μηχανισμός δεσμεύεται.
Κατά συνέπεια, μπορεί να εφαρμοστεί διαφορετική λογική. Για παράδειγμα, έχουμε το BOB σε 4 περιπτώσεις για διαφορετικές χώρες - η Lamoda βρίσκεται στη Ρωσία, το Καζακστάν, την Ουκρανία, τη Λευκορωσία. Δεδομένου ότι αναπτύσσονται χωριστά, έχουν ελαφρώς διαφορετικές ρυθμίσεις παραμέτρων και τη δική τους επιχειρηματική λογική. Υποδεικνύουμε στο μήνυμα σε ποια χώρα αναφέρεται. Κάθε καταναλωτής BOB σε κάθε χώρα διαβάζει με διαφορετικό groupId και αν το μήνυμα δεν ισχύει για αυτόν, το παραλείπει, π.χ. δεσμεύει αμέσως τη μετατόπιση +1. Εάν το ίδιο θέμα διαβάζεται από την Υπηρεσία Πληρωμών μας, τότε το κάνει με ξεχωριστή ομάδα και επομένως οι μετατοπίσεις δεν τέμνονται.
Απαιτήσεις εκδήλωσης:
- Πληρότητα δεδομένων. Θα ήθελα η εκδήλωση να έχει αρκετά δεδομένα ώστε να είναι δυνατή η επεξεργασία της.
- Ακεραιότητα Αναθέτουμε στο Events-bus την επαλήθευση ότι το συμβάν είναι συνεπές και ότι μπορεί να το επεξεργαστεί.
- Η σειρά είναι σημαντική. Σε περίπτωση επιστροφής, αναγκαζόμαστε να δουλέψουμε με την ιστορία. Με τις ειδοποιήσεις, η παραγγελία δεν είναι σημαντική, εάν είναι ομοιογενείς ειδοποιήσεις, το email θα είναι το ίδιο ανεξάρτητα από το ποια παραγγελία έφτασε πρώτη. Σε περίπτωση επιστροφής χρημάτων, υπάρχει μια σαφής διαδικασία· εάν αλλάξουμε τη σειρά, θα προκύψουν εξαιρέσεις, η επιστροφή χρημάτων δεν θα δημιουργηθεί ή θα υποβληθεί σε επεξεργασία - θα καταλήξουμε σε διαφορετική κατάσταση.
- Συνοχή. Έχουμε ένα κατάστημα και τώρα δημιουργούμε συμβάντα αντί για API. Χρειαζόμαστε έναν τρόπο γρήγορης και φθηνής μετάδοσης πληροφοριών σχετικά με νέα γεγονότα και αλλαγές σε υπάρχοντα στις υπηρεσίες μας. Αυτό επιτυγχάνεται μέσω μιας κοινής προδιαγραφής σε ξεχωριστό αποθετήριο git και γεννήτριες κώδικα. Επομένως, οι πελάτες και οι διακομιστές σε διαφορετικές υπηρεσίες συντονίζονται.
Ο Κάφκα στη Λαμόντα
Έχουμε τρεις εγκαταστάσεις Κάφκα:
- κούτσουρα?
- Ε&Α;
- Εκδηλώσεις-λεωφορείο.
Σήμερα μιλάμε μόνο για το τελευταίο σημείο. Στα events-bus, δεν έχουμε πολύ μεγάλες εγκαταστάσεις - 3 brokers (servers) και μόνο 27 θέματα. Κατά κανόνα, ένα θέμα είναι μια διαδικασία. Αλλά αυτό είναι ένα λεπτό σημείο, και θα το θίξουμε τώρα.
Πάνω είναι το γράφημα rps. Η διαδικασία επιστροφής χρημάτων επισημαίνεται με μια τιρκουάζ γραμμή (ναι, αυτή στον άξονα Χ) και η ροζ γραμμή είναι η διαδικασία ενημέρωσης περιεχομένου.
Ο κατάλογος Lamoda περιέχει εκατομμύρια προϊόντα και τα δεδομένα ενημερώνονται συνεχώς. Μερικές συλλογές ξεφεύγουν από τη μόδα, νέες κυκλοφορούν για να τις αντικαταστήσουν και νέα μοντέλα εμφανίζονται συνεχώς στον κατάλογο. Προσπαθούμε να προβλέψουμε τι θα είναι ενδιαφέρον για τους πελάτες μας αύριο, γι' αυτό αγοράζουμε συνεχώς νέα πράγματα, τα φωτογραφίζουμε και ενημερώνουμε τη βιτρίνα.
Οι ροζ κορυφές είναι ενημερώσεις προϊόντων, δηλαδή αλλαγές σε προϊόντα. Φαίνεται ότι τα παιδιά έβγαλαν φωτογραφίες, έβγαλαν φωτογραφίες και μετά ξανά! — φόρτωσε ένα πακέτο εκδηλώσεων.
Θήκες χρήσης Lamoda Events
Χρησιμοποιούμε την κατασκευασμένη αρχιτεκτονική για τις ακόλουθες λειτουργίες:
- Παρακολούθηση κατάστασης επιστροφής: παρότρυνση για δράση και παρακολούθηση κατάστασης από όλα τα εμπλεκόμενα συστήματα. Πληρωμή, καταστάσεις, φορολογία, ειδοποιήσεις. Εδώ δοκιμάσαμε την προσέγγιση, φτιάξαμε εργαλεία, συλλέξαμε όλα τα σφάλματα, γράψαμε τεκμηρίωση και είπαμε στους συναδέλφους μας πώς να τη χρησιμοποιήσουν.
- Ενημέρωση καρτών προϊόντων: διαμόρφωση, μεταδεδομένα, χαρακτηριστικά. Ένα σύστημα διαβάζει (το οποίο εμφανίζει) και πολλά γράφουν.
- Email, push και sms: η παραγγελία έχει παραληφθεί, η παραγγελία έφτασε, η επιστροφή έγινε αποδεκτή κ.λπ., είναι πολλά.
- Αποθήκη, ανανέωση αποθήκης — ποσοτική ενημέρωση ειδών, μόνο αριθμοί: άφιξη στην αποθήκη, επιστροφή. Είναι απαραίτητο όλα τα συστήματα που σχετίζονται με την κράτηση αγαθών να λειτουργούν με τα πιο πρόσφατα δεδομένα. Επί του παρόντος, το σύστημα ενημέρωσης μετοχών είναι αρκετά περίπλοκο· ο Κάφκα θα το απλοποιήσει.
- Ανάλυση Δεδομένων (τμήμα R&D), εργαλεία ML, analytics, στατιστικά. Θέλουμε οι πληροφορίες να είναι διαφανείς - ο Κάφκα είναι κατάλληλος για αυτό.
Τώρα το πιο ενδιαφέρον μέρος για τα μεγάλα χτυπήματα και τις ενδιαφέρουσες ανακαλύψεις που έχουν συμβεί τους τελευταίους έξι μήνες.
Προβλήματα σχεδιασμού
Ας υποθέσουμε ότι θέλουμε να κάνουμε κάτι νέο - για παράδειγμα, να μεταφέρουμε ολόκληρη τη διαδικασία παράδοσης στον Κάφκα. Τώρα μέρος της διαδικασίας υλοποιείται στην Επεξεργασία Παραγγελιών στο BOB. Υπάρχει ένα μοντέλο κατάστασης πίσω από τη μεταφορά μιας παραγγελίας στην υπηρεσία παράδοσης, τη μετακίνηση σε μια ενδιάμεση αποθήκη κ.λπ. Υπάρχει ένας ολόκληρος μονόλιθος, ακόμη και δύο, συν ένα σωρό API αφιερωμένα στην παράδοση. Ξέρουν πολύ περισσότερα για την παράδοση.
Αυτές φαίνεται να είναι παρόμοιες περιοχές, αλλά η Επεξεργασία Παραγγελιών στο BOB και το Σύστημα Αποστολής έχουν διαφορετικές καταστάσεις. Για παράδειγμα, ορισμένες υπηρεσίες ταχυμεταφορών δεν στέλνουν ενδιάμεσες καταστάσεις, αλλά μόνο τις τελικές: "παραδόθηκε" ή "χαμένο". Άλλοι, αντίθετα, αναφέρουν με μεγάλη λεπτομέρεια την κυκλοφορία των εμπορευμάτων. Ο καθένας έχει τους δικούς του κανόνες επικύρωσης: για κάποιους, το email είναι έγκυρο, πράγμα που σημαίνει ότι θα υποβληθεί σε επεξεργασία. για άλλους δεν ισχύει, αλλά η παραγγελία θα συνεχίσει να διεκπεραιώνεται γιατί υπάρχει τηλέφωνο επικοινωνίας και κάποιος θα πει ότι τέτοια παραγγελία δεν θα διεκπεραιωθεί καθόλου.
Ροή δεδομένων
Στην περίπτωση του Κάφκα, τίθεται το ζήτημα της οργάνωσης της ροής δεδομένων. Αυτή η εργασία περιλαμβάνει την επιλογή μιας στρατηγικής που βασίζεται σε πολλά σημεία· ας τα εξετάσουμε όλα.
Σε ένα θέμα ή σε διαφορετικά;
Έχουμε μια προδιαγραφή εκδήλωσης. Στο BOB γράφουμε ότι πρέπει να παραδοθεί μια τέτοια παραγγελία και υποδεικνύουμε: τον αριθμό παραγγελίας, τη σύνθεσή της, ορισμένα SKU και γραμμικούς κώδικες κ.λπ. Όταν τα εμπορεύματα φτάσουν στην αποθήκη, η παράδοση θα μπορεί να λάβει καταστάσεις, χρονικές σημάνσεις και ό,τι χρειάζεται. Στη συνέχεια, όμως, θέλουμε να λαμβάνουμε ενημερώσεις για αυτά τα δεδομένα στο BOB. Έχουμε μια αντίστροφη διαδικασία λήψης δεδομένων από την παράδοση. Είναι το ίδιο γεγονός; Ή είναι μια ξεχωριστή ανταλλαγή που αξίζει το δικό της θέμα;
Πιθανότατα, θα μοιάζουν πολύ και ο πειρασμός να δημιουργήσετε ένα θέμα δεν είναι αβάσιμος, γιατί ένα ξεχωριστό θέμα σημαίνει ξεχωριστούς καταναλωτές, ξεχωριστές ρυθμίσεις παραμέτρων, μια ξεχωριστή γενιά όλων αυτών. Όχι όμως γεγονός.
Νέο πεδίο ή νέο γεγονός;
Αλλά αν χρησιμοποιείτε τα ίδια συμβάντα, τότε προκύπτει άλλο πρόβλημα. Για παράδειγμα, δεν μπορούν όλα τα συστήματα παράδοσης να δημιουργήσουν το είδος DTO που μπορεί να δημιουργήσει το BOB. Τους στέλνουμε το αναγνωριστικό, αλλά δεν το αποθηκεύουν επειδή δεν το χρειάζονται και από την άποψη της έναρξης της διαδικασίας του διαύλου εκδήλωσης, αυτό το πεδίο είναι απαραίτητο.
Εάν εισαγάγουμε έναν κανόνα για το λεωφορείο συμβάντων ότι αυτό το πεδίο είναι απαραίτητο, τότε αναγκαζόμαστε να ορίσουμε πρόσθετους κανόνες επικύρωσης στο BOB ή στον χειριστή συμβάντος έναρξης. Η επικύρωση αρχίζει να εξαπλώνεται σε όλη την υπηρεσία - αυτό δεν είναι πολύ βολικό.
Ένα άλλο πρόβλημα είναι ο πειρασμός για σταδιακή ανάπτυξη. Μας λένε ότι κάτι πρέπει να προστεθεί στην εκδήλωση και ίσως, αν το καλοσκεφτούμε, θα έπρεπε να ήταν μια ξεχωριστή εκδήλωση. Αλλά στο σχέδιό μας, ένα ξεχωριστό γεγονός είναι ένα ξεχωριστό θέμα. Ένα ξεχωριστό θέμα είναι η όλη διαδικασία που περιέγραψα παραπάνω. Ο προγραμματιστής μπαίνει στον πειρασμό απλώς να προσθέσει ένα άλλο πεδίο στο σχήμα JSON και να το αναδημιουργήσει.
Στην περίπτωση των επιστροφών, φτάσαμε στην εκδήλωση εκδηλώσεων σε μισό χρόνο. Είχαμε ένα μετα-συμβάν που ονομάζεται ενημέρωση επιστροφής χρημάτων, το οποίο είχε ένα πεδίο τύπου που περιγράφει τι ήταν στην πραγματικότητα αυτή η ενημέρωση. Εξαιτίας αυτού, είχαμε "υπέροχους" διακόπτες με επικυρωτές που μας είπαν πώς να επικυρώσουμε αυτό το συμβάν με αυτόν τον τύπο.
Εκδόσεις εκδήλωσης
Για να επικυρώσετε μηνύματα στον Κάφκα μπορείτε να χρησιμοποιήσετε , αλλά ήταν απαραίτητο να τοποθετηθεί αμέσως πάνω του και να χρησιμοποιηθεί το Confluent. Στην περίπτωσή μας, πρέπει να είμαστε προσεκτικοί με την έκδοση. Δεν θα είναι πάντα δυνατή η εκ νέου ανάγνωση μηνυμάτων από το αρχείο καταγραφής αναπαραγωγής, επειδή το μοντέλο έχει "φύγει". Βασικά, αποδεικνύεται ότι δημιουργούνται εκδόσεις έτσι ώστε το μοντέλο να είναι συμβατό προς τα πίσω: για παράδειγμα, κάντε ένα πεδίο προσωρινά προαιρετικό. Εάν οι διαφορές είναι πολύ έντονες, αρχίζουμε να γράφουμε σε ένα νέο θέμα και μεταφέρουμε πελάτες όταν τελειώσουν την ανάγνωση του παλιού.
Εγγυημένη σειρά ανάγνωσης κατατμήσεων
Τα θέματα μέσα στον Κάφκα χωρίζονται σε χωρίσματα. Αυτό δεν είναι πολύ σημαντικό ενώ σχεδιάζουμε οντότητες και ανταλλαγές, αλλά είναι σημαντικό όταν αποφασίζουμε πώς να το καταναλώσουμε και να το κλιμακώσουμε.
Στη συνηθισμένη περίπτωση, γράφετε ένα θέμα στον Κάφκα. Από προεπιλογή, χρησιμοποιείται ένα διαμέρισμα και όλα τα μηνύματα σε αυτό το θέμα πηγαίνουν σε αυτό. Και κατά συνέπεια ο καταναλωτής διαβάζει αυτά τα μηνύματα διαδοχικά. Ας πούμε τώρα ότι πρέπει να επεκτείνουμε το σύστημα έτσι ώστε τα μηνύματα να διαβάζονται από δύο διαφορετικούς καταναλωτές. Εάν, για παράδειγμα, στέλνετε SMS, τότε μπορείτε να πείτε στον Κάφκα να κάνει ένα επιπλέον διαμέρισμα και ο Κάφκα θα αρχίσει να χωρίζει τα μηνύματα σε δύο μέρη - μισά εδώ, μισά εδώ.
Πώς τους χωρίζει ο Κάφκα; Κάθε μήνυμα έχει ένα σώμα (στο οποίο αποθηκεύουμε JSON) και ένα κλειδί. Μπορείτε να επισυνάψετε μια συνάρτηση κατακερματισμού σε αυτό το κλειδί, η οποία θα καθορίσει σε ποιο διαμέρισμα θα μπει το μήνυμα.
Στην περίπτωσή μας με τις επιστροφές χρημάτων, αυτό είναι σημαντικό, αν πάρουμε δύο διαμερίσματα, τότε υπάρχει πιθανότητα ένας παράλληλος καταναλωτής να επεξεργαστεί το δεύτερο συμβάν πριν από το πρώτο και να υπάρξει πρόβλημα. Η συνάρτηση κατακερματισμού διασφαλίζει ότι τα μηνύματα με το ίδιο κλειδί καταλήγουν στο ίδιο διαμέρισμα.
Γεγονότα vs εντολές
Αυτό είναι ένα άλλο πρόβλημα που αντιμετωπίσαμε. Το συμβάν είναι ένα συγκεκριμένο συμβάν: λέμε ότι κάτι συνέβη κάπου (κάτι_συνέβη), για παράδειγμα, ένα αντικείμενο ακυρώθηκε ή έγινε επιστροφή χρημάτων. Εάν κάποιος ακούσει αυτά τα συμβάντα, τότε σύμφωνα με το στοιχείο "ακυρώθηκε", θα δημιουργηθεί η οντότητα επιστροφής χρημάτων και κάπου στις ρυθμίσεις θα γραφεί η "επιστροφή χρημάτων".
Αλλά συνήθως, όταν σχεδιάζετε εκδηλώσεις, δεν θέλετε να τα γράφετε μάταια - βασίζεστε στο γεγονός ότι κάποιος θα τα διαβάσει. Υπάρχει μεγάλος πειρασμός να γράψετε όχι κάτι_έγινε (αντικείμενο_ακυρώθηκε, επιστροφή_χρηματοδότησης), αλλά κάτι_πρέπει_να_γίνεται. Για παράδειγμα, το προϊόν είναι έτοιμο για επιστροφή.
Από τη μία πλευρά, προτείνει πώς θα χρησιμοποιηθεί η εκδήλωση. Από την άλλη πλευρά, ακούγεται πολύ λιγότερο σαν ένα κανονικό όνομα συμβάντος. Εξάλλου, δεν απέχει πολύ από εδώ η εντολή do_something. Αλλά δεν έχετε καμία εγγύηση ότι κάποιος διάβασε αυτό το συμβάν. Και αν το διαβάσετε, τότε το διαβάσατε με επιτυχία. και αν το διαβάσατε με επιτυχία, τότε κάνατε κάτι, και αυτό το κάτι ήταν επιτυχημένο. Τη στιγμή που ένα συμβάν γίνεται do_something, η ανατροφοδότηση καθίσταται απαραίτητη και αυτό είναι πρόβλημα.
Στην ασύγχρονη ανταλλαγή στο RabbitMQ, όταν διαβάζετε το μήνυμα, πηγαίνετε στο http, έχετε μια απάντηση - τουλάχιστον ότι το μήνυμα ελήφθη. Όταν γράφετε στον Κάφκα, υπάρχει ένα μήνυμα που γράψατε στον Κάφκα, αλλά δεν ξέρετε τίποτα για τον τρόπο επεξεργασίας του.
Ως εκ τούτου, στην περίπτωσή μας, έπρεπε να εισαγάγουμε ένα συμβάν απόκρισης και να ρυθμίσουμε την παρακολούθηση έτσι ώστε αν αποστέλλονταν τόσα πολλά συμβάντα, μετά από τάδε ώρα θα πρέπει να φθάνει ο ίδιος αριθμός συμβάντων απόκρισης. Αν αυτό δεν συμβεί, τότε κάτι φαίνεται να έχει πάει στραβά. Για παράδειγμα, εάν στείλαμε το συμβάν "item_ready_to_refund", αναμένουμε ότι θα δημιουργηθεί μια επιστροφή χρημάτων, θα επιστραφούν τα χρήματα στον πελάτη και θα σταλεί σε εμάς το συμβάν "money_refunded". Αυτό όμως δεν είναι σίγουρο, επομένως χρειάζεται παρακολούθηση.
Νουάν
Υπάρχει ένα αρκετά προφανές πρόβλημα: εάν διαβάζετε από ένα θέμα διαδοχικά και έχετε κάποιο κακό μήνυμα, ο καταναλωτής θα πέσει και δεν θα προχωρήσετε περαιτέρω. Χρειάζεσαι σταματήσει όλους τους καταναλωτές, δεσμευτείτε περαιτέρω για να συνεχίσετε την ανάγνωση.
Το ξέραμε, το υπολογίζαμε και όμως συνέβη. Και αυτό συνέβη επειδή το συμβάν ήταν έγκυρο από την άποψη των συμβάντων-διαύλου, το συμβάν ήταν έγκυρο από την άποψη του προγράμματος επικύρωσης εφαρμογής, αλλά δεν ήταν έγκυρο από την άποψη του PostgreSQL, επειδή στο σύστημά μας MySQL με UNISIGNED INT το σύστημα είχε PostgreSQL μόνο με INT. Το μέγεθός του είναι λίγο μικρότερο και το Id δεν ταίριαζε. Η Συμφωνία πέθανε με εξαίρεση. Φυσικά, πιάσαμε την εξαίρεση επειδή στηριζόμασταν σε αυτήν και επρόκειτο να πραγματοποιήσουμε αυτήν τη μετατόπιση, αλλά πριν από αυτό θέλαμε να αυξήσουμε τον μετρητή προβλημάτων, καθώς η επεξεργασία του μηνύματος ήταν ανεπιτυχής. Οι μετρητές σε αυτό το έργο βρίσκονται επίσης στη βάση δεδομένων, και η Symfony έχει ήδη κλείσει την επικοινωνία με τη βάση δεδομένων και η δεύτερη εξαίρεση σκότωσε ολόκληρη τη διαδικασία χωρίς την ευκαιρία να πραγματοποιήσει μετατόπιση.
Η υπηρεσία ξάπλωσε για λίγο - ευτυχώς, με τον Κάφκα αυτό δεν είναι τόσο κακό, γιατί τα μηνύματα παραμένουν. Όταν αποκατασταθεί η εργασία, μπορείτε να ολοκληρώσετε την ανάγνωσή τους. Είναι άνετο.
Ο Κάφκα έχει τη δυνατότητα να ορίσει μια αυθαίρετη μετατόπιση μέσω εργαλείων. Αλλά για να το κάνετε αυτό, πρέπει να σταματήσετε όλους τους καταναλωτές - στην περίπτωσή μας, ετοιμάστε μια ξεχωριστή έκδοση στην οποία δεν θα υπάρχουν καταναλωτές, αναδιατάξεις. Στη συνέχεια, στον Κάφκα μπορείτε να αλλάξετε τη μετατόπιση μέσω εργαλείων και το μήνυμα θα περάσει.
Μια άλλη απόχρωση - αρχείο καταγραφής αναπαραγωγής εναντίον rdkafka.so - σχετίζεται με τις ιδιαιτερότητες του έργου μας. Χρησιμοποιούμε PHP και στην PHP, κατά κανόνα, όλες οι βιβλιοθήκες επικοινωνούν με τον Κάφκα μέσω του αποθετηρίου rdkafka.so και στη συνέχεια υπάρχει κάποιο είδος περιτυλίγματος. Ίσως αυτές να είναι οι προσωπικές μας δυσκολίες, αλλά αποδείχτηκε ότι το να ξαναδιαβάσουμε απλώς ένα κομμάτι από αυτά που είχαμε ήδη διαβάσει δεν είναι τόσο εύκολο. Γενικά, υπήρχαν προβλήματα λογισμικού.
Επιστρέφοντας στις ιδιαιτερότητες της εργασίας με κατατμήσεις, είναι γραμμένο ακριβώς στην τεκμηρίωση καταναλωτές >= κατατμήσεις θέματος. Αλλά το έμαθα πολύ αργότερα από όσο θα ήθελα. Εάν θέλετε να κλιμακώσετε και να έχετε δύο καταναλωτές, χρειάζεστε τουλάχιστον δύο κατατμήσεις. Δηλαδή, εάν είχατε ένα διαμέρισμα στο οποίο είχαν συγκεντρωθεί 20 χιλιάδες μηνύματα και κάνατε ένα νέο, ο αριθμός των μηνυμάτων δεν θα εξισωθεί σύντομα. Επομένως, για να έχετε δύο παράλληλους καταναλωτές, πρέπει να ασχοληθείτε με κατατμήσεις.
Παρακολούθηση
Πιστεύω ότι ο τρόπος με τον οποίο το παρακολουθούμε θα είναι ακόμη πιο ξεκάθαρο ποια προβλήματα υπάρχουν στην υπάρχουσα προσέγγιση.
Για παράδειγμα, υπολογίζουμε πόσα προϊόντα στη βάση δεδομένων άλλαξαν πρόσφατα την κατάστασή τους και, κατά συνέπεια, θα έπρεπε να έχουν συμβεί συμβάντα με βάση αυτές τις αλλαγές και στέλνουμε αυτόν τον αριθμό στο σύστημα παρακολούθησης. Μετά από τον Κάφκα παίρνουμε τον δεύτερο αριθμό, πόσα γεγονότα καταγράφηκαν στην πραγματικότητα. Προφανώς, η διαφορά μεταξύ αυτών των δύο αριθμών θα πρέπει πάντα να είναι μηδέν.
Επιπλέον, πρέπει να παρακολουθείτε πώς λειτουργεί ο παραγωγός, εάν τα συμβάντα-λεωφορεία έλαβαν μηνύματα και πώς είναι ο καταναλωτής. Για παράδειγμα, στα παρακάτω γραφήματα, το Εργαλείο επιστροφής χρημάτων λειτουργεί καλά, αλλά το BOB έχει σαφώς κάποια προβλήματα (μπλε κορυφές).
Ανέφερα ήδη την υστέρηση της ομάδας καταναλωτών. Σε γενικές γραμμές, αυτός είναι ο αριθμός των μη αναγνωσμένων μηνυμάτων. Γενικά, οι καταναλωτές μας δουλεύουν γρήγορα, επομένως η υστέρηση είναι συνήθως 0, αλλά μερικές φορές μπορεί να υπάρξει βραχυπρόθεσμη αιχμή. Ο Κάφκα μπορεί να το κάνει αυτό από το κουτί, αλλά πρέπει να ορίσετε ένα συγκεκριμένο διάστημα.
Υπάρχει ένα έργο που θα σας δώσει περισσότερες πληροφορίες για τον Κάφκα. Απλώς χρησιμοποιεί το API ομάδας καταναλωτών για να δώσει την κατάσταση της κατάστασης αυτής της ομάδας. Εκτός από το OK και το Failed, υπάρχει μια προειδοποίηση και μπορείτε να διαπιστώσετε ότι οι καταναλωτές σας δεν μπορούν να αντεπεξέλθουν στον ρυθμό παραγωγής - δεν έχουν χρόνο να διορθώσουν όσα γράφονται. Το σύστημα είναι αρκετά έξυπνο και εύκολο στη χρήση.
Αυτή είναι η απόκριση API. Εδώ είναι η ομάδα bob-live-fifa, partition refund.update.v1, κατάσταση ΟΚ, καθυστέρηση 0 - η τελευταία τελική μετατόπιση τέτοια και τέτοια.
Παρακολούθηση updated_at SLA (κολλημένο) Το ανέφερα ήδη. Για παράδειγμα, το προϊόν έχει αλλάξει στην κατάσταση ότι είναι έτοιμο για επιστροφή. Εγκαθιστούμε το Cron, το οποίο λέει ότι αν σε 5 λεπτά αυτό το αντικείμενο δεν έχει πάει για επιστροφή χρημάτων (επιστρέφουμε χρήματα μέσω συστημάτων πληρωμών πολύ γρήγορα), τότε σίγουρα κάτι πήγε στραβά και αυτό είναι σίγουρα μια περίπτωση υποστήριξης. Επομένως, παίρνουμε απλώς το Cron, το οποίο διαβάζει τέτοια πράγματα, και αν είναι μεγαλύτερα από 0, τότε στέλνει μια ειδοποίηση.
Συνοψίζοντας, η χρήση συμβάντων είναι βολική όταν:
- πληροφορίες απαιτούνται από πολλά συστήματα.
- το αποτέλεσμα της επεξεργασίας δεν είναι σημαντικό.
- υπάρχουν λίγα γεγονότα ή μικρά γεγονότα.
Φαίνεται ότι το άρθρο έχει ένα πολύ συγκεκριμένο θέμα - ασύγχρονο API στον Κάφκα, αλλά σε σχέση με αυτό θα ήθελα να προτείνω πολλά πράγματα ταυτόχρονα.
Πρώτο, επόμενο πρέπει να περιμένουμε μέχρι τον Νοέμβριο· τον Απρίλιο θα υπάρξει μια έκδοση της Αγίας Πετρούπολης και τον Ιούνιο θα μιλήσουμε για υψηλά φορτία στο Νοβοσιμπίρσκ.
Δεύτερον, ο συντάκτης της έκθεσης, Σεργκέι Ζάικα, είναι μέλος της Επιτροπής Προγράμματος του νέου μας συνεδρίου για τη διαχείριση γνώσης . Το συνέδριο είναι μονοήμερο, θα πραγματοποιηθεί στις 26 Απριλίου, αλλά το πρόγραμμά του είναι πολύ έντονο.
Και θα είναι τον Μάιο и (με το DevOpsConf που περιλαμβάνεται) - μπορείτε επίσης να προτείνετε το θέμα σας εκεί, να μιλήσετε για την εμπειρία σας και να παραπονεθείτε για τους γεμιστούς κώνους σας.
Πηγή: www.habr.com