Γεια σε όλους. Σε αυτό το άρθρο θα σας πω γιατί εμείς στην Avito επιλέξαμε τον Κάφκα πριν από εννέα μήνες και τι είναι. Θα μοιραστώ μια από τις περιπτώσεις χρήσης - έναν μεσίτη μηνυμάτων. Και τέλος, ας μιλήσουμε για τα πλεονεκτήματα που αποκομίσαμε από τη χρήση της προσέγγισης Kafka ως υπηρεσία.

πρόβλημα

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

Ένα από τα προβλήματα με έναν μεγάλο αριθμό υπηρεσιών είναι η επικοινωνία. Η Υπηρεσία Α θέλει συχνά να γνωρίζει πληροφορίες που έχει η Υπηρεσία Β Σε αυτήν την περίπτωση, η Υπηρεσία Α έχει πρόσβαση στην Υπηρεσία Β μέσω ενός σύγχρονου API. Η υπηρεσία Β θέλει να μάθει τι συμβαίνει με τις υπηρεσίες Δ και Δ και αυτές, με τη σειρά τους, ενδιαφέρονται για τις υπηρεσίες Α και Β. Όταν υπάρχουν πολλές τέτοιες «περίεργες» υπηρεσίες, οι συνδέσεις μεταξύ τους μετατρέπονται σε ένα μπερδεμένο κουβάρι.

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

Επιλογή τεχνολογίας

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

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

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

Ήταν επίσης εξαιρετικά σημαντικό για εμάς να επιλέξουμε το πιο επεκτάσιμο και αξιόπιστο σύστημα με υψηλή απόδοση (τουλάχιστον 100 χιλιάδες μηνύματα πολλών kilobyte ανά δευτερόλεπτο).

Σε αυτό το σημείο, αποχαιρετήσαμε το RabbitMQ (δύσκολο να κρατηθεί σταθερό σε υψηλές στροφές), το PGQ από το SkyTools (όχι αρκετά γρήγορο και δεν κλιμακώνεται καλά) και το NSQ (όχι επίμονο). Χρησιμοποιούμε όλες αυτές τις τεχνολογίες στην εταιρεία μας, αλλά δεν ήταν κατάλληλες για το πρόβλημα που επιλύθηκε.

Στη συνέχεια, αρχίσαμε να εξετάζουμε τεχνολογίες που ήταν νέες για εμάς - Apache Kafka, Apache Pulsar και NATS Streaming.

Το Pulsar ήταν το πρώτο που απορρίφθηκε. Αποφασίσαμε ότι το Kafka και το Pulsar είναι αρκετά παρόμοιες λύσεις. Και παρά το γεγονός ότι το Pulsar έχει δοκιμαστεί από μεγάλες εταιρείες, είναι νεότερο και προσφέρει χαμηλότερη καθυστέρηση (θεωρητικά), αποφασίσαμε να αφήσουμε το Kafka από αυτά τα δύο ως de facto πρότυπο για τέτοιες εργασίες. Μάλλον θα επιστρέψουμε στο Apache Pulsar στο μέλλον.

Και τώρα απομένουν δύο υποψήφιοι: το NATS Streaming και ο Apache Kafka. Μελετήσαμε και τις δύο λύσεις με κάποια λεπτομέρεια, και οι δύο ήταν κατάλληλες για την εργασία. Αλλά τελικά, φοβηθήκαμε τη σχετική νεολαία του NATS Streaming (και το γεγονός ότι ένας από τους κύριους προγραμματιστές, ο Tyler Treat, αποφάσισε να αφήσει το έργο και να ξεκινήσει το δικό του - Liftbridge). Ταυτόχρονα, η λειτουργία Clustering του NATS Streaming δεν παρείχε τη δυνατότητα ισχυρής οριζόντιας κλιμάκωσης (μάλλον αυτό δεν αποτελεί πλέον πρόβλημα μετά την προσθήκη της λειτουργίας κατάτμησης το 2017).

Ωστόσο, το NATS Streaming είναι μια δροσερή τεχνολογία γραμμένη στο Go και υποστηρίζεται από το Cloud Native Computing Foundation. Σε αντίθεση με τον Apache Kafka, δεν χρειάζεται Zookeeper για να λειτουργήσει (ίσως σύντομα το ίδιο μπορεί να ειπωθεί για τον Κάφκα), αφού εφαρμόζει εσωτερικά το RAFT. Ταυτόχρονα, το NATS Streaming είναι πιο εύκολο στη διαχείριση. Δεν αποκλείουμε να επιστρέψουμε σε αυτήν την τεχνολογία στο μέλλον.

