Αρχιτεκτονική Λογισμικού και Σχεδιασμός Συστημάτων: Ο οδηγός μεγάλης εικόνας και πόρων

Γεια σας συνάδελφοι.

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

Αρχιτεκτονική Λογισμικού και Σχεδιασμός Συστημάτων: Ο οδηγός μεγάλης εικόνας και πόρων
Δεδομένου ότι είναι απολύτως αδύνατο να καλυφθεί σε ένα άρθρο habro ένα τόσο κολοσσιαίο θέμα όπως αρχιτεκτονικά μοτίβα + σχέδια σχεδίασης από το 2019, προτείνουμε όχι μόνο το ίδιο το κείμενο του κ. Uruglu, αλλά και τους πολυάριθμους συνδέσμους που ευγενικά συμπεριέλαβε σε αυτό. Αν σας αρέσει, θα δημοσιεύσουμε ένα πιο εξειδικευμένο κείμενο για τον σχεδιασμό κατανεμημένων συστημάτων.

Αρχιτεκτονική Λογισμικού και Σχεδιασμός Συστημάτων: Ο οδηγός μεγάλης εικόνας και πόρων

Στιγμιότυπο Ισαάκ Σμιθ από το Unsplash

Εάν δεν χρειάστηκε ποτέ να αντιμετωπίσετε τέτοιες προκλήσεις όπως ο σχεδιασμός ενός συστήματος λογισμικού από την αρχή, τότε όταν ξεκινάτε μια τέτοια εργασία, μερικές φορές δεν είναι καν σαφές από πού να ξεκινήσετε. Πιστεύω ότι πρέπει πρώτα να χαράξετε τα όρια, ώστε να έχετε μια λίγο πολύ σίγουρη ιδέα για το τι ακριβώς θα σχεδιάσετε και μετά να σηκώσετε τα μανίκια σας και να εργαστείτε εντός αυτών των ορίων. Ως σημείο εκκίνησης, μπορείτε να πάρετε ένα προϊόν ή μια υπηρεσία (ιδανικά ένα που σας αρέσει πολύ) και να μάθετε πώς να το εφαρμόσετε. Ίσως εκπλαγείτε με το πόσο απλό φαίνεται αυτό το προϊόν και πόση πολυπλοκότητα περιέχει στην πραγματικότητα. Μην ξεχάσεις: απλό - συνήθως σύνθετο, και δεν πειράζει.

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

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

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

Ρυθμίστε το αρχικό επίπεδο

Τι εννοώ εδώ με τον όρο «βασική γραμμή»; Στην πραγματικότητα, στην εποχή μας, τα περισσότερα προβλήματα στη βιομηχανία λογισμικού «μπορούν» να λυθούν χρησιμοποιώντας υπάρχουσες μεθόδους και τεχνολογίες. Αντίστοιχα, με την πλοήγηση σε αυτό το τοπίο, έχετε ένα ορισμένο ξεκίνημα όταν αντιμετωπίζετε προβλήματα που κάποιος άλλος έπρεπε να λύσει πριν από εσάς. Μην ξεχνάτε ότι τα προγράμματα είναι γραμμένα για να λύνουν προβλήματα επιχειρήσεων και χρηστών, επομένως προσπαθούμε να λύσουμε το πρόβλημα με τον πιο απλό και απλό (από την πλευρά του χρήστη) τρόπο. Γιατί είναι σημαντικό να το θυμάστε αυτό; Ίσως στο σύστημα συντεταγμένων σας αρέσει να αναζητάτε μοναδικές λύσεις για όλα τα προβλήματα, επειδή σκέφτεστε, «τι είδους προγραμματιστής είμαι αν ακολουθώ μοτίβα παντού»; Στην πραγματικότητα, η τέχνη εδώ είναι να παίρνεις αποφάσεις για το πού και τι να κάνεις. Φυσικά, ο καθένας από εμάς πρέπει να αντιμετωπίσει κατά καιρούς μοναδικά προβλήματα, καθένα από τα οποία είναι μια πραγματική πρόκληση. Ωστόσο, εάν το αρχικό μας επίπεδο είναι σαφώς καθορισμένο, τότε ξέρουμε σε τι να ξοδέψουμε την ενέργειά μας: να αναζητήσουμε έτοιμες επιλογές για την επίλυση του προβλήματος που έχουμε μπροστά μας ή να το μελετήσουμε περαιτέρω και να αποκτήσουμε μια βαθύτερη κατανόηση.

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

Εντάξει, από πού να ξεκινήσω; U Ντόνα Μαρτίνα Υπάρχει ένα αποθετήριο στο GitHub που ονομάζεται σύστημα-σχεδιασμός-αστάρι, από το οποίο μπορείτε να μάθετε πώς να σχεδιάζετε συστήματα μεγάλης κλίμακας, καθώς και να προετοιμαστείτε για συνεντεύξεις σχετικά με αυτό το θέμα. Το αποθετήριο έχει μια ενότητα με παραδείγματα πραγματικές αρχιτεκτονικές, όπου, ειδικότερα, εξετάζεται πώς προσεγγίζουν το σχεδιασμό των συστημάτων τους μερικές γνωστές εταιρείεςπχ Twitter, Uber κ.λπ.

