[Μετάφραση] Μοντέλο κλωστής απεσταλμένου

Μετάφραση του άρθρου: Μοντέλο νήματος Envoy - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Βρήκα αυτό το άρθρο αρκετά ενδιαφέρον και δεδομένου ότι ο Envoy χρησιμοποιείται συχνότερα ως μέρος του "istio" ή απλώς ως "ελεγκτής εισόδου" των kubernetes, οι περισσότεροι άνθρωποι δεν έχουν την ίδια άμεση αλληλεπίδραση μαζί του όπως, για παράδειγμα, με τυπικά Εγκαταστάσεις Nginx ή Haproxy. Ωστόσο, αν κάτι σπάσει, καλό θα ήταν να καταλάβουμε πώς λειτουργεί από μέσα. Προσπάθησα να μεταφράσω όσο το δυνατόν μεγαλύτερο μέρος του κειμένου στα ρωσικά, συμπεριλαμβανομένων ειδικών λέξεων· για όσους το βρίσκουν οδυνηρό να το δουν, άφησα τα πρωτότυπα σε παρένθεση. Καλώς ήρθατε στο cat.

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

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

Επισκόπηση νημάτων

[Μετάφραση] Μοντέλο κλωστής απεσταλμένου

Ο Envoy χρησιμοποιεί τρεις διαφορετικούς τύπους ροών:

  • Κύριος: Αυτό το νήμα ελέγχει την εκκίνηση και τον τερματισμό της διαδικασίας, όλη την επεξεργασία του API XDS (xDiscovery Service), συμπεριλαμβανομένου του DNS, του ελέγχου υγείας, της γενικής διαχείρισης συμπλέγματος και χρόνου εκτέλεσης, επαναφοράς στατιστικών στοιχείων, διαχείρισης και γενικής διαχείρισης διεργασιών - σήματα Linux. hot επανεκκίνηση κ.λπ. συμβαίνει σε αυτό το νήμα είναι ασύγχρονο και "non-blocking". Γενικά, το κύριο νήμα συντονίζει όλες τις κρίσιμες διαδικασίες λειτουργικότητας που δεν απαιτούν μεγάλη ποσότητα CPU για να τρέξουν. Αυτό επιτρέπει στους περισσότερους κωδικούς ελέγχου να γράφονται σαν να ήταν μονού νήματος.
  • Εργάτης: Από προεπιλογή, το Envoy δημιουργεί ένα νήμα εργασίας για κάθε νήμα υλικού στο σύστημα, αυτό μπορεί να ελεγχθεί χρησιμοποιώντας την επιλογή --concurrency. Κάθε νήμα εργαζόμενου εκτελεί έναν βρόχο συμβάντων «μη αποκλεισμού», ο οποίος είναι υπεύθυνος για την ακρόαση κάθε ακροατή· κατά τη στιγμή της σύνταξης (29 Ιουλίου 2017) δεν υπάρχει κοινή χρήση του ακροατή, αποδοχή νέων συνδέσεων, δημιουργία στοίβας φίλτρων για τη σύνδεση και την επεξεργασία όλων των λειτουργιών εισόδου/εξόδου (IO) κατά τη διάρκεια ζωής της σύνδεσης. Και πάλι, αυτό επιτρέπει στους περισσότερους κωδικούς διαχείρισης σύνδεσης να γράφονται σαν να ήταν μονού νήματος.
  • Πλύσιμο αρχείων: Κάθε αρχείο που γράφει ο Envoy, κυρίως αρχεία καταγραφής πρόσβασης, έχει επί του παρόντος ένα ανεξάρτητο νήμα αποκλεισμού. Αυτό οφείλεται στο γεγονός ότι η εγγραφή σε αρχεία που αποθηκεύονται στην προσωρινή μνήμη από το σύστημα αρχείων ακόμη και κατά τη χρήση O_NONBLOCK μπορεί μερικές φορές να μπλοκαριστεί (αναστεναγμός). Όταν τα νήματα εργαζομένων πρέπει να γράψουν σε ένα αρχείο, τα δεδομένα στην πραγματικότητα μετακινούνται σε ένα buffer στη μνήμη όπου τελικά ξεπλένονται μέσω του νήματος ξεπλύνετε το αρχείο. Αυτή είναι μια περιοχή κώδικα όπου τεχνικά όλα τα νήματα εργασίας μπορούν να μπλοκάρουν το ίδιο κλείδωμα ενώ προσπαθούν να γεμίσουν ένα buffer μνήμης.

