Μία από τις αλλαγές που συμβαίνουν στην πληροφορική κάτω από το σήμα του ψηφιακού μετασχηματισμού είναι η διάσπαση μεγάλων, μονολιθικών εφαρμογών σε μικροϋπηρεσίες—μικρές, διακριτές μονάδες λειτουργικότητας - που λειτουργούν σε κοντέινερ—πακέτα λογισμικού που περιλαμβάνουν όλο τον κώδικα και τις εξαρτήσεις της υπηρεσίας που μπορούν να απομονωθούν και να μετακινηθούν εύκολα από τον ένα διακομιστή στον άλλο.
Οι κοντέινερ αρχιτεκτονικές όπως αυτές είναι εύκολο να αναβαθμιστούν και να εκτελεστούν στο cloud, και μεμονωμένες μικροσυσκευές μπορούν να αναπτυχθούν και να επαναληφθούν γρήγορα. Ωστόσο, η επικοινωνία μεταξύ αυτών των μικροϋπηρεσιών γίνεται όλο και πιο περίπλοκη καθώς οι εφαρμογές γίνονται μεγαλύτερες και πολλαπλές παρουσίες της ίδιας υπηρεσίας εκτελούνται ταυτόχρονα. Το πλέγμα εξυπηρέτησης είναι μια αναδυόμενη αρχιτεκτονική μορφή που στοχεύει στη δυναμική σύνδεση αυτών των μικροϋπηρεσιών με τρόπο που μειώνει τα γενικά διοικητικά και προγραμματικά έξοδα.
Τι είναι το πλέγμα εξυπηρέτησης;
Με την ευρύτερη έννοια, ένα πλέγμα εξυπηρέτησης είναι, όπως το περιγράφει η Red Hat, "ένας τρόπος για τον έλεγχο του τρόπου με τον οποίο διαφορετικά μέρη μιας εφαρμογής μοιράζονται δεδομένα μεταξύ τους." Ωστόσο, αυτή η περιγραφή θα μπορούσε να περιλαμβάνει πολλά διαφορετικά πράγματα. Στην πραγματικότητα, ακούγεται πάρα πολύ σαν το μεσαίο λογισμικό που οι περισσότεροι προγραμματιστές γνωρίζουν από εφαρμογές πελάτη-διακομιστή.
Αυτό που κάνει ένα πλέγμα υπηρεσιών μοναδικό είναι ότι έχει κατασκευαστεί για να φιλοξενεί τη μοναδική φύση των κατανεμημένων περιβαλλόντων μικροεπηρεσίας. Σε μια εφαρμογή μεγάλης κλίμακας που δημιουργήθηκε από μικροσυσκευές, ενδέχεται να υπάρχουν πολλές παρουσίες οποιασδήποτε δεδομένης υπηρεσίας, που εκτελείται σε διάφορους τοπικούς διακομιστές ή διακομιστές cloud. Όλα αυτά τα κινούμενα μέρη δυσκολεύουν προφανώς για μεμονωμένες μικροϋπηρεσίες να βρουν τις άλλες υπηρεσίες που χρειάζονται για να επικοινωνήσουν. Ένα πλέγμα εξυπηρέτησης φροντίζει αυτόματα να ανακαλύπτει και να συνδέει υπηρεσίες κάθε στιγμή, έτσι ώστε τόσο οι προγραμματιστές όσο και οι μεμονωμένες μικροϋπηρεσίες να μην χρειάζεται.
Σκεφτείτε ένα πλέγμα εξυπηρέτησης ως το αντίστοιχο δίκτυο που καθορίζεται από λογισμικό (SDN) για το Επίπεδο 7 του μοντέλου δικτύωσης OSI. Ακριβώς όπως το SDN δημιουργεί ένα επίπεδο αφαίρεσης, έτσι οι διαχειριστές δικτύου δεν χρειάζεται να ασχολούνται με φυσικές συνδέσεις δικτύου, ένα πλέγμα υπηρεσιών αποσυνδέει την υποκείμενη υποδομή της εφαρμογής από την αφηρημένη αρχιτεκτονική με την οποία αλληλεπιδράτε.
Η ιδέα ενός πλέγματος υπηρεσιών προέκυψε οργανικά καθώς οι προγραμματιστές άρχισαν να αντιμετωπίζουν τα προβλήματα των πραγματικά τεράστιων κατανεμημένων αρχιτεκτονικών. Ο Linkerd, το πρώτο έργο σε αυτόν τον τομέα, γεννήθηκε ως παρακλάδι ενός εσωτερικού έργου στο Twitter. Το Istio, ένα άλλο δημοφιλές πλέγμα υπηρεσιών με μεγάλη εταιρική υποστήριξη, προήλθε από τη Lyft. (Θα εξετάσουμε λεπτομερέστερα και τα δύο αυτά έργα σε μια στιγμή.)
Εξισορρόπηση φορτίου πλέγματος σέρβις
Ένα από τα βασικά χαρακτηριστικά που παρέχει ένα πλέγμα εξυπηρέτησης είναι η εξισορρόπηση φορτίου. Συνήθως θεωρούμε ότι η εξισορρόπηση φορτίου είναι μια λειτουργία δικτύου - θέλετε να αποτρέψετε τη συντριβή οποιουδήποτε διακομιστή ή συνδέσμου δικτύου από την κυκλοφορία, οπότε δρομολογείτε τα πακέτα σας ανάλογα. Τα πλέγματα εξυπηρέτησης κάνουν κάτι παρόμοιο σε επίπεδο εφαρμογής, όπως περιγράφει ο Twain Taylor και η κατανόηση που σας δίνει μια καλή αίσθηση του τι εννοούμε όταν λέμε ότι το πλέγμα υπηρεσίας είναι σαν δίκτυο που καθορίζεται από λογισμικό για το επίπεδο εφαρμογής.
Στην ουσία, μία από τις εργασίες του πλέγματος υπηρεσιών είναι να παρακολουθείτε ποιες περιπτώσεις διαφόρων μικροϋπηρεσιών που διανέμονται σε όλη την υποδομή είναι «πιο υγιείς». Μπορεί να τους κάνει δημοσκόπηση για να δουν πώς κάνουν ή να παρακολουθούν ποιες περιπτώσεις ανταποκρίνονται αργά σε αιτήματα υπηρεσίας και να στέλνουν επακόλουθα αιτήματα σε άλλες περιπτώσεις. Το πλέγμα εξυπηρέτησης μπορεί να κάνει παρόμοια δουλειά για διαδρομές δικτύου, παρατηρώντας πότε τα μηνύματα χρειάζονται πολύ χρόνο για να φτάσουν στον προορισμό τους και για άλλες αποζημιώσεις. Αυτές οι επιβραδύνσεις μπορεί να οφείλονται σε προβλήματα με το υποκείμενο υλικό ή απλώς στην υπερφόρτωση των υπηρεσιών με αιτήματα ή στην εργασία με την ικανότητα επεξεργασίας τους. Το σημαντικό είναι ότι το πλέγμα εξυπηρέτησης μπορεί να βρει μια άλλη παρουσία της ίδιας υπηρεσίας και να το δρομολογήσει αντί αυτού, κάνοντας έτσι την πιο αποτελεσματική χρήση της συνολικής χωρητικότητας της εφαρμογής.
Πλέγμα σέρβις εναντίον Kubernetes
Αν είστε κάπως εξοικειωμένοι με τις αρχιτεκτονικές που βασίζονται σε κοντέινερ, ίσως αναρωτιέστε πού η Kubernetes, η δημοφιλής πλατφόρμα ενορχήστρωσης εμπορευματοκιβωτίων ανοιχτού κώδικα, ταιριάζει σε αυτήν την εικόνα. Σε τελική ανάλυση, δεν είναι το πλήρες σημείο του Kubernetes ότι διαχειρίζεται τον τρόπο με τον οποίο τα κοντέινερ σας επικοινωνούν μεταξύ τους; Όπως επισημαίνει η ομάδα του Kublr στο εταιρικό τους blog, θα μπορούσατε να σκεφτείτε τον πόρο «υπηρεσίας» του Kubernetes ως ένα πολύ βασικό είδος πλέγματος υπηρεσιών, καθώς παρέχει ανακάλυψη υπηρεσιών και εξισορρόπηση αιτημάτων round-robin. Ωστόσο, τα πλήρως εξοπλισμένα πλέγματα υπηρεσιών παρέχουν πολύ περισσότερη λειτουργικότητα, όπως διαχείριση πολιτικών ασφαλείας και κρυπτογράφησης, "διακοπή κυκλώματος" για αναστολή αιτημάτων σε περιπτώσεις αργής απόκρισης, εξισορρόπηση φορτίου όπως περιγράφουμε παραπάνω και πολλά άλλα.
Λάβετε υπόψη ότι τα περισσότερα πλέγματα εξυπηρέτησης απαιτούν πραγματικά ένα σύστημα ενορχήστρωσης, όπως το Kubernetes, για να είναι σε ισχύ. Τα πλέγματα εξυπηρέτησης προσφέρουν εκτεταμένη λειτουργικότητα και όχι αντικατάσταση.
Υπηρεσία πλέγματος έναντι πυλών API
Κάθε μικροϋπηρεσία θα παρέχει μια διεπαφή προγραμματισμού εφαρμογών (API) που χρησιμεύει ως το μέσο με το οποίο επικοινωνούν άλλες υπηρεσίες μαζί του. Αυτό εγείρει το ζήτημα των διαφορών μεταξύ ενός πλέγματος υπηρεσιών και άλλων πιο παραδοσιακών μορφών διαχείρισης API, όπως οι πύλες API. Όπως εξηγεί η IBM, μια πύλη API βρίσκεται ανάμεσα σε μια ομάδα μικροσυστημάτων και στον «εξωτερικό» κόσμο, δρομολογώντας αιτήματα υπηρεσίας, όπως απαιτείται, έτσι ώστε ο αιτών να μην χρειάζεται να γνωρίζει ότι ασχολείται με μια εφαρμογή που βασίζεται σε μικροσυσκευές. Ένα πλέγμα εξυπηρέτησης, από την άλλη πλευρά, διαμεσολαβεί σε αιτήματα «εντός» της εφαρμογής μικροϋπηρεσιών, με τα διάφορα στοιχεία να γνωρίζουν πλήρως το περιβάλλον τους.
Ένας άλλος τρόπος να το σκεφτείτε, όπως γράφει ο Justin Warren Φορμπς, είναι ότι ένα πλέγμα εξυπηρέτησης προορίζεται για κίνηση ανατολής-δύσης μέσα σε ένα σύμπλεγμα και μια πύλη API είναι για κίνηση βορρά-νότου που εισέρχεται και εξέρχεται από το σύμπλεγμα. Όμως η όλη ιδέα ενός πλέγματος εξυπηρέτησης είναι ακόμα νωρίς και σε εξέλιξη. Πολλά πλέγματα υπηρεσιών - συμπεριλαμβανομένων των Linkerd και Istio - προσφέρουν πλέον λειτουργικότητα βορρά-νότου.
Αρχιτεκτονική πλέγματος υπηρεσιών
Η ιδέα ενός πλέγματος εξυπηρέτησης έχει αναδυθεί μόνο τα τελευταία δύο χρόνια, και υπάρχουν πολλές διαφορετικές προσεγγίσεις για την επίλυση του προβλήματος "πλέγμα εξυπηρέτησης", δηλαδή διαχείριση επικοινωνιών για μικροϋπηρεσίες. Ο Andrew Jenkins του Aspen Mesh προσδιορίζει τρεις πιθανές επιλογές σχετικά με το πού μπορεί να ζήσει το επίπεδο επικοινωνίας που δημιουργήθηκε από το πλέγμα υπηρεσιών:
- Σε ένα βιβλιοθήκη που κάθε μία από τις μικρο-υπηρεσίες σας εισάγει
- Σε ένα πράκτορας κόμβου που παρέχει υπηρεσίες σε όλα τα κοντέινερ σε έναν συγκεκριμένο κόμβο
- Σε ένα αμάξι μοτοσυκλέττας κοντέινερ που τρέχει παράλληλα με το κοντέινερ της εφαρμογής σας
Το μοτίβο με βάση το καρότσι είναι ένα από τα πιο δημοφιλή μοτίβα πλέγματος υπηρεσιών εκεί έξω - τόσο πολύ που κατά κάποιο τρόπο έχει γίνει συνώνυμο με τα πλέγματα σέρβις γενικά. Αν και αυτό δεν είναι αυστηρά αληθινό, η πλαϊνή προσέγγιση έχει γίνει τόσο ελκυστική που αυτή είναι η αρχιτεκτονική που θα εξετάσουμε με περισσότερες λεπτομέρειες.
Πλαίσια σε πλέγμα σέρβις
Τι σημαίνει να λέτε ότι ένα κοντέινερ πλευρικού αυτοκινήτου "τρέχει παράλληλα" με το κοντέινερ της εφαρμογής σας; Το Red Hat έχει μια αρκετά καλή εξήγηση. Κάθε κοντέινερ μικροσυσκευών σε ένα πλέγμα σέρβις αυτού του τύπου έχει ένα άλλο κοντέινερ μεσολάβησης που αντιστοιχεί σε αυτό. Όλη η λογική που απαιτείται για την επικοινωνία από υπηρεσία σε υπηρεσία αφαιρείται από τη μικροσυσκευή και τοποθετείται στο sidecar.
Αυτό μπορεί να φαίνεται περίπλοκο - τελικά, διπλασιάζετε αποτελεσματικά τον αριθμό των κοντέινερ στην εφαρμογή σας! Αλλά χρησιμοποιείτε επίσης ένα μοτίβο σχεδίασης που είναι το κλειδί για την απλοποίηση των κατανεμημένων εφαρμογών. Τοποθετώντας όλο αυτόν τον κώδικα δικτύωσης και επικοινωνίας σε ένα ξεχωριστό κοντέινερ, το έχετε ορίσει ως μέρος της υποδομής και ελευθερώσατε τους προγραμματιστές από την εφαρμογή του ως μέρος της εφαρμογής.
Στην ουσία, αυτό που απομένει είναι μια μικροϋπηρεσία που μπορεί να επικεντρωθεί με λέιζερ στην επιχειρηματική της λογική. Η μικροϋπηρεσία δεν χρειάζεται να γνωρίζει πώς να επικοινωνεί με όλες τις άλλες υπηρεσίες στο άγριο και τρελό περιβάλλον όπου λειτουργούν. Το μόνο που χρειάζεται είναι να γνωρίζει πώς να επικοινωνεί με το sidecar, το οποίο φροντίζει τα υπόλοιπα.
Πλέγματα υπηρεσιών: Linkerd, Envio, Istio, Πρόξενος
Ποια είναι λοιπόν τα πλέγματα εξυπηρέτησης που διατίθενται για χρήση; Λοιπόν, δεν υπάρχουν ακριβώς εκεί έξω τα εμπορικά προϊόντα. Τα περισσότερα πλέγματα εξυπηρέτησης είναι έργα ανοιχτού κώδικα που χρειάζονται κάποια προσπάθεια υλοποίησης. Τα μεγάλα ονόματα είναι:
- Linkerd (προφέρεται "linker-dee") - Κυκλοφόρησε το 2016 και έτσι η παλαιότερη από αυτές τις προσφορές, ο Linkerd αποσπάστηκε από μια βιβλιοθήκη που αναπτύχθηκε στο Twitter. Ένα άλλο βαρύ χτύπημα σε αυτόν τον χώρο, ο Conduit, μπήκε στο έργο Linkerd και αποτελεί τη βάση για το Linkerd 2.0.
- Envoy — Δημιουργήθηκε στο Lyft, ο Envoy καταλαμβάνει το τμήμα «επίπεδο δεδομένων» ενός πλέγματος σέρβις. Για να παρέχει ένα πλήρες πλέγμα εξυπηρέτησης, πρέπει να συνδυαστεί με ένα "επίπεδο ελέγχου", όπως ...
- Istio - Αναπτύχθηκε σε συνεργασία με τη Lyft, την IBM και την Google, το Istio είναι ένα σχέδιο ελέγχου για την εξυπηρέτηση διακομιστών μεσολάβησης όπως ο Envoy. Ενώ το Istio και το Envoy είναι ένα προεπιλεγμένο ζεύγος, το καθένα μπορεί να συνδυαστεί με άλλες πλατφόρμες.
- HashiCorp Consul - Παρουσιάστηκε με το Consul 1.2, μια δυνατότητα που ονομάζεται Connect πρόσθετη κρυπτογράφηση υπηρεσίας και εξουσιοδότηση βάσει ταυτότητας στο κατανεμημένο σύστημα της HashiCorp για ανακάλυψη και διαμόρφωση υπηρεσίας, μετατρέποντάς το σε ένα πλήρες πλέγμα υπηρεσιών.
Ποιο πλέγμα εξυπηρέτησης είναι κατάλληλο για εσάς; Μια σύγκριση είναι πέρα από το πεδίο εφαρμογής αυτού του άρθρου, αλλά αξίζει να σημειωθεί ότι όλα τα παραπάνω προϊόντα έχουν αποδειχθεί σε μεγάλα και απαιτητικά περιβάλλοντα. Οι Linkerd και Istio έχουν τα πιο εκτεταμένα σύνολα χαρακτηριστικών, αλλά όλα εξελίσσονται γρήγορα. Ίσως θελήσετε να δείτε την ανάλυση των χαρακτηριστικών του Τζορτζ Μιράντα των Linkerd, Envoy και Istio, αν και λάβετε υπόψη ότι το άρθρο του γράφτηκε πριν ο Conduit και ο Linkerd ενωθούν.
Λάβετε επίσης υπόψη ότι αυτός ο χώρος είναι νέος και θα μπορούσαν να εμφανιστούν νέοι ανταγωνιστές ανά πάσα στιγμή. Για παράδειγμα, τον Νοέμβριο του 2018 η Amazon άρχισε να προσφέρει μια δημόσια προεπισκόπηση ενός πλέγματος υπηρεσιών AWS. Λαμβάνοντας υπόψη πόσα καταστήματα χρησιμοποιούν το δημόσιο cloud του Amazon, το AWS App Mesh θα πρέπει να έχει σημαντικό αντίκτυπο.
