Επιλέγοντας ένα αρχιτεκτονικό στυλ (μέρος 2)

Γεια σου, Χαμπρ. Σήμερα συνεχίζω μια σειρά από δημοσιεύσεις που έγραψα ειδικά για την έναρξη μιας νέας ροής του μαθήματος. "Αρχιτέκτονας λογισμικού".

Εισαγωγή

Η επιλογή του αρχιτεκτονικού στυλ είναι μία από τις θεμελιώδεις τεχνικές αποφάσεις κατά την κατασκευή ενός πληροφοριακού συστήματος. Σε αυτή τη σειρά άρθρων, προτείνω να αναλύσω τα πιο δημοφιλή αρχιτεκτονικά στυλ για εφαρμογές κτιρίων και να απαντήσω στο ερώτημα πότε ποιο αρχιτεκτονικό στυλ είναι πιο προτιμότερο. Στη διαδικασία της παρουσίασης, θα προσπαθήσω να σχεδιάσω μια λογική αλυσίδα που εξηγεί την ανάπτυξη αρχιτεκτονικών στυλ από μονόλιθους σε μικροϋπηρεσίες.

В τελευταία φορά ασχοληθήκαμε με το μονόλιθο και καταλήξαμε στο συμπέρασμα ότι ο μονόλιθος έχει μια σειρά προβλημάτων: μέγεθος, συνδεσιμότητα, ανάπτυξη, επεκτασιμότητα, αξιοπιστία και ακαμψία.

Αυτή τη φορά προτείνω να μιλήσουμε για τις δυνατότητες οργάνωσης ενός συστήματος ως σύνολο ενοτήτων/βιβλιοθηκών (component-oriented architecture) ή υπηρεσιών (service-oriented architecture).

Αρχιτεκτονική προσανατολισμένη στα στοιχεία

Η αρχιτεκτονική προσανατολισμένη στα συστατικά στοιχεία περιλαμβάνει την εκτέλεση ενός συστήματος ως συνόλου στοιχείων που μπορούν να χρησιμοποιηθούν τόσο σε τρέχοντα όσο και σε μελλοντικά έργα. Κατά την κατανομή ενός συστήματος σε στοιχεία, λαμβάνονται υπόψη τα ακόλουθα: η επαναχρησιμοποίησή τους, η δυνατότητα αντικατάστασής τους, η ανεξαρτησία του περιβάλλοντος, η επεκτασιμότητα, η ενθυλάκωση και η ανεξαρτησία.

Με τη σωστή χρήση των εξαρτημάτων, το πρόβλημα της «μεγάλης σφαίρας βρωμιάς» (μεγάλο μέγεθος + υψηλή σύζευξη) επιλύεται και τα ίδια τα εξαρτήματα μπορούν να αντιπροσωπεύουν τόσο μονάδες συναρμολόγησης (ενότητες, βιβλιοθήκες) όσο και μονάδες ανάπτυξης (υπηρεσίες). Οι μονάδες ανάπτυξης δεν αντιστοιχίζονται πάντα στη διαδικασία που εκτελείται: για παράδειγμα, μια εφαρμογή Ιστού και μια βάση δεδομένων αναπτύσσονται μαζί.

Τις περισσότερες φορές, οι μονόλιθοι αναπτύσσονται ως ένα σύνολο ενοτήτων. Αυτή η προσέγγιση οδηγεί σε ανεξάρτητη ανάπτυξη, αλλά τα προβλήματα της ανεξάρτητης κλιμάκωσης και ανάπτυξης, της ανοχής σφαλμάτων και της ανεξαρτησίας από τη συνολική στοίβα τεχνολογίας παραμένουν. Αυτός είναι ο λόγος για τον οποίο η ενότητα είναι ένα μερικώς ανεξάρτητο στοιχείο.

Το μεγαλύτερο πρόβλημα με έναν τέτοιο μονόλιθο είναι ότι η διαίρεση σε ενότητες είναι καθαρά λογική και μπορεί εύκολα να παραβιαστεί από τους προγραμματιστές. Μπορεί να εμφανιστεί μια βασική μονάδα, η οποία σταδιακά μετατρέπεται σε σκουπιδότοπο, το γράφημα των εξαρτήσεων μεταξύ των μονάδων μπορεί να μεγαλώσει και ούτω καθεξής. Για να αποφευχθούν τέτοια προβλήματα, η ανάπτυξη θα πρέπει να πραγματοποιείται είτε από μια πολύ ώριμη ομάδα, είτε υπό την καθοδήγηση ενός «αρχιτέκτονα» που ασχολείται με την πλήρη αναθεώρηση κώδικα και χτυπά τα χέρια των προγραμματιστών που παραβιάζουν τη λογική δομή.