Κι όμως, σήμερα ο νικητής μας είναι ο Απάτσι Κάφκα. Στις δοκιμές μας, αποδείχθηκε αρκετά γρήγορο (πάνω από ένα εκατομμύριο μηνύματα ανά δευτερόλεπτο για ανάγνωση και γραφή με όγκο μηνύματος 1 kilobyte), αρκετά αξιόπιστο, εξαιρετικά επεκτάσιμο και αποδεδειγμένο από την εμπειρία στην παραγωγή μεγάλων εταιρειών. Επιπλέον, ο Kafka υποστηρίζει τουλάχιστον αρκετές μεγάλες εμπορικές εταιρείες (εμείς, για παράδειγμα, χρησιμοποιούμε την έκδοση Confluent), και ο Kafka έχει επίσης ένα ανεπτυγμένο οικοσύστημα.

Επισκόπηση Κάφκα

Πριν ξεκινήσουμε, θα ήθελα να προτείνω αμέσως ένα εξαιρετικό βιβλίο - "Kafka: The Definitive Guide" (υπάρχει και ρωσική μετάφραση, αλλά οι όροι είναι λίγο μπερδεμένοι). Περιέχει τις πληροφορίες που χρειάζεστε για να αποκτήσετε μια βασική κατανόηση του Κάφκα και ακόμη λίγο περισσότερο. Η τεκμηρίωση του Apache και το ιστολόγιο του Confluent είναι επίσης καλογραμμένα και ευανάγνωστα.

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

Μεσίτης

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

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

