Γεια σου Χαμπρ! Σας παρουσιάζω τη μετάφραση του άρθρου "Επίπεδο δεδομένων πλέγματος εξυπηρέτησης έναντι επιπέδου ελέγχου" ο συγγραφέας Ματ Κλέιν.

Αυτή τη φορά, «ήθελα και μετέφρασα» την περιγραφή και των δύο εξαρτημάτων πλέγματος υπηρεσιών, του επιπέδου δεδομένων και του επιπέδου ελέγχου. Αυτή η περιγραφή μου φάνηκε η πιο κατανοητή και ενδιαφέρουσα, και το πιο σημαντικό οδήγησε στην κατανόηση του "Είναι καθόλου απαραίτητο;"

Καθώς η ιδέα του "Service mesh" έχει γίνει ολοένα και πιο δημοφιλής τα τελευταία δύο χρόνια (Αρχικό άρθρο 10 Οκτωβρίου 2017) και ο αριθμός των συμμετεχόντων στο χώρο έχει αυξηθεί, έχω δει μια ανάλογη αύξηση της σύγχυσης μεταξύ όλων τεχνολογική κοινότητα σχετικά με τον τρόπο σύγκρισης και αντίθεσης διαφορετικών λύσεων.

Η κατάσταση συνοψίζεται καλύτερα από την ακόλουθη σειρά tweets που έγραψα τον Ιούλιο:

Σύγχυση πλέγματος υπηρεσιών #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Απεσταλμένος. Κανένας τους δεν ισοδυναμεί με το Ιστιο. Το Ίστιο είναι κάτι εντελώς διαφορετικό. 1 /

Τα πρώτα είναι απλά επίπεδα δεδομένων. Από μόνοι τους δεν κάνουν τίποτα. Πρέπει να έχουν διάθεση για κάτι παραπάνω. 2/

Το Istio είναι ένα παράδειγμα ενός επιπέδου ελέγχου που ενώνει τα μέρη μεταξύ τους. Αυτό είναι ένα άλλο στρώμα. /τέλος

Τα προηγούμενα tweets αναφέρουν πολλά διαφορετικά έργα (Linkerd, NGINX, HAProxy, Envoy και Istio), αλλά το πιο σημαντικό εισάγουν τις γενικές έννοιες του επιπέδου δεδομένων, του πλέγματος υπηρεσιών και του επιπέδου ελέγχου. Σε αυτήν την ανάρτηση, θα κάνω ένα βήμα πίσω και θα μιλήσω για το τι εννοώ με τους όρους "επίπεδο δεδομένων" και "επίπεδο ελέγχου" σε πολύ υψηλό επίπεδο και, στη συνέχεια, θα μιλήσω για το πώς ισχύουν οι όροι για τα έργα που αναφέρονται στα tweets.

Τι είναι ένα πλέγμα εξυπηρέτησης, αλήθεια;

Εικόνα 1: Επισκόπηση πλέγματος σέρβις

Σχήμα 1 απεικονίζει την έννοια του πλέγματος υπηρεσιών στο πιο βασικό του επίπεδο. Υπάρχουν τέσσερις ομάδες υπηρεσιών (AD). Κάθε παρουσία υπηρεσίας σχετίζεται με έναν τοπικό διακομιστή μεσολάβησης. Όλη η κίνηση δικτύου (HTTP, REST, gRPC, Redis, κ.λπ.) από μία μόνο παρουσία εφαρμογής μεταβιβάζεται μέσω ενός τοπικού διακομιστή μεσολάβησης στα κατάλληλα συμπλέγματα εξωτερικών υπηρεσιών. Με αυτόν τον τρόπο, η παρουσία της εφαρμογής δεν γνωρίζει το δίκτυο ως σύνολο και γνωρίζει μόνο τον τοπικό διακομιστή μεσολάβησής του. Στην πραγματικότητα, το δίκτυο κατανεμημένου συστήματος αφαιρέθηκε από την υπηρεσία.

Επίπεδο δεδομένων

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

• Ανακάλυψη υπηρεσίας. Ποιες υπηρεσίες/εφαρμογές είναι διαθέσιμες για την αίτησή σας;
• Έλεγχος υγείας. Είναι οι παρουσίες υπηρεσίας που επιστρέφονται από την ανακάλυψη υπηρεσίας υγιείς και έτοιμες να δεχτούν κίνηση δικτύου; Αυτό μπορεί να περιλαμβάνει ενεργητικούς (π.χ. απόκριση/έλεγχος υγείας) και παθητικούς (π.χ. χρήση 3 διαδοχικών σφαλμάτων 5xx ως ένδειξη μιας ανθυγιεινής κατάστασης υπηρεσίας) υγειονομικούς ελέγχους.
• Δρομολόγηση. Όταν λαμβάνετε ένα αίτημα στο "/foo" από μια υπηρεσία REST, σε ποιο σύμπλεγμα υπηρεσιών πρέπει να σταλεί το αίτημα;
• Εξισορρόπηση φορτίου. Αφού επιλεγεί ένα σύμπλεγμα υπηρεσιών κατά τη δρομολόγηση, σε ποια παρουσία υπηρεσίας πρέπει να σταλεί το αίτημα; Με τι τάιμ άουτ; Με ποιες ρυθμίσεις διακοπής κυκλώματος; Εάν το αίτημα αποτύχει, πρέπει να επαναληφθεί;
• Έλεγχος ταυτότητας και εξουσιοδότηση. Για εισερχόμενα αιτήματα, μπορεί η υπηρεσία κλήσης να αναγνωριστεί/εξουσιοδοτηθεί κρυπτογραφικά με χρήση mTLS ή κάποιου άλλου μηχανισμού; Εάν είναι αναγνωρισμένο/εξουσιοδοτημένο, επιτρέπεται η κλήση της ζητούμενης λειτουργίας (τελικού σημείου) στην υπηρεσία ή θα πρέπει να επιστραφεί μια μη επαληθευμένη απάντηση;
• Παρατηρησιμότητα. Θα πρέπει να δημιουργούνται λεπτομερή στατιστικά στοιχεία, αρχεία καταγραφής/καταγραφής και κατανεμημένα δεδομένα ιχνών για κάθε αίτημα, έτσι ώστε οι χειριστές να μπορούν να κατανοούν την κατανεμημένη ροή κυκλοφορίας και τα ζητήματα εντοπισμού σφαλμάτων όταν προκύπτουν.

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

Το επίπεδο ελέγχου

Η αφαίρεση δικτύου που παρέχει ένας τοπικός διακομιστής μεσολάβησης στο επίπεδο δεδομένων είναι μαγική(?). Ωστόσο, πώς γνωρίζει πραγματικά ο διακομιστής μεσολάβησης για τη διαδρομή "/foo" προς την υπηρεσία Β; Πώς μπορούν να χρησιμοποιηθούν τα δεδομένα ανακάλυψης υπηρεσίας που συμπληρώνονται από αιτήματα διακομιστή μεσολάβησης; Πώς διαμορφώνονται οι παράμετροι για εξισορρόπηση φορτίου, timeout, διακοπή κυκλώματος κ.λπ.; Πώς αναπτύσσετε μια εφαρμογή χρησιμοποιώντας τη μέθοδο μπλε/πράσινης ή τη χαριτωμένη μέθοδο μετάβασης κυκλοφορίας; Ποιος διαμορφώνει τις ρυθμίσεις ελέγχου ταυτότητας και εξουσιοδότησης σε όλο το σύστημα;

Όλα τα παραπάνω στοιχεία βρίσκονται υπό τον έλεγχο του επιπέδου ελέγχου του πλέγματος σέρβις. Το επίπεδο ελέγχου παίρνει ένα σύνολο απομονωμένων πληρεξουσίων χωρίς ιθαγένεια και τους μετατρέπει σε ένα κατανεμημένο σύστημα.

Νομίζω ότι ο λόγος που πολλοί τεχνολόγοι βρίσκουν σύγχυση τις ξεχωριστές έννοιες του επιπέδου δεδομένων και του επιπέδου ελέγχου είναι επειδή για τους περισσότερους ανθρώπους το επίπεδο δεδομένων είναι οικείο ενώ το επίπεδο ελέγχου είναι ξένο/ακατανόητο. Δουλεύουμε με δρομολογητές και μεταγωγείς φυσικού δικτύου εδώ και πολύ καιρό. Κατανοούμε ότι τα πακέτα/αιτήματα πρέπει να πηγαίνουν από το σημείο Α στο σημείο Β και ότι μπορούμε να χρησιμοποιήσουμε υλικό και λογισμικό για να το κάνουμε αυτό. Η νέα γενιά διακομιστή μεσολάβησης λογισμικού είναι απλώς φανταχτερές εκδόσεις των εργαλείων που χρησιμοποιούμε εδώ και πολύ καιρό.

Εικόνα 2: Ανθρώπινο επίπεδο ελέγχου

Ωστόσο, χρησιμοποιούμε επίπεδα ελέγχου για μεγάλο χρονικό διάστημα, αν και οι περισσότεροι χειριστές δικτύου ενδέχεται να μην συσχετίζουν αυτό το τμήμα του συστήματος με οποιοδήποτε στοιχείο τεχνολογίας. Ο λόγος είναι απλός:
Τα περισσότερα αεροπλάνα ελέγχου που χρησιμοποιούνται σήμερα είμαστε... εμείς.

Επί Φιγούρα 2 δείχνει αυτό που αποκαλώ «αεροπλάνο ανθρώπινου ελέγχου». Σε αυτόν τον τύπο ανάπτυξης, που είναι ακόμα πολύ συνηθισμένος, ένας πιθανώς γκρινιάρης ανθρώπινος χειριστής δημιουργεί στατικές διαμορφώσεις - πιθανώς μέσω σεναρίων - και τις αναπτύσσει μέσω κάποιας ειδικής διαδικασίας σε όλους τους διακομιστή μεσολάβησης. Στη συνέχεια, οι διακομιστής μεσολάβησης αρχίζουν να χρησιμοποιούν αυτήν τη διαμόρφωση και αρχίζουν να επεξεργάζονται το επίπεδο δεδομένων χρησιμοποιώντας τις ενημερωμένες ρυθμίσεις.

Εικόνα 3: Προηγμένο επίπεδο ελέγχου πλέγματος σέρβις

Επί Φιγούρα 3 δείχνει το "εκτεταμένο" επίπεδο ελέγχου του πλέγματος σέρβις. Αποτελείται από τα ακόλουθα μέρη:

• Ο άνθρωπος: Υπάρχει ακόμα ένα άτομο (ελπίζουμε λιγότερο θυμωμένο) που παίρνει αποφάσεις υψηλού επιπέδου σχετικά με ολόκληρο το σύστημα ως σύνολο.
• UI επιπέδου ελέγχου: Ένα άτομο αλληλεπιδρά με κάποιο είδος διεπαφής χρήστη για τον έλεγχο του συστήματος. Αυτό θα μπορούσε να είναι μια πύλη web, μια εφαρμογή γραμμής εντολών (CLI) ή κάποια άλλη διεπαφή. Χρησιμοποιώντας τη διεπαφή χρήστη, ο χειριστής έχει πρόσβαση σε παραμέτρους γενικής διαμόρφωσης συστήματος όπως:
  • Έλεγχος ανάπτυξης, μπλε/πράσινο ή/και σταδιακή μετάβαση της κυκλοφορίας
  • Επιλογές ελέγχου ταυτότητας και εξουσιοδότησης
  • Προδιαγραφές πίνακα δρομολόγησης, για παράδειγμα όταν η εφαρμογή Α ζητά πληροφορίες σχετικά με το "/foo" τι συμβαίνει
  • Ρυθμίσεις εξισορρόπησης φορτίου, όπως χρονικά όρια, επαναλήψεις, ρυθμίσεις διακοπής κυκλώματος κ.λπ.
• Προγραμματιστής φόρτου εργασίας: Οι υπηρεσίες εκτελούνται στην υποδομή μέσω κάποιου τύπου συστήματος προγραμματισμού/ενορχήστρωσης, όπως το Kubernetes ή το Nomad. Ο προγραμματιστής είναι υπεύθυνος για τη φόρτωση της υπηρεσίας μαζί με τον τοπικό του διακομιστή μεσολάβησης.
• Ανακάλυψη υπηρεσίας. Όταν ο προγραμματιστής ξεκινά και σταματά τις παρουσίες υπηρεσιών, αναφέρει την κατάσταση υγείας στο σύστημα εντοπισμού υπηρεσίας.
• API διαμόρφωσης διακομιστή μεσολάβησης Sidecar : Τοπικοί διακομιστής μεσολάβησης εξάγουν δυναμικά την κατάσταση από διάφορα στοιχεία του συστήματος χρησιμοποιώντας ένα τελικά συνεπές μοντέλο χωρίς παρέμβαση χειριστή. Ολόκληρο το σύστημα, που αποτελείται από όλες τις τρέχουσες παρουσίες υπηρεσιών και τοπικούς διακομιστές μεσολάβησης, συγκλίνει τελικά σε ένα οικοσύστημα. Το API του καθολικού επιπέδου δεδομένων του Envoy είναι ένα παράδειγμα του πώς αυτό λειτουργεί στην πράξη.

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

Επίπεδο δεδομένων και επίπεδο ελέγχου. Σύνοψη επιπέδου δεδομένων έναντι επιπέδου ελέγχου

• Επίπεδο δεδομένων πλέγματος σέρβις: Επηρεάζει κάθε πακέτο/αίτημα στο σύστημα. Υπεύθυνος για την ανακάλυψη εφαρμογών/υπηρεσιών, τον έλεγχο υγείας, τη δρομολόγηση, την εξισορρόπηση φορτίου, τον έλεγχο ταυτότητας/εξουσιοδότηση και την παρατηρησιμότητα.
• Επίπεδο ελέγχου πλέγματος σέρβις: Παρέχει πολιτική και διαμόρφωση για όλα τα επίπεδα δεδομένων που εκτελούνται εντός του δικτύου υπηρεσιών. Δεν αγγίζει κανένα πακέτο/αίτημα στο σύστημα. Το επίπεδο ελέγχου μετατρέπει όλα τα επίπεδα δεδομένων σε ένα κατανεμημένο σύστημα.

Τοπίο του τρέχοντος έργου

Έχοντας κατανοήσει την παραπάνω εξήγηση, ας δούμε την τρέχουσα κατάσταση του έργου πλέγματος υπηρεσιών.

• Επίπεδα δεδομένων: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Αεροπλάνα ελέγχου: Istio, Nelson, SmartStack

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

Ο Linkerd ήταν ένας από τους πρώτους διακομιστές μεσολάβησης επιπέδου δεδομένων για το πλέγμα υπηρεσιών στις αρχές του 2016 και έχει κάνει φανταστική δουλειά αυξάνοντας την ευαισθητοποίηση και την προσοχή στο μοντέλο σχεδιασμού πλέγματος υπηρεσιών. Περίπου 6 μήνες μετά από αυτό, ο Envoy εντάχθηκε στο Linkerd (αν και ήταν με τη Lyft από τα τέλη του 2015). Το Linkerd και το Envoy είναι τα δύο έργα που αναφέρονται συχνότερα όταν συζητούνται τα πλέγματα υπηρεσιών.

Το Ιστιο ανακοινώθηκε τον Μάιο του 2017. Οι στόχοι του έργου Istio είναι πολύ παρόμοιοι με το εκτεταμένο επίπεδο ελέγχου που φαίνεται στο Φιγούρα 3. Ο Envoy for Istio είναι ο προεπιλεγμένος πληρεξούσιος. Έτσι, το Istio είναι το επίπεδο ελέγχου και ο Envoy είναι το επίπεδο δεδομένων. Σε σύντομο χρονικό διάστημα, το Istio προκάλεσε πολύ ενθουσιασμό και άλλα αεροπλάνα δεδομένων άρχισαν να ενσωματώνονται ως αντικατάσταση του Envoy (τόσο το Linkerd όσο και το NGINX επέδειξαν ενσωμάτωση με το Istio). Το γεγονός ότι μπορούν να χρησιμοποιηθούν διαφορετικά επίπεδα δεδομένων εντός του ίδιου επιπέδου ελέγχου σημαίνει ότι το επίπεδο ελέγχου και το επίπεδο δεδομένων δεν είναι απαραίτητα στενά συνδεδεμένα. Ένα API όπως το API γενικού επιπέδου δεδομένων του Envoy μπορεί να σχηματίσει μια γέφυρα μεταξύ δύο τμημάτων του συστήματος.

Ο Nelson και το SmartStack βοηθούν στην περαιτέρω απεικόνιση του διαχωρισμού του επιπέδου ελέγχου και του επιπέδου δεδομένων. Ο Nelson χρησιμοποιεί το Envoy ως διακομιστή μεσολάβησής του και δημιουργεί ένα αξιόπιστο επίπεδο ελέγχου για το πλέγμα υπηρεσιών που βασίζεται στη στοίβα HashiCorp, δηλ. Nomad κ.λπ. Το SmartStack ήταν ίσως το πρώτο από ένα νέο κύμα δικτύων υπηρεσιών. Το SmartStack δημιουργεί ένα επίπεδο ελέγχου γύρω από το HAProxy ή το NGINX, επιδεικνύοντας την ικανότητα αποσύνδεσης του επιπέδου ελέγχου από το πλέγμα εξυπηρέτησης από το επίπεδο δεδομένων.

Η αρχιτεκτονική μικροϋπηρεσιών με πλέγμα υπηρεσιών κερδίζει ολοένα και μεγαλύτερη προσοχή (δικαίως!) και όλο και περισσότερα έργα και προμηθευτές αρχίζουν να εργάζονται προς αυτή την κατεύθυνση. Τα επόμενα χρόνια θα δούμε πολλές καινοτομίες τόσο στο επίπεδο δεδομένων όσο και στο επίπεδο ελέγχου, καθώς και περαιτέρω ανάμειξη διαφορετικών εξαρτημάτων. Τελικά, η αρχιτεκτονική microservice θα πρέπει να γίνει πιο διαφανής και μαγική (;) για τον χειριστή.
Ας ελπίσουμε ότι όλο και λιγότερο εκνευρισμένος.

Βασικά φαγητά

• Ένα πλέγμα εξυπηρέτησης αποτελείται από δύο διαφορετικά μέρη: το επίπεδο δεδομένων και το επίπεδο ελέγχου. Απαιτούνται και τα δύο εξαρτήματα και χωρίς αυτά το σύστημα δεν θα λειτουργήσει.
• Όλοι είναι εξοικειωμένοι με το επίπεδο ελέγχου και σε αυτό το σημείο, το επίπεδο ελέγχου μπορεί να είστε εσείς!
• Όλα τα επίπεδα δεδομένων ανταγωνίζονται μεταξύ τους σε χαρακτηριστικά, απόδοση, δυνατότητα διαμόρφωσης και επεκτασιμότητα.
• Όλα τα επίπεδα ελέγχου ανταγωνίζονται μεταξύ τους σε χαρακτηριστικά, δυνατότητα διαμόρφωσης, επεκτασιμότητα και ευκολία χρήσης.
• Ένα επίπεδο ελέγχου μπορεί να περιέχει τις σωστές αφαιρέσεις και API, έτσι ώστε να μπορούν να χρησιμοποιηθούν πολλαπλά επίπεδα δεδομένων.

Πηγή: www.habr.com