Ο κόσμος δεν μένει ακίνητος. Η πρόοδος δημιουργεί νέες τεχνολογικές προκλήσεις. Σύμφωνα με τις μεταβαλλόμενες απαιτήσεις, η αρχιτεκτονική των πληροφοριακών συστημάτων πρέπει να εξελιχθεί. Σήμερα θα μιλήσουμε για την αρχιτεκτονική με γνώμονα τα γεγονότα, τη συγχρονικότητα, τη συγχρονία, την ασυγχρονία και πώς μπορείτε να ζήσετε ειρηνικά με όλα αυτά στο Erlang.
Εισαγωγή
Ανάλογα με το μέγεθος του σχεδιασμένου συστήματος και τις απαιτήσεις για αυτό, εμείς, οι προγραμματιστές, επιλέγουμε τη μέθοδο ανταλλαγής πληροφοριών στο σύστημα. Στις περισσότερες περιπτώσεις, για την οργάνωση της αλληλεπίδρασης των υπηρεσιών, μια επιλογή εργασίας μπορεί να είναι ένα σχέδιο με έναν μεσίτη, για παράδειγμα, με βάση το RabbitMQ ή το kafka. Αλλά μερικές φορές η ροή των γεγονότων, το SLA και το επίπεδο ελέγχου του συστήματος είναι τέτοια που τα έτοιμα μηνύματα δεν είναι κατάλληλα για εμάς. Φυσικά, μπορείτε να περιπλέκετε λίγο το σύστημα αναλαμβάνοντας την ευθύνη για το επίπεδο μεταφοράς και το σχηματισμό συμπλέγματος, για παράδειγμα χρησιμοποιώντας ZeroMQ ή nanomsg. Αλλά εάν το σύστημα έχει αρκετή απόδοση και δυνατότητες ενός τυπικού συμπλέγματος Erlang, τότε το ζήτημα της εισαγωγής μιας πρόσθετης οντότητας απαιτεί λεπτομερή μελέτη και οικονομική αιτιολόγηση.
Το θέμα των αντιδραστικών κατανεμημένων εφαρμογών είναι αρκετά ευρύ. Για να παραμείνουμε εντός της μορφής του άρθρου, το θέμα της σημερινής συζήτησης θα είναι μόνο ομοιογενή περιβάλλοντα χτισμένα στο Erlang/Elixir. Το οικοσύστημα Erlang/OTP σάς επιτρέπει να εφαρμόσετε μια αντιδραστική αρχιτεκτονική με τη μικρότερη δυνατή προσπάθεια. Αλλά σε κάθε περίπτωση, θα χρειαστούμε ένα στρώμα μηνυμάτων.
Θεωρητική βάση
Ο σχεδιασμός ξεκινά με τον καθορισμό στόχων και περιορισμών. Ο κύριος στόχος δεν είναι στον τομέα της ανάπτυξης για χάρη της ανάπτυξης. Πρέπει να αποκτήσουμε ένα ασφαλές και επεκτάσιμο εργαλείο βάσει του οποίου μπορούμε να δημιουργήσουμε και, το πιο σημαντικό, να αναπτύξουμε σύγχρονες εφαρμογές διαφόρων επιπέδων: ξεκινώντας από εφαρμογές ενός διακομιστή που εξυπηρετούν ένα μικρό κοινό, το οποίο αργότερα μπορεί να εξελιχθεί σε ομάδες έως 50 -60 κόμβοι, που τελειώνουν με ομοσπονδίες συστάδων. Έτσι, ο κύριος στόχος είναι η μεγιστοποίηση των κερδών με τη μείωση του κόστους ανάπτυξης και ιδιοκτησίας του τελικού συστήματος.
Ας επισημάνουμε 4 βασικές απαιτήσεις για το τελικό σύστημα:
- Сπροσανατολισμένη σε εκδηλώσεις.
Το σύστημα είναι πάντα έτοιμο να περάσει από τη ροή των γεγονότων και να εκτελέσει τις απαραίτητες ενέργειες. - Мεπεκτασιμότητα.
Τα μεμονωμένα μπλοκ μπορούν να κλιμακωθούν τόσο κατακόρυφα όσο και οριζόντια. Ολόκληρο το σύστημα πρέπει να είναι ικανό για άπειρη οριζόντια ανάπτυξη. - Оανοχή σε σφάλματα.
Όλα τα επίπεδα και όλες οι υπηρεσίες θα πρέπει να μπορούν να ανακτούν αυτόματα από βλάβες. - Гεγγυημένος χρόνος απόκρισης.
Ο χρόνος είναι πολύτιμος και οι χρήστες δεν πρέπει να περιμένουν πολύ.
Θυμάστε το παλιό παραμύθι για το «Η μικρή μηχανή που μπορούσε»; Προκειμένου το σχεδιασμένο σύστημα να εξέλθει με επιτυχία από το στάδιο του πρωτοτύπου και να είναι προοδευτικό, η ίδρυσή του πρέπει να πληροί τις ελάχιστες απαιτήσεις ΝΕΦΟΣ.
Ένα ακόμη σημείο προστίθεται στα μηνύματα ως εργαλείο υποδομής και βάση για όλες τις υπηρεσίες: ευκολία χρήσης για προγραμματιστές.
Με γνώμονα την εκδήλωση
Για να αναπτυχθεί μια εφαρμογή από έναν μόνο διακομιστή σε ένα σύμπλεγμα, η αρχιτεκτονική της πρέπει να υποστηρίζει χαλαρή σύζευξη. Το ασύγχρονο μοντέλο πληροί αυτήν την απαίτηση. Σε αυτό, ο αποστολέας και ο παραλήπτης ενδιαφέρονται για το φορτίο πληροφοριών του μηνύματος και δεν ανησυχούν για τη μετάδοση και τη δρομολόγηση εντός του συστήματος.
Επεκτασιμότητα
Η επεκτασιμότητα και η αποτελεσματικότητα του συστήματος είναι το ένα δίπλα στο άλλο. Τα στοιχεία της εφαρμογής πρέπει να μπορούν να χρησιμοποιούν όλους τους διαθέσιμους πόρους. Όσο πιο αποτελεσματικά μπορούμε να χρησιμοποιήσουμε τη χωρητικότητα και όσο πιο βέλτιστες οι μέθοδοι επεξεργασίας μας, τόσο λιγότερα χρήματα ξοδεύουμε για εξοπλισμό.
Μέσα σε ένα μόνο μηχάνημα, η Erlang δημιουργεί ένα εξαιρετικά ανταγωνιστικό περιβάλλον. Η ισορροπία μεταξύ συγχρονισμού και παραλληλισμού μπορεί να οριστεί επιλέγοντας τον αριθμό των νημάτων του λειτουργικού συστήματος που είναι διαθέσιμα στο Erlang VM και τον αριθμό των προγραμματιστών που χρησιμοποιούν αυτά τα νήματα.
Οι διαδικασίες Erlang δεν μοιράζονται την κατάσταση και λειτουργούν σε λειτουργία μη αποκλεισμού. Αυτό παρέχει σχετικά χαμηλή καθυστέρηση και υψηλότερη απόδοση από τις παραδοσιακές εφαρμογές που βασίζονται σε αποκλεισμό. Ο προγραμματιστής της Erlang διασφαλίζει δίκαιη κατανομή της CPU και του IO και η απουσία αποκλεισμού επιτρέπει στην εφαρμογή να ανταποκρίνεται ακόμη και κατά τη διάρκεια φορτίων αιχμής ή αστοχιών.
Σε επίπεδο συστάδας, το πρόβλημα με την απόρριψη υπάρχει επίσης. Είναι σημαντικό όλα τα μηχανήματα στο σύμπλεγμα να είναι ομοιόμορφα φορτωμένα και να μην υπερφορτώνεται το δίκτυο. Ας φανταστούμε μια κατάσταση: η κίνηση των χρηστών προσγειώνεται σε εισερχόμενους εξισορροπητές (haproxy, nginx, κ.λπ.), κατανέμουν τα αιτήματα επεξεργασίας όσο το δυνατόν πιο ομοιόμορφα μεταξύ του συνόλου των διαθέσιμων backend. Εντός της υποδομής εφαρμογής, η υπηρεσία που υλοποιεί την απαιτούμενη διεπαφή είναι μόνο το τελευταίο μίλι και θα χρειαστεί να ζητήσει μια σειρά από άλλες υπηρεσίες για να ανταποκριθεί στο αρχικό αίτημα. Τα εσωτερικά αιτήματα απαιτούν επίσης δρομολόγηση και εξισορρόπηση.
Για την αποτελεσματική διαχείριση των ροών δεδομένων, τα μηνύματα πρέπει να παρέχουν στους προγραμματιστές μια διεπαφή για τη διαχείριση της δρομολόγησης και της εξισορρόπησης φορτίου. Χάρη σε αυτό, οι προγραμματιστές θα μπορούν, χρησιμοποιώντας μοτίβα μικροϋπηρεσιών (συγκεντρωτή, διακομιστή μεσολάβησης, αλυσίδα, διακλάδωση, κ.λπ.), να επιλύουν τόσο τυπικά προβλήματα όσο και εκείνα που προκύπτουν σπάνια.
Από επιχειρηματική άποψη, η επεκτασιμότητα είναι ένα από τα εργαλεία διαχείρισης κινδύνου. Το κύριο πράγμα είναι να ικανοποιηθούν τα αιτήματα των πελατών με τη βέλτιστη χρήση του εξοπλισμού:
- Όταν η ισχύς του εξοπλισμού αυξάνεται ως αποτέλεσμα της προόδου. Δεν θα είναι αδρανές λόγω ατελούς λογισμικού. Το Erlang κλιμακώνεται κάθετα καλά και θα μπορεί πάντα να χρησιμοποιεί όλους τους πυρήνες της CPU και τη διαθέσιμη μνήμη.
- Σε περιβάλλοντα cloud, μπορούμε να διαχειριστούμε την ποσότητα του εξοπλισμού ανάλογα με το τρέχον ή το προβλεπόμενο φορτίο και να εγγυηθούμε SLA.
ανοχή σε σφάλματα
Ας εξετάσουμε δύο αξιώματα: «Οι αποτυχίες είναι απαράδεκτες» και «Πάντα θα υπάρχουν αποτυχίες». Για μια επιχείρηση, η αποτυχία λογισμικού σημαίνει απώλεια χρημάτων και, το χειρότερο, απώλεια φήμης. Εξισορροπώντας τις πιθανές απώλειες και το κόστος ανάπτυξης λογισμικού με ανοχή σε σφάλματα, μπορεί συχνά να βρεθεί ένας συμβιβασμός.
Βραχυπρόθεσμα, μια αρχιτεκτονική που ενσωματώνει την ανοχή σφαλμάτων εξοικονομεί χρήματα για την αγορά λύσεων ομαδοποίησης off-the-shelf. Είναι ακριβά και έχουν και σφάλματα.
Μακροπρόθεσμα, μια αρχιτεκτονική ανεκτική σε σφάλματα αποδίδει πολλαπλάσια σε όλα τα στάδια ανάπτυξης.
Η ανταλλαγή μηνυμάτων εντός της βάσης κώδικα σάς επιτρέπει να επεξεργαστείτε λεπτομερώς την αλληλεπίδραση των στοιχείων εντός του συστήματος στο στάδιο ανάπτυξης. Αυτό απλοποιεί το έργο της απόκρισης και της διαχείρισης αστοχιών, καθώς όλα τα κρίσιμα εξαρτήματα χειρίζονται τις αστοχίες και το προκύπτον σύστημα ξέρει πώς να επανέρχεται αυτόματα στο κανονικό μετά από μια αποτυχία από το σχεδιασμό.
Αποκριτικότητα
Ανεξάρτητα από αποτυχίες, η εφαρμογή πρέπει να ανταποκρίνεται σε αιτήματα και να πληροί το SLA. Η πραγματικότητα είναι ότι οι άνθρωποι δεν θέλουν να περιμένουν, επομένως οι επιχειρήσεις πρέπει να προσαρμοστούν ανάλογα. Όλο και περισσότερες εφαρμογές αναμένεται να έχουν υψηλή απόκριση.
Οι αποκριτικές εφαρμογές λειτουργούν σχεδόν σε πραγματικό χρόνο. Το Erlang VM λειτουργεί σε ήπια λειτουργία σε πραγματικό χρόνο. Για ορισμένους τομείς, όπως το χρηματιστήριο, η ιατρική και ο έλεγχος βιομηχανικού εξοπλισμού, η λειτουργία σκληρού σε πραγματικό χρόνο είναι σημαντική.
Τα συστήματα απόκρισης βελτιώνουν το UX και ωφελούν την επιχείρηση.
Προκαταρκτική περίληψη
Κατά τον σχεδιασμό αυτού του άρθρου, ήθελα να μοιραστώ την εμπειρία μου από τη δημιουργία ενός μεσίτη ανταλλαγής μηνυμάτων και τη δημιουργία πολύπλοκων συστημάτων που βασίζονται σε αυτό. Αλλά το θεωρητικό και το κίνητρο μέρος αποδείχθηκε αρκετά εκτεταμένο.
Στο δεύτερο μέρος του άρθρου, θα μιλήσω για τις αποχρώσεις της υλοποίησης σημείων ανταλλαγής, μοτίβων ανταλλαγής μηνυμάτων και την εφαρμογή τους.
Στο τρίτο μέρος θα εξετάσουμε γενικά θέματα οργάνωσης υπηρεσιών, δρομολόγησης και εξισορρόπησης. Ας μιλήσουμε για την πρακτική πλευρά της επεκτασιμότητας και της ανοχής σε σφάλματα των συστημάτων.
Τέλος πρώτου μέρους.
Φωτογραφία .
Πηγή: www.habr.com