την ποσότητα των δεδομένων που αποθηκεύονται ή/και την ηλικία τους (retention.bytes, retention.ms)·
παράγοντας πλεονασμού δεδομένων (συντελεστής αναπαραγωγής).
μέγιστο μέγεθος ενός μηνύματος (max.message.bytes).
ο ελάχιστος αριθμός συνεπών αντιγράφων στον οποίο μπορούν να εγγραφούν δεδομένα σε ένα θέμα (min.insync.replicas).
τη δυνατότητα πραγματοποίησης μιας ανακατεύθυνσης σε ένα μη σύγχρονο αντίγραφο με καθυστέρηση με πιθανή απώλεια δεδομένων (unclean.leader.election.enable).
και πολλά άλλα (https://kafka.apache.org/documentation/#topicconfigs).

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

Στο δίσκο, τα δεδομένα για κάθε διαμέρισμα αποθηκεύονται με τη μορφή αρχείων τμήματος, τα οποία από προεπιλογή είναι ίσα με ένα gigabyte (ελέγχονται μέσω log.segment.bytes). Ένα σημαντικό χαρακτηριστικό είναι ότι τα δεδομένα διαγράφονται από κατατμήσεις (όταν ενεργοποιείται η διατήρηση) σε τμήματα (δεν μπορείτε να διαγράψετε ένα συμβάν από ένα διαμέρισμα, μπορείτε να διαγράψετε μόνο ένα ολόκληρο τμήμα και μόνο το ανενεργό).

Ζωοφύλακας

Το Zookeeper λειτουργεί ως αποθήκευση μεταδεδομένων και συντονιστής. Είναι αυτός που μπορεί να πει εάν οι μεσίτες είναι ζωντανοί (μπορείτε να το δείτε μέσα από τα μάτια του zookeeper χρησιμοποιώντας το zookeeper-shell με την εντολή ls /brokers/ids), ποιος μεσίτης είναι ο ελεγκτής (get /controller), εάν τα διαμερίσματα είναι σε συγχρονισμό με τα αντίγραφά τους (get /brokers/topics/topic_name/partitions/partition_number/state). Επίσης, ο παραγωγός και ο καταναλωτής θα πάνε πρώτα στον φύλακα του ζωολογικού κήπου για να μάθουν σε ποιο χρηματιστή ποια θέματα και διαμερίσματα αποθηκεύονται. Σε περιπτώσεις όπου καθορίζεται συντελεστής αναπαραγωγής μεγαλύτερος από 1 για ένα θέμα, ο φύλακας του ζωολογικού κήπου θα υποδείξει ποιες κατατμήσεις είναι οι κορυφαίες (θα γραφτούν και θα διαβαστούν). Σε περίπτωση αποτυχίας του μεσίτη, οι πληροφορίες σχετικά με τα νέα διαμερίσματα leader θα καταγράφονται στο zookeeper (από την έκδοση 1.1.0 ασύγχρονα, και αυτό είναι σημαντικό).

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

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

Παραγωγός

Ο παραγωγός είναι συνήθως μια υπηρεσία που γράφει απευθείας δεδομένα στον Apache Kafka. Ο Παραγωγός επιλέγει ένα θέμα στο οποίο θα αποθηκεύσει τα θεματικά του μηνύματα και αρχίζει να γράφει πληροφορίες σε αυτό. Για παράδειγμα, ο παραγωγός θα μπορούσε να είναι μια διαφημιστική υπηρεσία. Σε αυτήν την περίπτωση, θα στείλει συμβάντα όπως "δημιουργήθηκε διαφήμιση", "ενημερώθηκε η διαφήμιση", "διαγράφηκε η διαφήμιση" κ.λπ. σε θεματικά θέματα. Κάθε συμβάν είναι ένα ζεύγος κλειδιού-τιμής.

Από προεπιλογή, όλα τα συμβάντα κατανέμονται μεταξύ των διαμερισμάτων θέματος χρησιμοποιώντας το round-robin, εάν το κλειδί δεν έχει καθοριστεί (χάνεται η παραγγελία) και μέσω του MurmurHash (κλειδί) εάν το κλειδί υπάρχει (παραγγελία σε ένα διαμέρισμα).

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

Καταναλωτής

Ο καταναλωτής είναι υπεύθυνος για την ανάκτηση δεδομένων από τον Apache Kafka. Αν επιστρέψουμε στο παραπάνω παράδειγμα, ο καταναλωτής θα μπορούσε να είναι μια υπηρεσία μετριοπάθειας. Αυτή η υπηρεσία θα εγγραφεί στο θέμα της υπηρεσίας διαφημίσεων και, όταν εμφανιστεί μια νέα διαφήμιση, θα τη λάβει και θα την αναλύσει για συμμόρφωση με ορισμένες καθορισμένες πολιτικές.

Ο Apache Kafka θυμάται τα πρόσφατα γεγονότα που έλαβε ο καταναλωτής (ένα θέμα υπηρεσίας χρησιμοποιείται για αυτό __consumer__offsets), διασφαλίζοντας έτσι ότι εάν η ανάγνωση είναι επιτυχής, ο καταναλωτής δεν λαμβάνει το ίδιο μήνυμα δύο φορές. Ωστόσο, εάν χρησιμοποιήσετε την επιλογή enable.auto.commit = true και αναθέσετε πλήρως την εργασία παρακολούθησης της θέσης του καταναλωτή στο θέμα στον Κάφκα, μπορείτε χάνουν δεδομένα. Στον κώδικα παραγωγής, τις περισσότερες φορές η θέση του καταναλωτή ελέγχεται χειροκίνητα (ο προγραμματιστής ελέγχει τη στιγμή που πρέπει να πραγματοποιηθεί η δέσμευση του συμβάντος ανάγνωσης).

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

Αποτελέσματα δοκιμών

Δεν θα γράψω πολλά επεξηγηματικά κείμενα εδώ, απλώς θα μοιραστώ τα αποτελέσματα που προέκυψαν. Οι δοκιμές πραγματοποιήθηκαν σε 3 φυσικές μηχανές (12 CPU, 384 GB RAM, 15k SAS DISK, 10 GBit/s Net), μεσίτες και zookeeper χρησιμοποιήθηκαν στο lxc.

Δοκιμή απόδοσης

Κατά τη διάρκεια της δοκιμής, ελήφθησαν τα ακόλουθα αποτελέσματα.

Η ταχύτητα εγγραφής μηνυμάτων 1KB ταυτόχρονα από 9 παραγωγούς είναι 1300000 συμβάντα ανά δευτερόλεπτο.
Η ταχύτητα ανάγνωσης μηνυμάτων 1KB ταυτόχρονα από 9 καταναλωτές είναι 1500000 συμβάντα ανά δευτερόλεπτο.

Δοκιμή ανοχής σφαλμάτων

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

Ο μη φυσιολογικός τερματισμός ενός από τους μεσίτες δεν προκαλεί διακοπή ή μη διαθεσιμότητα του συμπλέγματος. Οι εργασίες συνεχίζονται κανονικά, αλλά οι υπόλοιποι μεσίτες έχουν μεγάλο φόρτο εργασίας.
Ο μη φυσιολογικός τερματισμός δύο μεσιτών στην περίπτωση ενός συμπλέγματος τριών μεσιτών και min.isr = 2 οδηγεί στο ότι το σύμπλεγμα δεν είναι διαθέσιμο για εγγραφή, αλλά προσβάσιμο για ανάγνωση. Εάν min.isr = 1, το σύμπλεγμα συνεχίζει να είναι διαθέσιμο τόσο για ανάγνωση όσο και για γραφή. Ωστόσο, αυτή η λειτουργία έρχεται σε αντίθεση με την απαίτηση για υψηλή ασφάλεια δεδομένων.
Ο μη φυσιολογικός τερματισμός ενός από τους διακομιστές Zookeeper δεν προκαλεί διακοπή ή μη διαθεσιμότητα του συμπλέγματος. Οι εργασίες συνεχίζονται κανονικά.
Ένας μη φυσιολογικός τερματισμός λειτουργίας δύο διακομιστών Zookeeper έχει ως αποτέλεσμα το σύμπλεγμα να μην είναι διαθέσιμο έως ότου αποκατασταθεί τουλάχιστον ένας από τους διακομιστές Zookeeper. Αυτή η δήλωση ισχύει για ένα σύμπλεγμα Zookeeper 3 διακομιστών. Ως αποτέλεσμα, μετά από έρευνα, αποφασίστηκε να αυξηθεί το σύμπλεγμα Zookeeper σε 5 διακομιστές για να αυξηθεί η ανοχή σφαλμάτων.

Ο Κάφκα ως υπηρεσία

Είμαστε πεπεισμένοι ότι το Kafka είναι μια εξαιρετική τεχνολογία που μας επιτρέπει να λύσουμε την εργασία που μας έχει ανατεθεί (εφαρμογή ενός μεσίτη μηνυμάτων). Ωστόσο, αποφασίσαμε να απαγορεύσουμε στις υπηρεσίες να έχουν απευθείας πρόσβαση στον Κάφκα και το κλείσαμε από πάνω με μια υπηρεσία διαύλου δεδομένων. Γιατί το κάναμε αυτό; Στην πραγματικότητα, υπάρχουν αρκετοί λόγοι.

Το Data-bus ανέλαβε όλα τα καθήκοντα που σχετίζονται με την ενοποίηση με τον Kafka (υλοποίηση και διαμόρφωση καταναλωτών και παραγωγών, παρακολούθηση, ειδοποίηση, καταγραφή, κλιμάκωση κ.λπ.). Έτσι, η ενσωμάτωση με τον μεσίτη μηνυμάτων είναι όσο το δυνατόν πιο απλή.
Το Data-bus μας επέτρεψε να αφαιρέσουμε την αφαίρεση από μια συγκεκριμένη γλώσσα ή βιβλιοθήκη για να εργαστούμε με τον Κάφκα.
Ο δίαυλος δεδομένων επέτρεψε σε άλλες υπηρεσίες να αφαιρέσουν το επίπεδο αποθήκευσης. Ίσως κάποια στιγμή αλλάξουμε τον Kafka σε Pulsar και κανείς δεν θα παρατηρήσει τίποτα (όλες οι υπηρεσίες γνωρίζουν μόνο για το API του διαύλου δεδομένων).
Το Data-bus ανέλαβε την επικύρωση των σχημάτων συμβάντων.
Ο έλεγχος ταυτότητας υλοποιείται με χρήση διαύλου δεδομένων.
Κάτω από την κάλυψη του διαύλου δεδομένων, μπορούμε να ενημερώσουμε αθόρυβα τις εκδόσεις του Kafka χωρίς χρόνο διακοπής λειτουργίας, να διαχειριστούμε κεντρικά τις διαμορφώσεις παραγωγών, καταναλωτών, μεσιτών κ.λπ.
Το Data-bus μας επέτρεψε να προσθέσουμε τα χαρακτηριστικά που χρειαζόμασταν που δεν υπάρχουν στον Κάφκα (όπως έλεγχος θεμάτων, παρακολούθηση ανωμαλιών στο σύμπλεγμα, δημιουργία DLQ κ.λπ.).
Το Data-bus σάς επιτρέπει να εφαρμόζετε κεντρικά το failover για όλες τις υπηρεσίες.

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

Φυσικά, δεν υπάρχει ασημένια σφαίρα, και αυτή η προσέγγιση έχει τους περιορισμούς της.

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

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

Υ.Γ. Ευχαριστώ τη φίλη μου, Ekaterina Obalyaeva, για τις υπέροχες φωτογραφίες αυτού του άρθρου. Αν σου άρεσαν, εδώ έρχονται κι άλλες εικονογραφήσεις.

Πηγή: www.habr.com