Χειρισμός σύνδεσης

Όπως συζητήθηκε εν συντομία παραπάνω, όλα τα νήματα των εργαζομένων ακούν όλους τους ακροατές χωρίς κανένα διαμοιρασμό. Έτσι, ο πυρήνας χρησιμοποιείται για να στέλνει με χάρη αποδεκτές υποδοχές σε νήματα εργασίας. Οι σύγχρονοι πυρήνες είναι γενικά πολύ καλοί σε αυτό, χρησιμοποιούν λειτουργίες όπως η ενίσχυση προτεραιότητας εισόδου/εξόδου (IO) για να προσπαθήσουν να γεμίσουν ένα νήμα με δουλειά προτού αρχίσουν να χρησιμοποιούν άλλα νήματα που επίσης ακούν στην ίδια υποδοχή, και επίσης δεν χρησιμοποιούν round robin κλείδωμα (Spinlock) για την επεξεργασία κάθε αιτήματος.
Μόλις γίνει αποδεκτή μια σύνδεση σε ένα νήμα εργάτη, δεν φεύγει ποτέ από αυτό το νήμα. Όλη η περαιτέρω επεξεργασία της σύνδεσης γίνεται εξ ολοκλήρου στο νήμα εργασίας, συμπεριλαμβανομένης οποιασδήποτε συμπεριφοράς προώθησης.

Αυτό έχει πολλές σημαντικές συνέπειες:

  • Όλες οι ομάδες σύνδεσης στο Envoy εκχωρούνται σε ένα νήμα εργάτη. Έτσι, παρόλο που οι ομάδες σύνδεσης HTTP/2 κάνουν μόνο μία σύνδεση σε κάθε κεντρικό υπολογιστή ανάντη τη φορά, εάν υπάρχουν τέσσερα νήματα εργασίας, θα υπάρχουν τέσσερις συνδέσεις HTTP/2 ανά κεντρικό υπολογιστή ανάντη σε σταθερή κατάσταση.
  • Ο λόγος που ο Envoy λειτουργεί με αυτόν τον τρόπο είναι ότι διατηρώντας τα πάντα σε ένα νήμα εργασίας, σχεδόν όλος ο κώδικας μπορεί να γραφτεί χωρίς αποκλεισμό και σαν να ήταν με ένα νήμα. Αυτός ο σχεδιασμός διευκολύνει τη σύνταξη πολλών κώδικα και κλιμακώνεται απίστευτα καλά σε σχεδόν απεριόριστο αριθμό νημάτων εργασίας.
  • Ωστόσο, ένα από τα κύρια σημεία είναι ότι από την άποψη του χώρου αποθήκευσης μνήμης και της αποδοτικότητας σύνδεσης, είναι πραγματικά πολύ σημαντικό να διαμορφώσετε το --concurrency. Η ύπαρξη περισσότερων νημάτων εργασίας από ό,τι χρειάζεται θα σπαταλήσει τη μνήμη, θα δημιουργήσει περισσότερες συνδέσεις σε αδράνεια και θα μειώσει τον ρυθμό συγκέντρωσης των συνδέσεων. Στη Lyft, τα εμπορευματοκιβώτια του πλευρικού καρέ του απεσταλμένου μας λειτουργούν με πολύ χαμηλή ταυτόχρονη λειτουργία, έτσι ώστε η απόδοση να ταιριάζει κατά προσέγγιση με τις υπηρεσίες στις οποίες κάθονται δίπλα. Εκτελούμε το Envoy ως διακομιστή μεσολάβησης άκρων μόνο στη μέγιστη ταυτόχρονη χρήση.

Τι σημαίνει μη μπλοκάρισμα;

Ο όρος "non-blocking" έχει χρησιμοποιηθεί αρκετές φορές μέχρι στιγμής όταν συζητάμε πώς λειτουργούν το κύριο και το νήμα εργασίας. Όλος ο κώδικας γράφεται με την παραδοχή ότι τίποτα δεν έχει ποτέ αποκλειστεί. Ωστόσο, αυτό δεν είναι απολύτως αληθές (τι δεν είναι απολύτως αλήθεια;).