Ωστόσο, πριν προχωρήσουμε σε αυτό το υλικό, ας ρίξουμε μια πιο προσεκτική ματιά στις σημαντικότερες αρχιτεκτονικές προκλήσεις που αντιμετωπίζουμε στην πράξη. Αυτό είναι σημαντικό γιατί πρέπει να προσδιορίσετε ΠΟΛΛΕΣ πτυχές ενός επίμονου και πολύπλευρου προβλήματος και στη συνέχεια να το λύσετε στο πλαίσιο των κανονισμών που ισχύουν σε ένα δεδομένο σύστημα. Τζάκσον Γκάμπαρντ, έγραψε ένας πρώην υπάλληλος του Facebook Βίντεο διάρκειας 50 λεπτών για συνεντεύξεις σχεδιασμού συστημάτων, όπου μοιράστηκε τη δική του εμπειρία από τον έλεγχο εκατοντάδων υποψηφίων. Ενώ το βίντεο εστιάζει σε μεγάλο βαθμό στον σχεδιασμό μεγάλων συστημάτων και στα κριτήρια επιτυχίας που είναι σημαντικά όταν αναζητάτε έναν υποψήφιο για μια τέτοια θέση, θα εξακολουθεί να χρησιμεύει ως μια περιεκτική πηγή για το ποια πράγματα είναι πιο σημαντικά κατά το σχεδιασμό συστημάτων. προτείνω κι εγώ περίληψη Αυτό το βίντεο.

Δημιουργήστε γνώσεις σχετικά με την αποθήκευση και την ανάκτηση δεδομένων

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

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

Αρχιτεκτονική Λογισμικού και Σχεδιασμός Συστημάτων: Ο οδηγός μεγάλης εικόνας και πόρων

Στιγμιότυπο Σάμουελ Ζέλερ από το Unsplash

Αφού κατανοήσετε επαρκώς τα διάφορα μοτίβα αποθήκευσης δεδομένων, προχωρήστε στη μελέτη της συνέπειας και της διαθεσιμότητας δεδομένων. Πρώτα απ 'όλα, πρέπει να καταλάβετε Θεώρημα CAP τουλάχιστον σε γενικούς όρους, και στη συνέχεια γυαλίστε αυτή τη γνώση εξετάζοντας πιο προσεκτικά τα καθιερωμένα πρότυπα συνοχή и προσιτότητα. Με αυτόν τον τρόπο, θα κατανοήσετε το πεδίο και θα κατανοήσετε ότι η ανάγνωση και η γραφή δεδομένων είναι στην πραγματικότητα δύο πολύ διαφορετικά προβλήματα, το καθένα με τις δικές του μοναδικές προκλήσεις. Οπλισμένοι με μερικά μοτίβα συνέπειας και διαθεσιμότητας, μπορείτε να αυξήσετε σημαντικά την απόδοση του συστήματος διασφαλίζοντας παράλληλα την ομαλή ροή δεδομένων στις εφαρμογές σας.

Τέλος, ολοκληρώνοντας τη συζήτηση για θέματα αποθήκευσης δεδομένων, θα πρέπει να αναφέρουμε και την προσωρινή αποθήκευση. Πρέπει να εκτελείται ταυτόχρονα στον πελάτη και στον διακομιστή; Ποια δεδομένα θα υπάρχουν στην κρυφή μνήμη σας; Και γιατί? Πώς οργανώνετε την ακύρωση της προσωρινής μνήμης; Θα γίνεται τακτικά, σε συγκεκριμένα χρονικά διαστήματα; Εάν ναι, πόσο συχνά; Συνιστώ να αρχίσετε να μελετάτε αυτά τα θέματα με επόμενη ενότητα το προαναφερθέν αστάρι σχεδιασμού συστήματος.

Μοτίβα Επικοινωνίας

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

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

Αρχιτεκτονική Λογισμικού και Σχεδιασμός Συστημάτων: Ο οδηγός μεγάλης εικόνας και πόρων

Στιγμιότυπο Τόνι Στόνταρντ από το Unsplash

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

Διανομή σύνδεσης

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

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

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

