Ξοδέψατε μήνες επανασχεδιάζοντας το μονόλιθο σας σε μικροϋπηρεσίες και επιτέλους όλοι συγκεντρώθηκαν για να γυρίσουν τον διακόπτη. Μπαίνεις στην πρώτη ιστοσελίδα... και δεν γίνεται τίποτα. Το ξαναφορτώνεις - και πάλι τίποτα καλό, ο ιστότοπος είναι τόσο αργός που δεν ανταποκρίνεται για αρκετά λεπτά. Τι συνέβη?
Στην ομιλία του, ο Jimmy Bogard θα πραγματοποιήσει μια «μεταθανάτια» σε μια πραγματική καταστροφή μικροϋπηρεσιών. Θα δείξει τα προβλήματα μοντελοποίησης, ανάπτυξης και παραγωγής που ανακάλυψε και πώς η ομάδα του μετέτρεψε σιγά σιγά το νέο κατανεμημένο μονόλιθο στην τελική εικόνα της λογικής. Αν και είναι αδύνατο να αποφευχθούν εντελώς τα σφάλματα σχεδιασμού, μπορείτε τουλάχιστον να εντοπίσετε προβλήματα νωρίς στη διαδικασία σχεδιασμού για να διασφαλίσετε ότι το τελικό προϊόν θα γίνει ένα αξιόπιστο κατανεμημένο σύστημα.
Γεια σε όλους, είμαι ο Jimmy και σήμερα θα ακούσετε πώς μπορείτε να αποφύγετε μεγάλες καταστροφές κατά την κατασκευή μικροϋπηρεσιών. Αυτή είναι η ιστορία μιας εταιρείας στην οποία εργάστηκα για περίπου ενάμιση χρόνο για να αποτρέψω τη σύγκρουση του πλοίου της με ένα παγόβουνο. Για να πούμε σωστά αυτή την ιστορία, θα πρέπει να γυρίσουμε τον χρόνο πίσω και να μιλήσουμε για το πού ξεκίνησε αυτή η εταιρεία και πώς η υποδομή πληροφορικής της έχει αναπτυχθεί με την πάροδο του χρόνου. Για να προστατεύσω τα ονόματα των αθώων σε αυτήν την καταστροφή, άλλαξα το όνομα αυτής της εταιρείας σε Bell Computers. Η επόμενη διαφάνεια δείχνει πώς έμοιαζε η υποδομή πληροφορικής τέτοιων εταιρειών στα μέσα της δεκαετίας του '90. Αυτή είναι μια τυπική αρχιτεκτονική ενός μεγάλου γενικού διακομιστή HP Tandem Mainframe με ανοχή σε σφάλματα για τη λειτουργία ενός καταστήματος υλικού υπολογιστών.
Χρειάστηκε να δημιουργήσουν ένα σύστημα για να διαχειρίζονται όλες τις παραγγελίες, τις πωλήσεις, τις επιστροφές, τους καταλόγους προϊόντων και τη βάση πελατών, γι' αυτό επέλεξαν την πιο κοινή λύση mainframe εκείνη τη στιγμή. Αυτό το γιγάντιο σύστημα περιείχε όλες τις πληροφορίες για την εταιρεία, ό,τι ήταν δυνατό και κάθε συναλλαγή γινόταν μέσω αυτού του mainframe. Κρατούσαν όλα τα αυγά τους σε ένα καλάθι και νόμιζαν ότι ήταν φυσιολογικό. Το μόνο πράγμα που δεν περιλαμβάνεται εδώ είναι οι κατάλογοι ταχυδρομικών παραγγελιών και η πραγματοποίηση παραγγελιών μέσω τηλεφώνου.
Με τον καιρό, το σύστημα γινόταν όλο και μεγαλύτερο, και μια τεράστια ποσότητα σκουπιδιών συσσωρεύτηκε σε αυτό. Επίσης, η COBOL δεν είναι η πιο εκφραστική γλώσσα στον κόσμο, οπότε το σύστημα κατέληξε να είναι ένα μεγάλο, μονολιθικό κομμάτι σκουπιδιών. Μέχρι το 2000, είδαν ότι πολλές εταιρείες είχαν ιστοσελίδες μέσω των οποίων διεξήγαγαν απολύτως όλες τις δραστηριότητές τους και αποφάσισαν να δημιουργήσουν τον πρώτο τους εμπορικό ιστότοπο dot-com.
Η αρχική σχεδίαση φαινόταν πολύ ωραία και αποτελούνταν από έναν ιστότοπο κορυφαίου επιπέδου bell.com και έναν αριθμό υποτομέων για μεμονωμένες εφαρμογές: catalog.bell.com, accounts.bell.com, orders.bell.com, αναζήτηση προϊόντων αναζήτησης.bell. com. Κάθε υποτομέας χρησιμοποιούσε το πλαίσιο ASP.Net 1.0 και τις δικές του βάσεις δεδομένων, και όλοι μίλησαν στο backend του συστήματος. Ωστόσο, όλες οι παραγγελίες συνέχισαν να επεξεργάζονται και να εκτελούνται σε ένα ενιαίο τεράστιο mainframe, στο οποίο παρέμεναν όλα τα σκουπίδια, αλλά το μπροστινό μέρος ήταν ξεχωριστοί ιστότοποι με μεμονωμένες εφαρμογές και ξεχωριστές βάσεις δεδομένων.
Έτσι, ο σχεδιασμός του συστήματος φαινόταν τακτικός και λογικός, αλλά το πραγματικό σύστημα ήταν όπως φαίνεται στην επόμενη διαφάνεια.
Όλα τα στοιχεία απηύθυναν κλήσεις το ένα στο άλλο, είχαν πρόσβαση σε API, ενσωματωμένα dll τρίτων και παρόμοια. Συχνά συνέβαινε τα συστήματα ελέγχου έκδοσης να άρπαζαν τον κωδικό κάποιου άλλου, να τον έσπρωχναν μέσα στο έργο και μετά να σπάσουν τα πάντα. Ο MS SQL Server 2005 χρησιμοποίησε την έννοια των διακομιστών συνδέσμων και, παρόλο που δεν έδειξα τα βέλη στη διαφάνεια, κάθε μία από τις βάσεις δεδομένων μίλησε επίσης μεταξύ τους, επειδή δεν υπάρχει τίποτα κακό με τη δημιουργία πινάκων με βάση δεδομένα που λαμβάνονται από πολλές βάσεις δεδομένων.
Δεδομένου ότι τώρα είχαν κάποιο διαχωρισμό μεταξύ διαφορετικών λογικών περιοχών του συστήματος, αυτό έγινε κατανεμημένο σταγόνες βρωμιάς, με το μεγαλύτερο κομμάτι σκουπιδιών να παραμένει ακόμα στο backend του mainframe.
Το αστείο ήταν ότι αυτό το mainframe κατασκευάστηκε από ανταγωνιστές της Bell Computers και συντηρούνταν ακόμα από τους τεχνικούς συμβούλους τους. Πεπεισμένη για τη μη ικανοποιητική απόδοση των εφαρμογών της, η εταιρεία αποφάσισε να απαλλαγεί από αυτές και να επανασχεδιάσει το σύστημα.
Η υπάρχουσα εφαρμογή ήταν σε παραγωγή για 15 χρόνια, γεγονός που αποτελεί ρεκόρ για εφαρμογές που βασίζονται στο ASP.Net. Η υπηρεσία δεχόταν παραγγελίες από όλο τον κόσμο και τα ετήσια έσοδα από αυτή την εφαρμογή έφτασαν το ένα δισεκατομμύριο δολάρια. Ένα σημαντικό μέρος του κέρδους δημιουργήθηκε από τον ιστότοπο bell.com. Τις Μαύρες Παρασκευές, ο αριθμός των παραγγελιών που πραγματοποιήθηκαν μέσω του ιστότοπου έφτανε πολλά εκατομμύρια. Ωστόσο, η υπάρχουσα αρχιτεκτονική δεν επέτρεπε καμία εξέλιξη, αφού οι άκαμπτες διασυνδέσεις στοιχείων του συστήματος πρακτικά δεν επέτρεπαν να γίνουν αλλαγές στην υπηρεσία.
Το πιο σοβαρό πρόβλημα ήταν η αδυναμία να δώσετε μια παραγγελία από μια χώρα, να την πληρώσετε σε μια άλλη και να την στείλετε σε μια τρίτη, παρά το γεγονός ότι ένα τέτοιο σύστημα συναλλαγών είναι πολύ συνηθισμένο στις παγκόσμιες εταιρείες. Ο υπάρχων ιστότοπος δεν επέτρεπε κάτι τέτοιο, επομένως έπρεπε να δεχτούν και να κάνουν αυτές τις παραγγελίες μέσω τηλεφώνου. Αυτό οδήγησε την εταιρεία να σκέφτεται όλο και περισσότερο την αλλαγή της αρχιτεκτονικής, ιδίως τη μετάβαση σε μικροϋπηρεσίες.
Έκαναν το έξυπνο πράγμα κοιτάζοντας άλλες εταιρείες για να δουν πώς είχαν λύσει ένα παρόμοιο πρόβλημα. Μία από αυτές τις λύσεις ήταν η αρχιτεκτονική υπηρεσιών Netflix, η οποία αποτελείται από μικροϋπηρεσίες συνδεδεμένες μέσω ενός API και μιας εξωτερικής βάσης δεδομένων.
Η διοίκηση της Bell Computers αποφάσισε να κατασκευάσει ακριβώς μια τέτοια αρχιτεκτονική, τηρώντας ορισμένες βασικές αρχές. Πρώτον, εξάλειψαν την επικάλυψη δεδομένων χρησιμοποιώντας μια προσέγγιση κοινής βάσης δεδομένων. Δεν στάλθηκαν δεδομένα, αντίθετα, όλοι όσοι τα χρειάζονταν έπρεπε να απευθυνθούν σε μια κεντρική πηγή. Ακολούθησε η απομόνωση και η αυτονομία - κάθε υπηρεσία ήταν ανεξάρτητη από τις άλλες. Αποφάσισαν να χρησιμοποιήσουν το Web API για τα πάντα - αν θέλατε να λάβετε δεδομένα ή να κάνετε αλλαγές σε άλλο σύστημα, όλα έγιναν μέσω του Web API. Το τελευταίο σημαντικό πράγμα ήταν ένας νέος κεντρικός υπολογιστής που ονομάζεται "Bell on Bell" σε αντίθεση με τον κεντρικό υπολογιστή "Bell" που βασίζεται στο υλικό των ανταγωνιστών.
Έτσι, κατά τη διάρκεια 18 μηνών, έχτισαν το σύστημα γύρω από αυτές τις βασικές αρχές και το έφεραν στην προπαραγωγή. Επιστρέφοντας στην εργασία μετά το Σαββατοκύριακο, οι προγραμματιστές συγκεντρώθηκαν και ενεργοποίησαν όλους τους διακομιστές στους οποίους ήταν συνδεδεμένο το νέο σύστημα. 18 μήνες δουλειάς, εκατοντάδες προγραμματιστές, το πιο σύγχρονο υλικό Bell - και κανένα θετικό αποτέλεσμα! Αυτό έχει απογοητεύσει πολλούς ανθρώπους επειδή έχουν τρέξει αυτό το σύστημα στους φορητούς υπολογιστές τους πολλές φορές και όλα ήταν καλά.
Ήταν έξυπνοι να ρίξουν όλα τα χρήματά τους για να λύσουν αυτό το πρόβλημα. Τοποθέτησαν τα πιο σύγχρονα rack server με διακόπτες, χρησιμοποίησαν οπτικές ίνες gigabit, το πιο ισχυρό hardware διακομιστή με τρελή ποσότητα μνήμης RAM, τα συνέδεσαν όλα, τα διαμόρφωσαν - και πάλι, τίποτα! Μετά άρχισαν να υποψιάζονται ότι ο λόγος μπορεί να ήταν τα χρονικά όρια, οπότε μπήκαν σε όλες τις ρυθμίσεις ιστού, σε όλες τις ρυθμίσεις API και ενημέρωσαν ολόκληρη τη διαμόρφωση χρονικού ορίου στις μέγιστες τιμές, έτσι ώστε το μόνο που μπορούσαν να κάνουν ήταν να κάθονται και να περιμένουν να συμβεί κάτι στον ιστότοπο. Περίμεναν και περίμεναν και περίμεναν 9 και μισό λεπτά μέχρι να φορτωθεί τελικά ο ιστότοπος.
Μετά από αυτό, τους ξημέρωσε ότι η τρέχουσα κατάσταση χρειάζεται μια ενδελεχή ανάλυση και μας κάλεσαν. Το πρώτο πράγμα που ανακαλύψαμε ήταν ότι κατά τη διάρκεια και των 18 μηνών ανάπτυξης, δεν δημιουργήθηκε ούτε ένα πραγματικό «micro» - όλα έγιναν μόνο μεγαλύτερα. Μετά από αυτό, αρχίσαμε να γράφουμε μια μεταθανάτια, γνωστή και ως «αναδρομική αναδρομή» ή «θλιβερή αναδρομή», γνωστή και ως «καταιγίδα ευθυνών», παρόμοια με μια «εγκεφαλική καταιγίδα», για να κατανοήσουμε την αιτία της καταστροφής.
Είχαμε αρκετές ενδείξεις, μία από τις οποίες ήταν ο πλήρης κορεσμός της κυκλοφορίας τη στιγμή της κλήσης του API. Όταν χρησιμοποιείτε μια μονολιθική αρχιτεκτονική υπηρεσίας, μπορείτε αμέσως να καταλάβετε τι ακριβώς πήγε στραβά, επειδή έχετε ένα ενιαίο ίχνος στοίβας που αναφέρει όλα όσα θα μπορούσαν να έχουν προκαλέσει την αποτυχία. Στην περίπτωση που μια δέσμη υπηρεσιών έχει ταυτόχρονα πρόσβαση στο ίδιο API, δεν υπάρχει τρόπος παρακολούθησης του ίχνους εκτός από τη χρήση πρόσθετων εργαλείων παρακολούθησης δικτύου όπως το WireShark, χάρη στα οποία μπορείτε να εξετάσετε ένα μόνο αίτημα και να μάθετε τι συνέβη κατά την υλοποίησή του. Έτσι, πήραμε μια ιστοσελίδα και αφιερώσαμε σχεδόν 2 εβδομάδες για να συνθέσουμε τα κομμάτια του παζλ, να πραγματοποιήσουμε διάφορες κλήσεις σε αυτήν και να αναλύσουμε τι οδήγησε το καθένα από αυτά.
Κοίτα αυτή την εικόνα. Δείχνει ότι ένα εξωτερικό αίτημα ζητά από την υπηρεσία να πραγματοποιήσει πολλές εσωτερικές κλήσεις που επιστρέφουν. Αποδεικνύεται ότι κάθε εσωτερική κλήση κάνει επιπλέον άλματα για να μπορέσει να εξυπηρετήσει ανεξάρτητα αυτό το αίτημα, επειδή δεν μπορεί να στραφεί πουθενά αλλού για να λάβει τις απαραίτητες πληροφορίες. Αυτή η εικόνα μοιάζει με έναν ανούσιο καταρράκτη κλήσεων, καθώς το εξωτερικό αίτημα καλεί πρόσθετες υπηρεσίες, οι οποίες καλούν άλλες πρόσθετες υπηρεσίες και ούτω καθεξής, σχεδόν επ' άπειρον.
Το πράσινο χρώμα σε αυτό το διάγραμμα δείχνει ένα ημικύκλιο στο οποίο οι υπηρεσίες καλούν η μία την άλλη - η υπηρεσία Α καλεί την υπηρεσία Β, η υπηρεσία Β καλεί την υπηρεσία C και καλεί ξανά την υπηρεσία Α. Ως αποτέλεσμα, έχουμε ένα "κατανεμημένο αδιέξοδο". Ένα μόνο αίτημα δημιούργησε χίλιες κλήσεις API δικτύου και δεδομένου ότι το σύστημα δεν είχε ενσωματωμένη ανοχή σφαλμάτων και προστασία βρόχου, το αίτημα θα αποτύγχανε εάν αποτύγχανε έστω και μία από αυτές τις κλήσεις API.
Κάναμε μαθηματικά. Κάθε κλήση API είχε SLA όχι περισσότερο από 150 ms και χρόνο λειτουργίας 99,9%. Ένα αίτημα προκάλεσε 200 διαφορετικές κλήσεις και στην καλύτερη περίπτωση, η σελίδα μπορούσε να εμφανιστεί σε 200 x 150 ms = 30 δευτερόλεπτα. Φυσικά, αυτό δεν ήταν καλό. Πολλαπλασιάζοντας το 99,9% χρόνο λειτουργίας επί 200, έχουμε 0% διαθεσιμότητα. Αποδεικνύεται ότι αυτή η αρχιτεκτονική ήταν καταδικασμένη σε αποτυχία από την αρχή.
Ρωτήσαμε τους προγραμματιστές πώς δεν κατάφεραν να αναγνωρίσουν αυτό το πρόβλημα μετά από 18 μήνες εργασίας; Αποδείχθηκε ότι μέτρησαν μόνο το SLA για τον κωδικό που έτρεξαν, αλλά αν η υπηρεσία τους καλούσε άλλη υπηρεσία, δεν μέτρησαν αυτόν τον χρόνο στο SLA τους. Ό,τι εκκινήθηκε μέσα σε μία διαδικασία τηρούσε την τιμή των 150 ms, αλλά η πρόσβαση σε άλλες διαδικασίες υπηρεσίας αύξησε τη συνολική καθυστέρηση πολλαπλάσια. Το πρώτο μάθημα που μάθαμε ήταν: «Έχετε τον έλεγχο της SLA σας ή η SLA σας ελέγχει;» Στην περίπτωσή μας, ήταν το δεύτερο.
Το επόμενο πράγμα που ανακαλύψαμε ήταν ότι γνώριζαν για την έννοια των παρανοήσεων κατανεμημένων υπολογιστών, που διατύπωσαν οι Peter Deitch και James Gosling, αλλά αγνόησαν το πρώτο μέρος της. Δηλώνει ότι οι δηλώσεις "το δίκτυο είναι αξιόπιστο", "μηδενική καθυστέρηση" και "άπειρη απόδοση" είναι εσφαλμένες αντιλήψεις. Άλλες παρανοήσεις περιλαμβάνουν τις δηλώσεις "το δίκτυο είναι ασφαλές", "η τοπολογία δεν αλλάζει ποτέ", "υπάρχει πάντα μόνο ένας διαχειριστής", "το κόστος μεταφοράς δεδομένων είναι μηδενικό" και "το δίκτυο είναι ομοιογενές".
Έκαναν λάθος επειδή δοκίμασαν την υπηρεσία τους σε τοπικά μηχανήματα και δεν συνδέθηκαν ποτέ με εξωτερικές υπηρεσίες. Κατά την ανάπτυξη τοπικά και τη χρήση τοπικής κρυφής μνήμης, δεν αντιμετώπισαν ποτέ άλματα δικτύου. Και στους 18 μήνες ανάπτυξης, ποτέ δεν αναρωτήθηκαν τι θα μπορούσε να συμβεί εάν επηρεάζονταν οι εξωτερικές υπηρεσίες.
Αν κοιτάξετε τα όρια της υπηρεσίας στην προηγούμενη εικόνα, μπορείτε να δείτε ότι είναι όλα λανθασμένα. Υπάρχουν πολλές πηγές που συμβουλεύουν πώς να ορίσετε τα όρια της υπηρεσίας και οι περισσότερες το κάνουν λάθος, όπως η Microsoft στην επόμενη διαφάνεια.
Αυτή η εικόνα είναι από το ιστολόγιο MS με θέμα "Πώς να δημιουργήσετε μικροϋπηρεσίες". Αυτό δείχνει μια απλή εφαρμογή Ιστού, ένα μπλοκ επιχειρηματικής λογικής και μια βάση δεδομένων. Το αίτημα έρχεται απευθείας, υπάρχει πιθανώς ένας διακομιστής για το web, ένας διακομιστής για την επιχείρηση και ένας για τη βάση δεδομένων. Εάν αυξήσετε την επισκεψιμότητα, η εικόνα θα αλλάξει λίγο.
Εδώ έρχεται ένα πρόγραμμα εξισορρόπησης φορτίου για τη διανομή της κυκλοφορίας μεταξύ δύο διακομιστών Ιστού, μια κρυφή μνήμη που βρίσκεται μεταξύ της υπηρεσίας Ιστού και της επιχειρηματικής λογικής και μια άλλη κρυφή μνήμη μεταξύ της επιχειρηματικής λογικής και της βάσης δεδομένων. Αυτή είναι ακριβώς η αρχιτεκτονική που χρησιμοποιούσε η Bell για την εξισορρόπηση φορτίου και την εφαρμογή ανάπτυξης μπλε/πράσινου στα μέσα της δεκαετίας του 2000. Μέχρι κάποιο χρονικό διάστημα όλα λειτουργούσαν καλά, αφού αυτό το σχέδιο προοριζόταν για μια μονολιθική δομή.
Η ακόλουθη εικόνα δείχνει πώς η MS συνιστά τη μετάβαση από μονόλιθο σε μικροϋπηρεσίες - απλώς χωρίζοντας κάθε μία από τις κύριες υπηρεσίες σε ξεχωριστές μικροϋπηρεσίες. Ήταν κατά τη διάρκεια της εφαρμογής αυτού του σχήματος που ο Bell έκανε ένα λάθος.
Διαίρεσαν όλες τις υπηρεσίες τους σε διαφορετικά επίπεδα, καθένα από τα οποία αποτελούνταν από πολλές μεμονωμένες υπηρεσίες. Για παράδειγμα, η υπηρεσία Ιστού περιλάμβανε μικροϋπηρεσίες για απόδοση περιεχομένου και έλεγχο ταυτότητας, η υπηρεσία επιχειρηματικής λογικής αποτελούνταν από μικροϋπηρεσίες για την επεξεργασία παραγγελιών και πληροφορίες λογαριασμού, η βάση δεδομένων χωρίστηκε σε μια δέσμη μικροϋπηρεσιών με εξειδικευμένα δεδομένα. Τόσο ο ιστός, η επιχειρηματική λογική όσο και η βάση δεδομένων ήταν υπηρεσίες χωρίς ιθαγένεια.
Ωστόσο, αυτή η εικόνα ήταν εντελώς λανθασμένη επειδή δεν χαρτογράφησε καμία επιχειρηματική μονάδα εκτός του συμπλέγματος IT της εταιρείας. Αυτό το σχήμα δεν έλαβε υπόψη καμία σχέση με τον έξω κόσμο, επομένως δεν ήταν σαφές πώς, για παράδειγμα, να αποκτήσετε αναλυτικά στοιχεία επιχειρήσεων τρίτων. Σημειώνω ότι είχαν επίσης πολλές υπηρεσίες που εφευρέθηκαν απλώς για να αναπτύξουν τη σταδιοδρομία μεμονωμένων υπαλλήλων που προσπάθησαν να διαχειριστούν όσο το δυνατόν περισσότερους ανθρώπους για να πάρουν περισσότερα χρήματα για αυτό.
Πίστευαν ότι η μετάβαση σε μικροϋπηρεσίες ήταν τόσο εύκολη όσο να πάρουν την εσωτερική τους υποδομή φυσικού επιπέδου N-tier και να κολλήσουν το Docker σε αυτό. Ας ρίξουμε μια ματιά στο πώς μοιάζει η παραδοσιακή αρχιτεκτονική N-tier.
Αποτελείται από 4 επίπεδα: το επίπεδο διεπαφής χρήστη διεπαφής χρήστη, το επίπεδο επιχειρηματικής λογικής, το επίπεδο πρόσβασης δεδομένων και τη βάση δεδομένων. Πιο προοδευτικό είναι το DDD (Domain-Driven Design) ή αρχιτεκτονική προσανατολισμένη στο λογισμικό, όπου τα δύο μεσαία επίπεδα είναι αντικείμενα τομέα και ένα αποθετήριο.
Προσπάθησα να εξετάσω διαφορετικούς τομείς αλλαγής, διαφορετικούς τομείς ευθύνης σε αυτήν την αρχιτεκτονική. Σε μια τυπική εφαρμογή N-tier, ταξινομούνται διαφορετικές περιοχές αλλαγής που διαπερνούν τη δομή κατακόρυφα από πάνω προς τα κάτω. Αυτές είναι οι ρυθμίσεις καταλόγου, διαμόρφωσης που εκτελούνται σε μεμονωμένους υπολογιστές και ελέγχους ολοκλήρωσης αγοράς, τους οποίους χειρίστηκε η ομάδα μου.
Η ιδιαιτερότητα αυτού του σχήματος είναι ότι τα όρια αυτών των περιοχών αλλαγής επηρεάζουν όχι μόνο το επίπεδο επιχειρηματικής λογικής, αλλά επεκτείνονται και στη βάση δεδομένων.
Ας δούμε τι σημαίνει να είσαι υπηρεσία. Υπάρχουν 6 χαρακτηριστικές ιδιότητες ενός ορισμού υπηρεσίας - είναι λογισμικό που:
- δημιουργήθηκε και χρησιμοποιείται από έναν συγκεκριμένο οργανισμό·
- είναι υπεύθυνος για το περιεχόμενο, την επεξεργασία ή/και την παροχή ενός συγκεκριμένου τύπου πληροφοριών εντός του συστήματος·
- μπορεί να κατασκευαστεί, να αναπτυχθεί και να λειτουργήσει ανεξάρτητα για την κάλυψη συγκεκριμένων επιχειρησιακών αναγκών.
- επικοινωνεί με τους καταναλωτές και άλλες υπηρεσίες, παρέχοντας πληροφορίες βάσει συμφωνιών ή συμβατικών εγγυήσεων·
- προστατεύει τον εαυτό του από μη εξουσιοδοτημένη πρόσβαση και τις πληροφορίες του από απώλεια·
- χειρίζεται τις αστοχίες με τέτοιο τρόπο ώστε να μην οδηγούν σε καταστροφή πληροφοριών.
Όλες αυτές οι ιδιότητες μπορούν να εκφραστούν με μία λέξη «αυτονομία». Οι υπηρεσίες λειτουργούν ανεξάρτητα η μία από την άλλη, ικανοποιούν ορισμένους περιορισμούς και ορίζουν συμβάσεις βάσει των οποίων οι άνθρωποι μπορούν να λαμβάνουν τις πληροφορίες που χρειάζονται. Δεν ανέφερα συγκεκριμένες τεχνολογίες, η χρήση των οποίων είναι αυτονόητη.
Ας δούμε τώρα τον ορισμό των μικροϋπηρεσιών:
- μια microservice είναι μικρή σε μέγεθος και έχει σχεδιαστεί για να λύνει ένα συγκεκριμένο πρόβλημα.
- Το microservice είναι αυτόνομο.
- Κατά τη δημιουργία μιας αρχιτεκτονικής μικροϋπηρεσιών, χρησιμοποιείται η μεταφορά της πολεοδομίας. Αυτός είναι ο ορισμός από το βιβλίο του Sam Newman, Building Microservices.
Ο ορισμός του Bounded Context προέρχεται από το βιβλίο του Eric Evans Domain-Driven Design. Αυτό είναι ένα βασικό μοτίβο στο DDD, ένα κέντρο σχεδιασμού αρχιτεκτονικής που λειτουργεί με ογκομετρικά αρχιτεκτονικά μοντέλα, χωρίζοντάς τα σε διαφορετικά Bounded Contexts και ορίζοντας ρητά τις αλληλεπιδράσεις μεταξύ τους.
Με απλά λόγια, ένα Bounded Context υποδηλώνει το εύρος στο οποίο μπορεί να χρησιμοποιηθεί μια συγκεκριμένη ενότητα. Σε αυτό το πλαίσιο είναι ένα λογικά ενοποιημένο μοντέλο που μπορεί να δει κανείς, για παράδειγμα, στον τομέα της επιχείρησής σας. Εάν ρωτήσετε «ποιος είναι πελάτης» στο προσωπικό που εμπλέκεται στις παραγγελίες, θα λάβετε έναν ορισμό, εάν ρωτήσετε αυτούς που ασχολούνται με τις πωλήσεις, θα πάρετε έναν άλλο και οι ερμηνευτές θα σας δώσουν έναν τρίτο ορισμό.
Έτσι, το Bounded Context λέει ότι εάν δεν μπορούμε να δώσουμε έναν σαφή ορισμό του τι είναι ο καταναλωτής των υπηρεσιών μας, ας ορίσουμε τα όρια εντός των οποίων μπορούμε να μιλήσουμε για την έννοια αυτού του όρου και στη συνέχεια να ορίσουμε τα σημεία μετάβασης μεταξύ αυτών των διαφορετικών ορισμών. Δηλαδή, αν μιλάμε για πελάτη από την άποψη της παραγγελίας, αυτό σημαίνει αυτό και εκείνο, και αν από πλευράς πωλήσεων, αυτό σημαίνει αυτό και εκείνο.
Ο επόμενος ορισμός της microservice είναι η ενθυλάκωση κάθε είδους εσωτερικών λειτουργιών, αποτρέποντας τη «διαρροή» των στοιχείων της διαδικασίας εργασίας στο περιβάλλον. Στη συνέχεια ακολουθεί ο «ορισμός των ρητών συμβάσεων για εξωτερικές αλληλεπιδράσεις ή εξωτερικές επικοινωνίες», ο οποίος αντιπροσωπεύεται από την ιδέα των συμβάσεων που επιστρέφουν από SLA. Ο τελευταίος ορισμός είναι η μεταφορά ενός κυττάρου ή κυττάρου, που σημαίνει την πλήρη ενθυλάκωση ενός συνόλου λειτουργιών μέσα σε μια μικροϋπηρεσία και την παρουσία σε αυτήν υποδοχέων για επικοινωνία με τον έξω κόσμο.
Είπαμε λοιπόν στα παιδιά της Bell Computers, «Δεν μπορούμε να διορθώσουμε κανένα από το χάος που έχετε δημιουργήσει γιατί απλά δεν έχετε τα χρήματα για να το κάνετε, αλλά θα φτιάξουμε μόνο μία υπηρεσία για να τα φτιάξουμε όλα. έννοια." Σε αυτό το σημείο, θα ξεκινήσω λέγοντάς σας πώς διορθώσαμε τη μοναδική μας υπηρεσία, ώστε να ανταποκρίνεται σε αιτήματα γρηγορότερα από 9 λεπτά.
22:30 λεπτά
Συνέχεια πολύ σύντομα...
Κάποια διαφήμιση
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με 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