Γεια σου, Χαμπρ. Οι εγγραφές για μια νέα ροή μαθημάτων είναι ανοιχτές αυτή τη στιγμή στο OTUS . Την παραμονή της έναρξης του μαθήματος, θέλω να μοιραστώ μαζί σας το πρωτότυπο άρθρο μου.
Εισαγωγή
Η επιλογή του αρχιτεκτονικού στυλ είναι μία από τις θεμελιώδεις τεχνικές αποφάσεις κατά την κατασκευή ενός πληροφοριακού συστήματος. Σε αυτή τη σειρά άρθρων, προτείνω να αναλύσω τα πιο δημοφιλή αρχιτεκτονικά στυλ για εφαρμογές κτιρίων και να απαντήσω στο ερώτημα πότε ποιο αρχιτεκτονικό στυλ είναι πιο προτιμότερο. Στη διαδικασία της παρουσίασης, θα προσπαθήσω να σχεδιάσω μια λογική αλυσίδα που εξηγεί την ανάπτυξη αρχιτεκτονικών στυλ από μονόλιθους σε μικροϋπηρεσίες.
Μια μικρή ιστορία
Αν προσπαθήσετε να ρωτήσετε τους προγραμματιστές: «Γιατί χρειαζόμαστε μικροϋπηρεσίες;», θα λάβετε ποικίλες απαντήσεις. Θα ακούσετε ότι οι microservices βελτιώνουν την επεκτασιμότητα, κάνουν τον κώδικα πιο κατανοητό, βελτιώνουν την ανοχή σφαλμάτων και μερικές φορές θα ακούσετε ότι σας επιτρέπουν να "καθαρίσετε τον κώδικά σας". Ας δούμε την ιστορία για να κατανοήσουμε τον σκοπό πίσω από την εμφάνιση των μικροϋπηρεσιών.
Εν ολίγοις, οι μικροϋπηρεσίες στην τρέχουσα κατανόησή μας προέκυψαν ως εξής: το 2011, ο James Lewis, αναλύοντας το έργο διαφόρων εταιρειών, επέστησε την προσοχή στην εμφάνιση ενός νέου προτύπου «micro-app», το οποίο βελτιστοποίησε το SOA όσον αφορά την επιτάχυνση της ανάπτυξης Υπηρεσίες. Λίγο αργότερα, το 2012, σε μια σύνοδο κορυφής αρχιτεκτονικής, το μοτίβο μετονομάστηκε σε microservice. Έτσι, ο αρχικός στόχος της εισαγωγής των μικροϋπηρεσιών ήταν η βελτίωση των διαβόητων ώρα για αγορά.
Οι μικροϋπηρεσίες ήταν στο κύμα δημοσιότητας το 2015. Σύμφωνα με ορισμένες μελέτες, ούτε ένα συνέδριο δεν ολοκληρώθηκε χωρίς έκθεση σχετικά με το θέμα των μικροϋπηρεσιών. Επιπλέον, ορισμένα συνέδρια ήταν αφιερωμένα αποκλειστικά στις μικροϋπηρεσίες. Σήμερα, πολλά έργα αρχίζουν να χρησιμοποιούν αυτό το αρχιτεκτονικό στυλ, και αν το έργο περιέχει τόνους κληροδοτημένου κώδικα, τότε η μετάβαση στις μικροϋπηρεσίες πιθανότατα πραγματοποιείται ενεργά.
Παρά όλα τα παραπάνω, ένας αρκετά μικρός αριθμός προγραμματιστών μπορεί ακόμα να ορίσει την έννοια της «μικροϋπηρεσίας». Αλλά για αυτό θα μιλήσουμε λίγο αργότερα...
Μονόλιθος
Το αρχιτεκτονικό στυλ που έρχεται σε αντίθεση με τις μικροϋπηρεσίες είναι το μονόλιθο (ή all-in-one). Μάλλον δεν έχει νόημα να πούμε τι είναι ένας μονόλιθος, γι' αυτό θα αναφέρω αμέσως τα μειονεκτήματα αυτού του αρχιτεκτονικού στυλ, το οποίο ξεκίνησε την περαιτέρω ανάπτυξη των αρχιτεκτονικών στυλ: μέγεθος, συνδεσιμότητα, ανάπτυξη, επεκτασιμότητα, αξιοπιστία και ακαμψία. Παρακάτω προτείνω να ρίξω μια ματιά σε καθεμία από τις ελλείψεις ξεχωριστά.
Μέγεθος
Ο μονόλιθος είναι πολύ μεγάλος. Και συνήθως επικοινωνεί με μια πολύ μεγάλη βάση δεδομένων. Η εφαρμογή γίνεται πολύ μεγάλη για να την καταλάβει καθόλου ένας προγραμματιστής. Μόνο όσοι έχουν αφιερώσει πολύ χρόνο σε αυτόν τον κώδικα μπορούν να δουλέψουν καλά με το μονόλιθο, ενώ οι αρχάριοι θα περάσουν πολύ χρόνο προσπαθώντας να καταλάβουν το μονόλιθο και δεν υπάρχει καμία εγγύηση ότι θα το καταλάβουν. Συνήθως, όταν εργάζεστε με ένα μονόλιθο, υπάρχει πάντα κάποιος «υπό όρους» ανώτερος που γνωρίζει λίγο πολύ καλά το μονόλιθο και κερδίζει τα χέρια άλλων νέων προγραμματιστών μέσα σε ενάμιση χρόνο. Φυσικά, ένας τέτοιος ανώτερος υπό όρους είναι ένα μόνο σημείο αποτυχίας και η αναχώρησή του μπορεί να οδηγήσει στο θάνατο του μονόλιθου.
Συνδεσιμότητα
Ο μονόλιθος είναι μια «μεγάλη μπάλα λάσπης», οι αλλαγές στις οποίες μπορεί να οδηγήσουν σε απρόβλεπτες συνέπειες. Κάνοντας αλλαγές σε ένα μέρος, μπορείτε να καταστρέψετε το μονόπετρο σε άλλο (το ίδιο «ξύσατε το αυτί σας, το *@ έπεσε»). Αυτό οφείλεται στο γεγονός ότι τα εξαρτήματα στο μονόλιθο έχουν πολύ περίπλοκες και, κυρίως, μη εμφανείς σχέσεις.
Ανάπτυξη
Η ανάπτυξη ενός μονόλιθου, λόγω των πολύπλοκων σχέσεων μεταξύ των συστατικών του, είναι μια μακρά διαδικασία με το δικό του τελετουργικό. Ένα τέτοιο τελετουργικό συνήθως δεν είναι εντελώς τυποποιημένο και μεταδίδεται «προφορικά».
Επεκτασιμότητα
Οι μονάδες Monolith μπορεί να έχουν αντικρουόμενες ανάγκες πόρων, που απαιτούν συμβιβασμό όσον αφορά το υλικό. Φανταστείτε ότι έχετε ένα μονόλιθο που αποτελείται από υπηρεσίες Α και Β. Η υπηρεσία Α είναι απαιτητική για το μέγεθος του σκληρού δίσκου και η υπηρεσία Β είναι απαιτητική για τη μνήμη RAM. Σε αυτήν την περίπτωση, είτε το μηχάνημα στο οποίο είναι εγκατεστημένο το μονόλιθο πρέπει να υποστηρίζει τις απαιτήσεις και των δύο υπηρεσιών, είτε θα πρέπει να απενεργοποιήσετε με μη αυτόματο τρόπο, τεχνητά μια από τις υπηρεσίες.
Ένα άλλο παράδειγμα (πιο κλασικό): η υπηρεσία Α είναι πολύ πιο δημοφιλής από την υπηρεσία Β, επομένως θέλετε να υπάρχουν 100 υπηρεσίες Α και 10 υπηρεσίες Β. Και πάλι, δύο επιλογές: είτε θα αναπτύξουμε 100 πλήρεις μονόλιθους, είτε σε μερικές τότε Οι υπηρεσίες Β θα πρέπει να απενεργοποιηθούν χειροκίνητα.
Αξιοπιστία
Εφόσον όλες οι υπηρεσίες βρίσκονται μαζί, αν πέσει ο μονόλιθος, τότε όλες οι υπηρεσίες πέφτουν ταυτόχρονα. Στην πραγματικότητα, αυτό μπορεί να μην είναι τόσο κακό, τουλάχιστον δεν θα υπάρχουν μερικές βλάβες σε ένα κατανεμημένο σύστημα, αλλά από την άλλη πλευρά, λόγω ενός σφάλματος στη λειτουργικότητα που χρησιμοποιείται από το 0.001% των χρηστών, μπορείτε να χάσετε όλους τους χρήστες του συστήματός σας.
Αδράνεια
Λόγω του μεγέθους του μονόλιθου, είναι δύσκολο να μεταβείτε σε νέες τεχνολογίες. Ως αποτέλεσμα, η διατήρηση του ίδιου ανώτερου επιπέδου είναι ένα ξεχωριστό καθήκον. Η στοίβα τεχνολογίας που επιλέγεται στην αρχή ενός έργου μπορεί να γίνει ένα μπλοκ που εμποδίζει την ανάπτυξη του προϊόντος.
Συμπέρασμα
Την επόμενη φορά θα μιλήσουμε για το πώς οι άνθρωποι προσπάθησαν να λύσουν αυτά τα προβλήματα μεταβαίνοντας στα συστατικά μέρη και το SOA.
Διαβάστε περισσότερα:
Πηγή: www.habr.com