Ο Envoy χρησιμοποιεί πολλές μακριές κλειδαριές διεργασιών:

  • Όπως συζητήθηκε, κατά την εγγραφή αρχείων καταγραφής πρόσβασης, όλα τα νήματα εργασίας αποκτούν το ίδιο κλείδωμα πριν γεμίσει το buffer καταγραφής στη μνήμη. Ο χρόνος συγκράτησης της κλειδαριάς πρέπει να είναι πολύ χαμηλός, αλλά είναι δυνατό η κλειδαριά να αμφισβητηθεί σε υψηλή ταυτόχρονη και υψηλή απόδοση.
  • Ο Envoy χρησιμοποιεί ένα πολύ περίπλοκο σύστημα για τον χειρισμό στατιστικών που είναι τοπικά στο νήμα. Αυτό θα είναι το θέμα μιας ξεχωριστής ανάρτησης. Ωστόσο, θα αναφέρω εν συντομία ότι ως μέρος της επεξεργασίας στατιστικών νημάτων τοπικά, μερικές φορές είναι απαραίτητο να αποκτήσετε κλειδαριά σε ένα κεντρικό "κατάστημα στατιστικών". Αυτό το κλείδωμα δεν πρέπει ποτέ να απαιτείται.
  • Το κύριο νήμα πρέπει περιοδικά να συντονίζεται με όλα τα νήματα εργασίας. Αυτό γίνεται με τη "δημοσίευση" από το κύριο νήμα στα νήματα εργασίας και μερικές φορές από τα νήματα εργαζομένων πίσω στο κύριο νήμα. Η αποστολή απαιτεί κλείδωμα, ώστε το δημοσιευμένο μήνυμα να μπορεί να μπει στην ουρά για μεταγενέστερη παράδοση. Αυτές οι κλειδαριές δεν πρέπει ποτέ να αμφισβητούνται σοβαρά, αλλά μπορούν να μπλοκαριστούν τεχνικά.
  • Όταν ο Envoy γράφει ένα αρχείο καταγραφής στη ροή σφαλμάτων του συστήματος (τυπικό σφάλμα), αποκτά ένα κλείδωμα σε ολόκληρη τη διαδικασία. Γενικά, η τοπική καταγραφή του Envoy θεωρείται τρομερή από άποψη απόδοσης, επομένως δεν έχει δοθεί ιδιαίτερη προσοχή στη βελτίωσή της.
  • Υπάρχουν μερικές άλλες τυχαίες κλειδαριές, αλλά κανένα από αυτά δεν είναι κρίσιμο για την απόδοση και δεν πρέπει ποτέ να αμφισβητηθεί.

Τοπική αποθήκευση νημάτων

Λόγω του τρόπου με τον οποίο ο Envoy διαχωρίζει τις ευθύνες του κύριου νήματος από τις ευθύνες του νήματος εργασίας, υπάρχει η απαίτηση να μπορεί να γίνει σύνθετη επεξεργασία στο κύριο νήμα και στη συνέχεια να παρέχεται σε κάθε νήμα εργαζομένου με εξαιρετικά ταυτόχρονο τρόπο. Αυτή η ενότητα περιγράφει το Envoy Thread Local Storage (TLS) σε υψηλό επίπεδο. Στην επόμενη ενότητα θα περιγράψω πώς χρησιμοποιείται για τη διαχείριση ενός cluster.
[Μετάφραση] Μοντέλο κλωστής απεσταλμένου

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

Το σύστημα TLS (Thread local storage) του Envoy λειτουργεί ως εξής:

  • Ο κώδικας που εκτελείται στο κύριο νήμα μπορεί να εκχωρήσει μια υποδοχή TLS για ολόκληρη τη διαδικασία. Αν και αυτό είναι αφηρημένο, στην πράξη είναι ένας δείκτης σε ένα διάνυσμα, παρέχοντας πρόσβαση O(1).
  • Το κύριο νήμα μπορεί να εγκαταστήσει αυθαίρετα δεδομένα στην υποδοχή του. Όταν γίνει αυτό, τα δεδομένα δημοσιεύονται σε κάθε νήμα εργαζόμενου ως ένα κανονικό συμβάν βρόχου συμβάντος.
  • Τα νήματα εργασίας μπορούν να διαβάσουν από την υποδοχή TLS τους και να ανακτήσουν τυχόν τοπικά δεδομένα νημάτων που είναι διαθέσιμα εκεί.

