Ο Τζος Έβανς μιλά για τον χαοτικό και πολύχρωμο κόσμο των μικροϋπηρεσιών Netflix, ξεκινώντας από τα πολύ βασικά - την ανατομία των μικροϋπηρεσιών, τις προκλήσεις που σχετίζονται με τα κατανεμημένα συστήματα και τα οφέλη τους. Χτίζοντας πάνω σε αυτό το θεμέλιο, διερευνά τις πολιτιστικές, αρχιτεκτονικές και λειτουργικές πρακτικές που οδηγούν στην κυριαρχία των μικροϋπηρεσιών.
Σε αντίθεση με την επιχειρησιακή μετατόπιση, η εισαγωγή νέων γλωσσών για τη διεθνοποίηση των υπηρεσιών και οι νέες τεχνολογίες όπως τα κοντέινερ είναι συνειδητές αποφάσεις για να προσθέσουν νέα πολυπλοκότητα στο περιβάλλον. Η ομάδα λειτουργιών μου τυποποιήθηκε στον καλύτερο τεχνολογικό οδικό χάρτη για το Netflix, ο οποίος διαμορφώθηκε σε προκαθορισμένες βέλτιστες πρακτικές με βάση την Java και το EC2, αλλά καθώς η επιχείρηση μεγάλωνε, οι προγραμματιστές άρχισαν να προσθέτουν νέα στοιχεία όπως Python, Ruby, Node-JS και Docker.
Είμαι πολύ περήφανος που ήμασταν οι πρώτοι που υποστηρίξαμε το προϊόν μας να λειτουργεί τέλεια χωρίς να περιμένουμε παράπονα πελατών. Όλα ξεκίνησαν αρκετά απλά - είχαμε προγράμματα λειτουργίας σε Python και μερικές εφαρμογές back-office στο Ruby, αλλά τα πράγματα έγιναν πολύ πιο ενδιαφέροντα όταν οι προγραμματιστές ιστού μας ανακοίνωσαν ότι επρόκειτο να εγκαταλείψουν το JVM και ότι επρόκειτο να μετακινήσουν τον ιστό εφαρμογή στην πλατφόρμα λογισμικού Node.js. Μετά την εισαγωγή του Docker, τα πράγματα έγιναν πολύ πιο περίπλοκα. Ακολουθήσαμε τη λογική και οι τεχνολογίες που καταλήξαμε έγιναν πραγματικότητα όταν τις εφαρμόσαμε για πελάτες γιατί είχαν πολύ νόημα. Θα σας πω γιατί είναι έτσι.
Το API Gateway έχει στην πραγματικότητα τη δυνατότητα να ενσωματώνει εξαιρετικά σενάρια που μπορούν να λειτουργήσουν ως τελικά σημεία για προγραμματιστές διεπαφής χρήστη. Μετέτρεψαν καθένα από αυτά τα σενάρια με τέτοιο τρόπο ώστε μετά την πραγματοποίηση αλλαγών να μπορούν να τα αναπτύξουν στην παραγωγή και στη συνέχεια στις συσκευές των χρηστών, και όλες αυτές οι αλλαγές συγχρονίστηκαν με τελικά σημεία που έτρεχαν στην πύλη API.
Ωστόσο, αυτό επανέλαβε το πρόβλημα της δημιουργίας ενός νέου μονόλιθου όπου η υπηρεσία API ήταν υπερφορτωμένη με κώδικα με τέτοιο τρόπο ώστε να εμφανιστούν διάφορα σενάρια αποτυχίας. Για παράδειγμα, ορισμένα τελικά σημεία καταργήθηκαν ή τα σενάρια δημιούργησαν τυχαία τόσες πολλές εκδόσεις κάτι που οι εκδόσεις κατέλαβαν όλη τη διαθέσιμη μνήμη της υπηρεσίας API.
Ήταν λογικό να ληφθούν αυτά τα τελικά σημεία και να τα αποσύρουμε από την υπηρεσία API. Για να γίνει αυτό, δημιουργήσαμε στοιχεία Node.js που λειτουργούσαν ως μικρές εφαρμογές σε κοντέινερ Docker. Αυτό μας επέτρεψε να απομονώσουμε τυχόν προβλήματα και σφάλματα που προκαλούνται από αυτές τις εφαρμογές κόμβων.
Το κόστος αυτών των αλλαγών είναι αρκετά μεγάλο και αποτελείται από τους εξής παράγοντες:
- Εργαλεία παραγωγικότητας. Η διαχείριση νέων τεχνολογιών απαιτούσε νέα εργαλεία επειδή η ομάδα UI, χρησιμοποιώντας πολύ καλά σενάρια για να δημιουργήσει ένα αποτελεσματικό μοντέλο, δεν χρειάστηκε να αφιερώσει πολύ χρόνο στη διαχείριση της υποδομής, έπρεπε μόνο να γράψει σενάρια και να ελέγξει τη λειτουργικότητά τους.
Opportunity Insight και ταξινόμηση - Ένα βασικό παράδειγμα είναι τα νέα εργαλεία που απαιτούνται για την αποκάλυψη πληροφοριών του προγράμματος οδήγησης απόδοσης. Ήταν απαραίτητο να γνωρίζουμε πόσο απασχολημένος ήταν ο επεξεργαστής, πώς χρησιμοποιήθηκε η μνήμη και η συλλογή αυτών των πληροφοριών απαιτούσε διαφορετικά εργαλεία. - Κατακερματισμός βασικών εικόνων - η απλή βάση AMI έχει γίνει πιο κατακερματισμένη και εξειδικευμένη.
- Διαχείριση κόμβων. Δεν υπάρχει διαθέσιμη αρχιτεκτονική ή τεχνολογία off-the-shelf που να σας επιτρέπει να διαχειρίζεστε κόμβους στο cloud, έτσι δημιουργήσαμε την Titus, μια πλατφόρμα διαχείρισης κοντέινερ που παρέχει επεκτάσιμη και αξιόπιστη ανάπτυξη κοντέινερ και ενσωμάτωση στο cloud με το Amazon AWS.
- Αντιγραφή βιβλιοθήκης ή πλατφόρμας. Η παροχή νέων τεχνολογιών με την ίδια βασική λειτουργικότητα της πλατφόρμας απαιτούσε την αντιγραφή της σε εργαλεία προγραμματιστών Node.js που βασίζονται σε σύννεφο.
- Καμπύλη μάθησης και βιομηχανική εμπειρία. Η εισαγωγή νέων τεχνολογιών δημιουργεί αναπόφευκτα νέες προκλήσεις από τις οποίες πρέπει να ξεπεραστούν και να διδαχθούν.
Έτσι, δεν μπορούσαμε να περιοριστούμε σε έναν «στρωμένο δρόμο» και έπρεπε να χτίζουμε συνεχώς νέους τρόπους για να προάγουμε τις τεχνολογίες μας. Για να διατηρήσουμε χαμηλό το κόστος, περιορίσαμε την κεντρική υποστήριξη και επικεντρωθήκαμε στο JVM, στους νέους κόμβους και στο Docker. Δώσαμε προτεραιότητα στον αποτελεσματικό αντίκτυπο, ενημερώσαμε τις ομάδες για το κόστος των αποφάσεών τους και τις ενθαρρύναμε να αναζητήσουν τρόπους για να επαναχρησιμοποιήσουν τις λύσεις υψηλού αντίκτυπου που είχαν ήδη αναπτύξει. Χρησιμοποιήσαμε αυτήν την προσέγγιση κατά τη μετάφραση της υπηρεσίας σε ξένες γλώσσες για να παραδώσουμε το προϊόν σε διεθνείς πελάτες. Τα παραδείγματα περιλαμβάνουν σχετικά απλές βιβλιοθήκες πελατών που μπορούν να δημιουργηθούν αυτόματα, έτσι ώστε να είναι αρκετά εύκολο να δημιουργήσετε μια έκδοση Python, μια έκδοση Ruby, μια έκδοση Java κ.λπ.
Αναζητούσαμε συνεχώς ευκαιρίες να χρησιμοποιήσουμε δοκιμασμένες τεχνολογίες που είχαν αποδειχθεί σε ένα μέρος και σε άλλες παρόμοιες καταστάσεις.
Ας μιλήσουμε για το τελευταίο στοιχείο - αλλαγές ή παραλλαγές. Δείτε πώς η κατανάλωση του προϊόντος μας ποικίλλει άνισα ανά ημέρα της εβδομάδας και ανά ώρα κατά τη διάρκεια της ημέρας. Θα μπορούσατε να πείτε ότι οι 9 το πρωί είναι η πιο δύσκολη στιγμή για το Netflix, όταν το φορτίο στο σύστημα φτάνει στο μέγιστο.
Πώς μπορούμε να επιτύχουμε υψηλή ταχύτητα υλοποίησης καινοτομιών λογισμικού, δηλαδή να κάνουμε συνεχώς νέες αλλαγές στο σύστημα, χωρίς να προκαλείται διακοπές στην παροχή υπηρεσιών και χωρίς να δημιουργείται ταλαιπωρία στους πελάτες μας; Το Netflix το πέτυχε μέσω της χρήσης του Spinnaker, μιας νέας παγκόσμιας πλατφόρμας διαχείρισης και συνεχούς παράδοσης (CD) που βασίζεται σε cloud.
Ουσιαστικά, το Spinnaker σχεδιάστηκε για να ενσωματώνει τις βέλτιστες πρακτικές μας, ώστε καθώς αναπτύσσουμε εξαρτήματα στην παραγωγή, να μπορούμε να ενσωματώσουμε το αποτέλεσμα απευθείας στην τεχνολογία παράδοσης πολυμέσων μας.
Καταφέραμε να ενσωματώσουμε δύο τεχνολογίες στον αγωγό παράδοσης που εκτιμούμε ιδιαίτερα: αυτοματοποιημένη ανάλυση καναρινιών και σταδιακή ανάπτυξη. Η ανάλυση Canary σημαίνει ότι κατευθύνουμε μια σταγόνα κυκλοφορίας στη νέα έκδοση του κώδικα και περνάμε την υπόλοιπη κίνηση παραγωγής μέσω της παλιάς έκδοσης. Στη συνέχεια, ελέγχουμε πώς ο νέος κώδικας αντιμετωπίζει την εργασία - καλύτερα ή χειρότερα από τον υπάρχοντα.
Μια κλιμακωτή διάθεση σημαίνει ότι εάν μια διάθεση σε μια περιοχή έχει προβλήματα, μεταβαίνουμε σε μια διάθεση σε άλλη περιοχή. Στην περίπτωση αυτή, η προαναφερθείσα λίστα ελέγχου πρέπει να περιλαμβάνεται στον αγωγό παραγωγής. Θα σας εξοικονομήσω λίγο χρόνο και θα σας προτείνω να δείτε την προηγούμενη ομιλία μου, Engineering Global Netflix Operations in the Cloud, αν σας ενδιαφέρει να εμβαθύνετε σε αυτό το θέμα. Μπορείτε να δείτε τη βιντεοσκόπηση της ομιλίας ακολουθώντας τον σύνδεσμο στο κάτω μέρος της διαφάνειας.
Στο τέλος της ομιλίας, θα μιλήσω εν συντομία για την οργάνωση και την αρχιτεκτονική του Netflix. Στην αρχή είχαμε ένα σχέδιο που ονομαζόταν Ηλεκτρονική Παράδοση, το οποίο ήταν η πρώτη έκδοση του NRDP 1.x ροής πολυμέσων. Ο όρος "backstream" μπορεί να χρησιμοποιηθεί εδώ επειδή αρχικά ο χρήστης μπορούσε να κατεβάσει περιεχόμενο μόνο για μετέπειτα αναπαραγωγή στη συσκευή. Η πρώτη πλατφόρμα ψηφιακής παράδοσης του Netflix, το 2009, έμοιαζε κάπως έτσι.
Η συσκευή χρήστη περιείχε την εφαρμογή Netflix, η οποία αποτελούνταν από διεπαφή διεπαφής χρήστη, μονάδες ασφαλείας, ενεργοποίηση και αναπαραγωγή υπηρεσίας, βασισμένη στην πλατφόρμα NRDP - Netflix Ready Device Platform.
Εκείνη την εποχή η διεπαφή χρήστη ήταν πολύ απλή. Περιείχε αυτό που ονομαζόταν Queque Reader και ο χρήστης πήγαινε στον ιστότοπο για να προσθέσει κάτι στο Queque και μετά έβλεπε το προστιθέμενο περιεχόμενο στη συσκευή του. Το θετικό ήταν ότι η ομάδα front end και η ομάδα back end ανήκαν στον ίδιο οργανισμό Ηλεκτρονικής Παράδοσης και είχαν στενή σχέση εργασίας. Το ωφέλιμο φορτίο δημιουργήθηκε βάσει XML. Ταυτόχρονα, δημιουργήθηκε το Netflix API για την επιχείρηση DVD, το οποίο ενθάρρυνε εφαρμογές τρίτων να κατευθύνουν την επισκεψιμότητα στην υπηρεσία μας.
Ωστόσο, το API του Netflix ήταν καλά προετοιμασμένο για να μας βοηθήσει με μια καινοτόμο διεπαφή χρήστη, που περιέχει μεταδεδομένα όλου του περιεχομένου, πληροφορίες σχετικά με το ποιες ταινίες ήταν διαθέσιμες, γεγονός που δημιούργησε τη δυνατότητα δημιουργίας λιστών παρακολούθησης. Είχε ένα γενικό API REST βασισμένο στο σχήμα JSON, τον κώδικα απόκρισης HTTP, τον ίδιο που χρησιμοποιείται στη σύγχρονη αρχιτεκτονική και ένα μοντέλο ασφαλείας OAuth, το οποίο ήταν ό,τι απαιτούνταν εκείνη την εποχή για μια εφαρμογή front-end. Αυτό κατέστησε δυνατή τη μετάβαση από ένα δημόσιο μοντέλο παράδοσης περιεχομένου ροής σε ένα ιδιωτικό.
Το πρόβλημα με τη μετάβαση ήταν ο κατακερματισμός, αφού πλέον το σύστημά μας λειτουργούσε δύο υπηρεσίες βασισμένες σε εντελώς διαφορετικές αρχές λειτουργίας - η μία σε Rest, JSON και OAuth, η άλλη σε RPC, XML και έναν μηχανισμό ασφαλείας χρήστη που βασίζεται στο σύστημα διακριτικών NTBA. Αυτή ήταν η πρώτη υβριδική αρχιτεκτονική.
Υπήρχε ουσιαστικά ένα τείχος προστασίας μεταξύ των δύο ομάδων μας επειδή αρχικά το API δεν ήταν πολύ καλά με το NCCP και αυτό οδήγησε σε τριβές μεταξύ των ομάδων. Οι διαφορές ήταν στις υπηρεσίες, τα πρωτόκολλα, τα κυκλώματα, τις μονάδες ασφαλείας και οι προγραμματιστές έπρεπε συχνά να αλλάζουν μεταξύ εντελώς διαφορετικών πλαισίων.
Ως προς αυτό, είχα μια συνομιλία με έναν από τους ανώτερους μηχανικούς της εταιρείας, στον οποίο έθεσα την ερώτηση: «Ποια πρέπει να είναι η σωστή μακροπρόθεσμη αρχιτεκτονική;» και μου έκανε την αντίθετη ερώτηση: «Μάλλον σε απασχολεί περισσότερο. σχετικά με τις οργανωτικές συνέπειες - τι συμβαίνει εάν ενσωματώσουμε αυτά τα πράγματα και σπάσουν αυτό που μάθαμε να κάνουμε καλά; Αυτή η προσέγγιση είναι πολύ σχετική με τον νόμο του Conway: "Οι οργανισμοί που σχεδιάζουν συστήματα περιορίζονται από ένα σχέδιο που αναπαράγει τη δομή επικοινωνίας αυτού του οργανισμού." Αυτός είναι ένας πολύ αφηρημένος ορισμός, επομένως προτιμώ έναν πιο συγκεκριμένο ορισμό: «Οποιοδήποτε κομμάτι λογισμικού αντανακλά την οργανωτική δομή που το δημιούργησε». Εδώ είναι η αγαπημένη μου φράση από τον Eric Raymond: "Εάν έχετε τέσσερις ομάδες προγραμματιστών που εργάζονται σε έναν μεταγλωττιστή, θα καταλήξετε με έναν μεταγλωττιστή τεσσάρων περασμάτων". Λοιπόν, το Netflix έχει έναν μεταγλωττιστή τεσσάρων περασμάτων και έτσι λειτουργούμε.
Μπορούμε να πούμε ότι σε αυτή την περίπτωση η ουρά κουνάει τον σκύλο. Η πρώτη μας προτεραιότητα δεν είναι η λύση, αλλά η οργάνωση· είναι η οργάνωση που οδηγεί την αρχιτεκτονική που έχουμε. Σταδιακά, από ένα πλήθος υπηρεσιών, περάσαμε σε μια αρχιτεκτονική που ονομάσαμε Blade Runner, γιατί εδώ μιλάμε για υπηρεσίες edge και τη δυνατότητα του NCCP να διαχωρίζεται και να ενσωματώνεται απευθείας στον διακομιστή μεσολάβησης Zuul, στην πύλη API και στο αντίστοιχο λειτουργικό Τα «κομμάτια» έχουν μετατραπεί σε νέες μικροϋπηρεσίες με πιο προηγμένες δυνατότητες ασφάλειας, επανάληψης, ταξινόμησης δεδομένων κ.λπ.
Έτσι, μπορεί να ειπωθεί ότι οι δομές των τμημάτων και η δυναμική της εταιρείας παίζουν σημαντικό ρόλο στη διαμόρφωση του σχεδιασμού του συστήματος και είναι ένας παράγοντας που προωθεί ή εμποδίζει την αλλαγή. Η αρχιτεκτονική των Microservices είναι πολύπλοκη και οργανική και η υγεία της βασίζεται στην πειθαρχία και στο εισαγόμενο χάος.
Κάποια διαφήμιση
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com