NatusAI
Η συζήτηση «μονολιθική εφαρμογή ή microservices» συχνά ξεκινά από το διάγραμμα εγκατάστασης. Ένα κουτί ή πολλά; Όμως το πιο χρήσιμο ερώτημα έρχεται νωρίτερα: ποια πολυπλοκότητα πρέπει να αναλάβει η ομάδα σας και ποια πρέπει να διαχειρίζεται η πλατφόρμα;
Μια μικρή ομάδα χρειάζεται ένα σαφές μοντέλο και μια σύντομη διαδρομή από την ιδέα σε μια εφαρμογή που λειτουργεί. Ένας οργανισμός που μεγαλώνει χρειάζεται επιπλέον χωρητικότητα, ανθεκτικότητα και χώρο ώστε οι ομάδες να δουλεύουν ανεξάρτητα. Οι ανάγκες αυτές σχετίζονται, αλλά δεν είναι ίδιες.
Το Cygnus εξετάζει μια διαφορετική ισορροπία: η λογική της εφαρμογής και τα δεδομένα μένουν σε ένα λογικό μοντέλο, και εξελίσσεται ο τρόπος με τον οποίο το μοντέλο αυτό τοποθετείται και εκτελείται. Στόχος είναι να μειωθεί η εργασία ενοποίησης που οι developers χτίζουν ξανά και ξανά γύρω από χωριστές βάσεις δεδομένων, υπηρεσίες και εργαλεία τεχνητής νοημοσύνης.
01 / Η επιλογή αρχιτεκτονικής
Μονολιθικές εφαρμογές και microservices λύνουν διαφορετικά προβλήματα.
Μια μονολιθική εφαρμογή πακετάρει την εφαρμογή ως μία μονάδα εγκατάστασης. Μπορεί να είναι αρθρωτή, προσεκτικά δοκιμασμένη και αναπαραγόμενη πίσω από έναν εξισορροπητή φορτίου. Το πλεονέκτημά της είναι πρακτικό: τοπικές κλήσεις, απλή αποσφαλμάτωση και λιγότερα κινούμενα μέρη. Οι περιορισμοί της συχνά εμφανίζονται γύρω από κοινές εκδόσεις, όρια ευθύνης ή άνισες ανάγκες πόρων.
Τα microservices χωρίζουν μια εφαρμογή σε υπηρεσίες που εγκαθίστανται ανεξάρτητα. Είναι χρήσιμα όταν πεδία και ομάδες χρειάζονται δικούς τους κύκλους εκδόσεων, πολιτικές κλιμάκωσης ή λειτουργικά όρια. Αυτή η ανεξαρτησία έχει κόστος: κλήσεις δικτύου, συμβόλαια με εκδόσεις, παρατηρησιμότητα, χειρισμό αστοχιών και συχνά συνέπεια μεταξύ χωριστών αποθετηρίων δεδομένων.
Καμία από τις δύο δεν είναι αυτόματα ταχύτερη ή πιο κλιμακώσιμη. Μια καλά σχεδιασμένη μονολιθική εφαρμογή μπορεί να εξυπηρετεί μεγάλο φόρτο εργασίας. Ένα κακώς διαμερισμένο σύστημα microservices μπορεί να διασκορπίσει τα σημεία συμφόρησης και να τα κάνει δυσκολότερο να εντοπιστούν.
Μονολιθική εφαρμογή
Μία εγκατάσταση. Τα εσωτερικά όρια εξαρτώνται από τον σχεδιασμό του κώδικα.
Microservices
Ανεξάρτητες υπηρεσίες και ευθύνη. Συμβόλαια δικτύου συνδέουν τα μέρη.
Σχεδιασμός Cygnus
Ένα ενιαίο μοντέλο ανάπτυξης. Η κατανεμημένη εγκατάσταση είναι κατεύθυνση πέρα από τη v1.
Η διάκριση έχει σημασία, επειδή η κατανομή της εγκατάστασης και η αρθρωτότητα της επιχειρησιακής λογικής είναι χωριστές αποφάσεις. Μπορείτε να έχετε modules χωρίς χωριστές υπηρεσίες· μπορείτε να έχετε πολλούς διακομιστές χωρίς να κατακερματίσετε το λογικό μοντέλο της εφαρμογής.
02 / Ένα λογικό μοντέλο
Η βάση δεδομένων και το backend πιο κοντά.
Το Cygnus είναι το σχεδιαζόμενο θεμέλιο γλώσσας, βάσης δεδομένων και backend της NatusAI. Ο σχεδιασμός φέρνει την τυποποιημένη λογική εφαρμογής, τα μόνιμα δεδομένα και τις εκτεθειμένες συναρτήσεις σε ένα συνεκτικό περιβάλλον. Αντί να συντηρούν χωριστή αντιστοίχιση σε κάθε όριο, οι developers δουλεύουν με συνδεδεμένα αντικείμενα και τις συναρτήσεις που ενεργούν πάνω τους.
Αυτό έχει ιδιαίτερη σημασία για ένα ψηφιακό δίδυμο ή μια επιχειρησιακή εφαρμογή. Ένα πλοίο, ένα κτίριο ή ένας βιομηχανικός εξοπλισμός έχει ταυτότητα, σχέσεις, τοποθεσία, μετρήσεις, έγγραφα και ιστορικό. Αν κάθε οπτική χωριστεί σε ένα άσχετο σύστημα, πρέπει να ξαναχτιστούν συνδέσεις που ήδη υπάρχουν στην επιχείρηση.
Ένα ενιαίο μοντέλο επιδιώκει να διατηρήσει αυτές τις συνδέσεις. Δίνει επίσης στο runtime περισσότερες πληροφορίες για τα δεδομένα, τα ερωτήματα και την εκτέλεση, πληροφορίες που μπορούν να υποστηρίξουν μελλοντικές αποφάσεις τοποθέτησης και συντονισμού.
Ένα μοντέλο για την εφαρμογή.
Περισσότερες επιλογές για το πού εκτελείται.
Πρόκειται για αρχή σχεδιασμού, όχι για υπόσχεση ότι κάθε φόρτος εργασίας κλιμακώνεται διαφανώς. Τα κλειδιά διαμερισμού, τα μοτίβα ερωτημάτων, τα όρια συναλλαγών και η καθυστέρηση εξακολουθούν να επηρεάζουν τον τρόπο με τον οποίο πρέπει να χτιστεί μια εφαρμογή.
03 / Τέσσερις τρόποι ανάπτυξης
Αιτήματα και δεδομένα κλιμακώνονται ως διαφορετικές ανάγκες.
Το «χρειαζόμαστε κλιμάκωση» μπορεί να σημαίνει περισσότερα ταυτόχρονα αιτήματα, μεγαλύτερο σύνολο δεδομένων, καλύτερη διαθεσιμότητα ή και τα τρία. Η αναπαραγωγή (replication) και το sharding αντιμετωπίζουν διαφορετικά μέρη του προβλήματος. Η παρακάτω διαδραστική απεικόνιση δείχνει την κατεύθυνση κατανεμημένου σχεδιασμού του Cygnus· δεν είναι ζωντανό cluster ούτε λειτουργία εγκατάστασης που έχει κυκλοφορήσει.
01 · Ένας κόμβος
Ξεκινήστε με μία συνεκτική εφαρμογή
Η λογική της εφαρμογής και ολόκληρο το σύνολο δεδομένων βρίσκονται μαζί σε έναν διακομιστή. Αυτό είναι το εύρος του σχεδιαζόμενου προφίλ εγκατάστασης του Cygnus v1.
Το απλούστερο μοντέλο λειτουργίας. Η χωρητικότητα και η διαθεσιμότητα εξαρτώνται από έναν διακομιστή και τις διαδικασίες ανάκτησής του.
02 · Αντίγραφα (replicas)
Αντιγράψτε το μοντέλο σε πολλούς κόμβους
Στην κατεύθυνση κατανεμημένου σχεδιασμού, οι κόμβοι φέρουν τον ίδιο κώδικα εφαρμογής και πλήρες αντίγραφο των δεδομένων. Η αναπαραγωγή μπορεί να υποστηρίξει πλεονασμό και πρόσθετη ικανότητα εξυπηρέτησης αιτημάτων, ανάλογα με το μοντέλο συνέπειας και δρομολόγησης εγγραφών.
Τα αντίγραφα πρέπει να συντονίζουν τις ενημερώσεις. Περισσότερα αντίγραφα δεν πολλαπλασιάζουν αυτόματα τη ρυθμαπόδοση εγγραφών.
03 · Shards
Μοιράστε τα δεδομένα, κρατήστε το μοντέλο
Ο κώδικας της εφαρμογής παραμένει κοινός, ενώ κάθε κόμβος έχει την ευθύνη ενός διαμερίσματος των δεδομένων. Η τοποθέτηση θα μπορούσε να ακολουθεί γεωγραφία, χρονικά διαστήματα ή εύρη κλειδιών, ανάλογα με τον φόρτο εργασίας.
Η δρομολόγηση και τα ερωτήματα μεταξύ διαμερισμάτων χρειάζονται ρητούς κανόνες. Άνισα δεδομένα ή μοτίβα πρόσβασης μπορεί να δημιουργήσουν σημεία υπερφόρτωσης (hot spots).
04 · Και τα δύο
Αναπαράγετε κάθε διαμέρισμα
Συνδυάστε χωρητικότητα σε πολλά shards με πλεονασμό μέσα σε κάθε shard. Η επιδιωκόμενη εμπειρία για τους developers παραμένει μία λογική βάση δεδομένων και ένα backend, ενώ το runtime χειρίζεται μια πιο σύνθετη φυσική τοπολογία.
Η τοποθέτηση αντιγράφων, η εφεδρεία (failover), η επανεξισορρόπηση και οι κατανεμημένες συναλλαγές απαιτούν επικύρωση. Πρόκειται για κατεύθυνση σχεδιασμού πέρα από τη v1.
πλήρες αντίγραφο των δεδομένων ένα διαμέρισμα των δεδομένων · Μόνο απεικόνιση: όχι ζωντανό cluster ούτε λειτουργία εγκατάστασης που έχει κυκλοφορήσει.
Ξεκινήστε σε έναν κόμβο
Το σχεδιαζόμενο προφίλ της v1 ξεκινά με έναν διακομιστή. Ο κώδικας της εφαρμογής και τα δεδομένα βρίσκονται μαζί, ώστε η πρώτη εγκατάσταση να παραμένει προσιτή. Αντίγραφα ασφαλείας, ανάκτηση, δικαιώματα και όρια πόρων παραμένουν μέρος της υπεύθυνης λειτουργίας της.
Αναπαραγωγή για πλεονασμό και ικανότητα αιτημάτων
Στο μελλοντικό κατανεμημένο μοντέλο, πολλοί κόμβοι θα μπορούσαν να φέρουν τον ίδιο κώδικα και πλήρες αντίγραφο του συνόλου δεδομένων. Αυτό μπορεί να δημιουργήσει περισσότερα σημεία εξυπηρέτησης κατάλληλων αιτημάτων και να επιτρέψει στο σύστημα να αντέχει ορισμένες αστοχίες κόμβων. Το αποτέλεσμα εξαρτάται από τη δρομολόγηση, την υστέρηση αναπαραγωγής, τις εγγυήσεις συνέπειας και το ποιες λειτουργίες μπορούν να εκτελεστούν σε ποια αντίγραφα.
Sharding για χωρητικότητα δεδομένων
Όταν το σύνολο δεδομένων ξεπερνά έναν διακομιστή, η προσθήκη πλήρων αντιγράφων δεν λύνει τον περιορισμό αποθήκευσης. Το sharding μοιράζει τα δεδομένα σε κόμβους. Ένας φόρτος εργασίας μπορεί να διαμεριστεί κατά γεωγραφία, χρονικό διάστημα ή εύρος κλειδιών. Τα ερωτήματα που διασχίζουν αυτά τα διαμερίσματα χρειάζονται δρομολόγηση και, μερικές φορές, κατανεμημένη εκτέλεση.
Μια απλή απεικόνιση χωρητικότητας: 30 TB λογικών δεδομένων χρειάζονται τουλάχιστον οκτώ διακομιστές των 4 TB, πριν από αντίγραφα, ευρετήρια, λειτουργικό περιθώριο ή άλλη επιβάρυνση. Πρόκειται για αριθμητική, όχι για μέτρηση χωρητικότητας του Cygnus.
Συνδυάστε τα δύο
Κάθε shard μπορεί να έχει τα δικά του αντίγραφα. Τα shards παρέχουν συνολική χωρητικότητα δεδομένων· τα αντίγραφα προσθέτουν πλεονασμό και δυνατότητες εξυπηρέτησης αιτημάτων. Αυτή η συνδυασμένη τοπολογία είναι συχνά αυτό που φαντάζεται κανείς όταν σκέφτεται μια βάση δεδομένων κατανεμημένη σε έναν στόλο διακομιστών.
Επέκταση και συρρίκνωση ανάλογα με τη ζήτηση
Η μακροπρόθεσμη κατεύθυνση είναι να αυτοματοποιηθούν αυτές οι επιλογές γύρω από πολιτικές φόρτου εργασίας: προσθήκη χωρητικότητας όταν η ζήτηση αυξάνεται, μετακίνηση της εκτέλεσης μαζί με τα δεδομένα που χρειάζεται και αποδέσμευση χωρητικότητας όταν η ζήτηση πέφτει. Στόχος είναι να διατηρείται το λογικό μοντέλο της εφαρμογής καθώς αλλάζει η τοποθέτηση.
Η συρρίκνωση πρέπει πρώτα να ολοκληρώσει την εργασία σε εξέλιξη και να μετακινήσει ή να διατηρήσει με ασφάλεια τα απαιτούμενα αντίγραφα δεδομένων. Ο χρονοπρογραμματισμός, η επανεξισορρόπηση, η συνέπεια και η ανάκτηση χρειάζονται ρητούς κανόνες και επικύρωση. Η αυτόματη οριζόντια επέκταση και συρρίκνωση είναι μελλοντικοί στόχοι σχεδιασμού cluster, εκτός της σχεδιαζόμενης v1 ενός διακομιστή.
04 / Η ευθύνη του runtime
Ο συντονισμός περνά στην πλατφόρμα.
Η επιδιωκόμενη εμπειρία του Cygnus διατηρεί έναν κώδικα εφαρμογής και μία λογική βάση δεδομένων καθώς εξελίσσεται η εγκατάσταση. Η κατανομή υπό τη διαχείριση του runtime θα αναλάμβανε την τοποθέτηση, τη δρομολόγηση, την αναπαραγωγή και τους μηχανισμούς συντονισμού των κόμβων που συμμετέχουν.
Οι μηχανισμοί αυτοί δεν εξαφανίζονται. Τα δίκτυα εισάγουν καθυστέρηση και διαμερισμούς. Οι ενημερώσεις χρειάζονται κανόνες συνέπειας. Οι συναλλαγές που εκτείνονται σε πολλά shards χρειάζονται καθορισμένο πρωτόκολλο. Η ανάκτηση πρέπει να γνωρίζει τι έχει γίνει commit, και η επανεξισορρόπηση πρέπει να αποφεύγει την απώλεια ευθύνης για δεδομένα ενώ αυτά μετακινούνται.
Η ευκαιρία είναι να υλοποιηθούν αυτές οι αρμοδιότητες μία φορά στην πλατφόρμα, με ρητά συμβόλαια και εργαλεία λειτουργίας, αντί κάθε εφαρμογή να συναρμολογεί τη δική της εκδοχή. Η εφαρμογή εξακολουθεί να χρειάζεται όρια που ταιριάζουν στον φόρτο εργασίας της.
05 / Τα δεδομένα στον χρόνο
Ένα συνδεδεμένο μοντέλο χρειάζεται μνήμη.
Πολλά επιχειρηματικά ερωτήματα περιέχουν μια χρονική διάσταση, ακόμη κι όταν κανείς δεν τη λέει φωναχτά. Πού βρισκόταν αυτός ο εξοπλισμός πριν από ένα συμβάν; Ποιος οργανισμός τον έλεγχε τότε; Τι γνώριζε το σύστημα όταν έκανε εκείνη τη σύσταση;
Ο σχεδιασμός του Cygnus συνδέει σχέσεις γράφου, γεωχωρικά δεδομένα, διανύσματα, triples, χρονοσειρές και αναζήτηση πλήρους κειμένου μέσα στο ίδιο λογικό θεμέλιο. Πρόκειται για τρόπους εξερεύνησης ενός αντικειμένου, όχι για χωριστούς ορισμούς του τι είναι αυτό το αντικείμενο.
- Γράφος και triples
Τι συνδέεται, και πώς;
- Γεωχωρικά
Πού βρισκόταν μια δεδομένη στιγμή;
- Χρονοσειρές
Πώς εξελίχθηκαν οι μετρήσεις του;
- Πλήρες κείμενο και διανύσματα
Ποιες εγγραφές ταιριάζουν ή έχουν παρόμοιο νόημα;
Εννοιολογικό μοντέλο. Οι ιστορικές απαντήσεις χρειάζονται επίσης διατηρημένες εκδόσεις πηγών και καταγεγραμμένη προέλευση ανάκτησης, μοντέλου και prompt.
Ιστορικό για τα δεδομένα, προέλευση για την τεχνητή νοημοσύνη
Τα χρονικά δεδομένα μπορούν να περιγράψουν πώς αλλάζουν ένα περιουσιακό στοιχείο, οι μετρήσεις του ή οι σχέσεις του. Μια ιστορική απάντηση τεχνητής νοημοσύνης απαιτεί περισσότερα. Εξαρτάται επίσης από τα έγγραφα πηγής, τα embeddings, τη διαμόρφωση ανάκτησης, την έκδοση του μοντέλου και το prompt που χρησιμοποιήθηκαν για να παραχθεί.
Η διατήρηση του ιστορικού δεδομένων δεν διατηρεί αυτόματα κάθε ευρετήριο διανυσμάτων ούτε αναπαράγει μια παλαιότερη απόκριση μοντέλου. Ένας χρήσιμος σχεδιασμός συνδέει συνειδητά αυτές τις εκδόσεις και καταγράφει την προέλευσή τους, ώστε μια απάντηση να παραπέμπει στα τεκμήρια και στο πλαίσιο που τη στήριξαν.
Ένα θεμέλιο για εφαρμογές και εργαλεία
Οι σχεδιαζόμενες εγγενείς δυνατότητες MCP και συνομιλίας παρέχουν τρόπους να εκτίθενται επιτρεπόμενες συναρτήσεις και να υποβάλλονται ερωτήματα στη συνδεδεμένη γνώση. Ένα εργαλείο ή μια διεπαφή συνομιλίας πρέπει να λειτουργεί με το ίδιο μοντέλο και την ίδια πολιτική πρόσβασης με την εφαρμογή. Ένα ιστορικό ερώτημα μπορεί τότε να αφορά μια επιλεγμένη χρονική στιγμή, εξηγώντας ποια τεκμήρια και ποια διαμόρφωση AI είναι διαθέσιμα για τη συγκεκριμένη απάντηση.
Εδώ ένα ενιαίο backend γίνεται κάτι περισσότερο από μια απλούστερη ιστορία εγκατάστασης: μπορεί να προσφέρει ένα κοινό θεμέλιο για επιχειρησιακά δεδομένα, επιχειρηματικό ιστορικό και εργασία με υποστήριξη τεχνητής νοημοσύνης.
06 / Επιλογή των ορίων
Η αρχιτεκτονική ευθυγραμμισμένη με τη δουλειά.
Τα microservices παραμένουν χρήσιμα όταν τα δικαιολογούν ανεξάρτητες ομάδες, διακριτά όρια ασφάλειας ή διαφορετικές απαιτήσεις λειτουργίας. Μια αρθρωτή μονολιθική εφαρμογή παραμένει χρήσιμη όταν μια κοινή εγκατάσταση κρατά την ομάδα παραγωγική. Η κατεύθυνση του Cygnus προσθέτει μια ακόμη επιλογή: ένα ενιαίο μοντέλο εφαρμογής και δεδομένων, με την κατανομή να διαχειρίζεται βαθύτερα μέσα στο runtime.
Η σωστή επιλογή ξεκινά από τον φόρτο εργασίας. Ποια αιτήματα κυριαρχούν; Πόσο γρήγορα πρέπει να γίνονται ορατές οι ενημερώσεις; Ποια δεδομένα ανήκουν μαζί; Τι συμβαίνει σε μια αστοχία δικτύου; Ποιες αρμοδιότητες χρειάζονται ανεξάρτητη ευθύνη;
Φιλοδοξία μας είναι να επιτρέψουμε στους developers να αφιερώνουν περισσότερο χρόνο σε αυτές τις ουσιαστικές αποφάσεις και λιγότερο στο να ξαναχτίζουν τις συνδέσεις ανάμεσα στα εργαλεία τους. Ξεκινήστε με ένα συνεκτικό μοντέλο. Διατηρήστε ακέραιες τις επιχειρησιακές σχέσεις. Επεκτείνετε τη φυσική εγκατάσταση όταν ο φόρτος εργασίας και η πλατφόρμα είναι έτοιμα.
Περαιτέρω ανάγνωση
- Martin Fowler: Monolith First (εξωτερικός ιστότοπος) — πώς μπορεί να εξελίσσεται η αρχιτεκτονική καθώς κατανοούνται καλύτερα τα όρια των πεδίων.
- PostgreSQL: Warm Standby (εξωτερικός ιστότοπος) — ένα παράδειγμα αναπαραγωγής, λειτουργίας εφεδρείας (standby) και των συμβιβασμών μεταξύ σύγχρονων και ασύγχρονων ενημερώσεων.
- Το μοτίβο sharding στο Microsoft Azure Architecture Center (εξωτερικός ιστότοπος) — κλειδιά διαμερισμού, δρομολόγηση και ζητήματα κατανομής δεδομένων.
- Εύρος του Cygnus v1 και μεταγενέστερα προφίλ — το δημόσιο εύρος και η κατάσταση πίσω από αυτή την οπτική σχεδιασμού.