Αν και είναι ένα πολύ απλό και απίστευτα ισχυρό παράδειγμα, μοιάζει πολύ με την έννοια του αποκλεισμού RCU (Read-Copy-Update). Ουσιαστικά, τα νήματα εργασίας δεν βλέπουν ποτέ αλλαγές δεδομένων στις υποδοχές TLS ενώ εκτελείται η εργασία. Η αλλαγή συμβαίνει μόνο κατά τη διάρκεια της περιόδου ανάπαυσης μεταξύ εργασιακών γεγονότων.

Ο Envoy το χρησιμοποιεί αυτό με δύο διαφορετικούς τρόπους:

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

Νήματα ενημέρωσης συμπλέγματος

Σε αυτήν την ενότητα, θα περιγράψω πώς χρησιμοποιείται το TLS (τοπικός χώρος αποθήκευσης νημάτων) για τη διαχείριση ενός συμπλέγματος. Η διαχείριση συμπλέγματος περιλαμβάνει επεξεργασία xDS API ή/και DNS, καθώς και έλεγχο υγείας.
[Μετάφραση] Μοντέλο κλωστής απεσταλμένου

Η διαχείριση ροής συμπλέγματος περιλαμβάνει τα ακόλουθα στοιχεία και βήματα:

  1. Το Cluster Manager είναι ένα στοιχείο εντός του Envoy που διαχειρίζεται όλα τα γνωστά upstream συμπλέγματος, το API της Υπηρεσίας Ανακάλυψης συμπλέγματος (CDS), τα API της Μυστικής Υπηρεσίας Ανακάλυψης (SDS) και της Υπηρεσίας Εντοπισμού Τελικού σημείου (EDS), DNS και ενεργούς εξωτερικούς ελέγχους. έλεγχος υγείας. Είναι υπεύθυνο για τη δημιουργία μιας «τελικά συνεπούς» άποψης για κάθε σύμπλεγμα ανάντη, το οποίο περιλαμβάνει ξενιστές που ανακαλύφθηκαν καθώς και την κατάσταση της υγείας.
  2. Ο ελεγκτής υγείας εκτελεί ενεργό έλεγχο υγείας και αναφέρει αλλαγές κατάστασης υγείας στον διαχειριστή συμπλέγματος.
  3. Εκτελούνται CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS για τον προσδιορισμό της ιδιότητας μέλους σε σύμπλεγμα. Η αλλαγή κατάστασης επιστρέφεται στον διαχειριστή συμπλέγματος.
  4. Κάθε νήμα εργαζόμενου εκτελεί συνεχώς έναν βρόχο συμβάντος.
  5. Όταν ο διαχειριστής συμπλέγματος καθορίζει ότι η κατάσταση για ένα σύμπλεγμα έχει αλλάξει, δημιουργεί ένα νέο στιγμιότυπο μόνο για ανάγνωση της κατάστασης του συμπλέγματος και το στέλνει σε κάθε νήμα εργασίας.
  6. Κατά την επόμενη ήσυχη περίοδο, το νήμα εργασίας θα ενημερώσει το στιγμιότυπο στην εκχωρημένη υποδοχή TLS.
  7. Κατά τη διάρκεια ενός συμβάντος I/O που υποτίθεται ότι καθορίζει το υπόλοιπο του κεντρικού υπολογιστή προς φόρτωση, ο εξισορροπητής φορτίου θα ζητήσει μια υποδοχή TLS (Thread local storage) για να λάβει πληροφορίες σχετικά με τον κεντρικό υπολογιστή. Αυτό δεν απαιτεί κλειδαριές. Σημειώστε επίσης ότι το TLS μπορεί επίσης να ενεργοποιήσει συμβάντα ενημέρωσης, έτσι ώστε οι εξισορροπητές φορτίου και άλλα στοιχεία να μπορούν να υπολογίσουν εκ νέου τις κρυφές μνήμες, τις δομές δεδομένων κ.λπ. Αυτό ξεφεύγει από το πεδίο εφαρμογής αυτής της ανάρτησης, αλλά χρησιμοποιείται σε διάφορα σημεία του κώδικα.

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

Άλλα υποσυστήματα που κάνουν χρήση του TLS

Το TLS (Thread local storage) και το RCU (Read Copy Update) χρησιμοποιούνται ευρέως στο Envoy.

Παραδείγματα χρήσης:

  • Μηχανισμός αλλαγής λειτουργικότητας κατά την εκτέλεση: Η τρέχουσα λίστα με τις ενεργοποιημένες λειτουργίες υπολογίζεται στο κύριο νήμα. Σε κάθε νήμα εργαζόμενου δίνεται στη συνέχεια ένα στιγμιότυπο μόνο για ανάγνωση χρησιμοποιώντας τη σημασιολογία RCU.
  • Αντικατάσταση πινάκων διαδρομής: Για πίνακες διαδρομών που παρέχονται από το RDS (Route Discovery Service), οι πίνακες διαδρομών δημιουργούνται στο κύριο νήμα. Το στιγμιότυπο μόνο για ανάγνωση θα παρέχεται στη συνέχεια σε κάθε νήμα εργαζόμενου χρησιμοποιώντας σημασιολογία RCU (Read Copy Update). Αυτό καθιστά την αλλαγή των πινάκων διαδρομών ατομικά αποτελεσματική.
  • Προσωρινή αποθήκευση κεφαλίδας HTTP: Όπως αποδεικνύεται, ο υπολογισμός της κεφαλίδας HTTP για κάθε αίτημα (ενώ εκτελούνται ~25K+ RPS ανά πυρήνα) είναι αρκετά ακριβός. Ο Envoy υπολογίζει κεντρικά την κεφαλίδα περίπου κάθε μισό δευτερόλεπτο και την παρέχει σε κάθε εργαζόμενο μέσω TLS και RCU.

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

Γνωστές παγίδες απόδοσης

Ενώ το Envoy αποδίδει αρκετά καλά συνολικά, υπάρχουν μερικές αξιοσημείωτες περιοχές που απαιτούν προσοχή όταν χρησιμοποιείται με πολύ υψηλή ταυτόχρονη απόδοση και απόδοση:

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

συμπέρασμα

Το μοντέλο threading του Envoy έχει σχεδιαστεί για να παρέχει ευκολία στον προγραμματισμό και τεράστιο παραλληλισμό σε βάρος της δυνητικά σπατάλης μνήμης και συνδέσεων, εάν δεν ρυθμιστούν σωστά. Αυτό το μοντέλο του επιτρέπει να αποδίδει πολύ καλά σε πολύ υψηλούς αριθμούς νημάτων και απόδοση.
Όπως ανέφερα εν συντομία στο Twitter, η σχεδίαση μπορεί επίσης να εκτελεστεί πάνω από μια στοίβα δικτύωσης πλήρους λειτουργίας χρήστη, όπως το DPDK (Data Plane Development Kit), που μπορεί να οδηγήσει σε συμβατικούς διακομιστές που χειρίζονται εκατομμύρια αιτήματα ανά δευτερόλεπτο με πλήρη επεξεργασία L7. Θα είναι πολύ ενδιαφέρον να δούμε τι θα κατασκευαστεί τα επόμενα χρόνια.
Ένα τελευταίο γρήγορο σχόλιο: Με έχουν ρωτήσει πολλές φορές γιατί επιλέξαμε την C++ για Envoy. Ο λόγος παραμένει ότι εξακολουθεί να είναι η μόνη ευρέως χρησιμοποιούμενη γλώσσα βιομηχανικής ποιότητας στην οποία μπορεί να κατασκευαστεί η αρχιτεκτονική που περιγράφεται σε αυτήν την ανάρτηση. Η C++ σίγουρα δεν είναι κατάλληλη για όλα ή ακόμα και για πολλά έργα, αλλά για ορισμένες περιπτώσεις χρήσης εξακολουθεί να είναι το μόνο εργαλείο για να ολοκληρώσετε τη δουλειά.

Σύνδεσμοι στον κώδικα

Σύνδεσμοι σε αρχεία με διεπαφές και υλοποιήσεις κεφαλίδων που συζητούνται σε αυτήν την ανάρτηση:

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο