Στο διαδίκτυο (σέρβις πλέγμα), και εδώ είναι ένα άλλο. Ζήτω! Μα γιατί? Στη συνέχεια, θέλω να εκφράσω την άποψή μου ότι θα ήταν καλύτερα να εμφανίζονταν τα πλέγματα εξυπηρέτησης πριν από 10 χρόνια, πριν από την εμφάνιση πλατφορμών εμπορευματοκιβωτίων όπως το Docker και το Kubernetes. Δεν λέω ότι η άποψή μου είναι καλύτερη ή χειρότερη από άλλες, αλλά επειδή τα πλέγματα υπηρεσίας είναι αρκετά πολύπλοκα ζώα, πολλαπλές απόψεις θα βοηθήσουν στην καλύτερη κατανόηση τους.
Θα μιλήσω για την πλατφόρμα dotCloud, η οποία χτίστηκε σε πάνω από εκατό μικροϋπηρεσίες και υποστήριζε χιλιάδες εφαρμογές με κοντέινερ. Θα εξηγήσω τις προκλήσεις που αντιμετωπίσαμε κατά την ανάπτυξη και την κυκλοφορία του και πώς τα πλέγματα υπηρεσιών θα μπορούσαν (ή δεν μπορούσαν) να βοηθήσουν.
Ιστορικό του dotCloud
Έχω γράψει για την ιστορία του dotCloud και τις επιλογές αρχιτεκτονικής για αυτήν την πλατφόρμα, αλλά δεν έχω μιλήσει πολύ για το επίπεδο δικτύου. Αν δεν θέλετε να βουτήξετε στο διάβασμα σχετικά με το dotCloud, εδώ είναι η ουσία με λίγα λόγια: είναι μια πλατφόρμα PaaS ως υπηρεσία που επιτρέπει στους πελάτες να εκτελούν ένα ευρύ φάσμα εφαρμογών (Java, PHP, Python...), με υποστήριξη για ένα ευρύ φάσμα δεδομένων υπηρεσίες (MongoDB, MySQL, Redis...) και μια ροή εργασίας όπως το Heroku: Ανεβάζετε τον κώδικά σας στην πλατφόρμα, δημιουργεί εικόνες κοντέινερ και τις αναπτύσσει.
Θα σας πω πώς κατευθύνθηκε η κίνηση στην πλατφόρμα dotCloud. Όχι επειδή ήταν ιδιαίτερα δροσερό (αν και το σύστημα δούλευε καλά για την εποχή του!), αλλά κυρίως επειδή με σύγχρονα εργαλεία μια τέτοια σχεδίαση μπορεί εύκολα να εφαρμοστεί σε σύντομο χρονικό διάστημα από μια μέτρια ομάδα, εάν χρειάζεται έναν τρόπο να δρομολογήσει την κυκλοφορία μεταξύ μιας δέσμης μικροϋπηρεσιών ή ένα σωρό εφαρμογές. Με αυτόν τον τρόπο, μπορείτε να συγκρίνετε τις επιλογές: τι θα συμβεί εάν αναπτύξετε τα πάντα μόνοι σας ή χρησιμοποιήσετε ένα υπάρχον πλέγμα υπηρεσιών. Η τυπική επιλογή είναι να το φτιάξετε μόνοι σας ή να το αγοράσετε.
Δρομολόγηση κυκλοφορίας για φιλοξενούμενες εφαρμογές
Οι εφαρμογές στο dotCloud μπορούν να εκθέσουν τα τελικά σημεία HTTP και TCP.
Τερματικά σημεία HTTP προστίθεται δυναμικά στη διαμόρφωση του συμπλέγματος εξισορρόπησης φορτίου . Αυτό είναι παρόμοιο με αυτό που κάνουν οι πόροι σήμερα στο Kubernetes και ένα load balancer όπως .
Οι πελάτες συνδέονται με τα τελικά σημεία HTTP μέσω κατάλληλων τομέων, υπό την προϋπόθεση ότι το όνομα τομέα οδηγεί σε εξισορροπητές φορτίου dotCloud. Τίποτα ιδιαίτερο.
Τελικά σημεία TCP συσχετίζεται με έναν αριθμό θύρας, ο οποίος στη συνέχεια μεταβιβάζεται σε όλα τα κοντέινερ σε αυτήν τη στοίβα μέσω μεταβλητών περιβάλλοντος.
Οι πελάτες μπορούν να συνδεθούν στα τελικά σημεία TCP χρησιμοποιώντας το κατάλληλο όνομα κεντρικού υπολογιστή (κάτι σαν gateway-X.dotcloud.com) και τον αριθμό θύρας.
Αυτό το όνομα κεντρικού υπολογιστή επιλύεται στο σύμπλεγμα διακομιστών «nats» (δεν σχετίζεται με ), το οποίο θα δρομολογεί τις εισερχόμενες συνδέσεις TCP στο σωστό κοντέινερ (ή, στην περίπτωση υπηρεσιών εξισορρόπησης φορτίου, στα σωστά κοντέινερ).
Εάν είστε εξοικειωμένοι με το Kubernetes, αυτό πιθανότατα θα σας θυμίσει τις Υπηρεσίες .
Δεν υπήρχαν αντίστοιχες υπηρεσίες στην πλατφόρμα dotCloud : Για λόγους απλότητας, η πρόσβαση στις υπηρεσίες έγινε με τον ίδιο τρόπο τόσο από το εσωτερικό όσο και από το εξωτερικό της πλατφόρμας.
Όλα οργανώθηκαν πολύ απλά: οι αρχικές υλοποιήσεις των δικτύων δρομολόγησης HTTP και TCP ήταν πιθανώς μόνο μερικές εκατοντάδες γραμμές Python η καθεμία. Απλοί (αφελείς θα έλεγα) αλγόριθμοι που βελτιώθηκαν καθώς η πλατφόρμα μεγάλωνε και εμφανίστηκαν πρόσθετες απαιτήσεις.
Δεν απαιτήθηκε εκτεταμένη ανακατασκευή του υπάρχοντος κώδικα. Συγκεκριμένα, μπορεί να χρησιμοποιήσει απευθείας τη διεύθυνση που λαμβάνεται μέσω μεταβλητών περιβάλλοντος.
Σε τι διαφέρει αυτό από ένα σύγχρονο πλέγμα σέρβις;
Περιορισμένος ορατότητα. Δεν είχαμε καθόλου μετρήσεις για το πλέγμα δρομολόγησης TCP. Όσον αφορά τη δρομολόγηση HTTP, οι νεότερες εκδόσεις εισήγαγαν λεπτομερείς μετρήσεις HTTP με κωδικούς σφάλματος και χρόνους απόκρισης, αλλά τα σύγχρονα πλέγματα υπηρεσιών προχωρούν ακόμη περισσότερο, παρέχοντας ενοποίηση με συστήματα συλλογής μετρήσεων όπως ο Prometheus, για παράδειγμα.
Η ορατότητα είναι σημαντική όχι μόνο από λειτουργική άποψη (για να βοηθήσει στην αντιμετώπιση προβλημάτων), αλλά και κατά την κυκλοφορία νέων λειτουργιών. Πρόκειται για ασφαλή и .
Αποτελεσματικότητα δρομολόγησης είναι επίσης περιορισμένη. Στο πλέγμα δρομολόγησης dotCloud, όλη η κίνηση έπρεπε να περάσει από ένα σύμπλεγμα αποκλειστικών κόμβων δρομολόγησης. Αυτό σήμαινε πιθανή διέλευση πολλαπλών ορίων AZ (Ζώνη διαθεσιμότητας) και σημαντική αύξηση του λανθάνοντος χρόνου. Θυμάμαι τον κώδικα αντιμετώπισης προβλημάτων που έκανε πάνω από εκατό ερωτήματα SQL ανά σελίδα και άνοιγε μια νέα σύνδεση με τον διακομιστή SQL για κάθε ερώτημα. Όταν εκτελείται τοπικά, η σελίδα φορτώνει αμέσως, αλλά στο dotCloud χρειάζονται μερικά δευτερόλεπτα για να φορτωθεί επειδή κάθε σύνδεση TCP (και επακόλουθο ερώτημα SQL) διαρκεί δεκάδες χιλιοστά του δευτερολέπτου. Στη συγκεκριμένη περίπτωση, οι επίμονες συνδέσεις έλυσαν το πρόβλημα.
Τα σύγχρονα πλέγματα σέρβις είναι καλύτερα στην αντιμετώπιση τέτοιων προβλημάτων. Πρώτα απ 'όλα, ελέγχουν ότι οι συνδέσεις είναι δρομολογημένες στην πηγή. Η λογική ροή είναι η ίδια: клиент → меш → сервис, αλλά τώρα το πλέγμα λειτουργεί τοπικά και όχι σε απομακρυσμένους κόμβους, οπότε η σύνδεση клиент → меш είναι τοπικό και πολύ γρήγορο (μικροδευτερόλεπτα αντί για χιλιοστά του δευτερολέπτου).
Τα σύγχρονα πλέγματα σέρβις εφαρμόζουν επίσης πιο έξυπνους αλγόριθμους εξισορρόπησης φορτίου. Παρακολουθώντας την υγεία των backends, μπορούν να στείλουν περισσότερη επισκεψιμότητα σε ταχύτερα backend, με αποτέλεσμα τη βελτίωση της συνολικής απόδοσης.
Ασφάλεια καλύτερα επίσης. Το πλέγμα δρομολόγησης dotCloud λειτουργούσε εξ ολοκλήρου στο EC2 Classic και δεν κρυπτογραφούσε την κυκλοφορία (με βάση την υπόθεση ότι αν κάποιος κατάφερνε να βάλει ένα sniffer στην κυκλοφορία του δικτύου EC2, είχατε ήδη μεγάλο πρόβλημα). Τα σύγχρονα πλέγματα υπηρεσιών προστατεύουν με διαφάνεια όλη μας την κυκλοφορία, για παράδειγμα, με αμοιβαίο έλεγχο ταυτότητας TLS και επακόλουθη κρυπτογράφηση.
Δρομολόγηση κυκλοφορίας για υπηρεσίες πλατφόρμας
Εντάξει, συζητήσαμε την κυκλοφορία μεταξύ εφαρμογών, αλλά τι γίνεται με την ίδια την πλατφόρμα dotCloud;
Η ίδια η πλατφόρμα αποτελούνταν από περίπου εκατό μικροϋπηρεσίες υπεύθυνες για διάφορες λειτουργίες. Ορισμένοι δέχονταν αιτήματα από άλλους και κάποιοι ήταν εργαζόμενοι στο παρελθόν που συνδέθηκαν με άλλες υπηρεσίες αλλά δεν δέχονταν οι ίδιοι συνδέσεις. Σε κάθε περίπτωση, κάθε υπηρεσία πρέπει να γνωρίζει τα τελικά σημεία των διευθύνσεων στις οποίες πρέπει να συνδεθεί.
Πολλές υπηρεσίες υψηλού επιπέδου ενδέχεται να χρησιμοποιούν το πλέγμα δρομολόγησης που περιγράφεται παραπάνω. Στην πραγματικότητα, πολλές από τις περισσότερες από εκατό μικροϋπηρεσίες του dotCloud έχουν αναπτυχθεί ως τακτικές εφαρμογές στην ίδια την πλατφόρμα dotCloud. Αλλά ένας μικρός αριθμός υπηρεσιών χαμηλού επιπέδου (ιδιαίτερα εκείνες που εφαρμόζουν αυτό το πλέγμα δρομολόγησης) χρειάζονταν κάτι πιο απλό, με λιγότερες εξαρτήσεις (καθώς δεν μπορούσαν να εξαρτηθούν από τον εαυτό τους για να δουλέψουν - το παλιό καλό πρόβλημα με το κοτόπουλο και το αυγό).
Αυτές οι υπηρεσίες χαμηλού επιπέδου, κρίσιμες για την αποστολή, αναπτύχθηκαν με τη λειτουργία κοντέινερ απευθείας σε μερικούς βασικούς κόμβους. Σε αυτήν την περίπτωση, δεν χρησιμοποιήθηκαν τυπικές υπηρεσίες πλατφόρμας: σύνδεσμος, προγραμματιστής και δρομέας. Αν θέλετε να συγκρίνετε με τις σύγχρονες πλατφόρμες εμπορευματοκιβωτίων, είναι σαν να τρέχετε με ένα αεροπλάνο ελέγχου docker run απευθείας στους κόμβους, αντί να αναθέσετε την εργασία στον Kubernetes. Είναι αρκετά παρόμοιο στην ιδέα , το οποίο χρησιμοποιεί ή κατά την εκκίνηση ενός αυτόνομου συμπλέγματος.
Αυτές οι υπηρεσίες αποκαλύφθηκαν με απλό και χονδρό τρόπο: ένα αρχείο YAML περιείχε τα ονόματα και τις διευθύνσεις τους. και κάθε πελάτης έπρεπε να πάρει ένα αντίγραφο αυτού του αρχείου YAML για ανάπτυξη.
Αφενός είναι εξαιρετικά αξιόπιστο γιατί δεν απαιτεί την υποστήριξη ενός εξωτερικού χώρου αποθήκευσης κλειδιών/τιμών όπως το Zookeeper (θυμηθείτε, etcd ή Consul δεν υπήρχε εκείνη την εποχή). Από την άλλη, δυσκόλεψε τη μετακίνηση των υπηρεσιών. Κάθε φορά που γινόταν μια κίνηση, όλοι οι πελάτες θα λάμβαναν ένα ενημερωμένο αρχείο YAML (και πιθανώς θα έκαναν επανεκκίνηση). Όχι πολύ άνετα!
Στη συνέχεια, αρχίσαμε να εφαρμόζουμε ένα νέο σχήμα, όπου κάθε πελάτης συνδεόταν με έναν τοπικό διακομιστή μεσολάβησης. Αντί για διεύθυνση και θύρα, χρειάζεται μόνο να γνωρίζει τον αριθμό θύρας της υπηρεσίας και να συνδεθεί μέσω localhost. Ο τοπικός διακομιστής μεσολάβησης χειρίζεται αυτήν τη σύνδεση και την προωθεί στον πραγματικό διακομιστή. Τώρα, όταν μετακινείτε το backend σε άλλο μηχάνημα ή κλιμακώνετε, αντί να ενημερώνετε όλους τους πελάτες, χρειάζεται μόνο να ενημερώσετε όλους αυτούς τους τοπικούς διακομιστές μεσολάβησης. και δεν απαιτείται πλέον επανεκκίνηση.
(Σχεδιάστηκε επίσης να ενθυλακωθεί η κίνηση στις συνδέσεις TLS και να τοποθετηθεί ένας άλλος διακομιστής μεσολάβησης στην πλευρά λήψης, καθώς και η επαλήθευση των πιστοποιητικών TLS χωρίς τη συμμετοχή της υπηρεσίας λήψης, η οποία έχει ρυθμιστεί να δέχεται συνδέσεις μόνο σε localhost. Περισσότερα για αυτό αργότερα).
Αυτό μοιάζει πολύ με από την Airbnb, αλλά η σημαντική διαφορά είναι ότι το SmartStack υλοποιείται και αναπτύσσεται στην παραγωγή, ενώ το εσωτερικό σύστημα δρομολόγησης του dotCloud έμεινε στο ράφι όταν το dotCloud έγινε Docker.
Προσωπικά θεωρώ ότι το SmartStack είναι ένας από τους προκατόχους συστημάτων όπως το Istio, το Linkerd και το Consul Connect επειδή όλα ακολουθούν το ίδιο μοτίβο:
- Εκτελέστε έναν διακομιστή μεσολάβησης σε κάθε κόμβο.
- Οι πελάτες συνδέονται με τον διακομιστή μεσολάβησης.
- Το επίπεδο ελέγχου ενημερώνει τη διαμόρφωση του διακομιστή μεσολάβησης όταν αλλάζουν τα backend.
- ... Κέρδος!
Σύγχρονη υλοποίηση πλέγματος υπηρεσιών
Εάν χρειαζόταν να εφαρμόσουμε ένα παρόμοιο πλέγμα σήμερα, θα μπορούσαμε να χρησιμοποιήσουμε παρόμοιες αρχές. Για παράδειγμα, διαμορφώστε μια εσωτερική ζώνη DNS αντιστοιχίζοντας τα ονόματα υπηρεσιών σε διευθύνσεις στο χώρο 127.0.0.0/8. Στη συνέχεια, εκτελέστε το HAProxy σε κάθε κόμβο στο σύμπλεγμα, αποδεχόμενοι συνδέσεις σε κάθε διεύθυνση υπηρεσίας (σε αυτό το υποδίκτυο 127.0.0.0/8) και ανακατεύθυνση/εξισορρόπηση του φορτίου στα κατάλληλα backends. Η διαμόρφωση HAProxy μπορεί να ελεγχθεί , επιτρέποντάς σας να αποθηκεύετε πληροφορίες υποστήριξης σε etcd ή Consul και να προωθείτε αυτόματα την ενημερωμένη διαμόρφωση στο HAProxy όταν χρειάζεται.
Κάπως έτσι λειτουργεί το Istio! Αλλά με κάποιες διαφορές:
- Χρήσεις αντί για HAProxy.
- Αποθηκεύει τη διαμόρφωση backend μέσω του Kubernetes API αντί για etcd ή Consul.
- Οι υπηρεσίες εκχωρούνται διευθύνσεις στο εσωτερικό υποδίκτυο (διευθύνσεις Kubernetes ClusterIP) αντί για 127.0.0.0/8.
- Διαθέτει ένα πρόσθετο στοιχείο (Citadel) για την προσθήκη αμοιβαίου ελέγχου ταυτότητας TLS μεταξύ του πελάτη και των διακομιστών.
- Υποστηρίζει νέα χαρακτηριστικά όπως διακοπή κυκλώματος, κατανεμημένη ανίχνευση, ανάπτυξη καναρινιών κ.λπ.
Ας ρίξουμε μια γρήγορη ματιά σε μερικές από τις διαφορές.
Αντιπρόσωπος απεσταλμένου
Το Envoy Proxy γράφτηκε από τη Lyft [ο ανταγωνιστής της Uber στην αγορά των ταξί - περίπου. λωρίδα]. Είναι παρόμοιο από πολλές απόψεις με άλλους διακομιστές μεσολάβησης (π.χ. HAProxy, Nginx, Traefik...), αλλά ο Lyft έγραψε τα δικά τους επειδή χρειάζονταν χαρακτηριστικά που έλειπαν από άλλους διακομιστή μεσολάβησης και φαινόταν πιο έξυπνο να φτιάξουν ένα νέο αντί να επεκτείνουν το υπάρχον.
Το Envoy μπορεί να χρησιμοποιηθεί μόνο του. Εάν έχω μια συγκεκριμένη υπηρεσία που πρέπει να συνδεθεί με άλλες υπηρεσίες, μπορώ να τη διαμορφώσω ώστε να συνδέεται με το Envoy και, στη συνέχεια, να διαμορφώσω και να επαναδιαμορφώσω το Envoy με τη θέση άλλων υπηρεσιών, ενώ αποκτώ πολλές εξαιρετικές πρόσθετες λειτουργίες, όπως η ορατότητα. Αντί για μια προσαρμοσμένη βιβλιοθήκη πελατών ή για εισαγωγή ιχνών κλήσεων στον κώδικα, στέλνουμε επισκεψιμότητα στο Envoy και συλλέγει μετρήσεις για εμάς.
Αλλά ο Απεσταλμένος είναι επίσης ικανός να λειτουργήσει ως επίπεδο δεδομένων (επίπεδο δεδομένων) για το πλέγμα εξυπηρέτησης. Αυτό σημαίνει ότι το Envoy έχει πλέον ρυθμιστεί για αυτό το πλέγμα υπηρεσίας επίπεδο ελέγχου (επίπεδο ελέγχου).
Αεροπλάνο ελέγχου
Για το επίπεδο ελέγχου, το Istio βασίζεται στο Kubernetes API. Αυτό δεν διαφέρει πολύ από τη χρήση του confd, το οποίο βασίζεται στο etcd ή στο Consul για την προβολή του συνόλου των κλειδιών στο χώρο αποθήκευσης δεδομένων. Το Istio χρησιμοποιεί το Kubernetes API για να προβάλει ένα σύνολο πόρων Kubernetes.
Μεταξύ αυτού και τότε: Προσωπικά το βρήκα χρήσιμο που γράφει:
Ο διακομιστής API Kubernetes είναι ένας "χαζός διακομιστής" που προσφέρει αποθήκευση, έκδοση εκδόσεων, επικύρωση, ενημέρωση και σημασιολογία για πόρους API.
Το Istio έχει σχεδιαστεί για να συνεργάζεται με την Kubernetes. και αν θέλετε να το χρησιμοποιήσετε εκτός του Kubernetes, τότε πρέπει να εκτελέσετε μια παρουσία του διακομιστή API Kubernetes (και την υπηρεσία βοηθού etcd).
Διευθύνσεις υπηρεσιών
Το Istio βασίζεται σε διευθύνσεις ClusterIP που εκχωρεί η Kubernetes, επομένως οι υπηρεσίες Istio λαμβάνουν μια εσωτερική διεύθυνση (όχι στην περιοχή 127.0.0.0/8).
Η επισκεψιμότητα στη διεύθυνση ClusterIP για μια συγκεκριμένη υπηρεσία σε ένα σύμπλεγμα Kubernetes χωρίς Istio παρεμποδίζεται από το kube-proxy και αποστέλλεται στο backend αυτού του διακομιστή μεσολάβησης. Εάν ενδιαφέρεστε για τις τεχνικές λεπτομέρειες, το kube-proxy ρυθμίζει κανόνες iptables (ή εξισορροπητές φορτίου IPVS, ανάλογα με τον τρόπο διαμόρφωσης) για να ξαναγράψει τις διευθύνσεις IP προορισμού των συνδέσεων που πηγαίνουν στη διεύθυνση ClusterIP.
Μόλις εγκατασταθεί το Istio σε ένα σύμπλεγμα Kubernetes, τίποτα δεν αλλάζει έως ότου ενεργοποιηθεί ρητά για έναν δεδομένο καταναλωτή ή ακόμα και ολόκληρο τον χώρο ονομάτων, εισάγοντας ένα κοντέινερ sidecar σε προσαρμοσμένες ομάδες. Αυτό το κοντέινερ θα γυρίσει μια παρουσία του Envoy και θα δημιουργήσει ένα σύνολο κανόνων iptables για να παρεμποδίσει την κυκλοφορία που πηγαίνει σε άλλες υπηρεσίες και να ανακατευθύνει αυτήν την κίνηση στον Envoy.
Όταν είναι ενσωματωμένο στο Kubernetes DNS, αυτό σημαίνει ότι ο κώδικάς μας μπορεί να συνδεθεί με το όνομα της υπηρεσίας και όλα «απλώς λειτουργούν». Με άλλα λόγια, ο κώδικας μας εκδίδει ερωτήματα όπως http://api/v1/users/4242τότε api επίλυση αιτήματος για 10.97.105.48, οι κανόνες iptables θα παρεμποδίσουν τις συνδέσεις από την 10.97.105.48 και θα τις προωθήσουν στον τοπικό διακομιστή μεσολάβησης Envoy και αυτός ο τοπικός διακομιστής μεσολάβησης θα προωθήσει το αίτημα στο πραγματικό API υποστήριξης. Φτου!
Επιπλέον διακοσμητικά στοιχεία
Το Istio παρέχει επίσης κρυπτογράφηση και έλεγχο ταυτότητας από άκρο σε άκρο μέσω mTLS (αμοιβαία TLS). Ένα στοιχείο που ονομάζεται Ακρόπολη.
Υπάρχει επίσης ένα εξάρτημα Mixer, το οποίο μπορεί να ζητήσει ο Απεσταλμένος του καθενός ζητήστε να λάβετε μια ειδική απόφαση σχετικά με αυτό το αίτημα ανάλογα με διάφορους παράγοντες, όπως κεφαλίδες, φόρτωση backend, κ.λπ... (μην ανησυχείτε: υπάρχουν πολλοί τρόποι για να συνεχίσετε να λειτουργεί το Mixer και ακόμα κι αν κολλήσει, το Envoy θα συνεχίσει να λειτουργεί πρόστιμο ως πληρεξούσιος) .
Και, φυσικά, αναφέραμε την ορατότητα: Ο Envoy συλλέγει έναν τεράστιο όγκο μετρήσεων ενώ παρέχει κατανεμημένη ανίχνευση. Σε μια αρχιτεκτονική μικροϋπηρεσιών, εάν ένα αίτημα API πρέπει να περάσει από τις μικροϋπηρεσίες A, B, C και D, τότε κατά τη σύνδεση, η κατανεμημένη ανίχνευση θα προσθέσει ένα μοναδικό αναγνωριστικό στο αίτημα και θα αποθηκεύσει αυτό το αναγνωριστικό μέσω υποαιτημάτων σε όλες αυτές τις μικροϋπηρεσίες, επιτρέποντας όλες οι σχετικές κλήσεις προς καταγραφή, καθυστερήσεις κ.λπ.
Ανάπτυξη ή αγορά
Το Ίστιο έχει τη φήμη ότι είναι πολύπλοκο. Αντίθετα, η κατασκευή του πλέγματος δρομολόγησης που περιέγραψα στην αρχή αυτής της ανάρτησης είναι σχετικά απλή χρησιμοποιώντας υπάρχοντα εργαλεία. Λοιπόν, έχει νόημα να δημιουργήσετε το δικό σας πλέγμα εξυπηρέτησης;
Εάν έχουμε μέτριες ανάγκες (δεν χρειαζόμαστε ορατότητα, διακόπτη κυκλώματος και άλλες λεπτές λεπτομέρειες), τότε έρχονται σκέψεις να αναπτύξουμε το δικό μας εργαλείο. Αλλά αν χρησιμοποιήσουμε το Kubernetes, μπορεί να μην χρειάζεται καν επειδή το Kubernetes παρέχει ήδη βασικά εργαλεία για την ανακάλυψη υπηρεσιών και την εξισορρόπηση φορτίου.
Αλλά εάν έχουμε προηγμένες απαιτήσεις, τότε η «αγορά» ενός πλέγματος υπηρεσιών φαίνεται να είναι μια πολύ καλύτερη επιλογή. (Αυτό δεν είναι πάντα "αγορά" επειδή το Istio είναι ανοιχτού κώδικα, αλλά πρέπει ακόμα να επενδύσουμε χρόνο στον μηχανικό για να το κατανοήσουμε, να το αναπτύξουμε και να το διαχειριστούμε.)
Να επιλέξω Istio, Linkerd ή Consul Connect;
Μέχρι στιγμής έχουμε μιλήσει μόνο για το Istio, αλλά αυτό δεν είναι το μόνο service mesh. Δημοφιλής εναλλακτική - , και υπάρχουν περισσότερα .
Τι να επιλέξω;
Ειλικρινά, δεν ξέρω. Αυτή τη στιγμή δεν θεωρώ τον εαυτό μου αρκετά ικανό να απαντήσω σε αυτό το ερώτημα. Υπάρχουν λίγα με σύγκριση αυτών των εργαλείων και μάλιστα .
Μια πολλά υποσχόμενη προσέγγιση είναι να χρησιμοποιήσετε ένα εργαλείο όπως . Εφαρμόζει ένα επίπεδο αφαίρεσης για να απλοποιήσει και να ενοποιήσει τα API που εκτίθενται από πλέγματα υπηρεσιών. Αντί να μαθαίνουμε τα συγκεκριμένα (και, κατά τη γνώμη μου, σχετικά πολύπλοκα) API διαφορετικών δικτύων υπηρεσιών, μπορούμε να χρησιμοποιήσουμε τις απλούστερες κατασκευές του SuperGloo - και να αλλάξουμε εύκολα από το ένα στο άλλο, σαν να είχαμε μια ενδιάμεση μορφή διαμόρφωσης που περιγράφει τις διεπαφές HTTP και τα backends ικανά δημιουργίας της πραγματικής διαμόρφωσης για Nginx, HAProxy, Traefik, Apache...
Έχω ασχοληθεί λίγο με το Istio και το SuperGloo και στο επόμενο άρθρο θέλω να δείξω πώς μπορείτε να προσθέσετε το Istio ή το Linkerd σε ένα υπάρχον σύμπλεγμα χρησιμοποιώντας το SuperGloo και πώς το τελευταίο κάνει τη δουλειά, δηλαδή σας επιτρέπει να μεταβείτε από ένα πλέγμα υπηρεσίας στο άλλο χωρίς αντικατάσταση διαμορφώσεων.
Πηγή: www.habr.com