Πώς να αντιμετωπίσετε την πολυπλοκότητα κατά το σχεδιασμό συστημάτων λογισμικού

Τι είναι αυτό; Καθημερινά, κάθε στιγμή κατά τη διάρκεια της καριέρας μας στη μηχανική, αντιμετωπίζουμε πολλά διαφορετικά προβλήματα ποικίλης πολυπλοκότητας και καταστάσεις όπου πρέπει να πάρουμε μια απόφαση ή να την αναβάλουμε λόγω έλλειψης δεδομένων. Κάθε φορά που χτίζουμε νέες υπηρεσίες, κατασκευάζουμε υποδομές ή ακόμη και διαμορφώνουμε διαδικασίες ανάπτυξης, αγγίζουμε έναν τεράστιο κόσμο διαφόρων προκλήσεων. Είναι δύσκολο, και ίσως ακόμη και αδύνατο, να απαριθμήσουμε όλα τα προβλήματα. Θα αντιμετωπίσετε μερικά από αυτά τα ζητήματα μόνο εάν εργάζεστε σε μια συγκεκριμένη θέση. Από την άλλη πλευρά, υπάρχουν πολλά που πρέπει όλοι να καταλάβουμε πώς να λύσουμε, καθώς είναι ζωτικής σημασίας για την κατασκευή συστημάτων πληροφορικής. Με μεγάλη πιθανότητα θα τα συναντήσετε σε όλα τα έργα. Σε αυτό το άρθρο, θα μοιραστώ τις εμπειρίες μου με ορισμένα από τα προβλήματα που αντιμετώπισα κατά τη δημιουργία προγραμμάτων λογισμικού. Τι είναι το CrossCutting Concern; Αν κοιτάξουμε στη Wikipedia, θα βρούμε τον ακόλουθο ορισμό Στην ανάπτυξη λογισμικού προσανατολισμένη στις πτυχές, οι εγκάρσιες ανησυχίες είναι πτυχές ενός προγράμματος που επηρεάζουν πολλές ενότητες, χωρίς τη δυνατότητα να ενσωματωθούν σε καμία από αυτές. Αυτές οι ανησυχίες συχνά δεν μπορούν να αποσυντεθούν καθαρά από το υπόλοιπο σύστημα τόσο στη σχεδίαση όσο και στην υλοποίηση και μπορεί να οδηγήσουν είτε σε διασπορά (διπλασιασμός κώδικα), μπέρδεμα (σημαντικές εξαρτήσεις μεταξύ συστημάτων) ή και στα δύο. Περιγράφει πολύ τι είναι, αλλά θέλω να το επεκτείνω και να το απλοποιήσω λίγο: Μια είναι μια έννοια ή στοιχείο του συστήματος/οργανισμού που επηρεάζει (ή «τείνει») πολλά άλλα μέρη. οριζόντια ανησυχία Τα καλύτερα παραδείγματα τέτοιων ανησυχιών είναι η αρχιτεκτονική συστήματος, η καταγραφή, η ασφάλεια, η διαχείριση συναλλαγών, η τηλεμετρία, ο σχεδιασμός βάσεων δεδομένων και υπάρχουν πολλά άλλα. Θα αναλύσουμε πολλά από αυτά αργότερα σε αυτό το άρθρο. Σε επίπεδο κώδικα, οι εγκάρσιες ανησυχίες υλοποιούνται συχνά χρησιμοποιώντας τεχνικές όπως , όπου αυτές οι ανησυχίες διαμορφώνονται σε ξεχωριστά στοιχεία που μπορούν να εφαρμοστούν σε όλη την εφαρμογή. Αυτό διατηρεί την επιχειρηματική λογική απομονωμένη από αυτές τις ανησυχίες, καθιστώντας τον κώδικα πιο ευανάγνωστο και διατηρήσιμο. ο Προγραμματισμός με προσανατολισμό στις όψεις (AOP) Ταξινόμηση πτυχών Υπάρχουν πολλοί πιθανοί τρόποι ταξινόμησης πτυχών τμηματοποιώντας τις με διαφορετικές ιδιότητες όπως εύρος, μέγεθος, λειτουργικότητα, σημασία, στόχος και άλλα, αλλά σε αυτό το άρθρο θα χρησιμοποιήσω μια απλή ταξινόμηση εύρους. Με αυτό, εννοώ όπου κατευθύνεται αυτή η συγκεκριμένη πτυχή είτε πρόκειται για ολόκληρο τον οργανισμό, ένα συγκεκριμένο σύστημα ή ένα συγκεκριμένο στοιχείο αυτού του συστήματος. Λοιπόν, θα χωρίσω τις πτυχές σε και . Macro Micro Με τον πτυχή εννοώ κυρίως ζητήματα που ακολουθούμε για ολόκληρο το σύστημα, όπως η επιλεγμένη αρχιτεκτονική συστήματος και ο σχεδιασμός του (μονολιθική, μικροϋπηρεσίες, αρχιτεκτονική προσανατολισμένη στις υπηρεσίες), στοίβα τεχνολογίας, δομή οργάνωσης, κ.λπ. αποφάσεις. όρο μακροσκοπική Εν τω μεταξύ, η πτυχή είναι πολύ πιο κοντά στο επίπεδο κώδικα και την ανάπτυξη. Για παράδειγμα, ποιο πλαίσιο χρησιμοποιείται για την αλληλεπίδραση με τη βάση δεδομένων, τη δομή του έργου φακέλων και κλάσεων ή ακόμα και συγκεκριμένα μοτίβα σχεδίασης αντικειμένων. Micro Αν και αυτή η ταξινόμηση δεν είναι ιδανική, βοηθά στη δομή της κατανόησης των πιθανών προβλημάτων και της σημασίας και του αντίκτυπου των λύσεων που εφαρμόζουμε σε αυτά. Σε αυτό το άρθρο, η κύρια εστίασή μου θα είναι στις μακροοικονομικές πτυχές. Μακροόψεις Οργανωτική δομή Όταν μόλις άρχισα να μαθαίνω για την αρχιτεκτονική λογισμικού, διάβασα πολλά ενδιαφέροντα άρθρα σχετικά με το νόμο του Conway και τον αντίκτυπό του στην οργανωτική δομή. Ειδικά . Άρα, αυτός ο νόμος το λέει αυτό Κάθε οργανισμός που σχεδιάζει ένα σύστημα (που ορίζεται ευρέως) θα παράγει ένα σχέδιο του οποίου η δομή είναι αντίγραφο της δομής επικοινωνίας του οργανισμού. Πάντα πίστευα ότι αυτή η έννοια είναι πράγματι πολύ καθολική και αντιπροσωπεύει τον Χρυσό Κανόνα. Στη συνέχεια άρχισα να μαθαίνω την προσέγγιση Domain-Driven Design (DDD) του Eric Evans για συστήματα μοντελοποίησης. Ο Έρικ Έβανς τονίζει τη σημασία της αναγνώρισης περιορισμένου πλαισίου. Αυτή η ιδέα περιλαμβάνει τη διαίρεση ενός σύνθετου μοντέλου τομέα σε μικρότερα, πιο διαχειρίσιμα τμήματα, το καθένα με το δικό του περιορισμένο σύνολο γνώσεων. Αυτή η προσέγγιση βοηθά στην αποτελεσματική ομαδική επικοινωνία, καθώς μειώνει την ανάγκη για εκτενή γνώση ολόκληρου του τομέα και ελαχιστοποιεί την εναλλαγή περιβάλλοντος, καθιστώντας έτσι τις συνομιλίες πιο αποτελεσματικές. Η εναλλαγή περιβάλλοντος είναι ό,τι χειρότερο και καταναλώνει περισσότερο πόρους. Ακόμη και οι υπολογιστές παλεύουν με αυτό. Αν και είναι απίθανο να επιτύχουμε πλήρη απουσία εναλλαγής περιβάλλοντος, πιστεύω ότι αυτό είναι που πρέπει να επιδιώξουμε. Επιστρέφοντας στο νόμο του Conway, έχω βρει αρκετά προβλήματα με αυτόν. που αντιμετώπισα με τον νόμο του Conway, ο οποίος προτείνει ότι ο σχεδιασμός του συστήματος αντικατοπτρίζει την οργανωτική δομή, είναι η δυνατότητα σχηματισμού πολύπλοκων και περιεκτικών οριοθετημένων πλαισίων. Αυτή η πολυπλοκότητα προκύπτει όταν η οργανωτική δομή δεν είναι ευθυγραμμισμένη με τα όρια τομέα, οδηγώντας σε Bounded Contexts που είναι σε μεγάλο βαθμό αλληλεξαρτώμενα και φορτωμένα με πληροφορίες. Οδηγεί σε συχνή εναλλαγή πλαισίου για την ομάδα ανάπτυξης. Το πρώτο ζήτημα είναι ότι η οργανωτική ορολογία διαρρέει σε επίπεδο κώδικα. Όταν αλλάζουν οι οργανωτικές δομές, απαιτούνται τροποποιήσεις της βάσης κώδικα, καταναλώνοντας πολύτιμους πόρους. Ένα άλλο ζήτημα Έτσι, ακολουθώντας βοηθά στη δημιουργία του συστήματος και της οργάνωσης που ενθαρρύνουν την επιθυμητή αρχιτεκτονική λογισμικού. Ωστόσο, είναι αξιοσημείωτο να πούμε ότι αυτή η προσέγγιση δεν θα λειτουργήσει πολύ καλά σε ήδη διαμορφωμένη αρχιτεκτονική και δομές, καθώς οι αλλαγές σε αυτό το στάδιο είναι παρατεταμένες, αλλά έχει εξαιρετική απόδοση σε νεοφυείς επιχειρήσεις, καθώς εισάγουν γρήγορα οποιεσδήποτε αλλαγές. τον ελιγμό Inverse Conway Big Ball of Mud Αυτό το μοτίβο ή το «αντι-μοτίβο» οδηγεί στην κατασκευή ενός συστήματος χωρίς καμία αρχιτεκτονική. Δεν υπάρχουν κανόνες, όρια και στρατηγική για τον έλεγχο της αναπόφευκτης αυξανόμενης πολυπλοκότητας. Η πολυπλοκότητα είναι ο πιο τρομερός εχθρός στο ταξίδι της κατασκευής συστημάτων λογισμικού. Για να αποφύγουμε την κατασκευή ενός τέτοιου τύπου συστήματος, πρέπει να ακολουθήσουμε συγκεκριμένους κανόνες και περιορισμούς. Αρχιτεκτονική συστήματος Υπάρχουν μυριάδες ορισμοί για την Αρχιτεκτονική Λογισμικού. Μου αρέσουν πολλά από αυτά αφού καλύπτουν διαφορετικές πτυχές του. Ωστόσο, για να μπορέσουμε να συλλογιστούμε για την αρχιτεκτονική, χρειάζεται φυσικά να σχηματίσουμε μερικά από αυτά στο μυαλό μας. Και είναι αξιοσημείωτο να πούμε ότι αυτός ο ορισμός μπορεί να εξελιχθεί. Έτσι, τουλάχιστον προς το παρόν, έχω την εξής περιγραφή για τον εαυτό μου. αφορά αποφάσεις και επιλογές που κάνετε καθημερινά και επηρεάζουν το ενσωματωμένο σύστημα. Η Αρχιτεκτονική Λογισμικού Για να λάβετε αποφάσεις που πρέπει να έχετε στο «τσαντάκι» σας αρχές και μοτίβα για την επίλυση προβλημάτων που προκύπτουν, είναι επίσης σημαντικό να δηλώσετε ότι η κατανόηση των απαιτήσεων είναι το κλειδί για τη δημιουργία αυτού που χρειάζεται μια επιχείρηση. Ωστόσο, μερικές φορές οι απαιτήσεις δεν είναι διαφανείς ή ακόμη και δεν καθορίζονται, σε αυτήν την περίπτωση, είναι καλύτερο να περιμένετε να λάβετε περισσότερες διευκρινίσεις ή να βασιστείτε στην εμπειρία σας και να εμπιστευτείτε τη διαίσθησή σας. Αλλά ούτως ή άλλως, δεν μπορείτε να πάρετε αποφάσεις σωστά αν δεν έχετε αρχές και πρότυπα στα οποία να βασιστείτε. Εκεί έρχομαι στον ορισμό του Στυλ Αρχιτεκτονικής Λογισμικού. είναι ένα σύνολο αρχών και προτύπων που καθορίζουν τον τρόπο κατασκευής λογισμικού. Το Software Architecture Style Υπάρχουν πολλά διαφορετικά αρχιτεκτονικά στυλ που επικεντρώνονται σε διάφορες πλευρές της σχεδιασμένης αρχιτεκτονικής και η εφαρμογή πολλαπλών από αυτά ταυτόχρονα είναι μια φυσιολογική κατάσταση. Για παράδειγμα, όπως: Μονολιθική αρχιτεκτονική Σχεδιασμός βάσει τομέα Βασισμένο σε εξαρτήματα Μικροϋπηρεσίες Σωλήνας και φίλτρα Με γνώμονα την εκδήλωση Μικροπυρήνα Προσανατολισμένη στις υπηρεσίες και ούτω καθεξής… Φυσικά, έχουν τα πλεονεκτήματα και τα μειονεκτήματά τους, αλλά το πιο σημαντικό πράγμα που έχω μάθει είναι ότι η αρχιτεκτονική εξελίσσεται σταδιακά ενώ εξαρτάται από τα πραγματικά προβλήματα. Ξεκινώντας με τη μονολιθική αρχιτεκτονική είναι μια εξαιρετική επιλογή για τη μείωση της λειτουργικής πολυπλοκότητας, πολύ πιθανόν αυτή η αρχιτεκτονική να ταιριάζει στις ανάγκες σας ακόμα και αφού φτάσετε στο στάδιο Προσαρμογής στην αγορά προϊόντος (PMI) της κατασκευής του προϊόντος. Σε κλίμακα, μπορείτε να εξετάσετε το ενδεχόμενο να κινηθείτε προς μια προσέγγιση με γνώμονα τα συμβάντα και τις μικροϋπηρεσίες για την επίτευξη ανεξάρτητης ανάπτυξης, ετερογενούς περιβάλλοντος στοίβας τεχνολογίας και λιγότερο συζευγμένης αρχιτεκτονικής (και λιγότερο διαφανής στο μεταξύ λόγω της φύσης των προσεγγίσεων που βασίζονται σε εκδηλώσεις και pub-sub, εάν αυτά υιοθετούνται). Η απλότητα και η αποτελεσματικότητα είναι κοντά και έχουν μεγάλη επίδραση το ένα στο άλλο. Συνήθως, οι περίπλοκες αρχιτεκτονικές επηρεάζουν την ταχύτητα ανάπτυξης νέων χαρακτηριστικών, υποστηρίζοντας και διατηρώντας τις υπάρχουσες και αμφισβητώντας τη φυσική εξέλιξη του συστήματος. Ωστόσο, τα πολύπλοκα συστήματα απαιτούν συχνά περίπλοκη και ολοκληρωμένη αρχιτεκτονική, κάτι που είναι αναπόφευκτο. Δικαίως, αυτό είναι ένα πολύ ευρύ θέμα και υπάρχουν πολλές εξαιρετικές ιδέες σχετικά με τον τρόπο δομής και κατασκευής συστημάτων για τη φυσική εξέλιξη. Με βάση την εμπειρία μου, έχω επεξεργαστεί την ακόλουθη προσέγγιση: Σχεδόν πάντα ξεκινά με τη μονολιθική αρχιτεκτονική, καθώς εξαλείφει τα περισσότερα προβλήματα που προκύπτουν λόγω της φύσης των κατανεμημένων συστημάτων. Είναι επίσης λογικό να ακολουθήσετε το modular monolith για να εστιάσετε σε δομικά στοιχεία με σαφή όρια. Η εφαρμογή μιας προσέγγισης βασισμένης σε στοιχεία θα μπορούσε να τους βοηθήσει να επικοινωνούν μεταξύ τους χρησιμοποιώντας συμβάντα, αλλά η ύπαρξη άμεσων κλήσεων (γνωστός και ως RPC) απλοποιεί τα πράγματα στην αρχή. Ωστόσο, είναι σημαντικό να παρακολουθείτε τις εξαρτήσεις μεταξύ των στοιχείων, καθώς εάν το συστατικό Α γνωρίζει πολλά για το στοιχείο Β, ίσως είναι λογικό να τα συγχωνεύσει σε ένα. Όταν πλησιάζετε πιο κοντά στην κατάσταση που πρέπει να κλιμακώσετε την ανάπτυξη και το σύστημά σας, θα μπορούσατε να εξετάσετε το ενδεχόμενο να ακολουθήσετε το μοτίβο για να εξαγάγετε σταδιακά στοιχεία που πρέπει να αναπτυχθούν ανεξάρτητα ή ακόμη και να κλιμακωθούν με συγκεκριμένες απαιτήσεις. Stangler Τώρα, αν έχετε ένα ξεκάθαρο όραμα για το μέλλον, το οποίο είναι λίγο απίστευτη τύχη, θα μπορούσατε να αποφασίσετε για την επιθυμητή αρχιτεκτονική. Αυτή τη στιγμή, θα μπορούσατε να αποφασίσετε να προχωρήσετε προς την αρχιτεκτονική μικροϋπηρεσιών εφαρμόζοντας επίσης προσεγγίσεις ενορχήστρωσης και χορογραφίας, ενσωματώνοντας μοτίβο CQRS για λειτουργίες εγγραφής και ανάγνωσης ανεξάρτητης κλίμακας ή ακόμη και αποφασίζοντας να παραμείνετε σε μονολιθική αρχιτεκτονική εάν ταιριάζει στις ανάγκες σας. Είναι επίσης ζωτικής σημασίας να κατανοήσετε τους αριθμούς και τις μετρήσεις όπως (Ημερήσιοι ενεργοί χρήστες), (Μηνιαία ενεργοί χρήστες), (Αίτηση ανά δευτερόλεπτο) και (Συναλλαγή ανά δευτερόλεπτο), καθώς θα μπορούσε να σας βοηθήσει να κάνετε επιλογές, επειδή η αρχιτεκτονική για 100 ενεργοί χρήστες και 100 εκατομμύρια ενεργοί χρήστες είναι διαφορετικοί. DAU MAU RPC TPC Ως τελευταία σημείωση, θα έλεγα ότι η αρχιτεκτονική έχει σημαντικό αντίκτυπο στην επιτυχία του προϊόντος. Απαιτείται κακώς σχεδιασμένη αρχιτεκτονική για τα προϊόντα στην κλιμάκωση, η οποία πολύ πιθανόν οδηγεί σε αποτυχία, καθώς οι πελάτες δεν θα περιμένουν όσο κλιμακώνετε το σύστημα, θα επιλέξουν έναν ανταγωνιστή, επομένως πρέπει να είμαστε μπροστά από την πιθανή κλιμάκωση. Από την άλλη πλευρά, το να έχετε ένα πολύ περίπλοκο και ήδη κλιμακούμενο σύστημα χωρίς πελάτες ή σχέδια να αποκτήσετε πολλούς από αυτούς, θα σας κοστίσει χρήματα στην επιχείρησή σας για τίποτα. Αν και ομολογώ ότι μερικές φορές δεν θα μπορούσε να είναι μια λιτή προσέγγιση, η ιδέα είναι να έχουμε ένα επεκτάσιμο αλλά όχι ήδη κλιμακούμενο σύστημα. Επιλογή στοίβας τεχνολογίας Η επιλογή μιας στοίβας τεχνολογίας είναι επίσης μια απόφαση μακροεπίπεδου, καθώς επηρεάζει τις προσλήψεις, τις προοπτικές φυσικής εξέλιξης του συστήματος, την επεκτασιμότητα και την απόδοση του συστήματος. Αυτή είναι η λίστα με τα βασικά στοιχεία για την επιλογή μιας στοίβας τεχνολογίας: Για παράδειγμα, μια απλή εφαρμογή Ιστού μπορεί να δημιουργηθεί με το πλαίσιο Blazor εάν οι προγραμματιστές σας έχουν εμπειρία με αυτό, αλλά λόγω της έλλειψης ωριμότητας του WebAssembly, η επιλογή React και Typescript για μακροπρόθεσμη επιτυχία θα μπορούσε να είναι καλύτερη απόφαση Απαιτήσεις και πολυπλοκότητα του έργου. Εάν αναμένετε να λάβετε μεγάλο όγκο επισκεψιμότητας, η επιλογή του ASP.NET Core έναντι του Django θα μπορούσε να είναι μια σοφή επιλογή λόγω της ανώτερης απόδοσής του στον χειρισμό ταυτόχρονων αιτημάτων. Ωστόσο, αυτή η απόφαση εξαρτάται από την κλίμακα επισκεψιμότητας που περιμένετε. Εάν χρειάζεται να διαχειριστείτε δυνητικά δισεκατομμύρια αιτήματα με χαμηλό λανθάνοντα χρόνο, η παρουσία του Garbage Collection θα μπορούσε να είναι μια πρόκληση. Επεκτασιμότητα και Ανάγκες Απόδοσης. Στις περισσότερες περιπτώσεις, αυτοί είναι οι παράγοντες που πρέπει να προσέχουμε. Ο χρόνος για την αγορά, το κόστος συντήρησης και η σταθερότητα πρόσληψης οδηγούν τις ανάγκες της επιχείρησής σας χωρίς εμπόδια. Πρόσληψη, Χρόνος Ανάπτυξης και Κόστος. Το σύνολο δεξιοτήτων της ομάδας ανάπτυξής σας είναι ένας κρίσιμος παράγοντας. Είναι γενικά πιο αποτελεσματικό να χρησιμοποιείτε τεχνολογίες με τις οποίες η ομάδα σας είναι ήδη εξοικειωμένη, εκτός εάν υπάρχει ισχυρός λόγος να επενδύσετε στην εκμάθηση μιας νέας στοίβας. Εμπειρογνωμοσύνη και πόροι της ομάδας. Μια ισχυρή κοινότητα και ένα πλούσιο οικοσύστημα βιβλιοθηκών και εργαλείων μπορούν να διευκολύνουν σημαντικά τη διαδικασία ανάπτυξης. Οι δημοφιλείς τεχνολογίες έχουν συχνά καλύτερη υποστήριξη από την κοινότητα, η οποία μπορεί να είναι ανεκτίμητη για την επίλυση προβλημάτων και την εύρεση πόρων. Έτσι, θα μπορούσατε να εξοικονομήσετε πόρους και να εστιάσετε κυρίως στο προϊόν. Ωριμότητα. Σκεφτείτε τη μακροπρόθεσμη βιωσιμότητα της τεχνολογίας. Οι τεχνολογίες που υιοθετούνται και υποστηρίζονται ευρέως είναι λιγότερο πιθανό να καταστούν παρωχημένες και γενικά να λαμβάνουν τακτικές ενημερώσεις και βελτιώσεις. Μακροχρόνια Συντήρηση και Υποστήριξη. Πώς η ύπαρξη πολλαπλών στοίβων τεχνολογίας θα μπορούσε να επηρεάσει την ανάπτυξη της επιχείρησης; Από μια άποψη, η εισαγωγή μιας ακόμη στοίβας θα μπορούσε να κλιμακώσει την πρόσληψή σας, αλλά από την άλλη πλευρά, επιφέρει επιπλέον κόστος συντήρησης, καθώς πρέπει να υποστηρίξετε και τις δύο στοίβες. Έτσι, όπως είπα προηγουμένως, κατά την άποψή μου, μόνο η επιπλέον ανάγκη θα πρέπει να είναι επιχείρημα για την ενσωμάτωση περισσότερων τεχνολογικών στοίβων. Τι ισχύει όμως για την αρχή της επιλογής του καλύτερου εργαλείου για ένα συγκεκριμένο πρόβλημα; Μερικές φορές δεν έχετε άλλη επιλογή από το να φέρετε νέα εργαλεία για την επίλυση ενός συγκεκριμένου προβλήματος με βάση τις ίδιες σκέψεις που αναφέρθηκαν, σε τέτοιες περιπτώσεις, είναι λογικό να επιλέξετε την καλύτερη λύση. Η δημιουργία συστημάτων χωρίς υψηλή σύζευξη με μια συγκεκριμένη τεχνολογία θα μπορούσε να είναι μια πρόκληση. Ωστόσο, είναι χρήσιμο να αγωνιζόμαστε για μια κατάσταση όπου το σύστημα δεν είναι στενά συνδεδεμένο με την τεχνολογία και δεν θα πεθάνει εάν αύριο, ένα συγκεκριμένο πλαίσιο ή εργαλείο γίνει ευάλωτο ή ακόμη και καταργηθεί. Μια άλλη σημαντική παράμετρος σχετίζεται με τις εξαρτήσεις λογισμικού ανοιχτού κώδικα και αποκλειστικού λογισμικού. Το ιδιόκτητο λογισμικό σάς δίνει λιγότερη ευελιξία και τη δυνατότητα προσαρμογής. Ωστόσο, ο πιο επικίνδυνος παράγοντας είναι το κλείδωμα του προμηθευτή, όπου εξαρτάστε από τα προϊόντα, τις τιμές, τους όρους και τον οδικό χάρτη ενός πωλητή. Αυτό μπορεί να είναι επικίνδυνο εάν ο πωλητής αλλάξει κατεύθυνση, αυξήσει τις τιμές ή διακόψει το προϊόν. Η εξάλειψη ενός μόνο σημείου αποτυχίας σε όλα τα επίπεδα είναι το κλειδί για τη δημιουργία αξιόπιστων συστημάτων ανάπτυξης. Το λογισμικό ανοιχτού κώδικα μειώνει αυτόν τον κίνδυνο, καθώς μια μεμονωμένη οντότητα δεν τον ελέγχει. Single Point of Failure (SPOF) Ένα μοναδικό σημείο αστοχίας (SPOF) αναφέρεται σε οποιοδήποτε μέρος ενός συστήματος που, εάν αποτύχει, θα προκαλέσει τη διακοπή της λειτουργίας ολόκληρου του συστήματος. Η εξάλειψη των SPOF σε όλα τα επίπεδα είναι ζωτικής σημασίας για κάθε σύστημα που απαιτεί υψηλή διαθεσιμότητα. Τα πάντα, συμπεριλαμβανομένων των γνώσεων, του προσωπικού, των στοιχείων συστήματος, των παρόχων cloud και των καλωδίων Διαδικτύου, μπορεί να αποτύχουν. Υπάρχουν πολλές βασικές τεχνικές που θα μπορούσαμε να εφαρμόσουμε για την εξάλειψη μεμονωμένων σημείων αστοχίας: Εφαρμογή πλεονασμού για κρίσιμα στοιχεία. Αυτό σημαίνει ότι υπάρχουν εφεδρικά στοιχεία που μπορούν να αναλάβουν τη διαχείριση εάν το κύριο στοιχείο αποτύχει. Ο πλεονασμός μπορεί να εφαρμοστεί σε διαφορετικά επίπεδα του συστήματος, συμπεριλαμβανομένου υλικού (διακομιστές, δίσκοι), δικτύωσης (συνδέσεις, μεταγωγείς) και λογισμικού (βάσεις δεδομένων, διακομιστές εφαρμογών). Εάν φιλοξενείτε τα πάντα σε έναν πάροχο Cloud και έχετε ακόμη και αντίγραφα ασφαλείας εκεί, σκεφτείτε να δημιουργήσετε ένα κανονικό πρόσθετο αντίγραφο ασφαλείας σε έναν άλλο για να μειώσετε το χαμένο κόστος σας σε περίπτωση καταστροφής. Πλεονασμός. Διανείμετε το σύστημά σας σε πολλές φυσικές τοποθεσίες, όπως κέντρα δεδομένων ή περιοχές cloud. Αυτή η προσέγγιση προστατεύει το σύστημά σας από βλάβες που αφορούν συγκεκριμένες τοποθεσίες, όπως διακοπές ρεύματος ή φυσικές καταστροφές. Κέντρα Δεδομένων. Εφαρμόστε μια προσέγγιση failover για όλα τα στοιχεία σας (DNS, CDN, Load balancers, Kubernetes, API Gateways και Databases). Δεδομένου ότι τα ζητήματα μπορεί να προκύψουν απροσδόκητα, είναι σημαντικό να έχετε ένα εφεδρικό σχέδιο για να αντικαταστήσετε οποιοδήποτε στοιχείο με τον κλώνό του, όπως απαιτείται, γρήγορα. Failover. Βεβαιωθείτε ότι οι υπηρεσίες σας έχουν κατασκευαστεί για να είναι οριζόντια κλιμακωτές και εξαιρετικά διαθέσιμες από την αρχή, τηρώντας τις ακόλουθες αρχές: Υπηρεσίες υψηλής διαθεσιμότητας. Εξασκηθείτε στην ανιθαγένεια της υπηρεσίας και αποφύγετε την αποθήκευση περιόδων σύνδεσης χρήστη σε κρυφές μνήμες στη μνήμη. Αντίθετα, χρησιμοποιήστε ένα κατανεμημένο σύστημα κρυφής μνήμης, όπως το Redis. Αποφύγετε να βασίζεστε στη χρονολογική σειρά κατανάλωσης μηνυμάτων κατά την ανάπτυξη λογικής. Ελαχιστοποιήστε τις αλλαγές για την αποτροπή της διακοπής των καταναλωτών API. Όπου είναι δυνατόν, επιλέξτε αλλαγές συμβατές με τα πίσω. Επίσης, λάβετε υπόψη το κόστος, καθώς μερικές φορές, η εφαρμογή μιας αλλαγής μπορεί να είναι πιο οικονομική. Ενσωματώστε την εκτέλεση μετεγκατάστασης στον αγωγό ανάπτυξης. Καθιερώστε μια στρατηγική για τον χειρισμό ταυτόχρονων αιτημάτων. Εφαρμόστε την ανακάλυψη, την παρακολούθηση και την καταγραφή υπηρεσιών για να βελτιώσετε την αξιοπιστία και την παρατηρησιμότητα. Αναπτύξτε την επιχειρηματική λογική για να είστε ανίκανοι, αναγνωρίζοντας ότι οι αστοχίες δικτύου είναι αναπόφευκτες. Ελέγχετε τακτικά και ελαχιστοποιείτε τις εξωτερικές εξαρτήσεις. Κάθε εξωτερική εξάρτηση μπορεί να εισάγει πιθανά SPOF, επομένως είναι σημαντικό να κατανοήσουμε και να μετριάζουμε αυτούς τους κινδύνους. Έλεγχος εξάρτησης. Μην ξεχνάτε ποτέ τη σημασία της διάδοσης της γνώσης μέσα στον οργανισμό σας. Οι άνθρωποι μπορεί να είναι απρόβλεπτοι και το να βασίζεσαι σε ένα μόνο άτομο είναι επικίνδυνο. Ενθαρρύνετε τα μέλη της ομάδας να ψηφιοποιήσουν τις γνώσεις τους μέσω της τεκμηρίωσης. Ωστόσο, προσέξτε την υπερβολική τεκμηρίωση. Χρησιμοποιήστε διάφορα εργαλεία AI για να απλοποιήσετε αυτή τη διαδικασία. Τακτική ανταλλαγή γνώσεων. Σύναψη Σε αυτό το άρθρο, καλύψαμε πολλές βασικές πτυχές και πώς μπορούμε να αντιμετωπίσουμε την πολυπλοκότητά τους. μακροεντολών Σας ευχαριστούμε που διαβάσατε! Τα λέμε την επόμενη φορά!