Εξισορρόπηση φορτίου είναι θεμελιωδώς σημαντικό και σχεδόν κάθε μεγάλο σύστημα Διαδικτύου με το οποίο ασχολούμαστε σήμερα βρίσκεται πίσω από έναν ή περισσότερους εξισορροπητές φορτίου. Οι συσκευές εξισορρόπησης φορτίου βοηθούν στη διανομή των αιτημάτων πελατών σε πολλές διαθέσιμες περιπτώσεις. Οι συσκευές εξισορρόπησης φορτίου διατίθενται τόσο σε υλικό όσο και σε λογισμικό, ωστόσο, στην πράξη, πιο συχνά πρέπει να αντιμετωπίζετε λογισμικό, για παράδειγμα HAProxy и ELB. Αντίστροφοι πληρεξούσιοι εννοιολογικά επίσης πολύ παρόμοια με τους εξισορροπητές φορτίου, αν και υπάρχει εύρος μεταξύ του πρώτου και του δεύτερου διακριτές διαφορές. Αυτές οι διαφορές πρέπει να λαμβάνονται υπόψη κατά το σχεδιασμό ενός συστήματος με βάση τις ανάγκες σας.

Θα πρέπει επίσης να γνωρίζετε για δίκτυα παράδοσης περιεχομένου (CDN). Ένα CDN είναι ένα παγκόσμιο κατανεμημένο δίκτυο διακομιστών μεσολάβησης που παρέχει πληροφορίες από εκείνους τους κόμβους που βρίσκονται γεωγραφικά πιο κοντά σε έναν συγκεκριμένο χρήστη. Τα CDN προτιμώνται να χρησιμοποιηθούν εάν εργάζεστε με στατικά αρχεία γραμμένα σε JavaScript, CSS και HTML. Επιπλέον, οι υπηρεσίες cloud που παρέχουν διαχειριστές κυκλοφορίας είναι κοινές σήμερα, για παράδειγμα, Azure Traffic Manager, δίνοντάς σας παγκόσμια διανομή και μειωμένο λανθάνοντα χρόνο όταν εργάζεστε με δυναμικό περιεχόμενο. Ωστόσο, τέτοιες υπηρεσίες είναι συνήθως χρήσιμες σε περιπτώσεις όπου πρέπει να εργαστείτε με υπηρεσίες web ανιθαγενών.

Ας μιλήσουμε για επιχειρηματική λογική. Δόμηση επιχειρηματικής λογικής, ροών εργασιών και στοιχείων

Έτσι, καταφέραμε να συζητήσουμε διάφορες πτυχές υποδομής του συστήματος. Πιθανότατα, ο χρήστης δεν σκέφτεται καν όλα αυτά τα στοιχεία του συστήματός σας και, ειλικρινά, δεν ενδιαφέρεται καθόλου για αυτά. Ο χρήστης ενδιαφέρεται για το πώς είναι η αλληλεπίδραση με το σύστημά σας, τι μπορεί να επιτευχθεί με αυτόν τον τρόπο, καθώς και πώς το σύστημα εκτελεί εντολές χρήστη, τι και πώς κάνει με τα δεδομένα χρήστη.

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

Συνεργατικές προσεγγίσεις

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

Αρχιτεκτονική Λογισμικού και Σχεδιασμός Συστημάτων: Ο οδηγός μεγάλης εικόνας και πόρων

Στιγμιότυπο Καλειδίτικο από το Unsplash

Το πρώτο βήμα είναι να αναπτύξετε μια ακριβή και κοινή κατανόηση του ποιος είναι ο επιχειρηματικός στόχος που προσπαθείτε να επιτύχετε και με ποια κινούμενα μέρη θα πρέπει να αντιμετωπίσετε. Ειδικότερα, τεχνικές μοντελοποίησης ομάδας καταιγιστικά γεγονότα (καταιγίδα εκδηλώσεων) βοηθούν στη σημαντική επιτάχυνση αυτής της διαδικασίας και αυξάνουν τις πιθανότητες επιτυχίας σας. Αυτή η εργασία μπορεί να γίνει πριν ή μετά την περιγραφή του περιγράμματος τα όρια των υπηρεσιών σας, και μετά εμβαθύνετε καθώς ωριμάζει το προϊόν. Με βάση το επίπεδο συνέπειας που θα επιτευχθεί εδώ, μπορείτε επίσης να διατυπώσετε κοινή γλώσσα για το περιορισμένο πλαίσιο στο οποίο εργάζεστε. Όταν χρειάζεται να μιλήσετε για την αρχιτεκτονική του συστήματός σας, μπορεί να σας φανεί χρήσιμο μοντέλο C4, προτείνεται Σάιμον Μπράουν, ειδικά όταν πρέπει να καταλάβετε πόσο θα πρέπει να μπείτε στις λεπτομέρειες του προβλήματος, οπτικοποιώντας τα πράγματα που θέλετε να επικοινωνήσετε.

Υπάρχει πιθανώς μια άλλη ώριμη τεχνολογία σε αυτό το θέμα που δεν είναι λιγότερο χρήσιμη από το Domain Driven Design. Ωστόσο, με κάποιο τρόπο επιστρέφουμε στην κατανόηση της θεματικής περιοχής, άρα γνώση και εμπειρία στον τομέα Σχεδιασμός βάσει τομέα θα πρέπει να είναι χρήσιμο για εσάς.

Πηγή: www.habr.com

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