Σημείωση. μετάφρ.Ο συγγραφέας αυτού του άρθρου (Luc Perkins) είναι υποστηρικτής των προγραμματιστών στο CNCF, την έδρα έργων ανοιχτού κώδικα όπως το Linkerd, το SMI (Service Mesh Interface) και το Kuma (παρεμπιπτόντως, έχετε αναρωτηθεί ποτέ γιατί το Istio δεν βρίσκεται σε αυτήν τη λίστα;..). Σε μια άλλη προσπάθεια να κατανοήσει καλύτερα την μοντέρνα διαφημιστική εκστρατεία που ονομάζεται «service mesh» στην κοινότητα DevOps, απαριθμεί 16 τυπικές δυνατότητες που παρέχουν τέτοιες λύσεις.
Σήμερα ― ένα από τα πιο καυτά θέματα στη μηχανική λογισμικού (και δικαίως!). Νομίζω ότι αυτή η τεχνολογία είναι απίστευτα πολλά υποσχόμενη και ονειρεύομαι να τη δω να υιοθετείται ευρέως (όταν έχει νόημα, φυσικά). Ωστόσο, εξακολουθεί να περιβάλλεται από μια αύρα μυστηρίου για τους περισσότερους ανθρώπους. Επιπλέον, ακόμη και εκείνοι που Τον ξέρω καλά με αυτό, συχνά δυσκολεύονται να διατυπώσουν τα πλεονεκτήματά του και τι ακριβώς είναι (συμπεριλαμβανομένου του ταπεινού υπηρέτη σας). Σε αυτό το άρθρο θα προσπαθήσω να διορθώσω την κατάσταση απαριθμώντας διάφορες σενάρια χρήσης «πλέγματα υπηρεσιών»*.
* Σημείωση: μετάφραση: από εδώ και στο εξής στο άρθρο, αυτή η μετάφραση («service mesh») θα χρησιμοποιείται για τον ακόμη νέο όρο service mesh.
Αλλά πρώτα θέλω να κάνω μερικές παρατηρήσεις:
- Δεν έχω εργαστεί ποτέ με πλέγματα υπηρεσιών ούτε τα έχω χρησιμοποιήσει εκτός των έργων που έχω αναλάβει για τη δική μου εκπαίδευση. Από την άλλη πλευρά, έγραψα μια δέσμη τεκμηρίωσης για το εσωτερικό service mesh του Twitter το 2015 (δεν ονομαζόταν καν "service mesh" τότε) και συνέβαλα στον ιστότοπο και την τεκμηρίωση για , άρα σημαίνει κάτι.
- Η λίστα μου είναι κατά προσέγγιση και ελλιπής. Σίγουρα υπάρχουν περιπτώσεις χρήσης που δεν γνωρίζω και πιθανότατα θα εμφανιστούν νέες με την πάροδο του χρόνου καθώς η τεχνολογία εξελίσσεται και γίνεται πιο δημοφιλής.
- Ταυτόχρονα, δεν υποστηρίζουν όλες οι υπάρχουσες υλοποιήσεις πλέγματος υπηρεσιών όλες τις αναφερόμενες περιπτώσεις χρήσης. Έτσι, οι δηλώσεις μου όπως «το service mesh μπορεί...» θα πρέπει να ερμηνευθούν ως «ορισμένες, και πιθανώς όλες, οι δημοφιλείς υλοποιήσεις του service mesh μπορούν...».
- Η σειρά των παραδειγμάτων δεν έχει σημασία.
Σύντομη λίστα:
- ανακάλυψη υπηρεσίας;
- κρυπτογράφηση?
- έλεγχος ταυτότητας και εξουσιοδότηση·
- εξισορρόπηση φορτίου;
- διακοπή κυκλώματος;
- αυτόματη κλιμάκωση;
- αναπτύξεις καναρινιών;
- μπλε-πράσινες αναπτύξεις;
- έλεγχος υγείας·
- απόρριψη φορτίου;
- κατοπτρισμός κυκλοφορίας;
- μόνωση;
- περιορισμός ρυθμού αιτημάτων, επαναλήψεις και χρονικά όρια·
- τηλεμετρία;
- έλεγχος;
- οραματισμός.
1. Ανακάλυψη υπηρεσιών
TL;DR: Σύνδεση με άλλες υπηρεσίες στο δίκτυο χρησιμοποιώντας απλά ονόματα.
Οι υπηρεσίες θα πρέπει να είναι σε θέση να «βρίσκουν» αυτόματα η μία την άλλη χρησιμοποιώντας κατάλληλα ονόματα, όπως π.χ. service.api.production, pets/staging ή cassandra. Τα περιβάλλοντα cloud είναι ελαστικά και πολλαπλές παρουσίες υπηρεσιών μπορούν να κρυφτούν πίσω από ένα όνομα. Είναι σαφές ότι σε μια τέτοια περίπτωση είναι φυσικά αδύνατο να κωδικοποιηθούν όλες οι διευθύνσεις IP.
Επιπλέον, όταν μια υπηρεσία βρίσκει μια άλλη, θα πρέπει να είναι σε θέση να στέλνει αιτήματα σε αυτήν την υπηρεσία χωρίς φόβο ότι θα καταλήξουν στην είσοδο της νεκρής παρουσίας της. Με άλλα λόγια, το service mesh πρέπει να παρακολουθεί την εύρυθμη λειτουργία όλων των στιγμιότυπων της υπηρεσίας και να διατηρεί τη λίστα των κεντρικών υπολογιστών όσο το δυνατόν πιο ενημερωμένη.
Κάθε πλέγμα υπηρεσιών υλοποιεί τον μηχανισμό ανακάλυψης υπηρεσιών διαφορετικά. Προς το παρόν, ο πιο συνηθισμένος τρόπος είναι η ανάθεση σε εξωτερικές διεργασίες όπως το DNS Kubernetes. Στο παρελθόν, χρησιμοποιούσαμε ένα σύστημα ονομάτων στο Twitter για αυτόν τον σκοπό. . Επιπλέον, η τεχνολογία service mesh καθιστά δυνατή την εισαγωγή προσαρμοσμένων μηχανισμών ονομασίας (αν και δεν έχω συναντήσει ακόμη καμία υλοποίηση SM με τέτοια λειτουργικότητα).
2. Κρυπτογράφηση
ΣΥΓΚΕΚΡΙΜΕΝΟ: Απαλλαγείτε από την μη κρυπτογραφημένη κίνηση μεταξύ των υπηρεσιών και αυτοματοποιήστε και κλιμακώστε αυτήν τη διαδικασία.
Είναι ωραίο να γνωρίζεις ότι οι εισβολείς δεν μπορούν να εισέλθουν στο εσωτερικό σου δίκτυο. Τα τείχη προστασίας κάνουν εξαιρετική δουλειά σε αυτό. Τι γίνεται όμως αν ένας χάκερ μπει μέσα; Θα μπορεί να κάνει ό,τι θέλει με την ενδοϋπηρεσιακή κυκλοφορία; Ας ελπίσουμε ότι αυτό δεν θα συμβεί. Για να αποφευχθεί ένα τέτοιο σενάριο, θα πρέπει να εφαρμοστεί ένα δίκτυο μηδενικής εμπιστοσύνης, στο οποίο όλη η κίνηση μεταξύ των υπηρεσιών είναι κρυπτογραφημένη. Τα περισσότερα σύγχρονα δίκτυα υπηρεσιών το επιτυγχάνουν αυτό μέσω αμοιβαίας (αμοιβαία TLS, mTLS). Σε ορισμένες περιπτώσεις, το mTLS λειτουργεί σε ολόκληρα νέφη και σμήνη (νομίζω ότι οι διαπλανητικές επικοινωνίες κάποια μέρα θα οργανωθούν με παρόμοιο τρόπο).
Φυσικά, για το πλέγμα υπηρεσιών mTLS προαιρετικός. Κάθε υπηρεσία μπορεί να διαχειρίζεται το δικό της TLS, αλλά αυτό σημαίνει ότι θα είναι απαραίτητο να βρεθεί ένας τρόπος για τη δημιουργία πιστοποιητικών, τη διανομή τους σε όλους τους κεντρικούς υπολογιστές της υπηρεσίας και την συμπερίληψη κώδικα στην εφαρμογή που θα φορτώνει αυτά τα πιστοποιητικά από αρχεία. Ναι, και μην ξεχνάτε να ανανεώνετε αυτά τα πιστοποιητικά σε τακτά χρονικά διαστήματα. Τα πλέγματα υπηρεσιών αυτοματοποιούν το mTLS με συστήματα όπως , τα οποία, με τη σειρά τους, αυτοματοποιούν τη διαδικασία έκδοσης και εναλλαγής πιστοποιητικών.
3. Έλεγχος ταυτότητας και εξουσιοδότηση
TL;DR: Καθορίστε ποιος ξεκινά το αίτημα και ορίστε τι επιτρέπεται να κάνει πριν καν το αίτημα φτάσει στην υπηρεσία.
Οι υπηρεσίες συχνά θέλουν να γνωρίζουν, που υποβάλλει ένα αίτημα (έλεγχο ταυτότητας) και, χρησιμοποιώντας αυτές τις πληροφορίες, αποφασίζει ότι αυτό το θέμα επιτρέπεται να κάνει (εξουσιοδότηση). Σε αυτήν την περίπτωση, η αντωνυμία «ποιος» μπορεί να κρύβεται:
- Άλλες υπηρεσίες. Αυτό ονομάζεται «έλεγχος ταυτότητας» peer'a". Για παράδειγμα, η υπηρεσία
webθέλει να έχει πρόσβαση στην υπηρεσίαdb. Τα πλέγματα υπηρεσιών συνήθως επιλύουν αυτά τα είδη προβλημάτων χρησιμοποιώντας mTLS, με πιστοποιητικά που λειτουργούν ως το απαραίτητο αναγνωριστικό. - Μερικοί ανθρώπινοι χρήστες. Αυτό ονομάζεται «έλεγχος ταυτότητας» αιτήματα". Για παράδειγμα, ο χρήστης
haxor69θέλει να αγοράσει μια καινούργια λάμπα. Τα πλέγματα υπηρεσιών παρέχουν διάφορους μηχανισμούς, όπως: .Πολλοί από εμάς έπρεπε να το κάνουμε αυτό στον κώδικα της εφαρμογής μας. Έρχεται ένα αίτημα, κοιτάμε τον πίνακα
users, βρείτε τον χρήστη και συγκρίνετε τον κωδικό πρόσβασης και, στη συνέχεια, ελέγξτε τη στήληpermissionsκ.λπ. Στην περίπτωση ενός πλέγματος υπηρεσιών, αυτό συμβαίνει πριν καν το αίτημα φτάσει στην υπηρεσία.
Μόλις διαπιστώσουμε από ποιον προήλθε το αίτημα, πρέπει να προσδιορίσουμε τι επιτρέπεται να κάνει αυτό το υποκείμενο. Ορισμένα πλέγματα υπηρεσιών σάς επιτρέπουν να ορίσετε βασικές πολιτικές (σχετικά με το ποιος μπορεί να κάνει τι) ως αρχεία YAML ή στη γραμμή εντολών, ενώ άλλα προσφέρουν ενσωμάτωση με πλαίσια όπως . Ο τελικός στόχος είναι οι υπηρεσίες σας να δέχονται οποιοδήποτε αίτημα με την πεποίθηση ότι προέρχεται από αξιόπιστη πηγή. и Αυτή η ενέργεια επιτρέπεται.
4. Εξισορρόπηση φορτίου
TL;DR: Κατανομή φορτίου σε όλες τις παρουσίες υπηρεσίας σύμφωνα με ένα συγκεκριμένο μοτίβο.
Η λέξη «υπηρεσία» στην ενότητα «υπηρεσία» πολύ συχνά αποτελείται από πολλά πανομοιότυπα αντίγραφα. Για παράδειγμα, σήμερα η υπηρεσία cache αποτελείται από 5 αντίτυπα και αύριο ο αριθμός τους μπορεί να αυξηθεί σε 11. Αιτήματα που αποστέλλονται σε cache, πρέπει να διανέμεται σύμφωνα με έναν συγκεκριμένο σκοπό. Για παράδειγμα, για να ελαχιστοποιηθεί η καθυστέρηση ή να μεγιστοποιηθεί η πιθανότητα να φτάσει κανείς σε μια λειτουργική παρουσία. Ο πιο συχνά χρησιμοποιούμενος αλγόριθμος είναι ο αλγόριθμος Round-robin, αλλά υπάρχουν και πολλοί άλλοι, όπως η σταθμισμένη μέθοδος. (σταθμισμένο) ερωτήματα (μπορείτε να επιλέξετε προτιμώμενους στόχους), δακτύλιος (δαχτυλίδι) κατακερματισμός (χρήση συνεπούς κατακερματισμού για ανοδικούς κεντρικούς υπολογιστές) ή μέθοδος ελαχίστων ερωτημάτων (προτιμάται η παρουσία με τα λιγότερα ερωτήματα).
Τα κλασικά load balancers έχουν και άλλα χαρακτηριστικά, όπως HTTP caching και προστασία DDoS, αλλά δεν είναι πολύ σχετικά με την κυκλοφορία ανατολικά-δυτικά (η τυπική εφαρμογή ενός service mesh). Ενώ δεν είναι απαραίτητο να χρησιμοποιήσετε ένα service mesh για την εξισορρόπηση φορτίου, σας επιτρέπει να ορίσετε και να ελέγξετε πολιτικές εξισορρόπησης φορτίου για κάθε υπηρεσία από ένα κεντρικό επίπεδο ελέγχου, εξαλείφοντας έτσι την ανάγκη εκτέλεσης και ρύθμισης παραμέτρων μεμονωμένων load balancers στη στοίβα δικτύου.
5. Διακοπή κυκλώματος
TL;DR: Διακοπή της κυκλοφορίας προς την προβληματική υπηρεσία και έλεγχος της ζημιάς στα χειρότερα σενάρια.
Εάν για κάποιο λόγο η υπηρεσία δεν μπορεί να χειριστεί την κίνηση, το πλέγμα υπηρεσιών παρέχει αρκετές επιλογές για την επίλυση αυτού του προβλήματος (άλλες θα συζητηθούν στις σχετικές ενότητες). Η διακοπή κυκλώματος είναι η πιο σοβαρή επιλογή για την αποσύνδεση μιας υπηρεσίας από την κυκλοφορία. Ωστόσο, από μόνο του δεν έχει νόημα - χρειάζεται ένα εφεδρικό σχέδιο. Μπορεί να παρέχεται αντίθλιψη. () σε υπηρεσίες που υποβάλλουν αιτήματα (απλώς θυμηθείτε να ρυθμίσετε το πλέγμα υπηρεσιών σας για αυτό!), ή, για παράδειγμα, χρωματίζοντας τη σελίδα κατάστασης κόκκινη και ανακατευθύνοντας τους χρήστες στην επόμενη έκδοση της σελίδας με την «πτώση φάλαινας» («Το Twitter είναι εκτός λειτουργίας»).
Τα πλέγματα υπηρεσιών όχι μόνο σας επιτρέπουν να προσδιορίσετε, όπου θα ακολουθήσει διακοπή λειτουργίας και ότι αυτό θα ακολουθήσει. Σε αυτήν την περίπτωση, το "when" μπορεί να περιλαμβάνει οποιονδήποτε συνδυασμό καθορισμένων παραμέτρων: τον συνολικό αριθμό αιτημάτων για μια συγκεκριμένη περίοδο, τον αριθμό των παράλληλων συνδέσεων, τα εκκρεμή αιτήματα, τις ενεργές επαναλήψεις κ.λπ.
Πιθανότατα δεν θέλετε να κάνετε υπερβολική χρήση της διακοπής κυκλώματος, αλλά είναι ωραίο να γνωρίζετε ότι έχετε ένα εφεδρικό σχέδιο σε περίπτωση έκτακτης ανάγκης.
6. Αυτόματη κλιμάκωση
TL;DR: Αύξηση ή μείωση του αριθμού των παρουσιών υπηρεσίας με βάση καθορισμένα κριτήρια.
Τα service meshes δεν είναι χρονοπρογραμματιστές, επομένως δεν φέρει εις πέρας ανεξάρτητη κλιμάκωση. Ωστόσο, μπορούν να παρέχουν πληροφορίες σχετικά με το ποιοι σχεδιαστές μπορούν να λάβουν αποφάσεις. Δεδομένου ότι τα πλέγματα υπηρεσιών έχουν πρόσβαση σε όλη την κίνηση μεταξύ των υπηρεσιών, έχουν εκτενείς πληροφορίες σχετικά με το τι συμβαίνει: ποιες υπηρεσίες αντιμετωπίζουν προβλήματα, ποιες υποχρησιμοποιούνται (η κατανεμημένη χωρητικότητά τους σπαταλιέται) κ.λπ.
Για παράδειγμα, το Kubernetes κλιμακώνει τις υπηρεσίες με βάση τη χρήση της CPU και της μνήμης των pod. (Δείτε την έκθεσή μας)" — περίπου μετάφρ.), αλλά αν αποφασίσετε να κάνετε κλιμάκωση με βάση οποιαδήποτε άλλη μέτρηση (στην περίπτωσή μας, που σχετίζεται με την επισκεψιμότητα), θα χρειαστείτε μια ειδική μέτρηση. Διαχείριση δείχνει πώς να το κάνετε αυτό με , и , αλλά η ίδια η διαδικασία είναι αρκετά περίπλοκη. Θα θέλαμε το πλέγμα υπηρεσιών να απλοποιήσει αυτό, επιτρέποντάς μας να καθορίζουμε απλώς συνθήκες όπως "αύξηση του αριθμού των παρουσιών υπηρεσίας". auth, εάν ο αριθμός των αιτημάτων που αναμένουν να εκτελεστούν υπερβαίνει το όριο για ένα λεπτό.
7. Αναπτύξεις Canary
TL;DR: Δοκιμή νέων λειτουργιών ή εκδόσεων μιας υπηρεσίας σε ένα υποσύνολο χρηστών.
Ας υποθέσουμε ότι αναπτύσσετε ένα προϊόν SaaS και σχεδιάζετε να κυκλοφορήσετε μια νέα, ενδιαφέρουσα έκδοση του. Το δοκίμασες σε στάδιο προετοιμασίας και λειτούργησε άψογα. Ωστόσο, εξακολουθούν να υπάρχουν κάποιες ανησυχίες σχετικά με τη συμπεριφορά του στην πραγματική ζωή. Με άλλα λόγια, είναι απαραίτητο να δοκιμάσετε τη νέα έκδοση σε πραγματικές εργασίες χωρίς να διακινδυνεύσετε την εμπιστοσύνη των χρηστών. Οι αναπτύξεις Canary είναι ιδανικές για αυτό. Σας επιτρέπουν να παρουσιάσετε μια νέα λειτουργία σε ένα υποσύνολο χρηστών. Αυτό το υποσύνολο μπορεί να αποτελείται από τους πιο πιστούς χρήστες ή από εκείνους που χρησιμοποιούν τη δωρεάν έκδοση του προϊόντος ή από χρήστες που έχουν προσφερθεί εθελοντικά να γίνουν «πειραματόζωα».
Τα πλέγματα υπηρεσιών το επιτυγχάνουν αυτό επιτρέποντάς σας να καθορίσετε κριτήρια που καθορίζουν ποιος βλέπει ποια έκδοση μιας εφαρμογής και δρομολογώντας την κίνηση ανάλογα. Ταυτόχρονα, δεν αλλάζει τίποτα για τις ίδιες τις υπηρεσίες. Η έκδοση 1.0 της υπηρεσίας υποθέτει ότι όλα τα αιτήματα προέρχονται από χρήστες που θα έπρεπε να τη δουν και η έκδοση 1.1 υποθέτει το ίδιο για τους χρήστες της. Εν τω μεταξύ, μπορείτε να αλλάξετε το ποσοστό επισκεψιμότητας μεταξύ της παλιάς και της νέας έκδοσης, ανακατευθύνοντας έναν αυξανόμενο αριθμό χρηστών στη νέα έκδοση, εάν λειτουργεί σταθερά και τα «ινδικά χοιρίδια» σας δώσουν το πράσινο φως.
8. Μπλε-πράσινες αναπτύξεις
TL;DR: Παρουσιάστε μια ωραία νέα λειτουργία, αλλά να είστε έτοιμοι να την επαναφέρετε αμέσως.
Σημασία είναι η κυκλοφορία μιας νέας «μπλε» υπηρεσίας, παράλληλα με την παλιά, «πράσινη». Εάν όλα πάνε ομαλά και η νέα υπηρεσία αποδειχθεί καλή, τότε η παλιά μπορεί να απενεργοποιηθεί σταδιακά. (Δυστυχώς, κάποια μέρα αυτή η νέα «μπλε» υπηρεσία θα ακολουθήσει επίσης την τύχη της «πράσινης» και θα εξαφανιστεί...) Οι μπλε-πράσινες αναπτύξεις διαφέρουν από τις καναρίνι στο ότι η νέα δυνατότητα καλύπτει μεμιάς χρήστες (δεν αποτελούν μέρος)· Το θέμα εδώ είναι να έχετε ένα «εφεδρικό καταφύγιο» έτοιμο σε περίπτωση που κάτι πάει στραβά.
Τα service meshes προσφέρουν έναν πολύ βολικό τρόπο για να δοκιμάσετε μια "μπλε" υπηρεσία και να μεταβείτε άμεσα σε μια λειτουργική "πράσινη" σε περίπτωση προβλημάτων. Για να μην αναφέρουμε ότι παρέχουν επίσης πολλές πληροφορίες (βλ. την ενότητα «Τηλεμετρία» παρακάτω) σχετικά με τη λειτουργία του «μπλε», κάτι που βοηθά στην κατανόηση του κατά πόσον είναι έτοιμο για πλήρη λειτουργία.
Σημείωση. μετάφρ.Μπορείτε να διαβάσετε περισσότερα σχετικά με τις διαφορετικές στρατηγικές ανάπτυξης στο Kubernetes (συμπεριλαμβανομένων των προαναφερθέντων canary, blue/green και άλλων) στο .
9. Έλεγχος υγείας
TL;DR: Παρακολουθήστε ποιες παρουσίες υπηρεσίας είναι υγιείς και ανταποκριθείτε σε εκείνες που δεν είναι πλέον υγιείς.
Ελεγχος υγείας (έλεγχος υγείας) βοηθά να αποφασιστεί εάν οι παρουσίες υπηρεσίας είναι έτοιμες να λάβουν και να επεξεργαστούν κίνηση. Για παράδειγμα, στην περίπτωση των υπηρεσιών HTTP, ένας έλεγχος εύρυθμης λειτουργίας μπορεί να μοιάζει με ένα αίτημα GET σε ένα τελικό σημείο. /health. Απάντηση 200 OK θα σημαίνει ότι η παρουσία είναι εύρυθμη, οποιαδήποτε άλλη - ότι δεν είναι έτοιμη να λάβει επισκεψιμότητα. Τα πλέγματα υπηρεσιών σάς επιτρέπουν να καθορίσετε τόσο τον τρόπο με τον οποίο ελέγχεται η εύρυθμη λειτουργία όσο και τη συχνότητα με την οποία εκτελείται ο έλεγχος. Αυτές οι πληροφορίες μπορούν στη συνέχεια να χρησιμοποιηθούν για άλλους σκοπούς, όπως η εξισορρόπηση φορτίου και η διακοπή κυκλώματος.
Έτσι, ο έλεγχος υγείας δεν αποτελεί από μόνος του μια περίπτωση χρήσης, αλλά συνήθως χρησιμοποιείται για την επίτευξη άλλων στόχων. Επίσης, ανάλογα με τα αποτελέσματα των ελέγχων εύρυθμης λειτουργίας, ενδέχεται να απαιτούνται εξωτερικές ενέργειες (σε σχέση με άλλους στόχους πλέγματος υπηρεσιών): για παράδειγμα, ενημέρωση της σελίδας κατάστασης, δημιουργία προβλήματος στο GitHub ή συμπλήρωση ενός αιτήματος JIRA. Και το service mesh προσφέρει έναν βολικό μηχανισμό για την αυτοματοποίηση όλων αυτών.
10. Απόρριψη φορτίου
TL;DR: Αναδρομολόγηση κυκλοφορίας σε απόκριση σε μια προσωρινή αύξηση της χρήσης.
Εάν μια υπηρεσία είναι υπερφορτωμένη με κίνηση, μπορείτε προσωρινά να ανακατευθύνετε μέρος αυτής της κίνησης σε άλλη τοποθεσία (δηλαδή, να την "ρίξετε" ή να την "ρίξετε"). (υπόστεγο) αυτόν εκεί). Για παράδειγμα, σε μια υπηρεσία δημιουργίας αντιγράφων ασφαλείας ή σε ένα κέντρο δεδομένων ή σε ένα μόνιμο. θέμα. Ως αποτέλεσμα, η υπηρεσία θα συνεχίσει να επεξεργάζεται ορισμένα αιτήματα αντί να παρουσιάζει σφάλματα και να σταματά την επεξεργασία όλων. Η διακοπή φορτίου είναι προτιμότερη από τη διακοπή του κυκλώματος, αλλά δεν συνιστάται η υπερβολική χρήση του. Βοηθά στην αποτροπή διαδοχικών βλαβών που μπορούν να προκαλέσουν διακοπή λειτουργίας των υπηρεσιών downstream.
11. Παραλληλοποίηση/αντανάκλαση της κυκλοφορίας
TL;DR: Στείλτε ένα αίτημα σε πολλά μέρη ταυτόχρονα.
Μερικές φορές υπάρχει η ανάγκη να στείλετε ένα αίτημα (ή μια επιλογή αιτημάτων) σε πολλές υπηρεσίες ταυτόχρονα. Ένα τυπικό παράδειγμα είναι η αποστολή μέρους της κίνησης παραγωγής σε μια υπηρεσία προετοιμασίας (staging service). Ο κύριος διακομιστής ιστού παραγωγής στέλνει ένα αίτημα στην υπηρεσία downstream products.production και μόνο σε αυτόν. Και το πλέγμα υπηρεσιών αντιγράφει έξυπνα αυτό το αίτημα και το στέλνει σε products.staging, το οποίο ούτε καν γνωρίζει ο διακομιστής ιστού.
Μια άλλη σχετική περίπτωση χρήσης για το service mesh που μπορεί να υλοποιηθεί πάνω από την παραλληλοποίηση της κυκλοφορίας είναι . Περιλαμβάνει την αποστολή των ίδιων αιτημάτων σε διαφορετικές εκδόσεις της υπηρεσίας και τον έλεγχο του κατά πόσον όλες οι εκδόσεις συμπεριφέρονται με τον ίδιο τρόπο. Δεν έχω συναντήσει ακόμη μια υλοποίηση πλέγματος υπηρεσιών με ένα ενσωματωμένο σύστημα δοκιμών παλινδρόμησης όπως , αλλά η ίδια η ιδέα φαίνεται πολλά υποσχόμενη.
12. Μόνωση
TL;DR: Χωρίστε το πλέγμα υπηρεσιών σας σε μίνι δίκτυα.
Επίσης γνωστό ως κατάτμηση, η απομόνωση είναι η τέχνη της διαίρεσης ενός πλέγματος υπηρεσιών σε λογικά ξεχωριστά τμήματα που δεν γνωρίζουν τίποτα το ένα για το άλλο. Η απομόνωση μοιάζει λίγο με τη δημιουργία εικονικών ιδιωτικών δικτύων. Η βασική διαφορά είναι ότι μπορείτε ακόμα να απολαύσετε όλα τα οφέλη ενός πλέγματος υπηρεσιών (όπως η ανακάλυψη υπηρεσιών), αλλά με πρόσθετη ασφάλεια. Για παράδειγμα, εάν ένας εισβολέας καταφέρει να διεισδύσει σε μια υπηρεσία σε ένα από τα υποδίκτυα, δεν θα μπορεί να δει ποιες υπηρεσίες εκτελούνται σε άλλα υποδίκτυα ή να υποκλέψει την κυκλοφορία τους.
Επιπλέον, τα οφέλη μπορεί να είναι και οργανωτικά. Ίσως θελήσετε να χωρίσετε τις υπηρεσίες σε υποδίκτυα με βάση τη δομή της εταιρείας σας και να απαλλάξετε τους προγραμματιστές από το γνωστικό φορτίο που συνεπάγεται η υποχρέωση να έχουν κατά νου ολόκληρο το πλέγμα υπηρεσιών.
13. Περιορισμός ρυθμού αιτημάτων, επαναλήψεις και χρονικά όρια
TL;DR: Δεν χρειάζεται πλέον να συμπεριλαμβάνετε χρονοβόρες εργασίες διαχείρισης αιτημάτων στη βάση κώδικα σας.
Όλα αυτά θα μπορούσαν να θεωρηθούν ξεχωριστές περιπτώσεις χρήσης, αλλά αποφάσισα να τα ομαδοποιήσω λόγω ενός κοινού χαρακτηριστικού: απαλλάσσουν από τον φόρτο εργασίας διαχείρισης κύκλου ζωής αιτημάτων που συνήθως χειρίζονται οι βιβλιοθήκες εφαρμογών. Εάν αναπτύσσετε έναν διακομιστή ιστού Ruby on Rails (μη ενσωματωμένο με το service mesh) που υποβάλλει αιτήματα σε υπηρεσίες backend μέσω , η εφαρμογή θα πρέπει να αποφασίσει μόνη της τι θα κάνει εάν αποτύχουν N αιτήματα. Θα πρέπει επίσης να υπολογίσετε τον όγκο κίνησης που μπορούν να χειριστούν αυτές οι υπηρεσίες και να κωδικοποιήσετε αυτές τις παραμέτρους χρησιμοποιώντας μια ειδική βιβλιοθήκη. Επιπλέον, η εφαρμογή θα πρέπει να αποφασίσει πότε θα τα παρατήσει και θα αφήσει το αίτημα να πάει χαμένο (χρονικό όριο). Και για να αλλάξετε οποιαδήποτε από τις παραπάνω παραμέτρους, ο διακομιστής ιστού θα πρέπει να σταματήσει, να επαναρυθμιστεί και να επανεκκινηθεί.
Η ανάθεση αυτών των ανησυχιών στο service mesh όχι μόνο σημαίνει ότι οι προγραμματιστές υπηρεσιών δεν χρειάζεται να τις σκέφτονται, αλλά ότι μπορούν να τις αντιμετωπιστούν με έναν πιο σφαιρικό τρόπο. Αν έχετε μια σύνθετη αλυσίδα υπηρεσιών, ας πούμε A –> B –> C –> D –> E, πρέπει να λάβετε υπόψη ολόκληρο τον κύκλο ζωής του αιτήματος. Εάν η εργασία είναι η παράταση των χρονικών ορίων στην υπηρεσία C, είναι λογικό να γίνει αυτό ταυτόχρονα, αντί για τμήματα: ενημερώνοντας τον κώδικα υπηρεσίας και περιμένοντας μέχρι να γίνει δεκτό το αίτημα έλξης και το σύστημα CI να αναπτύξει την ενημερωμένη υπηρεσία.
14. Τηλεμετρία
TL;DR: Συλλέξτε όλες τις απαραίτητες (και όχι εντελώς απαραίτητες) πληροφορίες από τις υπηρεσίες.
Η τηλεμετρία είναι ένας γενικός όρος που περιλαμβάνει μετρήσεις, κατανεμημένη ιχνηλάτηση και καταγραφή. Τα πλέγματα υπηρεσιών παρέχουν μηχανισμούς για τη συλλογή και επεξεργασία και των τριών τύπων δεδομένων. Εδώ είναι που τα πράγματα γίνονται λίγο ασαφή, καθώς ο αριθμός των πιθανών επιλογών είναι πολύ μεγάλος. Υπάρχει ένα εργαλείο συλλογής μετρήσεων και άλλα εργαλεία που μπορούν να χρησιμοποιηθούν για τη συλλογή αρχείων καταγραφής , , κλπ. (για παράδειγμα, ClickHouse με το δικό μας για K8s - περίπου. μετάφραση), για την κατανεμημένη ιχνηλάτηση υπάρχει κ.λπ. Κάθε πλέγμα υπηρεσιών μπορεί να υποστηρίζει ορισμένα εργαλεία και άλλα όχι. Θα είναι ενδιαφέρον να δούμε αν το έργο θα μπορέσει παρέχουν κάποια σύγκλιση.
Σε αυτήν την περίπτωση, το πλεονέκτημα της τεχνολογίας πλέγματος υπηρεσιών είναι ότι τα κοντέινερ με πλευρικά οχήματά τους μπορούν, κατ' αρχήν, να συλλέξουν όλα τα παραπάνω δεδομένα από τις υπηρεσίες τους. Με άλλα λόγια, έχετε στη διάθεσή σας ένα ενιαίο σύστημα συλλογής τηλεμετρικών δεδομένων και το service mesh μπορεί να επεξεργαστεί όλες αυτές τις πληροφορίες με ποικίλους τρόπους. Για παράδειγμα:
- αρχεία καταγραφής ουράς από μια συγκεκριμένη υπηρεσία στο CLI.
- παρακολούθηση του όγκου αιτημάτων από τον πίνακα ελέγχου πλέγματος υπηρεσιών·
- συλλέγουν κατανεμημένα ίχνη και τα προωθούν σε ένα σύστημα όπως το Jaeger.
Προσοχή, υποκειμενική κρίση: Γενικά, η τηλεμετρία είναι ένας τομέας όπου η ισχυρή παρέμβαση του πλέγματος υπηρεσιών είναι ανεπιθύμητη. Η συλλογή βασικών πληροφοριών και η παρακολούθηση ορισμένων «χρυσών μετρήσεων» όπως το ποσοστό επιτυχίας και η καθυστέρηση εν κινήσει είναι μια χαρά, αλλά ας ελπίσουμε ότι δεν θα δούμε να εμφανίζονται στοίβες Φρανκενστάιν που θα προσπαθούν να αντικαταστήσουν εξειδικευμένα συστήματα, μερικά από τα οποία είναι ήδη καθιερωμένα και κατανοητά.
15. Έλεγχος
TL;DR: Όσοι ξεχνούν τα μαθήματα της ιστορίας είναι καταδικασμένοι να τα επαναλάβουν.
Ο έλεγχος είναι η τέχνη της παρατήρησης σημαντικών γεγονότων σε ένα σύστημα. Στην περίπτωση ενός πλέγματος υπηρεσιών, αυτό μπορεί να σημαίνει παρακολούθηση του ποιος υπέβαλε αιτήματα σε συγκεκριμένα τελικά σημεία συγκεκριμένων υπηρεσιών ή πόσες φορές συνέβη ένα συγκεκριμένο συμβάν που σχετίζεται με την ασφάλεια τον τελευταίο μήνα.
Είναι σαφές ότι η ελεγκτική είναι πολύ στενά συνδεδεμένη με την τηλεμετρία. Η διαφορά είναι ότι η τηλεμετρία συνήθως σχετίζεται με πράγματα όπως η απόδοση και η τεχνική καταλληλότητα, ενώ ο έλεγχος μπορεί να σχετίζεται με νομικά και άλλα ζητήματα πέρα από το αυστηρά τεχνικό πεδίο (π.χ. συμμόρφωση με τον GDPR).
16. Οπτικοποίηση
TL;DR: Ζήτω το React.js, η πηγή των παράξενων διεπαφών.
Μπορεί να υπάρχει πιο κατάλληλος όρος, αλλά δεν τον γνωρίζω. Εννοώ απλώς μια γραφική αναπαράσταση του πλέγματος υπηρεσιών ή ορισμένων από τα στοιχεία του. Αυτές οι απεικονίσεις μπορούν να περιλαμβάνουν δείκτες όπως μέσους χρόνους καθυστέρησης, πληροφορίες διαμόρφωσης κοντέινερ sidecar, αποτελέσματα ελέγχου εύρυθμης λειτουργίας και ειδοποιήσεις.
Η εργασία σε ένα περιβάλλον προσανατολισμένο στην παροχή υπηρεσιών συνεπάγεται πολύ υψηλότερο γνωστικό φορτίο από την εργασία σε ένα περιβάλλον προσανατολισμένο στην παροχή υπηρεσιών. Επομένως, η γνωστική πίεση θα πρέπει να μειωθεί πάση θυσία. Μια απλή γραφική διεπαφή για το service mesh, με τη δυνατότητα να κάνετε κλικ σε ένα κουμπί και να λάβετε το επιθυμητό αποτέλεσμα, θα μπορούσε να είναι κρίσιμη για την ανάπτυξη αυτής της τεχνολογίας.
Δεν συμπεριλήφθηκαν στη λίστα
Αρχικά σκόπευα να συμπεριλάβω μερικές ακόμη περιπτώσεις χρήσης στη λίστα, αλλά στη συνέχεια αποφάσισα να μην το κάνω. Εδώ είναι, μαζί με τους λόγους της απόφασής μου:
- Κέντρο πολλαπλών δεδομένων. Κατά τη γνώμη μου, αυτό δεν είναι τόσο μια περίπτωση χρήσης όσο μια στενή και συγκεκριμένη εφαρμογή των πλεγμάτων υπηρεσιών ή κάποιου συνόλου χαρακτηριστικών όπως η ανακάλυψη υπηρεσιών.
- Είσοδος και έξοδος. Αυτή είναι μια σχετική περιοχή, αλλά έχω περιοριστεί (ίσως τεχνητά) στην περίπτωση χρήσης της «κυκλοφορίας ανατολής-δύσης». Η είσοδος και η έξοδος αξίζουν ξεχωριστό άρθρο.
Συμπέρασμα
Αυτά προς το παρόν! Και πάλι, αυτή η λίστα είναι πολύ υπό όρους και πιθανότατα ελλιπής. Αν νομίζετε ότι έχω παραλείψει κάτι ή έχω κάνει κάποιο λάθος, επικοινωνήστε μαζί μου στο Twitter (). Παρακαλώ να τηρείτε τους κανόνες ευπρέπειας.
ΥΓ από τον μεταφραστή
Η κύρια εικονογράφηση για το άρθρο βασίζεται σε μια εικόνα από το άρθρο «"(από τον Gregory MacKinnon). Δείχνει πώς ορισμένες από τις λειτουργίες από τις εφαρμογές (με πράσινο) έχουν μετακινηθεί στο πλέγμα υπηρεσιών που παρέχει τις συνδέσεις μεταξύ τους (με μπλε).
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «».
Πηγή: www.habr.com
