19 Σεπτεμβρίου στη Μόσχα η πρώτη θεματική συνάντηση HUG (Highload++ User Group), η οποία ήταν αφιερωμένη στις μικροϋπηρεσίες. Πραγματοποιήθηκε μια παρουσίαση «Operating Microservices: Size Matters, Even If You Have Kubernetes», στην οποία μοιραστήκαμε την εκτενή εμπειρία του Flant στη λειτουργία έργων με αρχιτεκτονική microservice. Πρώτα απ 'όλα, θα είναι χρήσιμο σε όλους τους προγραμματιστές που σκέφτονται να χρησιμοποιήσουν αυτήν την προσέγγιση στο τρέχον ή μελλοντικό τους έργο.
Παρουσιάζοντας (50 λεπτά, πολύ πιο κατατοπιστικό από το άρθρο), καθώς και το κύριο απόσπασμα από αυτό σε μορφή κειμένου.
Σημείωση: Το βίντεο και η παρουσίαση είναι επίσης διαθέσιμα στο τέλος αυτής της ανάρτησης.
Εισαγωγή
Συνήθως μια καλή ιστορία έχει αρχή, κύρια πλοκή και λύση. Αυτή η έκθεση μοιάζει περισσότερο με προοίμιο, και μάλιστα τραγική. Είναι επίσης σημαντικό να σημειωθεί ότι παρέχει μια εξωτερική άποψη για τις μικροϋπηρεσίες. εκμετάλλευση.
Θα ξεκινήσω με αυτό το γράφημα, ο συγγραφέας του οποίου (το 2015) Μάρτιν Φάουλερ:
Δείχνει πώς, στην περίπτωση μιας μονολιθικής εφαρμογής που φτάνει σε μια συγκεκριμένη τιμή, η παραγωγικότητα αρχίζει να μειώνεται. Οι μικροϋπηρεσίες διαφέρουν ως προς το ότι η αρχική παραγωγικότητα με αυτές είναι χαμηλότερη, αλλά όσο αυξάνεται η πολυπλοκότητα, η υποβάθμιση της αποτελεσματικότητας δεν είναι τόσο αισθητή για αυτές.
Θα προσθέσω σε αυτό το γράφημα για την περίπτωση χρήσης Kubernetes:
Γιατί είναι καλύτερη μια εφαρμογή με microservices; Γιατί μια τέτοια αρχιτεκτονική προβάλλει σοβαρές απαιτήσεις για την αρχιτεκτονική, οι οποίες με τη σειρά τους καλύπτονται τέλεια από τις δυνατότητες του Kubernetes. Από την άλλη πλευρά, ορισμένες από αυτές τις λειτουργίες θα είναι χρήσιμες για ένα μονόλιθο, ειδικά επειδή ο τυπικός μονόλιθος σήμερα δεν είναι ακριβώς μονόλιθος (λεπτομέρειες θα δοθούν αργότερα στην αναφορά).
Όπως μπορείτε να δείτε, το τελικό γράφημα (όταν τόσο οι μονολιθικές όσο και οι εφαρμογές μικροϋπηρεσιών βρίσκονται στην υποδομή με το Kubernetes) δεν διαφέρει πολύ από το αρχικό. Στη συνέχεια θα μιλήσουμε για εφαρμογές που λειτουργούν χρησιμοποιώντας Kubernetes.
Χρήσιμες και επιβλαβείς μικροϋπηρεσίες
Και εδώ είναι η κύρια ιδέα:
τι είναι κανονικός αρχιτεκτονική μικροϋπηρεσιών; Θα πρέπει να σας αποφέρει πραγματικά οφέλη, αυξάνοντας την αποτελεσματικότητα της εργασίας σας. Αν επιστρέψουμε στο γράφημα, εδώ είναι:
Αν της τηλεφωνήσεις χρήσιμος, τότε στην άλλη πλευρά του γραφήματος θα υπάρχει επιβλαβής μικροϋπηρεσίες (παρεμβαίνει στην εργασία):
Επιστρέφοντας στην «κύρια ιδέα»: πρέπει να εμπιστευτώ καθόλου την εμπειρία μου; Από την αρχή του τρέχοντος έτους έχω ψάξει 85 έργα. Δεν ήταν όλες μικροϋπηρεσίες (περίπου το ένα τρίτο με τα μισά από αυτά είχαν τέτοια αρχιτεκτονική), αλλά εξακολουθεί να είναι ένας μεγάλος αριθμός. Εμείς (η εταιρεία Flant) ως outsourcers καταφέρνουμε να δούμε μια μεγάλη ποικιλία εφαρμογών που αναπτύσσονται τόσο σε μικρές εταιρείες (με 5 προγραμματιστές) όσο και σε μεγάλες (~500 προγραμματιστές). Ένα πρόσθετο πλεονέκτημα είναι ότι βλέπουμε αυτές τις εφαρμογές να ζουν και να εξελίσσονται με τα χρόνια.
Γιατί μικροϋπηρεσίες;
Στην ερώτηση σχετικά με τα οφέλη των μικροϋπηρεσιών υπάρχει από τον ήδη αναφερόμενο Μάρτιν Φάουλερ:
- σαφή όρια αρθρωτότητας.
- ανεξάρτητη ανάπτυξη·
- ελευθερία επιλογής τεχνολογιών.
Έχω μιλήσει πολύ με αρχιτέκτονες λογισμικού και προγραμματιστές και ρώτησα γιατί χρειάζονται μικροϋπηρεσίες. Και έφτιαξα τη λίστα με τις προσδοκίες τους. Να τι συνέβη:
Αν περιγράψουμε μερικά από τα σημεία «σε αισθήσεις», τότε:
- ξεκάθαρα όρια μονάδων: εδώ έχουμε έναν τρομερό μονόλιθο και τώρα όλα θα είναι τακτοποιημένα στα αποθετήρια Git, στα οποία όλα είναι "στα ράφια", το ζεστό και το απαλό δεν αναμειγνύονται.
- ανεξαρτησία ανάπτυξης: θα είμαστε σε θέση να αναπτύξουμε υπηρεσίες ανεξάρτητα, έτσι ώστε η ανάπτυξη να πηγαίνει πιο γρήγορα (παράλληλη δημοσίευση νέων λειτουργιών).
- αναπτυξιακή ανεξαρτησία: μπορούμε να προσφέρουμε αυτή τη μικρουπηρεσία σε μια ομάδα/προγραμματιστή και αυτή σε μια άλλη, χάρη στην οποία μπορούμε να αναπτυχθούμε πιο γρήγορα.
- боμεγαλύτερη αξιοπιστία: εάν συμβεί μερική υποβάθμιση (μία microservice στις 20 πέσει), τότε μόνο ένα κουμπί θα σταματήσει να λειτουργεί και το σύστημα ως σύνολο θα συνεχίσει να λειτουργεί.
Τυπική (επιβλαβής) αρχιτεκτονική μικροϋπηρεσιών
Για να εξηγήσω γιατί η πραγματικότητα δεν είναι αυτή που περιμένουμε, θα παρουσιάσω συλλογικός μια εικόνα μιας αρχιτεκτονικής microservice που βασίζεται στην εμπειρία από πολλά διαφορετικά έργα.
Ένα παράδειγμα θα ήταν ένα αφηρημένο ηλεκτρονικό κατάστημα που πρόκειται να ανταγωνιστεί την Amazon ή τουλάχιστον το OZON. Η αρχιτεκτονική του microservice μοιάζει με αυτό:
Για έναν συνδυασμό λόγων, αυτές οι μικροϋπηρεσίες είναι γραμμένες σε διαφορετικές πλατφόρμες:
Δεδομένου ότι κάθε microservice πρέπει να έχει αυτονομία, πολλές από αυτές χρειάζονται τη δική τους βάση δεδομένων και cache. Η τελική αρχιτεκτονική έχει ως εξής:
Ποιες είναι οι συνέπειές του;
Ο Φάουλερ το έχει και αυτό — σχετικά με την «πληρωμή» για τη χρήση μικροϋπηρεσιών:
Και θα δούμε αν ικανοποιήθηκαν οι προσδοκίες μας.
Ξεκαθαρίστε τα όρια των ενοτήτων...
Αλλά Πόσες μικροϋπηρεσίες χρειαζόμαστε πραγματικά να διορθώσουμε;να κυκλοφορήσει η αλλαγή; Μπορούμε να καταλάβουμε πώς λειτουργούν όλα χωρίς κατανεμημένο ιχνηθέτη (εξάλλου, οποιοδήποτε αίτημα επεξεργάζεται από τις μισές μικροϋπηρεσίες);
Υπάρχει ένα μοτίβο"», και εδώ αποδείχθηκε ότι ήταν ένα κατανεμημένο κομμάτι βρωμιάς. Για να επιβεβαιωθεί αυτό, ακολουθεί μια κατά προσέγγιση απεικόνιση του τρόπου με τον οποίο προχωρούν τα αιτήματα:
Ανεξαρτησία ανάπτυξης...
Τεχνικά, έχει επιτευχθεί: μπορούμε να αναπτύξουμε κάθε microservice ξεχωριστά. Αλλά στην πράξη πρέπει να λάβετε υπόψη ότι πάντα κυκλοφορεί πολλές μικροϋπηρεσίες, και πρέπει να λάβουμε υπόψη τη σειρά διάδοσής τους. Με την καλή έννοια, γενικά πρέπει να δοκιμάσουμε σε ένα ξεχωριστό κύκλωμα εάν ανοίγουμε την απελευθέρωση με τη σωστή σειρά.
Ελευθερία επιλογής τεχνολογίας...
Αυτή είναι. Απλά θυμηθείτε ότι η ελευθερία συχνά συνορεύει με την ανομία. Είναι πολύ σημαντικό εδώ να μην επιλέγουμε τεχνολογίες απλώς για να «παίξουμε» μαζί τους.
Ανεξαρτησία ανάπτυξης...
Πώς να δημιουργήσετε ένα δοκιμαστικό βρόχο για ολόκληρη την εφαρμογή (με τόσα πολλά στοιχεία); Πρέπει όμως να το διατηρείτε ενημερωμένο. Όλα αυτά οδηγούν στο γεγονός ότι πραγματικός αριθμός κυκλωμάτων δοκιμής, το οποίο μπορούμε καταρχήν να περιλάβουμε, αποδεικνύεται ελάχιστο.
Τι θα λέγατε να τα αναπτύξετε όλα αυτά τοπικά;... Αποδεικνύεται ότι συχνά ο προγραμματιστής κάνει τη δουλειά του ανεξάρτητα, αλλά «τυχαία», επειδή αναγκάζεται να περιμένει μέχρι να ελευθερωθεί το κύκλωμα για δοκιμή.
Ξεχωριστή κλιμάκωση...
Ναι, αλλά περιορίζεται στην περιοχή του DBMS που χρησιμοποιείται. Στο συγκεκριμένο παράδειγμα αρχιτεκτονικής, η Cassandra δεν θα έχει προβλήματα, αλλά η MySQL και η PostgreSQL.
Боμεγαλύτερη αξιοπιστία...
Όχι μόνο η αποτυχία μιας μικρουπηρεσίας στην πραγματικότητα συχνά σπάει τη σωστή λειτουργία ολόκληρου του συστήματος, αλλά υπάρχει επίσης ένα νέο πρόβλημα: Το να κάνεις κάθε microservice ανεκτική σε σφάλματα είναι πολύ δύσκολο. Επειδή οι μικροϋπηρεσίες χρησιμοποιούν διαφορετικές τεχνολογίες (memcache, Redis κ.λπ.), για καθεμία πρέπει να σκεφτείτε τα πάντα και να τα εφαρμόσετε, κάτι που, φυσικά, είναι δυνατό, αλλά απαιτεί τεράστιους πόρους.
Δυνατότητα μέτρησης φορτίου...
Αυτό είναι πραγματικά καλό.
Η «ελαφρότητα» των μικροϋπηρεσιών...
Δεν έχουμε μόνο τεράστια γενικά έξοδα δικτύου (πολλαπλασιάζονται τα αιτήματα για DNS κ.λπ.), αλλά και λόγω των πολλών υποερωτημάτων που ξεκινήσαμε αντιγραφή δεδομένων (κρυφές μνήμες καταστημάτων), γεγονός που οδήγησε σε σημαντικό χώρο αποθήκευσης.
Και εδώ είναι το αποτέλεσμα της ικανοποίησης των προσδοκιών μας:
Αλλά δεν είναι μόνο αυτό!
Επειδή:
- Το πιθανότερο είναι να χρειαστούμε ένα λεωφορείο μηνυμάτων.
- Πώς να δημιουργήσετε ένα συνεπές αντίγραφο ασφαλείας την κατάλληλη στιγμή; Ο μοναδικός реальный επιλογή είναι να απενεργοποιήσετε την κυκλοφορία για αυτό. Αλλά πώς να το κάνουμε αυτό στην παραγωγή;
- Εάν μιλάμε για υποστήριξη πολλών περιοχών, τότε η οργάνωση της βιωσιμότητας σε καθεμία από αυτές είναι ένα έργο που απαιτεί μεγάλη ένταση εργασίας.
- Ανακύπτει το πρόβλημα της πραγματοποίησης κεντρικών αλλαγών. Για παράδειγμα, αν χρειαστεί να ενημερώσουμε την έκδοση της PHP, θα χρειαστεί να δεσμευτούμε σε κάθε αποθετήριο (και υπάρχουν δεκάδες από αυτά).
- Η αύξηση της λειτουργικής πολυπλοκότητας είναι, απροσδόκητα, εκθετική.
Τι να τα κάνεις όλα αυτά;
Ξεκινήστε με μια μονολιθική εφαρμογή. Η εμπειρία του Φάουλερ ότι σχεδόν όλες οι επιτυχημένες εφαρμογές microservice ξεκίνησαν ως μονόλιθος που έγινε πολύ μεγάλος και στη συνέχεια έσπασε. Ταυτόχρονα, σχεδόν όλα τα συστήματα που κατασκευάστηκαν ως microservices από την αρχή, αργά ή γρήγορα αντιμετώπισαν σοβαρά προβλήματα.
Μια άλλη πολύτιμη σκέψη είναι ότι για να είναι επιτυχημένο ένα έργο με αρχιτεκτονική microservice, πρέπει να γνωρίζεις πολύ καλά και θεματική περιοχή, και πώς να δημιουργήσετε μικροϋπηρεσίες. Και ο καλύτερος τρόπος για να μάθετε μια θεματική περιοχή είναι να φτιάξετε ένα μονόπετρο.
Τι γίνεται όμως αν βρισκόμαστε ήδη σε αυτήν την κατάσταση;
Το πρώτο βήμα για την επίλυση οποιουδήποτε προβλήματος είναι να συμφωνήσουμε μαζί του και να κατανοήσουμε ότι είναι ένα πρόβλημα, που δεν θέλουμε να υποφέρουμε άλλο.
Εάν, στην περίπτωση ενός κατάφυτου μονόλιθου (όταν έχουμε εξαντλήσει την ευκαιρία να αγοράσουμε πρόσθετους πόρους για αυτό), το κόψουμε, τότε στην περίπτωση αυτή αποδεικνύεται η αντίθετη ιστορία: όταν οι υπερβολικές μικροϋπηρεσίες δεν βοηθούν πλέον, αλλά εμποδίζουν - κόβουμε την περίσσεια και μεγεθύνουμε!
Για παράδειγμα, για τη συλλογική εικόνα που συζητήθηκε παραπάνω...
Απαλλαγείτε από τις πιο αμφισβητήσιμες μικροϋπηρεσίες:
Συνδυάστε όλες τις μικροϋπηρεσίες που είναι υπεύθυνες για τη δημιουργία frontend:
... σε μία microservice, γραμμένη σε μία (σύγχρονη και κανονική, όπως νομίζετε εσείς) γλώσσα/πλαίσιο:
Θα έχει ένα ORM (ένα DBMS) και πρώτα μερικές εφαρμογές:
... αλλά σε γενικές γραμμές μπορείτε να μεταφέρετε πολλά περισσότερα εκεί, παίρνοντας το εξής αποτέλεσμα:
Επιπλέον, στο Kubernetes τα τρέχουμε όλα αυτά σε ξεχωριστές περιπτώσεις, πράγμα που σημαίνει ότι μπορούμε ακόμα να μετρήσουμε το φορτίο και να το κλιμακώσουμε ξεχωριστά.
Συνοψίζοντας
Κοιτάξτε τη μεγαλύτερη εικόνα. Πολύ συχνά, όλα αυτά τα προβλήματα με τις μικροϋπηρεσίες προκύπτουν επειδή κάποιος ανέλαβε την αποστολή του, αλλά ήθελε να «παίξει με τις μικροϋπηρεσίες».
Στη λέξη "microservices" το "micro" μέρος είναι περιττό.. Είναι "micro" μόνο επειδή είναι μικρότεροι από έναν τεράστιο μονόλιθο. Αλλά μην τα θεωρείτε κάτι μικρό.
Και για μια τελευταία σκέψη, ας επιστρέψουμε στο αρχικό διάγραμμα:
Ένα σημείωμα γραμμένο πάνω του (επάνω δεξιά) συνοψίζεται στο γεγονός ότι οι δεξιότητες της ομάδας που κάνει το έργο σας είναι πάντα πρωταρχικές — θα παίξουν βασικό ρόλο στην επιλογή σας μεταξύ microservices και monolith. Αν η ομάδα δεν έχει αρκετές δεξιότητες, αλλά αρχίσει να κάνει μικροϋπηρεσίες, η ιστορία θα είναι σίγουρα μοιραία.
Βίντεο και διαφάνειες
Βίντεο από την ομιλία (~50 λεπτά, δυστυχώς, δεν μεταφέρει τα πολυάριθμα συναισθήματα των επισκεπτών, τα οποία καθόρισαν σε μεγάλο βαθμό τη διάθεση του ρεπορτάζ, αλλά έτσι είναι):
Παρουσίαση της έκθεσης:
PS
Άλλες αναφορές στο ιστολόγιό μας:
- «» (Dmitry Stolyarov; 28 Μαΐου 2018 στο RootConf);
- «» (Dmitry Stolyarov, 7 Νοεμβρίου 2017 στο HighLoad++);
- «» (Dmitry Stolyarov, 6 Ιουνίου 2017 στο RootConf);
- «» (Dmitry Stolyarov, 8 Νοεμβρίου 2016 στο HighLoad++);
- «» (Dmitry Stolyarov; 31 Μαΐου 2016 στο RootConf).
Μπορεί επίσης να σας ενδιαφέρουν οι ακόλουθες δημοσιεύσεις:
- «"?
- «"?
- «».
Πηγή: www.habr.com