Ο «ιδανικός» μονόλιθος είναι ένα σύνολο από λογικά διαχωρισμένες ενότητες, καθεμία από τις οποίες εξετάζει τη δική της βάση δεδομένων.

Αρχιτεκτονική Προσανατολισμού Υπηρεσιών

Εάν το σύστημα υποτίθεται ότι είναι οργανωμένο με τη μορφή ενός συνόλου υπηρεσιών, τότε μιλάμε για μια αρχιτεκτονική προσανατολισμένη στις υπηρεσίες. Οι αρχές του είναι η διαλειτουργικότητα εφαρμογών με επίκεντρο τον χρήστη, η επαναχρησιμοποίηση επιχειρηματικών υπηρεσιών, η ανεξαρτησία της στοίβας τεχνολογίας και η αυτονομία (ανεξάρτητη εξέλιξη, επεκτασιμότητα και ανάπτυξη).

Η αρχιτεκτονική προσανατολισμένη στις υπηρεσίες (SOA = αρχιτεκτονική προσανατολισμένη στην υπηρεσία) επιλύει όλα τα προβλήματα που έχουν εντοπιστεί σε ένα μονόλιθο: μόνο μία υπηρεσία επηρεάζεται όταν συμβαίνει μια αλλαγή και ένα καλά καθορισμένο API υποστηρίζει καλή ενθυλάκωση στοιχείων.

Αλλά δεν είναι όλα τόσο ομαλά: το SOA δημιουργεί νέα προβλήματα. Οι απομακρυσμένες κλήσεις είναι πιο ακριβές από τις τοπικές και η ανακατανομή των ευθυνών μεταξύ των στοιχείων έχει γίνει σημαντικά πιο ακριβή.

Παρεμπιπτόντως, η δυνατότητα ανεξάρτητης ανάπτυξης είναι ένα πολύ σημαντικό χαρακτηριστικό της υπηρεσίας. Εάν οι υπηρεσίες πρέπει να αναπτυχθούν μαζί ή, επιπλέον, σε μια συγκεκριμένη σειρά, τότε το σύστημα δεν μπορεί να θεωρηθεί προσανατολισμένο στις υπηρεσίες. Σε αυτή την περίπτωση, μιλούν για ένα κατανεμημένο μονόλιθο (θεωρείται ως αντι-μοτίβο όχι μόνο από την άποψη του SOA, αλλά και από την άποψη της αρχιτεκτονικής μικροϋπηρεσιών).

Η αρχιτεκτονική προσανατολισμένη στις υπηρεσίες υποστηρίζεται καλά από την αρχιτεκτονική κοινότητα και τους πωλητές. Αυτό συνεπάγεται την παρουσία πολλών μαθημάτων και πιστοποιήσεων, καλά ανεπτυγμένων μοτίβων. Το τελευταίο περιλαμβάνει, για παράδειγμα, το γνωστό λεωφορείο εξυπηρέτησης επιχειρήσεων (ESB = λεωφορείο εξυπηρέτησης επιχείρησης). Ταυτόχρονα, το ESB είναι μια αποσκευή από τους πωλητές· δεν χρειάζεται απαραίτητα να χρησιμοποιείται στο SOA.

Η δημοτικότητα της αρχιτεκτονικής προσανατολισμένης στις υπηρεσίες κορυφώθηκε γύρω στο 2008, μετά το οποίο άρχισε να μειώνεται, η οποία έγινε σημαντικά πιο δραματική μετά την εμφάνιση των μικροϋπηρεσιών (~2015).

Συμπέρασμα

Αφού συζητήσαμε τις δυνατότητες οργάνωσης των πληροφοριακών συστημάτων με τη μορφή υπηρεσιών και ενοτήτων, προτείνω να προχωρήσουμε επιτέλους στις αρχές της αρχιτεκτονικής μικροϋπηρεσιών και να δώσουμε ιδιαίτερη προσοχή στη διαφορά μεταξύ αρχιτεκτονικής μικροϋπηρεσιών και αρχιτεκτονικής προσανατολισμένης στις υπηρεσίες στο επόμενο μέρος.

Επιλέγοντας ένα αρχιτεκτονικό στυλ (μέρος 2)

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο